Судя по тексту ответа он и написан автором Benchmark Game.
А вообще забавно, конечно — как только в интернетах начинают обсуждать Benchmark Game, его автор сразу же появляется в комментариях. Как он это делает — ума не приложу :)
В чём причина отставания V8 от Oracle Java в скорости работы вычислительных алгоритмов, например, числодробилок (т.е. когда GC не вмешивается)?
Эта причина временная или фундаментальная? Связано ли она с типизацией языков?
При первом приближении (если не брать во внимание то, что у V8 вообще нет интерпретатора) обе реализации работают примерно одинаково — ищут «горячие» участки кода и более тщательно оптимизируют их. Почему тогда несмотря на «миллионы гугла» за много лет оптимизатор V8 так и не приблизился к HotSpot? Понятно, что HotSpot это вроде как state of art, но именно V8 (иногда вместе с LuaJIT) хоть как-то могут противопоставить свой JIT продукту Oracle.
Хотелось бы, конечно, узнать ответ от mraleph, но любой приму с благодарностью.
Странный выбор методов сжатия. Зачем брать gzip, если есть lzma2? Зачем брать bzip2, если он, мягко говоря, устарел, и есть гораздо более эффективные BWT-like алгоритмы? И вообще, если сжимается такой набор данных, то надо брать алгоритмы, основанные на статистическом анализе входящего потока, серию алгоритмов PAQ, например. А зачем сжимать поток данных с высокой энтропией выбранными кодировщиками — я так и не понял.
Ruby уже давно не такой медленный, как это было во времена 1.8. Начиная с 1.9, и особенно с 2.х основной интерпретатор Ruby в целом быстрее Python, Perl и PHP5. Язык существенно ускорился, а мифы всё тянутся за ним.
Вот что ещё подумал: если где-то пишут, что X быстрее C\C++, то это скорее всего означает, что C\C++ можно ускорить так, что он всё равно будет первым. Неоптимальный алгоритм? Реализуем оптимальный. Упор на массовую многопоточность? C\C++ есть чем ответить Erlang-у и Scala\Akka. Выигрыш от использования оптимизированного GC? Ничего не мешает взять этот GC целиком себе в проект, тем более, что он на C\C++ скорее всего и написан.
Как аргумент — проект максимально быстрой библиотеки регулярных выражений, с JIT, SIMD и всем этим. По словам автора этот написанный на C++ проект всё же опережает безусловно очень быстрый движок RE V8 в тесте regexdna.
https://github.com/coreperf/rejit
Насколько мне известно самый быстрый (в среднем) интерпретатор — у LuaJIT. А у V8 JS интерпретатора вообще нет — есть 2 JIT-компилятора, один умеет быстро компилироваться, а другой — выдавать быстрый код. У Mozilla Spider(Ion)Monkey интерпретатор есть, но он не то, чтобы очень быстрый. Кроме того, крайне эффективный JIT-компилятор есть у Apple — до недавнего времени они использовали LLVM, но недавно написали свой бэкэнд. И тот же LuaJIT зачастую с микротестах работает быстрее любых JIT-компиляторов JS, даром что его один человек написал. Проигрывает LuaJIT в основном по причине простенького сборщика мусора, до которого у Майка раньше просто не дошли руки, а теперь процесс завис в непонятном состоянии.
Что же касается фразы «JS быстрее C++», то это вполне возможно даже если считать генерируемый JIT-ом код. Java не даст соврать. Пока, конечно, на длинных дистанциях у Hotspot конкурентов нет, но ничто не мешает прикрутить подобный механизм к V8. Хотя вряд ли кому придёт в голову это делать — требования к потребляемой памяти и скорости генерации кода у серверного и клиентского бэкэндов совсем разные. Скорее научат Java и C# генерировать IR-код для универсальной машины WebAssembly.
Now you'll have to learn russian for the sake of comfortable discussion :)
А вообще забавно, конечно — как только в интернетах начинают обсуждать Benchmark Game, его автор сразу же появляется в комментариях. Как он это делает — ума не приложу :)
А если использовать TypeScript — у не го вроде типы можно декларировать?
JNI вообще не о том.
Эта причина временная или фундаментальная? Связано ли она с типизацией языков?
При первом приближении (если не брать во внимание то, что у V8 вообще нет интерпретатора) обе реализации работают примерно одинаково — ищут «горячие» участки кода и более тщательно оптимизируют их. Почему тогда несмотря на «миллионы гугла» за много лет оптимизатор V8 так и не приблизился к HotSpot? Понятно, что HotSpot это вроде как state of art, но именно V8 (иногда вместе с LuaJIT) хоть как-то могут противопоставить свой JIT продукту Oracle.
Хотелось бы, конечно, узнать ответ от mraleph, но любой приму с благодарностью.
Оно вроде корректно поддерживает всё вышеперечисленное.
Как аргумент — проект максимально быстрой библиотеки регулярных выражений, с JIT, SIMD и всем этим. По словам автора этот написанный на C++ проект всё же опережает безусловно очень быстрый движок RE V8 в тесте regexdna.
https://github.com/coreperf/rejit
Что же касается фразы «JS быстрее C++», то это вполне возможно даже если считать генерируемый JIT-ом код. Java не даст соврать. Пока, конечно, на длинных дистанциях у Hotspot конкурентов нет, но ничто не мешает прикрутить подобный механизм к V8. Хотя вряд ли кому придёт в голову это делать — требования к потребляемой памяти и скорости генерации кода у серверного и клиентского бэкэндов совсем разные. Скорее научат Java и C# генерировать IR-код для универсальной машины WebAssembly.