Grupo de esploristoj el germanaj universitatoj la rezultoj , dum kiu 10 versioj de norma pelilo por 10-gigabit Intel Ixgbe (X5xx) retkartoj estis evoluigitaj en malsamaj programlingvoj. La ŝoforo funkcias en uzantspaco kaj estas efektivigita en C, Rust, Go, C#, Java, OCaml, Haskell, Swift, JavaScript kaj Python. Skribante kodon, la ĉefa fokuso estis atingi la plej bonan eblan agadon, konsiderante la karakterizaĵojn de ĉiu lingvo. Ĉiuj opcioj estas identaj laŭ funkcieco kaj konsistas el proksimume 1000 linioj de kodo. Projektaj evoluoj sub la permesilo BSD.
La Rust-versio de la ŝoforo montriĝis tre proksima en efikeco al la referenca ŝoforo en la C-lingvo. Sub ŝarĝo kun samtempa sendo de blokoj de 32 pakaĵoj, la Rust-ŝoforo estis iomete malantaŭe, sed en testoj kun pli ol 32 pakaĵetoj per bloko, la rapido praktike ne diferencis de la C-ŝoforo kaj montris agadon je la nivelo de prilaborado de 28 milionoj. pakaĵoj je sekundo sur servilo kun Xeon CPU E3-1230 v2 3.3 GHz.
La sekva niĉo laŭ rendimento estis okupita de ŝoforoj en la lingvoj Go kaj C#, kiuj montris sufiĉe proksimajn rezultojn (la ŝoforo Go venkis en testoj kun blokoj de ĝis 16 pakoj, kaj komencis iomete perdi en testoj kun pli ol 16 pakoj. en bloko). Kun 256 pakaĵetoj per bloko, la pinta rendimento de la C#-ŝoforo estis proksimume 28 milionoj da pakaĵetoj je sekundo, kaj la Go-ŝoforo estis proksimume 25 milionoj da pakaĵetoj je sekundo.
Poste, kun sufiĉe proksimaj rezultoj, estis la ŝoforoj por
Java, OCaml kaj Haskell, kiuj jam rimarkeble postrestis malantaŭ la antaŭe pripensitaj opcioj kaj ne povis venki la 12 milionojn da pakaĵoj por dua trinkejo. Swift kaj JavaScript-ŝoforoj montris eĉ pli grandan malfruon, povante prilabori fluojn je la nivelo de 5 milionoj da pakaĵoj sekundo.
La plej alta rango estis kompletigita de la ŝoforo Python, kiu povis prilabori nur 0.14 milionojn da pakaĵoj sekundo. La efektivigo de Python estis uzata por taksi la rapidecon de la interpretistoj sen JIT kaj sen specifaj optimumigoj (la kodo estis efektivigita uzante CPython 3.7 kaj ne estis kongrua kun PyPy, sed oni rimarkas, ke optimumigo de datumstokaj strukturoj povus plibonigi rendimenton je ĉirkaŭ 10 fojojn. ).
Plie, latentecaj testoj estis faritaj por montri la efikecon de bufrado kaj la efikon de la rubkolektanto. La testado mezuris la latentecon post kiam ĉiu pakaĵeto estis plusendita de la ŝoforo kompare kun la preciza tempo kiam ĝi estis sendita. La gvidantoj daŭre estis la C kaj Rust-ŝoforoj, kies rezultoj estis preskaŭ nedistingeblaj por fluo de 1 miliono da pakaĵetoj je sekundo (ĉirkaŭ 20 µs). La Go-ŝoforo funkciis bone, estante nur iomete malantaŭ la gvidantoj kaj ankaŭ restante sur la nivelo de 20 µs. La C#-ŝoforo montris prokrastojn de proksimume 50 µs.
La plej longajn prokrastojn montris JavaScript kaj Java-ŝoforoj (latentecoj de pli ol 300 µs).
La studo estis farita por taksi la eblecon evoluigi ŝoforojn kaj operaciumajn komponantojn en pli altnivelaj lingvoj ol C. Nuntempe, 39 el 40 memorproblemoj en Linukso rilatas al ŝoforoj, do la problemoj pri uzado de pli sekura lingvo kaj movi ŝoforojn el la kerno kaj en uzantspacon. kaj fabrikantoj jam aktive eksperimentas en ĉi tiu direkto (ekzemple, Google evoluigis TCP-stakon por la OS en la lingvo Go, kompanio CloudFlare efektivigo de la QUIC-protokolo en Rust, Apple movis la TCP-stakon sur porteblaj aparatoj en uzantspacon).
En la kurso de la laboro, estis konkludite ke la Rust-lingvo estas la plej bona kandidato por ŝoforevoluo. La kapabloj de Rust forigas la problemojn asociitajn kun malaltnivela memoradministrado je la kosto de proksimume 2% ĝis 10% rendimentperdo kompare kun C-ŝoforoj. Go kaj C# ankaŭ estas konsiderataj taŭgaj por krei sistemajn komponentojn en situacioj kie sub-milisekunda latenco kaŭzita de rubkolekto estas akceptebla.
fonto: opennet.ru