>> Всё немного проще. Внизу приписка "на данной задаче..."
> Да, но начал ты пост с:
>> Вчера мне рассказали, что JS — наибыстрый скриптовый язык (ц).
> Для того, чтобы тест был релевантен этой заявке, должны быть хоть какие-то
> намёки на валидность. Я подозреваю, что утверждение, что js -- самый
> быстрый скриптовый язык, вполне может быть верным, просто потому, что в
> его оптимизации вливается груда инженерного гения, и потому что есть как
> минимум две конкурирующие реализации.Так же и в Python.
> И твои проверки вот нисколько мне не
> добавляют сомнений в том, что js -- самый быстрый.
У меня нет задачи заставить тебя сомневаться. Мне интересен был ответ заявителя, почему в первом попавшемся частном случае "самый быстрый" проиграл, но заявитель куда-то пропал.
>> Не вполне корректно, поскольку не учитывается чтение файла Нодой, но при такой разнице в результатах погрешностью измерений решил пренебречь.
> Ещё не учитывается время запуска ноды: сколько времени нода, при твоём способе
> измерений, будет выполнять пустую программу?
Мне не интересна пустая программа и время запуска Ноды, я измеряю время получения результата.
> А в случае jit-компилятора, ещё и
> время компиляции остаётся неучтённым.
Время компиляции можно оценить при запуске в ключём --always-opt (пусть специалисты по Ноде поправят).
> И это уже погрешность, которая на такой
> задаче в 77 сложений превзойдёт измеряемое значение на несколько порядков, я
> подозреваю. От 2 и выше. Время завершения ноды? Она может не
> просто дёргать exit, а выполнять цикл сборки мусора, с тем, чтобы
> а) закрыть все файлы правильно, сбросить все буфера, и в целом
> вызвать все деструкторы, и б) проверить, что не было утечек памяти.
> Кроме того, если избавиться от этого косяка, тут может оказаться, что
> разница в скорости вывода в консоль окажется доминирующей.
По-моему, ты не прочитал про --always-opt в предыдущем моём сообщении, потому не увидел, что JIT увеличивает время получения результата на порядок.
> Это может не быть косяком -- если ноду использовать для запуска скриптов
> в стиле юниксовых скриптов, когда процесс интерпретатора запускается под каждый скрипт
> заново, но в других случаях это может оказаться неважно совершенно, в
> частности в тех случаях, под которые заточена нода, то есть серверные
> процессы. Поэтому нужна какая-то реальная задача, или хотя бы модель этой
> задачи.
Вот у меня реальная, пусть и бесполезная, задача: вычислить 77-е число Фибьоначчи, запуская интерпретаторы в стиле юниксовых скриптов.
