Javascript-форум (https://javascript.ru/forum/)
-   Оффтопик (https://javascript.ru/forum/offtopic/)
-   -   Прирост производительности типизированных переменных (https://javascript.ru/forum/offtopic/61276-prirost-proizvoditelnosti-tipizirovannykh-peremennykh.html)

Safort 14.02.2016 19:12

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

kobezzza 14.02.2016 23:06

Цитата:

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

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

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

Цитата:

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

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

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


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

Цитата:

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

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

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

webgame 15.02.2016 09:47

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

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

kobezzza 15.02.2016 12:55

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

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

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

webgame 17.02.2016 17:33

Цитата:

Сообщение от kobezzza (Сообщение 407855)
Ноду долгое время ругали за 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++ писать так же, какие можно выбрать альтернативы ноде, и в чем будет преимущество, если будет?

kobezzza 17.02.2016 18:54

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

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

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

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

kobezzza 19.02.2016 16:41

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


Часовой пояс GMT +3, время: 00:46.