Un grup de cercetători din universitățile germane rezultate , timp în care au fost dezvoltate 10 versiuni ale unui driver standard pentru plăcile de rețea Intel Ixgbe (X10xx) de 5 gigabiti în diferite limbaje de programare. Driverul rulează în spațiul utilizatorului și este implementat în C, Rust, Go, C#, Java, OCaml, Haskell, Swift, JavaScript și Python. La scrierea codului, accentul principal a fost pe obținerea celor mai bune performanțe posibile, ținând cont de caracteristicile fiecărei limbi. Toate opțiunile sunt identice ca funcționalitate și constau din aproximativ 1000 de linii de cod. Dezvoltarea proiectelor sub licența BSD.
Versiunea Rust a driverului s-a dovedit a fi foarte apropiată ca performanță de driverul de referință în limbajul C. Sub o sarcină cu trimitere simultană a blocurilor de 32 de pachete, driverul Rust a fost ușor în urmă, dar în testele cu mai mult de 32 de pachete pe bloc, viteza nu a fost practic diferită de driverul C și a demonstrat performanță la nivelul de procesare a 28 de milioane. pachete pe secundă pe un server cu un procesor Xeon E3-1230 v2 3.3 GHz.
Următoarea nișă în ceea ce privește performanța a fost ocupată de șoferi în limbajele Go și C#, care au dat rezultate destul de apropiate (șoferul Go a câștigat la teste cu blocuri de până la 16 pachete și a început să piardă ușor în testele cu mai mult de 16 pachete într-un bloc). Cu 256 de pachete pe bloc, performanța maximă a driverului C# a fost de aproximativ 28 de milioane de pachete pe secundă, iar driverul Go a fost de aproximativ 25 de milioane de pachete pe secundă.
Urmează, cu rezultate destul de apropiate, șoferii pentru
Java, OCaml și Haskell, care erau deja vizibil în urma opțiunilor luate în considerare anterior și nu puteau depăși bara de 12 milioane de pachete pe secundă. Driverele Swift și JavaScript au prezentat un decalaj și mai mare, fiind capabili să proceseze fluxuri la nivelul de 5 milioane de pachete pe secundă.
Topul clasamentului a fost completat de driverul Python, care a putut procesa doar 0.14 milioane de pachete pe secundă. Implementarea Python a fost folosită pentru a evalua viteza interpreților fără JIT și fără optimizări specifice (codul a fost executat folosind CPython 3.7 și nu a fost compatibil cu PyPy, dar se observă că optimizarea structurilor de stocare a datelor ar putea îmbunătăți performanța de aproximativ 10 ori). ).
În plus, au fost efectuate teste de latență pentru a arăta eficiența tamponării și impactul colectorului de gunoi. Testarea a măsurat latența după ce fiecare pachet a fost transmis de șofer în comparație cu ora exactă la care a fost trimis. Liderii erau încă driverele C și Rust, ale căror rezultate erau practic imposibil de distins pentru un flux de 1 milion de pachete pe secundă (aproximativ 20 µs). Șoferul Go a evoluat bine, fiind doar puțin în urma liderilor și rămânând totodată la nivelul de 20 µs. Driverul C# a arătat întârzieri de aproximativ 50 µs.
Cele mai mari întârzieri au fost afișate de driverele JavaScript și Java (latențe de peste 300 µs).
Studiul a fost realizat pentru a evalua posibilitatea de a dezvolta drivere și componente ale sistemului de operare în limbaje de nivel superior decât C. În prezent, 39 din 40 de probleme de memorie în Linux sunt legate de drivere, așa că problemele legate de utilizarea unui limbaj mai sigur și mutarea driverelor din kernel în spațiul utilizatorului iar producătorii experimentează deja activ în această direcție (de exemplu, Google a dezvoltat o stivă TCP pentru sistemul de operare în limba Go, compania CloudFlare implementarea protocolului QUIC în Rust, Apple a mutat stiva TCP de pe dispozitivele mobile în spațiul utilizatorului).
În cursul lucrărilor, s-a ajuns la concluzia că limbajul Rust este cel mai bun candidat pentru dezvoltarea șoferilor. Capacitățile Rust elimină problemele asociate cu gestionarea memoriei de nivel scăzut cu un cost de aproximativ 2% până la 10% pierderi de performanță în comparație cu driverele C. Go și C# sunt, de asemenea, considerate potrivite pentru crearea componentelor de sistem în situațiile în care latența de sub milisecunde cauzată de colectarea gunoiului este acceptabilă.
Sursa: opennet.ru