Парсинг логов в 230 раз быстрее на Rust

Ну так подскажи «how to prevent it or ignore node.js starting time».

https://github.com/nodeca/pako/tree/master/benchmark

Есть исходники, есть библиотеки. Может просто стоит уделить им время, вместо того чтобы левые бенчмарки выкатывать?

Кстати, а почему бенчмарки JS (и Java) должны игнорировать время прогрева? Прогрев - родовой порок VM, его нужно учитывать.

Бенчмарки должны четко определять, что именно они бенчмаркают. Если цель - бенчмаркать работу CLI-скрипта, с какой стати выкидывать время запуска?

Просто я искренне не понимаю, нафига такое предъявлять в разговорах о производительности движка. Слабые стороны всем давно известны, от них никто не открещивается.

вместо того чтобы левые бенчмарки выкатывать

Там чёрным по белому написано что тестируется.

Слабые стороны всем давно известны, от них никто не открещивается.

У JS есть сильные стороны?

То есть вы считаете что svgo в ~100 раз медленнее чисто из-за медленного запуска node.js?

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

Ну то есть если бы ты предъявил тест, где гиганская картинка реально оптимизируется 30 секунд, и показал что выбрал примерно одинаковые алгоритмы, я бы не стал специально прикапываться что надо юзать корректные библиотеки бенчмарков.

Ну да ладно. Вот чистый матан: https://github.com/RazrFalcon/color-thief-rs

Я запускал js код в Chrome:

About 150x faster that JS version.

Видишь ли, фантастические результаты могут означать 2 вещи:

1. прорыв, тянущий на нобелевку
2. банальную рукожопость

Когда кто-то заявляет про разницу больше 10 раз, это однозначно рукожопость, можно даже не проверять. Если на JS пишут быстрый код и не очень стараются, разница должна быть не больше 5 раз. А если стараются - раза 2 и меньше.

Возможно, но ты встрял с этим в разговор про другие вещи.

У меня почему-то монитор опять стал жиром потеть.

в 230 раз быстрее на Rust

чем на ....

Чем на перфокартах

«Переписать нормально» — это с Си, а не на Си.

Со Си, а не С Си

Кстати, с практической точки зрения, если хочешь грамотно торпедировать svgo - сделай сборку под ноду, webassembly.

Сейчас с твоей тулзой скорее всего не хотят связываться тупо потому что влом со сборкой возиться - нельзя svgo «просто взять и заменить». Не знаю твоих конечных целей, и нужна ли тебе массовая миграция. Но если нужна - я б коварный план делал примерно так как написал.

https://github.com/fontello/wawoff2 - вот тут экспериментировал с аналогичной проблемой. В среднем по больнице webassembly раза в 2 скорость просадило по сравнению с сишечкой (просто смотрел на больших файлах фонтов). Приемлимо. Ну и время старта, увы, если тысячи коротких запусков.

Компилируется наверное да, быстрее. А вот линкуется это ппц. Вот тебе пример - релизный билд llvm у меня линкуется пару минут и я могу это делать в 6 потоков, а дебажный линкуется минут 20 и максимум 3 потока, иначе не укладывается в 16 гигов оперативы и к линкеру приходит oom killer.

Это именно с Rust-программами происходит или это особенность llvm? Всё же он не на Rust написан.

Скорее, кто придумал собирать все зависимости в debug.

примерно одинаковые алгоритмы

Это нереально. Ибо даже базовые контейнеры реализованы сильно по другому.

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

это однозначно рукожопость

Да. Вебмакак. О чём и тема.

грамотно торпедировать svgo

Мне это не интересно. Прогу я писал под свои нужды.

Возможно вам это покажется странным, но топить за JS - это аномалия.

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

Хеллоуворд на питоне выполняется примерно вдвое быстрее чем на жаве например, питон вин

...для хеллоуворлдов. Да, это так.

Жээсоненавистничество - тоже. Но мне не очень понятно, какое отношение это имеет к текущей теме. И не интересно общаться на подобном уровне.

Для это нужно хорошо знать язык, на котором написана либа. Знанием JS и Java я похвастаться не могу.

на подобном уровне

Вы про «JS такой же быстрый как Си, а вы все дураки»?

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

JS использует JIT-компилятор. В V8 это будет TurboFan (или что там сейчас популярно), в Мозилле - IonMonkey, в JVM - Graal, и так далее. У них всех даже свои имена есть. В результате их работы получается примерно один и тот же машинный код для одних и тех же элементарных операций.

Если задача вычислительная, то на языке можно писать обычный код и перфомансный код. Если код написан перфомансно, то там в конце будут очень чёткие вычислительные конструкции, которые транслируются JIT-компилятором в примерно один и тот же машинный код, на какой бы платформе ты их не запускал.

Исключения - это обычно всякие ad-hoc оптимизации, написанные людьми в особо хитром красивом ассемблере. Какой-нибудь синус, который корпорация Intel написала для вполне конкретных процессоров, и для каждой серии железа есть свой вариант. И каждый из вариантов пишется специалистами по нескольку месяцев фуллтайм. Как бы хитро ты не попробобвал написать свой синус в своём JIT-компиляторе, он гарантированно будет хуже по перфомансу, чем написанный специалистами по синусам из Intel Compiler.

Еще можно найти какие-нибудь корнер-кейсы. Например, JS на JVM сливает не менее чем в сто раз на определённых видах регулярных выражений тому JS что в V8. А на других, наоборот, уделывает в несколько раз (не в сто, лол). В движке по-разному ставятся приоритеты оптимизаций, и на специальных синтетических тестах можно показать превосходство кого угодно, но только на узком наборе данных.

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

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

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

Я прекрасно понимаю как работает JIT в теории. Только на практике результаты как-то не очень.

У JS есть сильные стороны?

Учитель: Дети, сколько будет два плюс два?
Саша: Четыре!
Петя: Четыре.
JavaScript: 22

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

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

Я думаю, это особенность всех компилируемых языков.

ruby > python > rust

Удивлен, разница всего 2 порядка.

Можно ли считать, что раст хорошо выпрямляет руки?

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

обратная совместимость

Обратная совместимость у JS? У него по стандарту каждый год, и в каждом добавляют что-то новое.

Ну я имею в виду такую фигню как «теперь вот так не пиши, пиши вот так» (не знаю как это более точно назвать).

Не понял, о чем ты. Вот появились в JS генераторы, промисы и что там еще - никто не сказал «не пиши больше лапши из коллбеков»?

У C/C++ тоже. Но это не является плюсом для большинства.

Да даже нет. Просто от интерпретируемых не всегда ожидаешь оверхеда в 3 порядка.