Прирост производительности типизированных переменных
 

Чисто теоретически интересует, какой в среднем прирост производительности javascript будет, если везде будут использоваться только типизированные переменные и не будет var'ов ?

При декларации переменной не меняй ей потмо тип и будет тебе прирост производительности. Во всех современных JS VM крутится очень хитрый JIT, который сам эти типы и выводит, просто не надо складывать строки с числами в таком случае :)

kobezzza,
Ты все верно говоришь, но я никак не могу понять, почему тогда JS медленнее c++ ? Я вот делал простой короткий, но очень длинный цикл с простыми расчетами типа a+b на c++, asm.js и на обычном ES5. Разница в скорости в несколько раз. Откуда она берется, если код настолько простой и короткий, что браузер должен был перевести его в нативный код и тупо исполнять? Тестил на FF v44.

Ну во первых в JS JIT работает на уровне функций, т.е. после множественного вызова функции JIT обратит на неё внимание и попробует оптимизировать.

В ASM.js AOT, а не JIT, т.е. всё компилится непосредственное перед запуском программы, а не во время, а это возможно благодаря явной информации о типах и общей строгости диалекта. С другой стороны JIT, не замедляет старт приложения, а вот AOT очень даже может.

Если посмотреть профилировщик в JS, то значительная часть времени уходит на сборку мусора, а в ASM.js никакой сборки мусора нет и прямой доступ к памяти, как в С, что также даёт бешеный профит.

Ну и последнее: обычно в asm.js идёт портирование из С/С++, который в свою очередь был скомпилен, а компиляторы С просто монстры с точки зрения оптимизаций на этапе компиляции, но конечно же, это не быстрый процесс :)

Но с другой стороны: благодаря мощной конкуренции на рынке JS VM, скорость работы VM постоянно растёт и сделала JS одним из самых быстрых скриптовых языков в мире. Например, пол года назад гугл стал интегрировать новый JIT в V8 - TurboFan, который использует информацию ES6 и значительно ускоряет работу или же если взять Chackra Core от MS - то он вообще звездолёт :)

Я все равно не могу понять. Вот смотри, я описал тесты в которых не должно быть ничего из твоего описания. Во-первых, у меня в тесте нет вызова функций - там простой for цикл. Во-вторых, JIT компиляция точно так же переводит в нативный бинарный машинный код, как и AOT, и исполняет этот мой простой цикл именно так. Нет никакого смысла каждую итерацию цикла чтото там опять компилировать, интерпретировать, отслеживать и тд, там ничего не меняется, и типы переменных тоже, а значит и сборщик мусора не нужен, на него не тратиться время. Единственная причина почему может быть медленнее, это если компилятор хуже. C++ это AOT, а значит он может долго анализировать код , делать много проходов для анализа, перебирать варианты как и что лучше сделать, а в JS надо как можно быстрее компилировать, да еще не всё вместе анализировать, а частями, да еще и сам компилятор хуже. Но всё остальное по уму не должно влиять.

Как бы никто и не спорит. Только JIT это делает во время работы программы, а не сразу + есть много способов в JS отменить работу JIT в рамках функции - например использовать eval.

Обычно используется перевод кода в байткод, а затем JIT уже в машинный, но это уже каждая VM по своему, например V8 сразу генерит машинный код, т.е. их получается 2 - оптимизированный и нет.

Конечно нет, JS очень динамичный язык из из-за кучи перестраховок падает производительность.

С++ это как правило тупо компиляция в машинный код и распространение уже скомпиленной программы.

JIT - компиляция во время исполнения программы (параллельно с работой программы);
AOT - компиляция перед непосредственным запуском.

***

А вообще, как бы перед тем как строить теории, догадки и т.д. нужно как минимум провести тесты и определить через профилирование на что тратится время и работает ли JIT.

В отладчике ФФ или Хрома всё нужное есть. Также тут можно прочитать про тестирование http://habrahabr.ru/company/mailru/blog/273839/

На счет профилирования это ты верно сказал, надо будет посмотреть. Потому что я не вижу ни одной причины зачем бы нужно было, как ты говоришь, делать JIT компиляцию во время выполнения такого цикла, который тупо выполняет пару команд сложения триллион раз:) нет ни одной причины даже переводить JS в байткод или байткод в машинный во время выполнения этого цикла, для таких простых циклов это делается до его выполнения, и по уму один раз генерится машинный код и далее уже только он и выполняется, поскольку в теле цикла нет никаких зависимостей с внешним миров, вызовов функций, преобраования типов и тд., все операции и типы данных легко приводятся и укладываются в стандартные регистры процессора. Я все это говорю потому что еще 17 лет назад писал очень сложные оптимизации на ассемблере, и прекрасно понимаю, как работает процессор на самом низком уровне. А постоянное увеличение производительности VM говорит только о тупости их создателей, потому что все типы оптимизация о которых я читал до 2015 года, придуманы еще 20 лет назад, и очевидны были давно.

P.s. Я с тобой ни в коем случае не спорю, поскольку в JS ты понимаешь лучше меня, просто болит душа за него, потому что на других форумах я постоянно читаю много упреков в сторону JS и node.js, особенно от c++ программистов, которые считают что на нем пишут те, кто не умеет программмировать, а причина именно в скорости выполнения. Буду благодарен, если ты поделишься со мной ссылками на хорошие статьи про ручную оптимизацию JS в плане различных способов указания JIT компилятору как нужно обрабатывать конкретные участки кода (к примеру, я точно знаю что посетителю более привлекательно подождать подольше вначале при компиляции, но во время выполнения, чтобы работало побыстрее), и о новых ES6/ES7 нюансах, которые помогают компилятору и VM быстрее работать, как можно помогать подсказаками в коде, где и как лучше обрабатывать (к примеру, чтобы я решал какой вызов функции оставить вызовом, а где вставив в это место ее вызова само тело функции, да и вообще о всяком таком), как уменьшить нагрузку на сборщик мусора (к примеру, я могу не использовать var во время выполнения повсеместно, а создать Typed Array один раз и хранить там все переменные, если это поможет, правда я не знаю как заменить обращение к таким переменным в коде с массив[n] на нормальные имена для удобства, конечно если это возможно и вообще имеет смысл:) думал asm.js использовал, но этот Emscripten настолько убогий, сырой, неудобный, да и лишается смысл, потому что писать уже надо на c++, что сложнее чем на JS для клиент-серверных приложений в браузере. Спасибо за ссылку на хабре;)

webgame,
Я не Кобеззза, но и у меня кое что есть для тебя https://groups.google.com/forum/#!ms...Q/5ENNAiUzEgAJ
Если в кратце, то со скоростью в ES6 всё не так радужно, как могло казаться.

Спасибо. Интересно. Но как я понял это все касается только V8, может чакра всех спасет?)))

webgame,
может быть, а может и нет)

Потому что VM это не знает изначально, а утверждать на 100% она не может, а если она начнёт изучать код на возможность AOT, то это замедлит "старт" приложения, ибо в реальном мире мы имеем не простой цикл, а хренову тучу говно кода :)

Вот и получается, что из нашего текстового кода генерится байт код или неоптимизированный машинный (тут уже от VM зависит), а потом параллельно VM смотрит частые вызовы функций и пытается их оптимизировать (кстати вариант JIT когда оптимизируется именно функции, а не блоки считается боле эффективным).

В ES6 появились новые синтаксические конструкции, которые могут позволить делать дополнительные оптимизации (такие как arrow function или const), но пока JIT-ы только учатся их понимать, думаю через пару лет ситуация улучшиться.

Если бы всё так было просто, то всё было бы сделано давно :) Я как то смотрел видео одного из разработчиков V8 и он как раз рассказывал, что многие исторические вещи в JS сильно усложняют жизнь при анализе и оптимизации кода, например "дырявые массивы":

var a = [];
a[99] = 1; // Такой массив будет реализован поверх хеш-таблицы

var b = [1, 2, 3]; // Такой массив может быть представлен как нормальный массив

WebAssembly или тот же ASM.js работают в рамках той же VM, просто за счёт того, что язык очень строгий и низкоуровневый, то можно вы первых сразу генерить супер быстрый машинный код, а во вторых делать многие оптимизации, которые нельзя делать в простом JS.

Такое пишут неучи :) У каждого языка своя задача, и если нужно сверхбыстрое многопоточное "числодробление", то JS не лучший выбор. Но для задач которые решает Нода или JS в целом он очень шустрый. При написании серверных приложений в большинстве случаев важна масштабируемость, гибкость и простота, а не задрочка оптимизации на одной машинке. Ну а если таки такая задача есть, то сам бог велел просто написать её на более подходящем инструменте и подружить с нодой.

Более того, что с приходом WebAssemly, как раз появляется нормальная возможность безшовной интеграции своих С++ приложений с JS и использования сильных сторон обоих языков.

А если сравнивать JS с другими скриптовыми языками, то он на высоте :)

Спасибо за развернутый ответ!

Вопрос у меня на счет сервера, я еще не работал с node.js (раньше всегда делал на php), но теперь надо много соединений держать одновременно, и вот смотрю что работает быстрее, меньше жрет памяти на каждое соединение и проще в программировании, вот смотрю 2 года назад статья - http://jxcore.com/nodejx-vs-vert-x-vs-node-js-cluster/
И другие подобные статьи тоже смотрю, и везде почему то node.js хуже чем Go, Vert.x, и намного хуже чем JXCore. Так ли это, в чем между ними разница и как обстоят дела сейчас? p.s. мне нужен сервер для обработки запросов от клиентов в ММО браузерных играх.

Ноду долгое время ругали за callback-и, но с приходом async-await всё это уже не актуально. Рекомендую Koa как платформу для сервера ноды (лучше взять сразу 2.0).

Сравнить с Go не могу, т.к. не знаю язык. А вот Vert.x прикольная штука, но это Java и она намного многословнее и дороже в обслуживании, нежеле нода.

По производительности надо сравнивать с актуальной версией ноды (5+), т.к. там обновлённый V8 сильно шустрее стал.

Я вот читал статью 2012 года про теста миллиона соединний - http://habrahabr.ru/post/123154/ , щас явно производительность node.js и V8 выросла. там держалось миллион открытые соединений, правда comet, а не websocket, если я правильно понял, и сервер усперал обрабатывать только одно сообщение за 20 секунд на соединение. Что скажите об этом? И может знаете подобные современные тесты и статьи ? И в чем вообще преимущества node.js , помимо того что писать можно на javascript ? Если к примеру я могу на C/C++ писать так же, какие можно выбрать альтернативы ноде, и в чем будет преимущество, если будет?

Глупо мерить производительность одной машины, всё равно всё в кластерах считается и куда дешевле завести парк слабых машин, чем одну супер мощную и задрачивать оптимизации на ней. Выбирая Node.js мы получаем огромнейшую базу готовых модулей, хороший язык и VM. На С/С++ можно, но зачем? Мы же хотим разрабатывать проект и делать бизнес, а не возится и тратить время на никому не нужные преждевременные оптимизации. Нет универсального решения.

Альтернатив ноде много. Наверное для каждого языка есть хотя бы один похожий фреймворк:

PHP - PHP Daemon
Python - Twisted, Tornado
Java - Spray, Vert.x
...

Выбирать надо тот, на котором удобнее разрабатывать) А скорость тут не критично, ибо узкое место в серверных приложения всегда одно - база данных :)

Кстати про Vert.x - у него есть удобная апиха для JS, т.е. можно вести разработку на JS (в Java входит VM JS) и использовать всю мощь Java, а как дополнительный бонус у них интегрирован Babel и TypeScript.