Довольно интересный эксперимент посвященный использованию разных языков программирования для написания драйверов. Авторы исследования не поленились и выкатили реализацию одного и того же сетевого драйвера для карт 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 действительно очень классный.

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

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

KP>Не для Java, но для C#, Go и даже Haskell?

Может быть и так.

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

Не факт.

BB>Интересно, как там обстоят дела со сборкой мусора. Насколько представляю, сборка мусора может стартовать в самый неподходящий момент….
В .NET рукояток для управления сборкой вынесено больше чем где — есть и возможность создавать регионы без GC, с низким вмешательством GC, и т.п. Гуглится по GCLatencyMode, просто в это всё никто особо не вникает, а все тормоза вешают на то что "плохой GC невовремя стартанул"

hi_octane:

BB>>Интересно, как там обстоят дела со сборкой мусора. Насколько представляю, сборка мусора может стартовать в самый неподходящий момент….
_>В .NET рукояток для управления сборкой вынесено больше чем где — есть и возможность создавать регионы без GC, с низким вмешательством GC, и т.п. Гуглится по GCLatencyMode, просто в это всё никто особо не вникает, а все тормоза вешают на то что "плохой GC невовремя стартанул"
И что толку с этих рукояток? В чем смысл оттягивать GC в высоконагруженной системе, работающей 24/7? Всё равно GC случится и в это время устройство не будет обслуживаться.

Неуправляемые объекты в управляемой среде сводят на нет весь смысл использования новомодных хипстерских технологий.
Можно реализовать виртуальную кучу поверх управляемых объектов, но это неэффективный костыль.

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

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

Там как-то мутно. Они пишут, что для этой задачи им никак не избежать выделения памяти, что звучит странно. На вид, это как раз такая задача когда выделение совсем не нужно.
Надо копать, может на выходных посмотрю. Подозреваю, что будет трудно это дело запустить.
Ну и известная тема, что мерить перфоманс и писать правильных код очень не просто. Можно не разогреть, не выравнить и т.д.

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

ltc> Вот мой любимый сайт (потому что всегда быстро открывается, реально приятно пользоваться), stackoverflow. Бэкенд на ASP.NET, C#. Он достаточно популярный?
Ты б ещё кывт в пример привёл. SO популярен только в IT-тусовке. Попробуй спросить у своих знакомых, которые не связаны с IT слышали ли они о таком сайте.

ltc> У фб и вк — пхп(около того).
Ну и заодно об этих зайтах у тех же знакомых спроси. И сравни результаты.

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

ltc>У фб и вк — пхп(около того).

Что интересно, обе компании стали пилить свои реализации PHP, изкоробочная не канает. Хотя что именно сейчас ВК использует, не знаю.

BB>И что толку с этих рукояток? В чем смысл оттягивать GC в высоконагруженной системе, работающей 24/7?
Высокая нагрузка очень часто неравномерная бывает. Например на некоторых биржах просто шквал апдейтов идёт ближе к концу интервалов — минутного, пяти-минутного, 15-минутного, и т.п. — валят ордера ботов которые "по закрытию свечи" решают поменять позу. В эти интервалы GC ну совсем низзя, можно вляпаться на сотню стоимостей сервера за какие-то секунды. А через 10 секунд уже можно выдохнуть, и спустить GC с поводка. В букмекерских конторах — большие потоки ордеров идут перед самым началом игры, в конце таймов, при назначении штрафных — там GC нельзя. А в другое время появляется куча окон (все матчи начинаются по "круглому" времени) когда можно хоть весь сервис рестартануть — никто не заметит. В крипто-сервисах тоже моменты есть когда очень важно без задержек разослать новую работу или подписанный блок.

BB>Всё равно GC случится и в это время устройство не будет обслуживаться.
Для прям идеально равномерной нагрузки (обычно это какие-то тыщи датчиков IoT) — годится WorkStation GC + GCLatencyMode.Interactive. Чуть больше средняя нагрузка на проц, но моментов "не обслуживания" фактически нет, если в коде нет каких-то прям жутких косяков с выделением памяти.

Тут главное знать что основные стереотипы о .NET GC формировались ещё до 2005-го года. С тех пор GC ну очень поменялся.

Собственно в C++/Rust тоже ряд проблем с памятью решается ну очень тяжело. Допустим у меня есть "тяжёлый" по памяти расчёт, в работе куча матриц, в конце остаётся ответ из нескольких чисел. У биржевых ботов такое бывает. И вот мне нужно оправить ответ в сеть как можно быстрее, а память освободить только когда ответ "ушёл" в сетевую карту. Если написать код естественно, с RAII, и прочими плюшками авто-освобождения — то матрицы начнут удаляться прямо по завершению расчёта. Тем более если библиотеки для расчёта вообще сторонние — они сами начнут чистить за собой прежде чем отдадут циферки, и сожрут ценное время, причём в том же потоке. А удаление непростое — работают деструкторы, аллокаторы пытаются обновить списки, по-возможности смержить непрерывные блоки, и т.п. И программисту чтобы это всё обойти придётся много думать, менять код библиотек, и т.п. А в .NET с GC проблемы вообще нет — перед расчётом перевёл GC в подходящий режим, после отправки в сеть — вернул назад, готово.

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

ltc>У фб и вк — пхп(около того).

Тяжелая часть бэкэнда в фейсбуке написана на С++.
folly не просто так появилась.

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

Если варианты на управляемых языках будут содержать хак на хаке для минимизации влияния сборщика мусора, то еще вопрос, какой код будет более понятным.

Да и зачем это все, если в результате все равно будет вариант на C и именно им все и будут пользоваться. Драйвер на C# даже сложнее написать, чем на голом C.

P.S. Основная неприятность языков со сборщиками мусора не скорость их работы, а количество потребляемой памяти. Для сравнимой скорости им требуется в 4-6 раз больше памяти.

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

Про архитектуру stackoverflow как-то писали. Там куча серверов, все данные либо закешированы в ОЗУ, либо на SSD дисках. Когда данных становится больше — добавляют сервера с гигантским количеством ОЗУ и исключительно SSD дисками. Там сложно тормозить, потому что задача найти данные по ключу и отдать пользователю с таким железом решается запросто.

_>В .NET рукояток для управления сборкой вынесено больше чем где — есть и возможность создавать регионы без GC, с низким вмешательством GC, и т.п. Гуглится по GCLatencyMode, просто в это всё никто особо не вникает, а все тормоза вешают на то что "плохой GC невовремя стартанул"

Вот это меня не перестает удивлять годами. Сначала люди берут язык с GC (Java, C#), потом героически борются с этим GC (используют всякие трюки, чтобы минимизировать влияние сборщика мусора, понятность кода от этого, понятно, не улучшается). А затем с гордостью рассказывают, каких успехов они достигли в борьбе с GC.

GC он либо упрощает программирование, либо он не нужен (ибо его накладные расходы должны чем-то компенсироваться). Необходимость борьбы с GC верный признак того, что программист делает что-то себе во вред.

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

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

M>Про архитектуру stackoverflow как-то писали. Там куча серверов, все данные либо закешированы в ОЗУ, либо на SSD дисках. Когда данных становится больше — добавляют сервера с гигантским количеством ОЗУ и исключительно SSD дисками. Там сложно тормозить, потому что задача найти данные по ключу и отдать пользователю с таким железом решается запросто.

Примерно об этом я и писал в исходном сообщении — при современном железе не так важно, на каком языке писать.
И много RAM и SSD — это едва ли отличительная черта SO, если нужна скорость, то альтернатив нет.

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

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

К графикам надо относиться аккуратно, часть реализаций тюнилась под быстродействие, часть написана идиоматично:
https://www.jishuwen.com/d/2QI1

Но в целом мне очень не нравится идея, что в жертву скорости и стоимости разработки драйверов приносится ЦПУ МОЕЙ машины.

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


M>Про архитектуру stackoverflow как-то писали. Там куча серверов, все данные либо закешированы в ОЗУ, либо на SSD дисках.

Вроде серверов как раз немного, но оне довольно мощные у них. Вертикальное масштабирование.

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

M> Вот это меня не перестает удивлять годами. Сначала люди берут язык с GC (Java, C#), потом героически борются с этим GC (используют всякие трюки, чтобы минимизировать влияние сборщика мусора, понятность кода от этого, понятно, не улучшается). А затем с гордостью рассказывают, каких успехов они достигли в борьбе с GC.
Могу рассказать об опыте с FX биржей на Java в контексте "борьбы с GC". Биржа это довольно большой программный комплекс. Вылизанная супер-быстрая часть относительно небольшая, не более 5% всего кода. Зато вся система на одном языке, в едином стиле, простое взаимодействие между компонентами.
Более того, в Java очень развитая инфраструктура — анализаторы, профайлеры, всякие метрики, тред/мемори дампы, билды, управление зависимостями, куча библиотек и т.д., т.п. — делает поддержку программного комплекса гораздо проще.
Кстати, вообще говоря, вылизывать быстродействие на любом языке всё равно придётся, GC тут не самое страшное.

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

M>Вот это меня не перестает удивлять годами. Сначала люди берут язык с GC (Java, C#), потом героически борются с этим GC (используют всякие трюки, чтобы минимизировать влияние сборщика мусора, понятность кода от этого, понятно, не улучшается). А затем с гордостью рассказывают, каких успехов они достигли в борьбе с GC.

Если в программе много запросов на выделение и освобождение памяти, проблемы будут в любом языке (когда в первый раз с этим столкнулся, было странно видеть что программа на C++ при первом вызове метода с большим количеством аллокаций работает быстро, а при втором в несколько раз медленнее — фрагментация кучи). Решения само собой есть, в разных языках разные, но полностью проблему вроде нигде не решили.

M>GC он либо упрощает программирование, либо он не нужен (ибо его накладные расходы должны чем-то компенсироваться). Необходимость борьбы с GC верный признак того, что программист делает что-то себе во вред.

А необходимость использовать кастомный аллокатор о чём говорит?

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

M>> Вот это меня не перестает удивлять годами. Сначала люди берут язык с GC (Java, C#), потом героически борются с этим GC (используют всякие трюки, чтобы минимизировать влияние сборщика мусора, понятность кода от этого, понятно, не улучшается). А затем с гордостью рассказывают, каких успехов они достигли в борьбе с GC.
·>Могу рассказать об опыте с FX биржей на Java в контексте "борьбы с GC". Биржа это довольно большой программный комплекс. Вылизанная супер-быстрая часть относительно небольшая, не более 5% всего кода.

Биржи зачастую являются монополиями, и конкуренции на скорость там обычно нет. Собственно поэтому с той стороны и приемлема Java.
Со стороны же участников торгов, там где скорость напрямую конвертируются в деньги, никакой Java нет и в помине

·>Кстати, вообще говоря, вылизывать быстродействие на любом языке всё равно придётся, GC тут не самое страшное.

Но на некоторых это проще и всё равно в итоге быстрее

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

EP> ·>Могу рассказать об опыте с FX биржей на Java в контексте "борьбы с GC". Биржа это довольно большой программный комплекс. Вылизанная супер-быстрая часть относительно небольшая, не более 5% всего кода.
EP> Биржи зачастую являются монополиями, и конкуренции на скорость там обычно нет. Собственно поэтому с той стороны и приемлема Java.
Ты наверное путаешь с equities биржами, когда какой-нибудь там AAPL торгуется только на одной бирже. FX биржи конкурируют по полной. Там latency прямо пропорционально доходам. Чем меньше latency, тем более узкий спред могут выставлять market makers. Чем уже спред, тем вероятнее будет trade, процент с которого — прибыль биржи.
По SLA latency был 4ms для 99.99% . Медиана — ~300us. Может из того железа и можно выжать побольше, используя "любые" языки, но уже не принципиально.

EP> Со стороны же участников торгов, там где скорость напрямую конвертируются в деньги, никакой Java нет и в помине
Кто где и как. Зависит от.

EP> ·>Кстати, вообще говоря, вылизывать быстродействие на любом языке всё равно придётся, GC тут не самое страшное.
EP> Но на некоторых это проще и всё равно в итоге быстрее
Это хорошо для кода "написал, вылизал и забыл". Если тебе надо постоянно вносить изменения, выполняя хотелки бизнеса, то пока ты будешь писать кастомный аллокатор в "любом" языке, решение на java уже выкатят в прод.

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

·>Там latency прямо пропорционально доходам.

Больше latency — больше доход? Тогда конечно.

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

KP>То, что драйвер можно успешно сделать на Go меня невероятно порадовало! Хотя, чему тут удивляться если в Fuchsia сетевой стек на нём и написан
Эээ... А где именно?

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

·>Могу рассказать об опыте с FX биржей на Java в контексте "борьбы с GC". Биржа это довольно большой программный комплекс. Вылизанная супер-быстрая часть относительно небольшая, не более 5% всего кода. Зато вся система на одном языке, в едином стиле, простое взаимодействие между компонентами.
·>Более того, в Java очень развитая инфраструктура — анализаторы, профайлеры, всякие метрики, тред/мемори дампы, билды, управление зависимостями, куча библиотек и т.д., т.п. — делает поддержку программного комплекса гораздо проще.

Было бы интересно чуть подробнее, если есть время. То есть как оптимизировался это участок, как именно использовались инструменты, где можно подробнее почитать про это.

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

M> Для сравнимой скорости им требуется в 4-6 раз больше памяти.

Откуда такие цифры?

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

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

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

_>И программисту чтобы это всё обойти придётся много думать, менять код библиотек, и т.п.
Кастомные аллокаторы изначальная фича всех нормальных структур данных

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

S>Было бы интересно чуть подробнее, если есть время. То есть как оптимизировался это участок, как именно использовались инструменты, где можно подробнее почитать про это.
Не могу предложить чего-то нового, но можно в стареньком покопаться.
https://martinfowler.com/articles/lmax.html — думаю уж все видели
можно ещё тут порыться https://www.lmax.com/blog/staff-blogs/
пачка ссылок есть тут: https://www.real-logic.co.uk/about.html
https://mechanical-sympathy.blogspot.com/
https://shipilev.net/
https://www.azul.com/blog/

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

DM> ·>Там latency прямо пропорционально доходам.
DM> Больше latency — больше доход? Тогда конечно.
Вообще говоря это каком-то смысле правильно — больше девяток в latency — больше доход. real time системы часто бывают именно в стабильности отклика, а не "как можно быстрее".

M>> Для сравнимой скорости им требуется в 4-6 раз больше памяти.

S>Откуда такие цифры?

https://habr.com/ru/post/188580/

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

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

прочитал код в memory.go/rs/итд и должен признать, что код на go является самым прямолинейным и самым читаемым из всех, но выглядит конечно как говно

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

CK>прочитал код в memory.go/rs/итд и должен признать, что код на go является самым прямолинейным и самым читаемым из всех, но выглядит конечно как говно

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

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

M>>> Для сравнимой скорости им требуется в 4-6 раз больше памяти.
S>>Откуда такие цифры?
M>https://habr.com/ru/post/188580/

Там опираются на один выбранный график (самый страшный?) из статьи 2005 года.
https://cse.buffalo.edu/~mhertz/gcmalloc-oopsla-2005.pdf

Наскольно это объективно и актуально сейчас — стоит еще подумать. Что с чем сравнивают там — тоже полезно почитать.

M>>>> Для сравнимой скорости им требуется в 4-6 раз больше памяти.
S>>>Откуда такие цифры?
M>>https://habr.com/ru/post/188580/

DM>Там опираются на один выбранный график (самый страшный?) из статьи 2005 года.
DM>https://cse.buffalo.edu/~mhertz/gcmalloc-oopsla-2005.pdf

DM>Наскольно это объективно и актуально сейчас — стоит еще подумать. Что с чем сравнивают там — тоже полезно почитать.

Ну, так давай более свежие грифики и статьи — сравним, подумаем. Только не из рекламной агитки очередных оптимизаторов GC, а из независимого исследования.

Я ожидал, что ответ будет в стиле статья древняя, поэтому... и понты, никак не объясняющие, сколько на самом деле вносит накладных расходов GC на CPU, отравление кеша и потребление памяти.

Когда в GoLang (1.5 или 1.6) сделали очередную мегапеределку GC и годились на весь интернет его маленькими остановками "мира" на сборку, на хабре вышла статья, в которой разбирали алгоритм его работы. Оказалось GC — привет из 70-х (разумеется реализаторы сделали кучу оптимизаций и вообще хорошо постарались, но сам алгоритм по сути из 70-х) и его скорость работы с короткими паузами оказалась обусловлена характером нагрузки приложений, которые пишут на Go (запрос -> ответ -> освобождение памяти). Измени характер нагрузки и все будет плохо, т.е. если этот же алгоритм использовать в Java, он себя покажет отвратительно.

В общем, я привел конкретный пример с конкретными цифрами и разбором, почему ARC взамен GC так радостно встретили. Ответ в стиле статья древняя и измеряли там не то и так — это пустой треп (потому что конструктив отсутствует — одни понты). Есть что сказать по теме, давай реальные ссылки, показывающие насколько влияет GC и более подробное описание, как сделать GC, чтобы он в любой задаче мало памяти жрал, мало тормозил основное приложение (в том числе и не отравлял кеш) и паузы для сборки делал короткие в предсказуемое время. Щас я вижу общие слова и попытки до чего-то докопаться, которые никак не опровергают мое утверждение — GC для скорости работы сравнимой с ручным управлением памятью нужно в 4-6 раз больше памяти. В каких-то случаях, если приложение позволяет, это можно оптимизировать настройкой параметров GC. Однако, большинство, если не все, широко используемые GC после освобождения памяти еще делают ее дефрагментацию, т.е. копируют живые объекты, а такой алгоритм для быстрой работы, однозначно, требует использовать много памяти, чтобы его часто не запускали.

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

DM>>Там опираются на один выбранный график (самый страшный?) из статьи 2005 года.
DM>>https://cse.buffalo.edu/~mhertz/gcmalloc-oopsla-2005.pdf
DM>>Наскольно это объективно и актуально сейчас — стоит еще подумать. Что с чем сравнивают там — тоже полезно почитать.

M>Ну, так давай более свежие грифики и статьи — сравним, подумаем. Только не из рекламной агитки очередных оптимизаторов GC, а из независимого исследования.
M>Я ожидал, что ответ будет в стиле статья древняя, поэтому... и понты, никак не объясняющие, сколько на самом деле вносит накладных расходов GC на CPU, отравление кеша и потребление памяти.
M>В общем, я привел конкретный пример с конкретными цифрами и разбором, почему ARC взамен GC так радостно встретили. Ответ в стиле статья древняя и измеряли там не то и так — это пустой треп (потому что конструктив отсутствует — одни понты).

Ты почему-то решил, что я с тобой спорю и опровергаю. Почему ты так решил? Ты где-то прочитал "измеряли там не то и так", где ты это прочитал? Я не это писал. Может, ты не умеешь читать? Давай тогда сперва справку, что умеешь. Сколько знаков в минуту, на сколько вопросов по тексту в среднем способен ответить. Или тебе просто очень хочется поспорить и поругаться?

Между тем, я лишь добавил к твоему утверждению конкретики — откуда та цифра взята, чтобы люди могли узнать больше, и понять, что это за цифра и как получена.
И предлагаю подумать. Например о том, что
1) в оригинальной статье графиков много, но в производной статье (на перевод которой ты сослался) используют лишь один из графиков, где очень в невыгодном свете выглядят сборщики. Из множества бенчмарков первой статьи во второй взяли один.
2) измеряли там программы на джаве, которая так устроена, что довольно много аллоцирует, у нее value-типов кроме совсем простых нет. Можно ли эти выводы обобщать на другие языки/платформы с GC? По-моему, нельзя.
3) в качестве сравниваемых GC там брали игрушечные реализации, причем многие довольно тупые (без поколений). Они ожидаемо сливают, тут ничего удивительного нет. Но настоящие современные GC, что в JVM, что в CLR, что кое-где еще, отличаются от показанных в той статье. Как именно — я не буду сейчас рассказывать, у кого есть интерес и время, тот найдет и прочитает, или уже прочитал.
4) в качестве "ручного управления памятью" там взяты те же программы на джаве, но освобождение памяти делается с использованием "оракула", идеально откуда-то знающего, когда значение можно освободить. Это понятное приближение к "ручному управлению" в рамках того эксперимента, но это не отражает реальное поведение программ на С/С++ и других языках без GC, но например со смартпоинтерами, считающими ссылки.

В итоге мой личный вывод — не надо ту статью и особенно один график огульно обобщать, и брать ту цифру за повально применимую оценку. Это интересный эксперимент и интересная цифра, но она довольно синтетическая и описывает только тот эксперимент, не более.

И да, в Go сборщик довольно допотопный, тут ты меня не удивил. За хорошими многопоточными тебе в CLR и JVM, неплохой однопоточный — в Окамле. А аленький цветочек я тебе искать не буду.

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

DM>В итоге мой личный вывод — не надо ту статью и особенно один график огульно обобщать, и брать ту цифру за повально применимую оценку. Это интересный эксперимент и интересная цифра, но она довольно синтетическая и описывает только тот эксперимент, не более.

Сравнение же есть.

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

DM>>В итоге мой личный вывод — не надо ту статью и особенно один график огульно обобщать, и брать ту цифру за повально применимую оценку. Это интересный эксперимент и интересная цифра, но она довольно синтетическая и описывает только тот эксперимент, не более.

N>Сравнение же есть.

Да, и это совсем другое сравнение с другими цифрами. Оно не говорит, что "GC для скорости работы сравнимой с ручным управлением памятью нужно в 4-6 раз больше памяти." Тут получается, что хоть сколько давай (хоть в 30 раз больше), все равно джава тормозит. А на одном тесте С++ больше джавы съел, и что теперь? Я ж не говорю, что GC языки не тормозят или памяти не жрут. Я о другом говорю.

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

M>на хабре вышла статья, в которой разбирали алгоритм его работы.

Отличный аргумент, попробую его в ксв

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

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

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

Молодцы то какие, GCSettings.LatencyMode = GCLatencyMode.SustainedLowLatency; они сделали, только вот добавить в проект
<ServerGarbageCollection>true</ServerGarbageCollection>
руки у парней не дошли.
Кому интересны детали:
https://devblogs.microsoft.com/premier-developer/understanding-different-gc-modes-with-concurrency-visualizer/

Там табличка есть, колонка Total GC Pause (ms), правда сценарий несколько другой, но тем не менее.

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

BB>>Интересно, как там обстоят дела со сборкой мусора. Насколько представляю, сборка мусора может стартовать в самый неподходящий момент….
_>В .NET рукояток для управления сборкой вынесено больше чем где — есть и возможность создавать регионы без GC, с низким вмешательством GC, и т.п. Гуглится по GCLatencyMode, просто в это всё никто особо не вникает, а все тормоза вешают на то что "плохой GC невовремя стартанул"

Они то решили рульнуть через GCLatencyMode, только не до конца, серверный GC забыли включить
Разница, правда в несколько другом сценарии-налицо(смотреть таблицы сравнений разных режимов GC).
https://devblogs.microsoft.com/premier-developer/understanding-different-gc-modes-with-concurrency-visualizer/
А так да, с GC в .NET Core можно подружиться, вплоть до прямого запрета ему работать

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

BB>hi_octane:

BB>>>Интересно, как там обстоят дела со сборкой мусора. Насколько представляю, сборка мусора может стартовать в самый неподходящий момент….
_>>В .NET рукояток для управления сборкой вынесено больше чем где — есть и возможность создавать регионы без GC, с низким вмешательством GC, и т.п. Гуглится по GCLatencyMode, просто в это всё никто особо не вникает, а все тормоза вешают на то что "плохой GC невовремя стартанул"
BB>И что толку с этих рукояток? В чем смысл оттягивать GC в высоконагруженной системе, работающей 24/7? Всё равно GC случится и в это время устройство не будет обслуживаться.
Если вопросы латентности стоят ребром-GC выключается и рулим памятью сами.
Это подход-работает.
У меня есть тестовые прогоны на обработку почти 2 трлн. ордеров в течении полутора недель без единого запуска GC. Я бы дальше гонял, но место на NASе под данные закончились.

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

_>>В .NET рукояток для управления сборкой вынесено больше чем где — есть и возможность создавать регионы без GC, с низким вмешательством GC, и т.п. Гуглится по GCLatencyMode, просто в это всё никто особо не вникает, а все тормоза вешают на то что "плохой GC невовремя стартанул"

M>Вот это меня не перестает удивлять годами. Сначала люди берут язык с GC (Java, C#), потом героически борются с этим GC (используют всякие трюки, чтобы минимизировать влияние сборщика мусора, понятность кода от этого, понятно, не улучшается). А затем с гордостью рассказывают, каких успехов они достигли в борьбе с GC.

M>GC он либо упрощает программирование, либо он не нужен (ибо его накладные расходы должны чем-то компенсироваться). Необходимость борьбы с GC верный признак того, что программист делает что-то себе во вред.

GC используется там, где без него действительно не обойтись либо это слишком дорого.
В большинстве сценариев работы высоконагруженных низколатентных бизнес-приложений сценарии аллокации памяти типовые и очень простые, легко реализуемые руками адекватного разработчика.

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

H> У меня есть тестовые прогоны на обработку почти 2 трлн. ордеров в течении полутора недель без единого запуска GC. Я бы дальше гонял, но место на NASе под данные закончились.
А где об этом почитать подробно? Тут

Автор: Hardballer
Дата: 15.10.18

ты давно обещал что-то публичное...

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

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

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

Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>А там где в HFT конкуренция на скорость её и не используют

ну почему, используют: LMAX is a new retail financial trading platform. As a result it has to process many trades with low latency. The system is built on the JVM platform and centers on a Business Logic Processor that can handle 6 million orders per second on a single thread.

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

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

H>> У меня есть тестовые прогоны на обработку почти 2 трлн. ордеров в течении полутора недель без единого запуска GC. Я бы дальше гонял, но место на NASе под данные закончились.
·>А где об этом почитать подробно? Тут

Автор: Hardballer
Дата: 15.10.18

ты давно обещал что-то публичное...

В публику пока не вылезли, поэтому никак. Да и когда вылезем, деталей я тоже писать не буду как я это все сделал, по очевидным же причинам.

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

S>Дурацкий вопрос, но чем user space драйвер отличается от обычной программы? Доступ к DMA? А если речь о kernel space, там какие будут варианты?
Да в общем то ничем.
Более того, часто такие ещё и работают медленнее потому что приходится нырять в ядро и обратно за вещами, которые из юзера не сделать.

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

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

С/С++ компиляторы это умеют очень давно.

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

BB>По-моемуб Dokan написан на C# — это sshfs для винды.
Он написан на С.
Dokan это в общем то только сам kernel драйвер, а примеры как его использовать есть на разных языках — в общем то пофигу из какого языка IOCTL дёргать.

BB> Он какое-то время работает, потом помирает — нужно кикать и перезапускать (а может не от времени зависит, а от объема трафика... )
У меня поверх Dokan драйвера своя UserFS написана, для личных нужд.
Usermode часть на С++, кернел — родной Dokan driver который на С. Ничего не течёт, ничего не помирает.

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

_>Если написать код естественно, с RAII, и прочими плюшками авто-освобождения — то матрицы начнут удаляться прямо по завершению расчёта.
Это если не понимать что такое аллокатор.
В С/С++ они заменяемы, более того, в С++ довольно легко сделать отдельные стратегии аллокации для разных типов объектов.
Всё что тебе там надо это прокси аллокатор, который понимает что сейчас надо как можно быстрее и просто складывает освобождённые объекты в SLL "на потом".

_> Тем более если библиотеки для расчёта вообще сторонние — они сами начнут чистить за собой прежде чем отдадут циферки, и сожрут ценное время, причём в том же потоке.
Можно перекрыть аллокатор глобально Разишо библиотеки будут не new/delete пользоваться а совсем врукопашку с аллокацией работать.

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

_>>И программисту чтобы это всё обойти придётся много думать, менять код библиотек, и т.п.
S>Кастомные аллокаторы изначальная фича всех нормальных структур данных

Особенно тех, которые заточены на производительность.

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

S>было странно видеть что программа на C++ при первом вызове метода с большим количеством аллокаций работает быстро, а при втором в несколько раз медленнее — фрагментация кучи).
Проблема тут не в С++ а в плохом аллокаторе, который либо в рантайме либо вообще системный.

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

CC>С/С++ компиляторы это умеют очень давно.

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

C++, с другой стороны, язык дьявольски сложный, и одни и те же вещи каждая группа разработчиков считает правильным делать на свой, непохожий на других, манер. Поэтому я не думаю, что выделение компилятором идеоматических конструкций в C++ с целью их оптимальной кодогенерации, такое уж перспективное развитие компиляторной науки.

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

CC>Всё что тебе там надо это прокси аллокатор, который понимает что сейчас надо как можно быстрее и просто складывает освобождённые объекты в SLL "на потом".

А разве использование определенного пользователем аллокатора в C++ позволяет отложить исполнение деструктора "на потом"?

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

Pzz>А разве использование определенного пользователем аллокатора в C++ позволяет отложить исполнение деструктора "на потом"?

Деструктора — нет, но вот реального освобождения памяти можно и избежать, есть есть такая цель.

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

EP>>А там где в HFT конкуренция на скорость её и не используют
rfq>ну почему, используют: LMAX

Во во, со стороны биржи, ибо там скорость не критична, они практически все на Java. Покажи хоть один HFT shop использующий Java на критическом пути.

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

EP>> Биржи зачастую являются монополиями, и конкуренции на скорость там обычно нет. Собственно поэтому с той стороны и приемлема Java.
·>Ты наверное путаешь с equities биржами, когда какой-нибудь там AAPL торгуется только на одной бирже. FX биржи конкурируют по полной. Там latency прямо пропорционально доходам. Чем меньше latency, тем более узкий спред могут выставлять market makers.

На спред влияют куча факторов, и latency биржи далеко не является главным.

·>Чем уже спред, тем вероятнее будет trade,

Это не факт.

·>процент с которого — прибыль биржи.

Equity биржи тоже снимают stamp. Но объёмы торгов магическим образом не увеличатся при уменьшении latency.
Иначе все бы они давно бы были на порядке быстрее. Посмотри на доходы крупных бирж, увеличение их скажем на 5% покрыло бы расходы на использование любой из доступных сегодня технологий.

·>По SLA latency был 4ms для 99.99% . Медиана — ~300us. Может из того железа и можно выжать побольше, используя "любые" языки, но уже не принципиально.

Во-во, эти циферки как раз наглядный показатель отсутствия конкуренции по latency. Сравни эти циферки с latency топовых HFT-систем — задачи решаются примерно одинаковые, где-то даже сложнее со стороны торгующих систем, ибо там ещё нужно делать предсказание, обработав данные с кучи источников, и проверки риска, чего нет на стороне биржи, при этом latency отличается драматически — ибо там реальная конкуренция.

EP>> Со стороны же участников торгов, там где скорость напрямую конвертируются в деньги, никакой Java нет и в помине
·>Кто где и как. Зависит от.

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

EP>> ·>Кстати, вообще говоря, вылизывать быстродействие на любом языке всё равно придётся, GC тут не самое страшное.
EP>> Но на некоторых это проще и всё равно в итоге быстрее
·>Это хорошо для кода "написал, вылизал и забыл". Если тебе надо постоянно вносить изменения, выполняя хотелки бизнеса, то пока ты будешь писать кастомный аллокатор в "любом" языке, решение на java уже выкатят в прод.

Непонятно о чём речь.
Если нужен быстрый код — то да, на C++ применяются ряд техник, как и на любом другом языке. На C++ быстрый код получить легче и менее трудозатратно, нежели чем например на Java. На Java для получения быстрого кода придётся работать против языка, затратить намного больше усилий, и при этом всё равно получить более тормозной код.
То есть используя твой пример — выполнять хотелки бизнеса в условиях требований к скорости — на Java займёт больше времени и ресурсов, и решение выкатится в код позднее
Если же требований по скорости нет, то непонятно при чём здесь вообще кастомный аллокатор

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

DM>> ·>Там latency прямо пропорционально доходам.
DM>> Больше latency — больше доход? Тогда конечно.
·>Вообще говоря это каком-то смысле правильно — больше девяток в latency — больше доход.

То есть нужно полагать системы с тридцатью девятками на latency в одни сутки имеют огромный доход?

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

Pzz>Go — язык очень простой и неизбыточный, одну и ту же вещь там разными путями не сделаешь, поэтому ассортимент идеоматических конструкций, которые должен понимать компилятор, невелик.
Pzz>C++, с другой стороны, язык дьявольски сложный, и одни и те же вещи каждая группа разработчиков считает правильным делать на свой, непохожий на других, манер. Поэтому я не думаю, что выделение компилятором идеоматических конструкций в C++ с целью их оптимальной кодогенерации, такое уж перспективное развитие компиляторной науки.

Оптимизатор работает на разных уровнях. В том числе и на уровне IL — в которым остаётся например простейшая SSA форма, вместо зоопарка непохожих друг на друга "манер".
Другое дело что в C++, за счёт шаблонов, идиоматические вещи оптимизируются не только на уровне компилятора, но и на уровне библиотек. Тот же упомянутый выше цикл побайтного копирования руками и писать необязательно, а можно использовать высокоуровневый std::copy, который уже внутри, если позволяют типы, запустит memmove.

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

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

Что значит слился? Они выкидывали языки чтобы масштаб увеличить. Ну, и не факт, что реализация оптимальна. Плюс время идет и МС за это время несколько оптимизировал дотнет. В тесте используется netcoreapp2.1, а уже 5.0 на дворе. Говорят там подоптимизировали многое. Плюс код так себя. Можно по выжимать из него.

Особо приятно, что ко многим языкам целая работа с описанием есть.

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

Что-то ты явно приукрашиваешь. Как языки (точнее рантаймы) распределились на три группы:


И Хаскель явно в конце второй группы с огромным отставанием от лидеров. Фактически он слился.

Меня больше удивило то, как слилась Ява. Я писал на ней под Андройд и она вела себя довольно не плохо. Так что тоже думаю, дело в рантайме и качестве кода.

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

Да, питон показал просто константную скорость с твердой константой — 0.

Но это ожидаемо. Я всегда смеюсь над теми кто серьезно говорит о скорости интерпретируемых языков.

Скорее меня удивил Свифт. Эппл столько пиара о его скоростных характеристиках написал. Даже от ЖЦ отказались из-за скорости. А тут такое. Думаю, там тоже реализация повлияла.

С++-ная реализация, кстати, появилась. Но в пенесометрии ее почему-то не добавили. А жаль.

На эти тесты нужно натравить спецов, чтобы они подтюнили тесты и перевели их на лучшие рантаймы. За C# (а точнее дотнет) ручаюсь, что можно разогнать за счет тюнинга и замены рантайма.

С Явой и Свифтом вообще странно и надо разбираться. А вот Хаскель таки слился. Как и ОКамл (что тоже странно). Твоих восторгов по производительности Хаскеля не разделяю.

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

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

Чуть-чуть почитал 2018-ixy-c-sharp.pdf и поглядел на то как код выглядит сейчас. Код явно переписывални на фишках Core 2.1.

Например, автор просто отжог в исходной реализации TxBatchBusyWait() использовав Linq и ToArray:

1 public void TxBatchBusyWait(PacketBuffer[] buffers)
2 {
3     int numSent = 0;
4     while (numSent < buffers.Length)
5     {
6         numSent += TxBatch(buffers.Skip(numSent).Take(buffers.Length - numSent).ToArray());
8     }
9 }

Удивительно, что эта версия вообще не слилась к черту.
Вот соврмеменная:

      /// <summary>
      /// Calls TxBatch until all packets are queued with busy waiting
      /// </summary>
      public void TxBatchBusyWait(int queueId, Span<PacketBuffer> buffers)
      {
          while(buffers.Length > 0)
          {
              var numSent = TxBatch(queueId, buffers);
              buffers = buffers.Slice(numSent);
          }
      }

Но и в текущей версии есть много чего оптимизировать. Куча динамически занимаемой памяти. Ненужная виртуальность и т.п.

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


KP>Так же интересно то, что драйвер на Java показал довольно хреновые результаты, не Python (который как и положено Python-у слился самым первым, показав всю свою знаменитую скорость работы), но тем не менее. Как же тогда её в HFT используют? Тут я сильно озадачился... надо тюнить JVM как я понимаю?
Странно что нет кода на https://dlang.org/
Последний раз сравнивал, отличий в перформансе в сравнении с растом не заметил(мерял time в linux).
Очень хороший ЯП, не заслужено забыт. Хотя вижу потихоньку развивается. Глава в прошлом году сменился. У него есть политика развития. посмотрим.
Главное преимущество бинарная совместимость с си.
А эти ваши ВМ это прошлый век. Жаль что это вовремя не поняли создатели.

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

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

Ты как всегда в точку попадашь. Как-то нарвался на вот такую инфу:

Обычно используют популярные Java (одноклассники), PHP (facebook, vk), C# (stackoverflow), Python (youtube), Ruby (twitter) — стандартные обычные языки, когда можно найти и хорошие инструменты, и много разработчиков.

Ну, может врут.

Казалось бы, если тебе верить, то все должно написано хотя бы на Rust-е.

Думаю, что высшим приоратом для серверов является надежность. На втором — масштабируемость. И уже на третьем — скорость исполнения кода.

Понятно, что при росте люди начинают оптимизировать. Но оптимизация может заключаться в переписывании нескольких узких мест на низкоуровневом языке. А как видно из этого примера. Rust, Go и C# вполне сходят за универсальные.

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

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

Ну, в C# и Go, как я понял задействовал ансэйф и сплайсы (новая фича дотнета безопасная замена указателям). В Яве на это забили. В Хаскеле это вообще было бы странно. Так что все логично, языки и рантаймы имеющие низкоуровневые фичи выигрывают в низкоуроневой пенесометрии. А Хаскель все не даже, а слил. И сильно.

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

VD>Ну, в C# и Go, как я понял задействовал ансэйф и сплайсы (новая фича дотнета безопасная замена указателям). В Яве на это забили. В Хаскеле это вообще было бы странно. Так что все логично, языки и рантаймы имеющие низкоуровневые фичи выигрывают в низкоуроневой пенесометрии. А Хаскель все не даже, а слил. И сильно.

В любом случае писать драйвер на ВМ это из области извращений, был у меня ПК на работе, у которого часть софта для звуковухи был на дотнете
еще не было ССД, это был такой трэш когда я с клавы пытался изменить уровень. Первое обращение всегда было болью. Потом регулятор оживал и начинал реагировать, но все же.

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

VD>Что значит слился? Они выкидывали языки чтобы масштаб увеличить. Ну, и не факт, что реализация оптимальна. Плюс время идет и МС за это время несколько оптимизировал дотнет. В тесте используется netcoreapp2.1, а уже 5.0 на дворе. Говорят там подоптимизировали многое. Плюс код так себя. Можно по выжимать из него.

Выкидывали еще и потому, сейчас не могу найти где именно это было, что после определенной нагрузки производительность приложения падала до 0. Про оптимальный код я полностью согласен.

VD>Что-то ты явно приукрашиваешь. Как языки (точнее рантаймы) распределились на три группы:
VD>Image: batches-3.3.png

VD>И Хаскель явно в конце второй группы с огромным отставанием от лидеров. Фактически он слился.

Ну как бы сам факт того что два функциональных языка в группе с Java, в оптимизацию которой дохулиар вбухан сам со себе интересен. Разве нет?

VD>Да, питон показал просто константную скорость с твердой константой — 0.

Ну тут однозначно же — он не для этого

VD>С Явой и Свифтом вообще странно и надо разбираться. А вот Хаскель таки слился. Как и ОКамл (что тоже странно). Твоих восторгов по производительности Хаскеля не разделяю.

Меня в первую очередь заинтересовало то, что функциональные, Хаскель так вообще один из самых чистых языков с точки зрения функционального программирования, обходят или держатся в группе с языками в скорость для которых реально вкладываются.

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

AA>Странно что нет кода на https://dlang.org/

Стюардессу закопали

AA>Последний раз сравнивал, отличий в перформансе в сравнении с растом не заметил(мерял time в linux).
AA>Очень хороший ЯП, не заслужено забыт. Хотя вижу потихоньку развивается. Глава в прошлом году сменился. У него есть политика развития. посмотрим.

Заслуженно, более чем заслуженно. Нельзя сначала выкатывать 1.х, говорить что это стабильно, давать писать в проде, а потом говорить "ой, а будет не совместимая ветка 2.х". Время этого этого языка ушло, а с добавлением метапрограммирования в Го, у него вообще преимущества испарятся.

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


KP>Заслуженно, более чем заслуженно. Нельзя сначала выкатывать 1.х, говорить что это стабильно, давать писать в проде, а потом говорить "ой, а будет не совместимая ветка 2.х". Время этого этого языка ушло, а с добавлением метапрограммирования в Го, у него вообще преимущества испарятся.

ну вчера тыкал, пакетов потихоньку становится больше.
производительность очень важный фактор(сравнение с го):
https://github.com/huntlabs/hunt/blob/v1.7.5/docs/images/benchmark-1.png

И самое главное, серьезные ребята все же пользуют https://dlang.org/orgs-using-d.html

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

AA>ну вчера тыкал, пакетов потихоньку становится больше.

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

AA>производительность очень важный фактор(сравнение с го):
AA>https://github.com/huntlabs/hunt/blob/v1.7.5/docs/images/benchmark-1.png

А что там тестируют я не понял, описание честно скажем, мутное "The Date field in http header is set". Отправка/прием статической странички по HTTP? Ну это маловато как бы для хоть какого-то утверждения. А если говорить про производительность Го — её хватает во всех случаях, пока наличие GC не становится проблемой.

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

VD>Ты как всегда в точку попадашь. Как-то нарвался на вот такую инфу:
VD>

VD>Обычно используют популярные Java (одноклассники), PHP (facebook, vk), C# (stackoverflow), Python (youtube), Ruby (twitter) — стандартные обычные языки, когда можно найти и хорошие инструменты, и много разработчиков.

VD>Ну, может врут.

Врут. Facebook использует не php, а свой диалект с трансляцией в C и компиляцией результата gcc (см. Hiphop). А потом вовсе перешла на свой язык Hack.

Одноклассники кроме java ещё пишут на scala. Потом Одноклассники объединились с vk и у них все больше общей кодовой базы появляется. Сейчас там появляется все больше машинного обучения и на серверах работает C++, CUDA, Python.

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

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

Емнип ФБ этот пхп злобно хачила чтоб приемлимо работало. Не работал он отлично.

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

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

Вот вам ещё для раздумий интересная информация — https://www.hackerrank.com/environment/languages.

Это допустимые тайминги для ресурсоёмких алгоритмов на разных языках. Примечательно, что для C# это 3 секунды, для Java 4, хотя для C# используется непонятно какой древний компилятор из mono. Там много интересного.

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

IT> Вот вам ещё для раздумий интересная информация — https://www.hackerrank.com/environment/languages.
IT> Это допустимые тайминги для ресурсоёмких алгоритмов на разных языках. Примечательно, что для C# это 3 секунды, для Java 4, хотя для C# используется непонятно какой древний компилятор из mono. Там много интересного.
Особенно впечатляет bash — одна секунда.

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

IT>> Это допустимые тайминги для ресурсоёмких алгоритмов на разных языках. Примечательно, что для C# это 3 секунды, для Java 4, хотя для C# используется непонятно какой древний компилятор из mono. Там много интересного.
·>Особенно впечатляет bash — одна секунда.

Тоже обратил внимание. Жаль не пишу на нём, не могу проверить. По плюсам и шарпу примерно соответствует.

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

IT>Вот вам ещё для раздумий интересная информация — https://www.hackerrank.com/environment/languages.

Да, согласен, это довольно интересные значения и они неплохо иллюстрируют кривизну рук тех, кто их использует. Там Go требует большое памяти чем Java, а Rust больше времени чем C++, Java, Kotlin и Go. Полагаю что они просто задолбались слушать жалобы от пользователей и решили что проще накинуть времени и ресурсов нежели объяснять участникам что у них руки из жопы растут

IT>Это допустимые тайминги для ресурсоёмких алгоритмов на разных языках. Примечательно, что для C# это 3 секунды, для Java 4, хотя для C# используется непонятно какой древний компилятор из mono. Там много интересного.

Ну я бы не стал такие далеко идущие выводы делать. Если уж хочется ресурсоемкие алгоритмы сравнивать, ты 100% знаешь где искать, и там .NET обходит JVM ну может на 10%.

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

KP>Да, согласен, это довольно интересные значения и они неплохо иллюстрируют кривизну рук тех, кто их использует. Там Go требует большое памяти чем Java, а Rust больше времени чем C++, Java, Kotlin и Go. Полагаю что они просто задолбались слушать жалобы от пользователей и решили что проще накинуть времени и ресурсов нежели объяснять участникам что у них руки из жопы растут

Т.е. Go программисты — это типичные нытики, а C# программисты — настоящие суровые парни, которые никогда никому не жалуются? Ну что же, вполне возможно.

KP>Ну я бы не стал такие далеко идущие выводы делать. Если уж хочется ресурсоемкие алгоритмы сравнивать, ты 100% знаешь где искать, и там .NET обходит JVM ну может на 10%.

Думаю, дело не только в этом. На хакерранке алгоритмы пишутся без дополнительных библиотек, а у джавы родовая травма с примитивными коллекциями, которая как раз решается исключительно кастомным кодом. Большинство алгоритмов на хакерранке — это манипуляция целыми числами, что ставит джаву в неудобное положение — либо использовать массивы, либо коллекции объектов.

Кстати, в твоих "ресурсоёмких алгоритмах" наблюдается примерно таже хрень.

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

·>Особенно впечатляет bash — одна секунда.

А что тут удивительного, вызов заоптимизированных Си программ по сути. Быстрее будет только на самом Си
написать.

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

S>·>Особенно впечатляет bash — одна секунда.
S>А что тут удивительного, вызов заоптимизированных Си программ по сути. Быстрее будет только на самом Си написать.
Дык в том-то и оно — для Си — две секунды.
Могу предположить, это дефолтное значение. И т.к. никто на bash не пишет, то никто и не жаловался, чтобы увеличили.

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

IT>Т.е. Go программисты — это типичные нытики, а C# программисты — настоящие суровые парни, которые никогда никому не жалуются? Ну что же, вполне возможно.

Мне думается что уровень усредненного разработчика на C# выше чем на Go. Go примитивный и его часто используют как последнее средство когда у тебя есть команда из условных студентов, а что-то релизить надо.

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

S>>·>Особенно впечатляет bash — одна секунда.
S>>А что тут удивительного, вызов заоптимизированных Си программ по сути. Быстрее будет только на самом Си написать.
·>Дык в том-то и оно — для Си — две секунды.

Это я не видел, по ссылке не ходил. Что Корузо напел... А так исходя из здравых соображений, вполне
можно допустить, что для баша время могут сделать сопоставимо с чистым Си.

·>Могу предположить, это дефолтное значение. И т.к. никто на bash не пишет, то никто и не жаловался, чтобы увеличили.

Да, скорее всего, мало найдется желающих все это на баше сделать, поэтому поставили какой-то baseline.

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

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

Это даже не алгоритмический косяк, а результат полного наплевательства и мышления в стиле "выливаем воду из чайника, и таким образом сводим задачу к предыдущей".