雖然對於系統編程(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實現了下列這些優化:
垃圾回收
.NET中的垃圾回收已發展到第三代。一些數據程序分析師需要將自己過半的時間用於垃圾回收,而無法用在更有價值的工作中。
改善性能的方法之一是使用Struct,Struct可改善下列領域的性能問題:
關於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的文章。他的演講演示文稿也已經發布到網上。
查看英文原文:Systems Programming in C#