Довольно интересный эксперимент посвященный использованию разных языков программирования для написания драйверов. Авторы исследования не поленились и выкатили реализацию одного и того же сетевого драйвера для карт Intel Ixgbe на следующих языках: C, Rust, Go, C#, Java, OCaml, Haskell, Swift, JavaScript и Python. Почему-то поленились сделать реализацию для C++, по мне так больше упущение, но что есть, то есть.

Как и ожидалось быстрей всего реализации на Си и Rust, фактически одна и та же скорость. Чуть медленнее, но всё равно достойный результат у Go и C# (правда C# слился из за больших задержек в тесте на 20 Mpps оставив в победителях C, Rust и Go).

Но самое интересное в исходниках. Код на Си вполне ожидаем, классическая такая сишечка. Код на Go тоже довольно приличный, с небольшими вкраплениями unsafe, видна попытка сделать код идиоматичным на сколько это возможно с учетом задачи. Код на Rust тоже довольно хорош, хотя и погуще обмазан unsafe конструкциями, но все еще похож на Rust.

Удивительными оказались результаты для драйверов на OCaml и Haskell — они очень даже неплохо держат нагрузку, что для меня было большой неожиданностью. При этом кода на Haskell один из самых читаемых в этой коллекции реализаций, как мне показалось.

Так же интересно то, что драйвер на Java показал довольно хреновые результаты, не Python (который как и положено Python-у слился самым первым, показав всю свою знаменитую скорость работы), но тем не менее. Как же тогда её в HFT используют? Тут я сильно озадачился... надо тюнить JVM как я понимаю?

Здравствуйте, kaa.python, Вы писали:

KP>Удивительными оказались результаты для драйверов на OCaml и Haskell — они очень даже неплохо держат нагрузку, что для меня было большой неожиданностью. При этом кода на Haskell один из самых читаемых в этой коллекции реализаций, как мне показалось.

KP>Так же интересно то, что драйвер на Java показал довольно хреновые результаты, не Python (который как и положено Python-у слился самым первым, показав всю свою знаменитую скорость работы), но тем не менее. Как же тогда её в HFT используют? Тут я сильно озадачился... надо тюнить JVM как я понимаю?

Немного в сторону, после того как прочитал вот это:





подумал, что для львиной доли применений на сегодняшнем железе подойдет вообще любой язык, главное не допускать совсем уж жестких алгоритмических косяков. А священные войны типа "мой крутой С++ быстрее вашего отстойного C#" все менее и менее актуальны.

Здравствуйте, ltc, Вы писали:

ltc>подумал, что для львиной доли применений на сегодняшнем железе подойдет вообще любой язык, главное не допускать совсем уж жестких алгоритмических косяков. А священные войны типа "мой крутой С++ быстрее вашего отстойного C#" все менее и менее актуальны.

Совершенно верно! Тут же тесты относительно "последнего бастиона" Си, где его уверенно потеснили, ведь читабельность и автоматическое управление памятью рулят. То, что драйвер можно успешно сделать на Go меня невероятно порадовало! Хотя, чему тут удивляться если в Fuchsia сетевой стек на нём и написан

Здравствуйте, kaa.python, Вы писали:

KP>Так же интересно то, что драйвер на Java показал довольно хреновые результаты, не Python (который как и положено Python-у слился самым первым, показав всю свою знаменитую скорость работы), но тем не менее. Как же тогда её в HFT используют? Тут я сильно озадачился... надо тюнить JVM как я понимаю?

А там где в HFT конкуренция на скорость её и не используют

Здравствуйте, kaa.python, Вы писали:

KP>Совершенно верно! Тут же тесты относительно "последнего бастиона" Си, где его уверенно потеснили, ведь читабельность и автоматическое управление памятью рулят. То, что драйвер можно успешно сделать на Go меня невероятно порадовало! Хотя, чему тут удивляться если в Fuchsia сетевой стек на нём и написан

Дурацкий вопрос, но чем user space драйвер отличается от обычной программы? Доступ к DMA? А если речь о kernel space, там какие будут варианты?

Здравствуйте, kaa.python, Вы писали:

KP>Как и ожидалось быстрей всего реализации на Си и Rust, фактически одна и та же скорость. Чуть медленнее, но всё равно достойный результат у Go и C# (правда C# слился из за больших задержек в тесте на 20 Mpps оставив в победителях C, Rust и Go).

Интересно, а откуда в Go такие задержки? Там, что ли, каждый обрабатываемый пакет последовательно проходит через несколько гороутин?

Здравствуйте, ltc, Вы писали:

ltc>подумал, что для львиной доли применений на сегодняшнем железе подойдет вообще любой язык, главное не допускать совсем уж жестких алгоритмических косяков. А священные войны типа "мой крутой С++ быстрее вашего отстойного C#" все менее и менее актуальны.

Ну, чтобы менюшки к таск-бару пририсовывать, действительно подойдет любой язык. А вот если мы говорим о высоконагруженном сервере, производительность имеет значение, потому что она напрямую конвертируется в деньги, потраченные на содержание большего или меньшего пула серверов.

kaa.python:

KP>Довольно интересный эксперимент посвященный использованию разных языков программирования для написания драйверов. Авторы исследования не поленились и выкатили реализацию одного и того же сетевого драйвера для карт Intel Ixgbe на следующих языках: C, Rust, Go, C#, Java, OCaml, Haskell, Swift, JavaScript и Python. Почему-то поленились сделать реализацию для C++, по мне так больше упущение, но что есть, то есть.

Интересно, как там обстоят дела со сборкой мусора. Насколько представляю, сборка мусора может стартовать в самый неподходящий момент...
Совсем обойтись без кучи довольно сложно (на мой взгляд неопытного джависта и шарпея) — всякие буферки, временные строки и пр...

ЗЫ. Слышал, что юзерспейсовые дрова можно писать на шарпе и др, но чтобы на JavaScript и Python — это жесть...
По-моемуб Dokan написан на C# — это sshfs для винды. Он какое-то время работает, потом помирает — нужно кикать и перезапускать (а может не от времени зависит, а от объема трафика... )

Здравствуйте, Pzz, Вы писали:

ltc>>подумал, что для львиной доли применений на сегодняшнем железе подойдет вообще любой язык, главное не допускать совсем уж жестких алгоритмических косяков. А священные войны типа "мой крутой С++ быстрее вашего отстойного C#" все менее и менее актуальны.

Pzz>Ну, чтобы менюшки к таск-бару пририсовывать, действительно подойдет любой язык. А вот если мы говорим о высоконагруженном сервере, производительность имеет значение, потому что она напрямую конвертируется в деньги, потраченные на содержание большего или меньшего пула серверов.

Что подразумевается под сервером? Если, например, сервер базы данных — согласен, но их не так много народу и пишет.
А если это бэкенд вебсайта, коих пишут миллионы, то тут совсем не факт.

Здравствуйте, Pzz, Вы писали:

Pzz>Интересно, а откуда в Go такие задержки? Там, что ли, каждый обрабатываемый пакет последовательно проходит через несколько гороутин?

Там их вообще нет, ни каналов, ни горутин. Думаю, на это есть две причины: во-первых, у Go очень слабый оптимизатор, в то время как у Си и у Rust на оборот очень мощные, во-вторых, GC не бесплатен.

Здравствуйте, kaa.python, Вы писали:

KP>Там их вообще нет, ни каналов, ни горутин. Думаю, на это есть две причины: во-первых, у Go очень слабый оптимизатор, в то время как у Си и у Rust на оборот очень мощные, во-вторых, GC не бесплатен.

Оптимизатор должен влиять и на bandwidth, и на latency. Bandwidth там предсказуемо меньше, чем у C, но он "плавненько" так меньше, видно, что код просто всегда работает раза в два медленнее. А вот латентность как-то совершенно неожиданно большая.

Оптимизатор Go, кстати, умеет делать довольно необычные вещи, которые не умеет делать оптимизатор C. Например, он умеет выделять идеоматические конструкции (например, цикл для побайтного копирования данных с места на место) и генерировать для них соответствующий код. И при инлайнинге/escape analysis'е он умеет "заглядывать" через границы импортируемых пакетов.

Здравствуйте, ltc, Вы писали:

Pzz>>Ну, чтобы менюшки к таск-бару пририсовывать, действительно подойдет любой язык. А вот если мы говорим о высоконагруженном сервере, производительность имеет значение, потому что она напрямую конвертируется в деньги, потраченные на содержание большего или меньшего пула серверов.

ltc>Что подразумевается под сервером? Если, например, сервер базы данных — согласен, но их не так много народу и пишет.
ltc>А если это бэкенд вебсайта, коих пишут миллионы, то тут совсем не факт.

У большинства бэкенд серверов загрузка очень маленькая, потому что большинство вебсайтов никто не посещает. Но вот если вдруг сайт выстреливает, то приходится это бэкенды пачками ставить. А они денег стоят.

Здравствуйте, Pzz, Вы писали:

ltc>>Что подразумевается под сервером? Если, например, сервер базы данных — согласен, но их не так много народу и пишет.
ltc>>А если это бэкенд вебсайта, коих пишут миллионы, то тут совсем не факт.

Pzz>У большинства бэкенд серверов загрузка очень маленькая, потому что большинство вебсайтов никто не посещает. Но вот если вдруг сайт выстреливает, то приходится это бэкенды пачками ставить. А они денег стоят.

Вот мой любимый сайт (потому что всегда быстро открывается, реально приятно пользоваться), stackoverflow. Бэкенд на ASP.NET, C#. Он достаточно популярный?
У фб и вк — пхп(около того).

Здравствуйте, ltc, Вы писали:

ltc>Вот мой любимый сайт (потому что всегда быстро открывается, реально приятно пользоваться), stackoverflow. Бэкенд на ASP.NET, C#. Он достаточно популярный?
ltc>У фб и вк — пхп(около того).

И?

Здравствуйте, Pzz, Вы писали:

ltc>>Вот мой любимый сайт (потому что всегда быстро открывается, реально приятно пользоваться), stackoverflow. Бэкенд на ASP.NET, C#. Он достаточно популярный?
ltc>>У фб и вк — пхп(около того).

Pzz>И?

Ни C# ни пхп чемпионами по скорости не считаются и отлично работают на высоконагруженных серверах.

Здравствуйте, ltc, Вы писали:

ltc>Ни C# ни пхп чемпионами по скорости не считаются и отлично работают на высоконагруженных серверах.

Ну, можно просто серверов побольше поставить. Особенно, если твоя фамилия "фейсбук".

Здравствуйте, kaa.python, Вы писали:

KP>Удивительными оказались результаты для драйверов на OCaml и Haskell — они очень даже неплохо держат нагрузку, что для меня было большой неожиданностью. При этом кода на Haskell один из самых читаемых в этой коллекции реализаций, как мне показалось.
Это какой-то сюрреализм, так как они практически аутсайдеры. Единственный кто не аутсайдер — это Rust. При этом, он реально не делает код безопаснее вообще никак.

Здравствуйте, kaa.python, Вы писали:

KP>Так же интересно то, что драйвер на Java показал довольно хреновые результаты, не Python (который как и положено Python-у слился самым первым, показав всю свою знаменитую скорость работы), но тем не менее. Как же тогда её в HFT используют? Тут я сильно озадачился... надо тюнить JVM как я понимаю?

Думаю, проблемы в реализации или ещё что-то. Всё же задача, мягко говоря, не для Java. Смотри на задачи, в которых всё внутри стека Java проходит, какие-нибудь HTTP-серверы, например.

Здравствуйте, vsb, Вы писали:

vsb>Думаю, проблемы в реализации или ещё что-то. Всё же задача, мягко говоря, не для Java. Смотри на задачи, в которых всё внутри стека Java проходит, какие-нибудь HTTP-серверы, например.

Не для Java, но для C#, Go и даже Haskell? Не находишь что список немного внезапный при том, что для описанного тобой сценария с "какими-нибудь HTTP-серверами" Go тоже будет быстрее?

Здравствуйте, Mystic Artifact, Вы писали:

MA> Это какой-то сюрреализм, так как они практически аутсайдеры. Единственный кто не аутсайдер — это Rust. При этом, он реально не делает код безопаснее вообще никак.

Может быть, так как писали в академической среде, все просто собаку на Haskell да OCaml съели, вот и качество офигеное. Код на Haskell действительно очень классный.