'n Groep navorsers van Duitse universiteite
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.
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).
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
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