Здравствуйте, ·, Вы писали:
·>Могу рассказать об опыте с FX биржей на Java в контексте "борьбы с GC". Биржа это довольно большой программный комплекс. Вылизанная супер-быстрая часть относительно небольшая, не более 5% всего кода. Зато вся система на одном языке, в едином стиле, простое взаимодействие между компонентами. ·>Более того, в Java очень развитая инфраструктура — анализаторы, профайлеры, всякие метрики, тред/мемори дампы, билды, управление зависимостями, куча библиотек и т.д., т.п. — делает поддержку программного комплекса гораздо проще.
Было бы интересно чуть подробнее, если есть время. То есть как оптимизировался это участок, как именно использовались инструменты, где можно подробнее почитать про это.
ARI ARI ARI... Arrivederci!
Re[4]: эксперимент :: сетевой драйвер на 10 языках
Здравствуйте, Pzz, Вы писали:
Pzz>Ну, можно просто серверов побольше поставить. Особенно, если твоя фамилия "фейсбук".
Еще им можно php в С транслировать.
Re[5]: эксперимент :: сетевой драйвер на 10 языках
Здравствуйте, hi_octane, Вы писали:
_>И программисту чтобы это всё обойти придётся много думать, менять код библиотек, и т.п.
Кастомные аллокаторы изначальная фича всех нормальных структур данных
Re[6]: эксперимент :: сетевой драйвер на 10 языках
Здравствуйте, D. Mon, Вы писали:
DM> ·>Там latency прямо пропорционально доходам. DM> Больше latency — больше доход? Тогда конечно.
Вообще говоря это каком-то смысле правильно — больше девяток в latency — больше доход. real time системы часто бывают именно в стабильности отклика, а не "как можно быстрее".
Здравствуйте, kaa.python, Вы писали:
KP>Но самое интересное в исходниках. Код на Си вполне ожидаем, классическая такая сишечка. Код на Go тоже довольно приличный, с небольшими вкраплениями unsafe, видна попытка сделать код идиоматичным на сколько это возможно с учетом задачи. Код на Rust тоже довольно хорош, хотя и погуще обмазан unsafe конструкциями, но все еще похож на Rust.
прочитал код в memory.go/rs/итд и должен признать, что код на go является самым прямолинейным и самым читаемым из всех, но выглядит конечно как говно
Re[2]: эксперимент :: сетевой драйвер на 10 языках
Здравствуйте, chaotic-kotik, Вы писали:
CK>прочитал код в memory.go/rs/итд и должен признать, что код на go является самым прямолинейным и самым читаемым из всех, но выглядит конечно как говно
Ага, язык крайне убог. Но когда что-то реально пишешь и поддерживаешь на нем, привыкаешь к убогости, а читабельность рулит невероятно.
Re[6]: эксперимент :: сетевой драйвер на 10 языках
Здравствуйте, Masterspline, Вы писали:
M>>> Для сравнимой скорости им требуется в 4-6 раз больше памяти. S>>Откуда такие цифры? M>https://habr.com/ru/post/188580/
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 после освобождения памяти еще делают ее дефрагментацию, т.е. копируют живые объекты, а такой алгоритм для быстрой работы, однозначно, требует использовать много памяти, чтобы его часто не запускали.
Re[8]: эксперимент :: сетевой драйвер на 10 языках
Здравствуйте, 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, неплохой однопоточный — в Окамле. А аленький цветочек я тебе искать не буду.
Re[9]: эксперимент :: сетевой драйвер на 10 языках
Здравствуйте, D. Mon, Вы писали:
DM>В итоге мой личный вывод — не надо ту статью и особенно один график огульно обобщать, и брать ту цифру за повально применимую оценку. Это интересный эксперимент и интересная цифра, но она довольно синтетическая и описывает только тот эксперимент, не более.
Здравствуйте, Nuzhny, Вы писали:
DM>>В итоге мой личный вывод — не надо ту статью и особенно один график огульно обобщать, и брать ту цифру за повально применимую оценку. Это интересный эксперимент и интересная цифра, но она довольно синтетическая и описывает только тот эксперимент, не более.
N>Сравнение же есть.
Да, и это совсем другое сравнение с другими цифрами. Оно не говорит, что "GC для скорости работы сравнимой с ручным управлением памятью нужно в 4-6 раз больше памяти." Тут получается, что хоть сколько давай (хоть в 30 раз больше), все равно джава тормозит. А на одном тесте С++ больше джавы съел, и что теперь? Я ж не говорю, что GC языки не тормозят или памяти не жрут. Я о другом говорю.
Re[8]: эксперимент :: сетевой драйвер на 10 языках
Здравствуйте, 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).
Здравствуйте, hi_octane, Вы писали:
BB>>Интересно, как там обстоят дела со сборкой мусора. Насколько представляю, сборка мусора может стартовать в самый неподходящий момент…. _>В .NET рукояток для управления сборкой вынесено больше чем где — есть и возможность создавать регионы без GC, с низким вмешательством GC, и т.п. Гуглится по GCLatencyMode, просто в это всё никто особо не вникает, а все тормоза вешают на то что "плохой GC невовремя стартанул"
Здравствуйте, Bill Baklushi, Вы писали:
BB>hi_octane:
BB>>>Интересно, как там обстоят дела со сборкой мусора. Насколько представляю, сборка мусора может стартовать в самый неподходящий момент…. _>>В .NET рукояток для управления сборкой вынесено больше чем где — есть и возможность создавать регионы без GC, с низким вмешательством GC, и т.п. Гуглится по GCLatencyMode, просто в это всё никто особо не вникает, а все тормоза вешают на то что "плохой GC невовремя стартанул" BB>И что толку с этих рукояток? В чем смысл оттягивать GC в высоконагруженной системе, работающей 24/7? Всё равно GC случится и в это время устройство не будет обслуживаться.
Если вопросы латентности стоят ребром-GC выключается и рулим памятью сами.
Это подход-работает.
У меня есть тестовые прогоны на обработку почти 2 трлн. ордеров в течении полутора недель без единого запуска GC. Я бы дальше гонял, но место на NASе под данные закончились.
Re[4]: эксперимент :: сетевой драйвер на 10 языках
Здравствуйте, Masterspline, Вы писали:
_>>В .NET рукояток для управления сборкой вынесено больше чем где — есть и возможность создавать регионы без GC, с низким вмешательством GC, и т.п. Гуглится по GCLatencyMode, просто в это всё никто особо не вникает, а все тормоза вешают на то что "плохой GC невовремя стартанул"
M>Вот это меня не перестает удивлять годами. Сначала люди берут язык с GC (Java, C#), потом героически борются с этим GC (используют всякие трюки, чтобы минимизировать влияние сборщика мусора, понятность кода от этого, понятно, не улучшается). А затем с гордостью рассказывают, каких успехов они достигли в борьбе с GC.
M>GC он либо упрощает программирование, либо он не нужен (ибо его накладные расходы должны чем-то компенсироваться). Необходимость борьбы с GC верный признак того, что программист делает что-то себе во вред.
GC используется там, где без него действительно не обойтись либо это слишком дорого.
В большинстве сценариев работы высоконагруженных низколатентных бизнес-приложений сценарии аллокации памяти типовые и очень простые, легко реализуемые руками адекватного разработчика.
Re[5]: эксперимент :: сетевой драйвер на 10 языках
Здравствуйте, Hardballer, Вы писали:
H> У меня есть тестовые прогоны на обработку почти 2 трлн. ордеров в течении полутора недель без единого запуска GC. Я бы дальше гонял, но место на NASе под данные закончились.
А где об этом почитать подробно? Тут
