Um grupo de pesquisadores de universidades alemãs resultados , durante o qual foram desenvolvidas 10 versões de um driver padrão para placas de rede Intel Ixgbe (X10xx) de 5 gigabits em diferentes linguagens de programação. O driver é executado no espaço do usuário e é implementado em C, Rust, Go, C#, Java, OCaml, Haskell, Swift, JavaScript e Python. Na hora de escrever o código, o foco principal foi alcançar o melhor desempenho possível, levando em consideração as características de cada linguagem. Todas as opções são idênticas em funcionalidade e consistem em aproximadamente 1000 linhas de código. Desenvolvimentos de projetos sob a licença BSD.
A versão Rust do driver revelou ter desempenho muito próximo do driver de referência na linguagem C. Sob carga com envio simultâneo de blocos de 32 pacotes, o driver Rust ficou um pouco atrás, mas em testes com mais de 32 pacotes por bloco, a velocidade praticamente não foi diferente do driver C e demonstrou desempenho no nível de processamento de 28 milhões pacotes por segundo em um servidor com CPU Xeon E3-1230 v2 3.3 GHz.
O próximo nicho em termos de desempenho foi ocupado por drivers nas linguagens Go e C#, que apresentaram resultados bastante próximos (o driver Go venceu em testes com blocos de até 16 pacotes, e começou a perder um pouco em testes com mais de 16 pacotes em um bloco). Com 256 pacotes por bloco, o desempenho máximo do driver C# foi de aproximadamente 28 milhões de pacotes por segundo, e o driver Go foi de aproximadamente 25 milhões de pacotes por segundo.
Em seguida, com resultados bastante próximos, vieram os impulsionadores da
Java, OCaml e Haskell, que já estavam visivelmente atrás das opções consideradas anteriormente e não conseguiram superar a barra de 12 milhões de pacotes por segundo. Os drivers Swift e JavaScript apresentaram um atraso ainda maior, sendo capazes de processar fluxos no nível de 5 milhões de pacotes por segundo.
A classificação mais alta foi completada pelo driver Python, que foi capaz de processar apenas 0.14 milhão de pacotes por segundo. A implementação Python foi utilizada para avaliar a velocidade dos interpretadores sem JIT e sem otimizações específicas (o código foi executado utilizando CPython 3.7 e não era compatível com PyPy, mas nota-se que a otimização das estruturas de armazenamento de dados poderia melhorar o desempenho em cerca de 10 vezes ).
Além disso, foram realizados testes de latência para mostrar a eficácia do buffer e o impacto do coletor de lixo. O teste mediu a latência após cada pacote ser encaminhado pelo driver em comparação com o momento exato em que foi enviado. Os líderes ainda eram os drivers C e Rust, cujos resultados eram praticamente indistinguíveis para um fluxo de 1 milhão de pacotes por segundo (aproximadamente 20 µs). O driver Go teve um bom desempenho, ficando apenas um pouco atrás dos líderes e também permanecendo no nível de 20 µs. O driver C# apresentou atrasos de aproximadamente 50 µs.
Os atrasos mais longos foram mostrados pelos drivers JavaScript e Java (latências superiores a 300 µs).
O estudo foi realizado para avaliar a possibilidade de desenvolvimento de drivers e componentes de sistemas operacionais em linguagens de nível superior ao C. Atualmente, 39 dos 40 problemas de memória no Linux estão relacionados a drivers, portanto, os problemas de usar uma linguagem mais segura e mover drivers do kernel para o espaço do usuário e os fabricantes já estão experimentando ativamente nessa direção (por exemplo, o Google desenvolveu uma pilha TCP para o sistema operacional na linguagem Go, empresa CloudFlare implementação do protocolo QUIC em Rust, a Apple moveu a pilha TCP em dispositivos móveis para o espaço do usuário).
No decorrer do trabalho concluiu-se que a linguagem Rust é a melhor candidata para desenvolvimento de drivers. Os recursos do Rust eliminam os problemas associados ao gerenciamento de memória de baixo nível ao custo de aproximadamente 2% a 10% de perda de desempenho em comparação com os drivers C. Go e C# também são considerados adequados para a criação de componentes de sistema em situações em que a latência inferior a um milissegundo causada pela coleta de lixo é aceitável.
Fonte: opennet.ru