Netwerkbestuurderprestasievergelyking in 10 programmeertale

'n Groep navorsers van Duitse universiteite gepubliseer bevindings eksperimenteer, waartydens 10 variante van 'n tipiese drywer vir 10-gigabit Intel Ixgbe (X5xx) netwerkkaarte in verskillende programmeertale ontwikkel is. Die bestuurder loop in gebruikersruimte en word geïmplementeer in C, Rust, Go, C#, Java, OCaml, Haskell, Swift, JavaScript en Python. By die skryf van die kode was die fokus op die bereiking van die hoogste moontlike prestasie, met inagneming van die kenmerke van elke taal. Wat funksionaliteit betref, is alle opsies identies en bestaan ​​uit ongeveer 1000 reëls kode. Projekprestasies versprei onder die BSD-lisensie.

Die Rust-weergawe van die drywer was baie na aan die verwysing C-bestuurder in prestasie. Met 'n vrag met 'n enkele versending van blokke van 32 pakkies, het die Rust-bestuurder 'n bietjie agtergebly, maar in toetse met meer as 32 pakkies per blok, het dit feitlik nie in spoed verskil van die C-bestuurder nie en het prestasie op die vlak van verwerking getoon 28 miljoen pakkies per sekonde op 'n bediener met 'n Xeon CPU E3-1230 v2 3.3 GHz.

Netwerkbestuurderprestasievergelyking in 10 programmeertale

Die volgende nis in terme van werkverrigting is beset deur Go- en C#-bestuurders, wat redelik goeie resultate getoon het (die Go-bestuurder het gewen in toetse met blokke wat tot 16 pakkette ingesluit het, en het effens begin verloor in toetse met meer as 16 pakkette in 'n blok). Met 256 pakkies per blok was die topprestasie vir die C#-bestuurder ongeveer 28Mpps, en vir die Go-bestuurders, ongeveer 25Mpps.

Volgende, met redelik naby resultate, gevolg deur bestuurders vir
Java, OCaml en Haskell, wat reeds merkbaar agter die opsies was wat voorheen oorweeg is en nie die staaf van 12 miljoen pakkies per sekonde kon oorkom nie. Bestuurders gebaseer op Swift en JavaScript het 'n selfs groter agterstand getoon, wat strome op die vlak van 5 miljoen pakkies per sekonde kon verwerk.

Die bestuurder in die Python-taal het die gradering gesluit, wat slegs 0.14 miljoen pakkies per sekonde kon verwerk. Die Python-implementering is gebruik om die spoed van tolke sonder JIT en sonder spesifieke optimaliserings te evalueer (die kode is met CPython 3.7 uitgevoer en was nie versoenbaar met PyPy nie, maar daar word opgemerk dat optimalisering van datastrukture werkverrigting met ongeveer 10 keer kan verbeter).

Boonop is latensietoetse uitgevoer, wat die doeltreffendheid van buffering en die impak van die vullisverwyderaar getoon het. Die toets het die latensie gemeet nadat elke pakkie deur die bestuurder herlei is, in vergelyking met 'n bekende stuurtyd. Die leiers was steeds die C- en Rust-drywers, waarvan die resultate byna ononderskeibaar was vir 'n vloei van 1 miljoen pakkies per sekonde (ongeveer 20 µs). Die bestuurder in die Go-taal het goed gevaar, wat net effens agter die voorlopers was en ook op die vlak van 20 µs gehou het. Die C#-bestuurder het vertragings van ongeveer 50 µs getoon.
Bestuurders gebaseer op JavaScript en Java het die grootste vertragings getoon (vertragings meer as 300 µs).

Netwerkbestuurderprestasievergelyking in 10 programmeertale

Die studie is uitgevoer om die moontlikheid te evalueer om drywers en bedryfstelselkomponente in tale van 'n hoër vlak as C te ontwikkel. Tans is 39 uit 40 Linux-geheueprobleme bestuurderverwant, dus die kwessies van die aanneming van 'n veiliger taal en die verskuiwing van bestuurders uit die kern en na gebruikersruimte relevant bly en vervaardigers eksperimenteer reeds aktief in hierdie rigting (Google het byvoorbeeld 'n TCP-stapel vir OS ontwikkel Fuchsia in Go, CloudFlare geskep implementering van die QUIC-protokol in Rust, het Apple die TCP-stapel op mobiele toestelle na gebruikersruimte geskuif).

In die loop van die werk wat uitgevoer is, is tot die gevolgtrekking gekom dat die Rust-taal die beste kandidaat vir bestuurderontwikkeling is. Die kenmerke wat deur Rust verskaf word, laat jou toe om ontslae te raak van die probleme wat ontstaan ​​as gevolg van lae-vlak geheue hantering, ten koste van 'n prestasie boete van ongeveer 2%-10% in vergelyking met C-taal bestuurders. Daar word ook gevind dat Go en C# geskik is vir die bou van stelselkomponente in situasies waar sub-millisekonde latensie wat deur die vullisverwyderaar veroorsaak word, aanvaarbaar is.

Bron: opennet.ru

Voeg 'n opmerking