10 программалоо тилдериндеги версиялардагы тармак драйверинин иштешин салыштыруу

Германиянын университеттеринин изилдөөчүлөр тобу жарыяланган натыйжалары тажрыйба, анын жүрүшүндө 10 гигабиттик Intel Ixgbe (X10xx) тармак карталары үчүн стандарттуу драйвердин 5 версиясы түрдүү программалоо тилдеринде иштелип чыккан. Драйвер колдонуучу мейкиндигинде иштейт жана C, Rust, Go, C#, Java, OCaml, Haskell, Swift, JavaScript жана Python тилдеринде ишке ашырылат. Кодду жазууда ар бир тилдин өзгөчөлүгүн эске алуу менен эң жакшы көрсөткүчкө жетишүүгө негизги көңүл бурулган. Бардык опциялар функционалдык жагынан окшош жана болжол менен 1000 код саптарынан турат. Долбоордун иштеп чыгуулары жайылуу BSD лицензиясы боюнча.

Айдоочунун Rust версиясы C тилиндеги шилтеме драйверине аткаруу жагынан абдан жакын болуп чыкты. 32 пакеттик блокторду бир эле учурда жөнөтүү менен жүктүн астында Rust драйвери бир аз артта калды, бирок ар бир блокко 32 пакеттен ашык болгон сыноолордо ылдамдык C драйверинен дээрлик айырмаланбайт жана 28 миллион иштетүү деңгээлинде көрсөткүчтү көрсөттү. Xeon CPU E3-1230 v2 3.3 ГГц менен серверде секундасына пакеттер.

10 программалоо тилдериндеги версиялардагы тармак драйверинин иштешин салыштыруу

Өндүрүштүк жагынан кийинки орунду Go жана C# тилдериндеги драйверлер ээлешти, алар бир топ жакын натыйжаларды көрсөтүштү (Go драйвери 16 пакетке чейинки блоктордун тесттеринде жеңип, 16 пакеттен ашык тесттерде бир аз жогото баштады. блокто). Бир блокко 256 пакет менен C# драйверинин эң жогорку көрсөткүчү секундасына болжол менен 28 миллион пакетти, ал эми Go драйвери секундасына болжол менен 25 миллион пакетти түзгөн.

Кийинки, кыйла жакын жыйынтыктар менен, айдоочулар болду
Java, OCaml жана Haskell, алар буга чейин каралган варианттардан байкаларлык артта калып, секундасына 12 миллион пакетти жеңе алышкан эмес. Swift жана JavaScript драйверлери секундасына 5 миллион пакет деңгээлинде агымдарды иштете алгандан да чоң артта калган.

Жогорку рейтингди секундасына 0.14 миллион пакетти гана иштете алган Python драйвери аяктады. Python ишке ашыруу котормочулардын ылдамдыгын JITсиз жана конкреттүү оптималдаштыруусуз баалоо үчүн колдонулган (код CPython 3.7 аркылуу аткарылган жана PyPy менен шайкеш келген эмес, бирок маалыматтарды сактоо структураларын оптималдаштыруу иштин натыйжалуулугун болжол менен 10 эсеге жакшыртышы мүмкүн экени белгиленген. ).

Кошумчалай кетсек, буферлөөнүн натыйжалуулугун жана таштанды жыйгычтын таасирин көрсөтүү үчүн күтүү сыноолору жүргүзүлдү. Сыноо ар бир пакетти айдоочу жөнөткөндөн кийинки күтүү убактысын аны жөнөтүлгөн так убакытка салыштырган. Лидерлер дагы эле C жана Rust драйверлери болгон, алардын натыйжалары секундасына 1 миллион пакет (болжол менен 20 мкс) агымы үчүн дээрлик айырмаланбайт. Go айдоочусу лидерлерден бир аз гана артта калып, ошондой эле 20 мкс деңгээлинде калып, жакшы аткарды. C# драйвери болжол менен 50 мкс кечигүүнү көрсөттү.
Эң узун кечигүүлөрдү JavaScript жана Java драйверлери көрсөтүштү (300 мкс ашык кечигүү).

10 программалоо тилдериндеги версиялардагы тармак драйверинин иштешин салыштыруу

Изилдөө драйверлерди жана иштөө тутумунун компоненттерин C тилине караганда жогорку деңгээлдеги тилдерде иштеп чыгуу мүмкүнчүлүгүн баалоо үчүн жүргүзүлгөн. Учурда Linux'тагы 39 эс тутум көйгөйүнүн 40у драйверлерге байланыштуу, ошондуктан коопсуз тилди колдонуу жана драйверлерди ядродон жана колдонуучу мейкиндигине жылдыруу маселелери актуалдуу бойдон калууда жана өндүрүүчүлөр бул багытта жигердүү эксперимент жүргүзүп жатышат (мисалы, Google OS үчүн TCP стекин иштеп чыккан Фуксия Go тилинде, CloudFlare компаниясы түзүлгөн Rustта QUIC протоколун ишке ашыруу менен, Apple мобилдик түзмөктөрдө TCP стекин колдонуучу мейкиндигине жылдырды).

Иштин жүрүшүндө, Rust тили айдоочуларды өнүктүрүү үчүн мыкты талапкер деген тыянак чыгарылды. Rust'тун мүмкүнчүлүктөрү төмөнкү деңгээлдеги эс тутумду башкаруу менен байланышкан көйгөйлөрдү C драйверлерине салыштырмалуу болжол менен 2% дан 10%га чейин жоготууга алып келет. Go жана C# ошондой эле таштанды чогултуу менен шартталган суб-миллисекунддук кечигүү алгылыктуу болгон кырдаалдарда системанын компоненттерин түзүү үчүн ылайыктуу деп эсептелет.

Source: opennet.ru

Комментарий кошуу