c++的性能, c#的產能？！魚和熊掌可以兼得，.NET NATIVE初窺

2019-11-17 03:12:35

字體：大中小

來源：轉載

供稿：網友

c++的性能, c#的產能？！魚和熊掌可以兼得，.NET NATIVE初窺

　　對于微軟開發者來說，每次BUILD大會都是值得期待的。這次也是驚喜滿滿，除了大眾矚目的WP8.1的發布還有一項會令開發者興奮的技術出現：.NET NATIVE。下面就來詳細了解一下其為何物。

[小九的學堂，致力于以平凡的語言描述不平凡的技術。如要轉載，請注明來源：小九的學堂。VEVb.com/xfuture]

.Net當初的出現是因為java讓人了解到計算機發展的今天，語言的產能重要性是高于性能的。于是微軟便出了CLR和.Net。JIT（運行時編譯）雖然消耗了性能，卻大大增加了產能。但是ObjectC又告訴了大家在平板和智能手機內存和存儲受限的情況下，機器碼編譯性能是多么重要，而且也省電，這也很重要不是嗎。

微軟W8出現是平板時代應運而生的，于是便出現了開發時的產能，運行時的性能的合體：.NET NATIVE。

　　.NET NATIVE目的是為了生產上的流水線產出的手工產品，易于開發，運行時精致。

.NET NATIVE之前被稱為PRoject N, 它可以把C#語言編譯成機器碼native code，使之可以像C++一樣運行。其實這樣講比較籠統，具體是在NATIVE里微軟重寫了.NET Framework，將程序所需要的framework里的元素加進去而其他的則不用，生成可以運行的機器碼，最終實現運行時本地機器碼，不用動態編譯，節省了內存和空間。

　　這其中有個誤區，很多人認為是.NET NATIVE把C#編譯成了C++，其實并不是，C++編譯器后端接受IL作為輸入，生成MDIL。

　　.NET NATIVE解決了很多.NET的問題，比如.NET運行時計算，是消耗內存和開銷更多電量，.NET NATIVE編譯時只有用到的才會靜態鏈接，其他部分就不要了，內存中放入的只有框架的一部分，所以內存占用很少，電量消耗也少，很適合平板等內存相比較小的設備。

　　.Net native也實現了云編譯，開發者提供.NET代碼，而消費者安裝的是自己設備可以使用的機器碼.

　　.Net native解決了.NET 版本管理的問題。開發中最常遇到這個東西.NET 低版本不支持，或者是要支持一些低版本機器，導致我們開發的環境一直是以低版本.net來進行的。.net native編譯成機器碼就不存在這種問題了。個人認為這個是其商業價值所在。

　　據官網，用native編譯的windows商店程序, 啟動速度加快60%,占用內存減少將近20%.

　　現在.net native支持windows store apps，暫時不支持其他的一些.net桌面程序，WPF等。但我們可以期待以后會出現全盤都支持的時代。私人認為WPF是難點，畢竟是用了GPU.

　　安卓也有類似的，4.4出現了ART。希望有ART開發經驗的來一起研究進行對比。http://www.pcpop.com/doc/0/967/967006.shtml

　　個人認為出現的有點略晚，XP已經下架了。現在基本都是.net 3.5及以上了。還是以觀后效吧。

運行時的截圖

：

安裝：首先需要update2.大概3G（比2013還要大）。安裝OK后。安裝.net native 下面有鏈接。

.net native preview支持windowsstore 所以建立一個windowsstore的app:

然后右鍵點擊windowsstore項目，點擊 enable .net native

會彈出一個說明界面：

之后點擊Run static native analysis 會出現This application is compatible with .net native code generation。

位置在release folder下：

　　假如還有問題，這個鏈接也許會解決您的疑惑：

　　http://msdn.microsoft.com/zh-cn/vstudio/dn642499.aspx

是否支持 F# 或 VB 或我最喜歡的語言？

此預覽版僅支持 C# 代碼，因為它是大多數應用商店應用使用的 .NET 語言。但在我們拓寬工作重點之后，毫無疑問，我們會支持所有 .NET 語言。

此產品是僅與性能有關，還是也允許生成針對 Win32/64 本機編譯并且不需要在目標計算機上安裝 .NET Framework 的 C# 代碼（舉例來說）？

沒錯：.NET Native 不僅僅與性能有關，而且與工作效率和一致的設備體驗有關。利用 .NET Native，您能夠使用托管語言編寫代碼并且能夠像往常一樣上載 MSIL 包。但是，應用將作為完全自包含的本機編譯代碼部署在最終用戶設備上（當 .NET Native 進入生產時），并且不依賴目標設備/計算機上的 .NET Framework。如您所知，.NET 應用程序的范圍很廣。因此，我們對完整的 .NET Framework 也進行了重大投入（例如，我們剛剛發布了 RyuJIT 的 CTP）。

設計此產品時考慮了哪些方案？

我們考慮過的方案是用于設備的應用商店應用 - 使開發人員能夠保持 .NET 和 MSIL 的工作效率優勢并且能夠將 MSIL 包上載到應用商店，為最終用戶提供性能類似的本機代碼 (C++)（與 Windows Phone 8 類似，在云中進行編譯）。

.NET Native 是否將取代 .NET Micro Framework 以及 C#/.NET 是否將完全可供小型設備使用？

.NET Native 當前的重點是 Windows 應用商店應用。Micro Framework 由 Windows Embedded 團隊交付，.NET 團隊與他們一起攜手為客戶提供最佳服務。

開發人員預覽版是否適用于創建 Windows Phone 應用和庫？

可以創建與 .NET Native 一起使用的通用類庫。在此預覽版中，僅 Windows 應用商店應用可使用 .NET Native 進行創建。正在實現使用 .NET Native 開發 Windows Phone 應用。

此產品能否提高 C# 開發人員開發高度圖形化的應用和/或游戲的體驗？

可以。.NET Native 編譯器與 Microsoft C++ 優化器共享部分基本代碼。

服務器/桌面應用是否將受益于 .NET Native 和/或云中的編譯器？

桌面應用是我們策略中的非常重要的部分。最初，我們的重心是 Windows 應用商店應用與 .NET Native。從長遠來看，我們將繼續改進所有 .NET 應用程序的本機編譯。

如何進行鏈接？框架代碼是否將編譯到應用程序中？這將如何影響包/二進制文件大小？

是的，框架代碼將編譯到應用程序中。對于包大小，由于大多數應用商店應用都有大量多媒體，因此差異不明顯。因此，代碼大小確實會發生變化；但是，僅會將應用使用的框架部分鏈接到應用中。最終結果是，使用 .NET Native 編譯的二進制文件將與執行 NGEN 的二進制文件處在相同的大小范圍中。我們仍將研究可進一步減少大小差異的策略。

使用 .NET Native 編譯比使用 MSIL 編譯慢。為什么？

常規應用開發使用 Visual Studio 中的標準 MSIL/JIT 開發體驗。只有在將應用部署到設備才會調用 .NET Native 編譯器，在大多數開發過程完成之后，重心將轉移到應用的優化上。此時，編譯時間與使用鏈接時間代碼生成優化的 C++ 的差不多。

P/Invoke 有什么變化？是否會將它們優化為標準 DLL 調用？

即使對二進制文件進行本機編譯，但我們保留了托管代碼類型安全性（以及垃圾回收）和完整 C# 異常模型的好處。利用 .NET Native，我們還極大地優化了互操作路徑 - 因此，盡管 P/Invoke 不會優化為標準 DLL 調用，但開銷極低，以便執行 GC 同步和任何必需的封送。

有什么限制？此產品是否支持開放的泛型和反射？

.NET Native 將在進入生產時支持目標平臺支持的所有功能。由于這是預覽版，很多功能正在開發中，因此目前有一些限制。話雖如此，此預覽版中支持開放的泛型和反射（是的，甚至支持靜態編譯！）。在此預覽版中，編譯器具有試圖弄清運行時需要的泛型實例化和元數據的內置啟發機制。因此，大量的應用有望直接運行，而不必簡化源代碼來獲得編譯器的好處。