一群來自德國大學的研究人員 結果 在此期間，使用不同的編程語言開發了 10 Gb Intel Ixgbe (X10xx) 網卡典型驅動程序的 5 個變體。 該驅動程序在用戶空間中運行，並使用 C、Rust、Go、C#、Java、OCaml、Haskell、Swift、JavaScript 和 Python 實現。 編寫代碼時，重點是實現盡可能高的性能，同時考慮到每種語言的特性。 就功能而言，所有選項都是相同的，並且由大約 1000 行代碼組成。 項目成果 在 BSD 許可證下。
Rust 版本的驅動程序在性能上與參考 C 驅動程序非常接近。 在單次發送 32 個數據包塊的負載下，Rust 驅動程序有點滯後，但在每個塊超過 32 個數據包的測試中，它的速度實際上與 C 驅動程序沒有差異，並且在處理級別上展示了性能在配備 Xeon CPU E28-3 v1230 2 GHz 的服務器上每秒處理 3.3 萬個數據包。
就性能而言，下一個利基市場是 Go 和 C# 驅動程序，它們顯示出相當接近的結果（Go 驅動程序在包含最多 16 個包的塊的測試中獲勝，並且在包含超過 16 個包的測試中開始略有下降）堵塞）。 每個塊有 256 個數據包，C# 驅動程序的峰值性能約為 28Mpps，而 Go 驅動程序的峰值性能約為 25Mpps。
接下來，結果相當接近，其次是驅動程序
Java、OCaml 和 Haskell 已經明顯落後於之前考慮的選項，無法克服每秒 12 萬個數據包的障礙。 基於 Swift 和 JavaScript 的驅動程序表現出更大的積壓，能夠以每秒 5 萬個數據包的水平處理流。
Python語言的驅動程序關閉了評級，每秒只能處理0.14萬個數據包。 Python 實現用於評估沒有 JIT 且沒有特定優化的解釋器的速度（代碼使用 CPython 3.7 運行，與 PyPy 不兼容，但值得注意的是，優化數據結構可以將性能提高約 10 倍）。
此外，還進行了延遲測試，顯示了緩衝的有效性和垃圾收集器的影響。 該測試測量了驅動程序重定向每個數據包後的延遲，並與已知的發送時間進行比較。 領先者仍然是 C 和 Rust 驅動程序，對於每秒 1 萬個數據包（約 20 µs）的流量，其結果幾乎無法區分。 Go語言的驅動表現不錯，僅略微落後於領先者，也保持在20 µs的水平。 C# 驅動程序顯示大約 50 µs 的延遲。
基於 JavaScript 和 Java 的驅動程序顯示出最大的延遲（延遲超過 300 µs）。
進行這項研究的目的是評估用比 C 更高級別的語言開發驅動程序和操作系統組件的可能性。 目前，39 個 Linux 內存問題中有 40 個與驅動程序相關，因此採用更安全的語言並將驅動程序從內核移出到用戶空間的問題 並且製造商已經在這個方向上積極嘗試（例如Google已經為OS開發了TCP堆棧） 在 Go 中，CloudFlare 在 Rust 中實現 QUIC 協議時，Apple 將移動設備上的 TCP 堆棧移至用戶空間）。
在開展工作的過程中，得出的結論是 Rust 語言是驅動程序開發的最佳候選者。 Rust 提供的功能可以讓您擺脫由於低級內存處理而產生的問題，但與 C 語言驅動程序相比，代價是約 2%-10% 的性能損失。 Go 和 C# 還被發現適合在垃圾收集器造成的亞毫秒級延遲可以接受的情況下構建系統組件。
來源： opennet.ru