Порівняння продуктивності мережного драйвера у варіантах 10 мовами програмування

Група дослідників із німецьких університетів опублікувала результати експерименту, в ході якого різними мовами програмування було розроблено 10 варіантів типового драйвера для 10-гігабітних мережевих карт Intel Ixgbe (X5xx). Драйвер працює у просторі користувача та реалізований мовами C, Rust, Go, C#, Java, OCaml, Haskell, Swift, JavaScript та Python. При написанні коду основна увага приділялася досягненню максимально можливої ​​продуктивності з урахуванням особливостей кожної мови. За функціональністю всі варіанти ідентичні і складаються з приблизно 1000 рядків коду. Напрацювання проекту поширюються під ліцензією BSD.

Варіант драйвера мовою Rust виявився дуже близьким за продуктивністю до еталонного драйвера мовою Сі. При навантаженні з одноразовим відправленням блоків по 32 пакети Rust-драйвер трохи відставав, але в тестах з більш ніж 32 пакетами в блоці за швидкістю практично не відрізнявся від драйвера на Сі і демонстрував продуктивність на рівні обробки 28 млн. пакетів в секунду на сервері з CPU Xeon E3-1230 v2 3.3 GHz.

Порівняння продуктивності мережного драйвера у варіантах 10 мовами програмування

Наступну нішу за продуктивністю зайняли драйвери мовами Go і С#, які показали досить близькі результати (драйвер на Go вигравав у тестах з блоками, що включають до 16 пакетів, і став трохи програвати в тестах з більш ніж 16 пакетами в блоці). При 256 пакетах в блоці пікова продуктивність при драйвері на C # склала приблизно 28 млн. пакетів в секунду, а драйвера на Go приблизно 25 млн. пакетів в секунду.

Далі з досить близькими результатами слідували драйвери на
Java, OCaml і Haskell, які вже помітно відставали від раніше розглянутих варіантів і не змогли подолати планку 12 млн пакетів на секунду. Ще більше відставання показали драйвери на Swift та JavaScript, які змогли обробити потоки на рівні 5 млн. пакетів в секунду.

Замкнув рейтинг драйвер мовою Python, який зміг обробити лише 0.14 млн пакетів на секунду. Реалізація на Python була використана для оцінки швидкості роботи інтерпретаторів без JIT і без специфічних оптимізації (код виконувався з використанням CPython 3.7 і не сумісний з PyPy, але зазначається, що оптимізація структур зберігання даних могла б підвищити продуктивність приблизно в 10 разів).

Додатково були проведені тести на час затримки, які показували ефективність буферизації та вплив збирача сміття. При тестуванні вимірювалася затримка після перенаправлення кожного пакета драйвером порівняно з відомим часом відправки. Лідерами, як і раніше, стали драйвери на Сі і Rust, результати яких були практично невідмінні для потоку в 1 млн пакетів в секунду (приблизно 20 µs). Добре виявив себе драйвер мовою Go, який лише трохи відстав від лідерів і також тримався на рівні 20 µs. Драйвер на C# показав затримки приблизно 50 µs.
Найбільші затримки показали драйвери JavaScript і Java (затримки більше 300 µs).

Порівняння продуктивності мережного драйвера у варіантах 10 мовами програмування

Дослідження проведено з метою оцінки можливості розробки драйверів та компонентів операційної системи мовами вищого рівня, ніж Сі. В даний час 39 з 40 проблем при роботі з пам'яттю в Linux припадають на драйвери, тому питання застосування безпечнішої мови та винесення драйверів з ядра в простір користувача залишаються актуальними та виробники вже активно експериментують у цьому напрямку (наприклад, Google розробив TCP-стек для ОС Фуксія мовою Go, компанія CloudFlare створила реалізацію протоколу QUIC мовою Rust, компанія Apple перенесла TCP-стек на мобільних пристроях в простір користувача).

У ході проведеної роботи зроблено висновок, що мова Rust є найкращим кандидатом для розробки драйверів. Надані в Rust можливості дозволяють позбавитися проблем, що виникають через низькорівневу роботу з пам'яттю, ціною зниження продуктивності приблизно на 2%-10% в порівнянні з драйверами мовою Сі. Мови Go і C# також визнані придатними для створення системних компонентів, у ситуаціях коли прийнятні затримки на рівні часток мілісекунд, спричинені застосуванням збирача сміття.

Джерело: opennet.ru

Додати коментар або відгук