雖然對于系統編程（System programming）的定義很模糊，不過可以將其描述為在比特、字節、指令，或CPU周期層面所進行的思考。系統編程這個概念也暗含了對性能和可靠性的需求。Microsoft技術總監Joe Duffy在QCon New York活動中介紹了使用C#進行系統編程的戰略，同時他還談到了這其中的一些陷阱以及緩解方法。

Joe的演講中很多內容來自一個名為Midori的研究項目。該項目意在使用C#從零開始打造一個操作系統，這也讓我們對編譯器的結構和有關高性能代碼的新戰略有了全新認識。

使用托管語言（Managed language）構建操作系統使得我們能夠在內存層面上運用C#中的安全功能。這樣做可以避免由于緩沖區溢出或格式字符串（Format string）弱點而針對內存進行的代碼注入攻擊，因為此時可以由運行時負責邊界檢查（Bound checking）和類型安全（Type safety）。

代碼的生成

代碼可以通過預先（Ahead of time，Aot）或即時（Just in time，Jit）的方式編譯。Jit的優勢在于編譯速度更快，但Aot可以獲得更好的機器代碼，因為編譯器可以對代碼執行更多優化。

原生語言編譯器實現的很多優化原本是托管語言所不具備的。一般原因通常在于，通過Jit編譯器實現這些優化通常可能需要極大的運算量或過于復雜。正是這些問題導致C#在緊密、高效的底層代碼生成方面口碑不佳。最近通過RyuJit實現了下列這些優化：

• Inlining（使用所調用函數的主體取代函數調用點）

• Flowgraph和Loop分析

• 靜態單一指派（SSA）和全局值編號

• 通用子表達式消元（Common subexpression elimination）

• 復制/常量傳播（Copy/constant propagation）

• 無用代碼刪除

• 范圍分析

• 非虛擬化（Devirtualization）

• 循環不變量代碼提升（Loop invariant code hoisting）

• SIMD和向量化

• 通用共享（Generic sharing）

• 堆棧分配（正在開發中）

垃圾回收

.NET中的垃圾回收已發展到第三代。一些數據程序分析師需要將自己過半的時間用于垃圾回收，而無法用在更有價值的工作中。

改善性能的方法之一是使用Struct，Struct可改善下列領域的性能問題：

• 降低GC壓力，因為Struct是針對堆棧分配的。

• 提高內存局部性（Memory locality），改善緩存命中率。

• 整體減少對內存的使用，避免32-64位應用程序中對象的8-16字節開銷。

關于Struct有個問題需要注意：在復制超出某一大小的Struct時可能導致Memcpy。為了優化性能，應確保Struct盡可能小，不要超過32/64字節。

C# 7的一些功能使得通過Struct進行底層優化的過程變得更容易。C# 7的元數組（Tuple）是Struct，而非老版本中的System.Tuple<>，后者現已成為對象。引用返回則是Struct的另一個特性，可以無需復制直接通過函數返回Struct。

錯誤處理

可恢復的錯誤總會存在例外，然而很多錯誤都是不可恢復的。諸如無效轉換、棧溢出以及空引用等錯誤實際上屬于Bug。但I/O故障和驗證錯誤是可以預見并從中恢復的。

這種錯誤恢復催生了Fail fast策略。Fail fast是一種包含在.NET中的機制，這種機制下諸如StackOverflow等例外可能會繞過異常處理程序導致進程崩潰。該策略使得查找此類錯誤的過程變得更簡單，因為此時例外已經無法被過度的通用異常處理程序所處理。Midori團隊發現他們的可恢復錯誤（例外）與Bug（Fail fast）已經達到了1:10的比例。

詳細信息請參閱Joe的博客，他在博客上寫了很多有關Midori的文章。他的演講演示文稿也已經發布到網上。

原文地址：http://www.infoq.com/cn/news/2016/07/systems-programming-qcon

---

.NET社區新聞，深度好文，微信中搜索dotNET跨平臺或掃描二維碼關注

總結

以上是生活随笔為你收集整理的使用C#进行系统编程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。