Сделал парочку тестов, не hello-word-ов
(пост не копипаста, в одном экземпляре для лора)
Зачем- ибо тесты в офф гитхабе emscripten все на уровне хеловордов без нагрузки.
тесты имеют одинаковый код на всех указанных языках/платформах, никаких скрытых переделок
Ссылка https://github.com/danilw/cputests там доступны исходники под четыре платформы (С++ только линукс) также лайв демонстрация (ссылки в Readme на гитхабе)
Описание тестов:
basic- простое копирование с конвертацией/конкатенацией строк, самый простой тест
terrain- рекурсия с лямбдой для построения изображения по общеизвестному алгоритму, также рисование изображения вертикальными прямоугольниками (что нагружает все системы отрисовки)
render- алгоритм рей-трейсинга с тенью и отражениями и красивыми материалами, сотни миллионов циклов для построения 640*480 картинки
render_mini- упрощенный render для отрисовки в реальном времени(камерой можно управлять, читай описание на гитхабе), от 3 до 5 миллионов циклов на один кадр 300*200
Результаты:(цифры смотреть на гитхабе)
javascript движок от Firefox намного быстрее и имеет очень много оптимизаций по сравнению с Chrome
даже результаты basic это демонстрируют
результат terrain- показывает что в Chrome (как и в Java) отсутствуют оптимизации «лямбд», при этом js45 (движок джаваскрипта файрфокса) можно запустить с параметрами --no-cgc --no-ggc --ion-offthread-compile=off --ion-osr=off --ion-inlining=off --ion-range-analysis=off то terrain и basic начнут давать результат идентичный версии Chrome (тоесть медленнее в разы)
Я тестировал на нескольких версиях вебкита(браузерах), включая одну самосборку и node.js (тут полный ужас он в два и более раза медленнее вебкита), Хром Хромиум QtWebEngine и другие, опции сборки не тормозили производительность вебкита
Результаты render и render_mini на джаваскрипте показывают что в все плохо с .prototype. и циклами, слово прототип тормозит код в разы
Почему об этом написано тут https://developer.mozilla.org/en-US/docs/Web/JavaScript/The_performance_hazar...
Подводные камни и проблемы:
javascript- очевидно что производительность всегда была проблемой, и при написании даже текстового редактора с функционалом WYSIWYG уже упираетесь в производительность, что ставит крест на любых «реальных играх на webgl» для браузера, о которых упоминают в подобных темах Blend4Web 17.04
про саму ограниченность джаваскрипта в синтаксисе, отсутствие многопоточности (ее нет, евенты и таймеры это однопоточность все таже), невозможность замены базовых алгоритмов типо конвертаци строк, или перевода текста в изображение(текстуру), css алгоритмы отрисовки и прочие базовые элементы браузера... не буду в лишний раз упоминать
про ограниченность webgl(которая даже до opengl2 по функционалу не доходит если сравнивать) и отсутствие Cuda тоже не буду расписывать, это очевидно.
wasm:
во первых- это не настоящий C или C++, так как стандарты не соблюдены и приведены к джаваскрипт стандарту
можно инициализировать static там где нельзя, можно вообще не объявлять static или public/private компилятор выдаст стандартные ошибки «illegal/unknown reference» но проект соберется и будет работать в браузере, потоки ненастоящие(половина из которых вообще не доступна, и узнать что можно что нельзя можно только методом тыка запуская свой проект и читая ошибки браузера «thread(имя либы, SDL треды тоже не поддерживаются) initialization not supported in wasm», std::chrono::duration_cast и std::chrono::duration и std::chrono::high_resolution_clock (и много подобного) привязано к типу джаваскрипта Date что ломает Си/++ программы полностью, ибо возвращаемые данные и результаты не соответствуют «тому что должно быть в Си»
слишком много подводных камней о которых узнаешь из сообщения в браузере
несовместимость «портов» с настоящими, абсолютно все что есть в портах GLFW, SDL ...(и тесты SDL2 и новых портов из гитхаба) работают совершенно подругому, инициализации и функций рисования, некоторые функции которые «обязаны быть» вообще нельзя использовать в месте где они нужны(или они просто неработают) и нужно делать магию с асертами (assert.h)
офф вики библиотек чьи порты сделаны в wasm- просто несоответствует реализации в wasm
TL:DR Из тестов видно что wasm показал очень хороший результат и всего в два раза медленнее java, только скорость отрисовки в «экран»(2d софтвеерно) очень медленная(и опятьже ограниченность на порты, левых либ(буст каиро гтк кутэ.....сотни полезного существует) зависимых от левых либ- неполучится по очевидной причине(сложные либы не соберутся))
Я сделаю еще, как минимум, один проект для сравнения OpenGL производительности отрисовки (посмотрю по факту), в течении пары дней/недели, тогда смогу говорить и про OpenGL
