Здравствуйте, 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 сетевой стек на нём и написан
Эээ... А где именно?