Видеокодек был реализован на С++, на Flash и на JavaScript (последние два написаны на Haxe).
Немного замеров на тестовом видео (на разных файлах цифры будут разными) :
Выходит, что JS обогнал флэш, но от натива отстает в 2-4 раза. На задаче, где много целочисленной арифметики и очень много хождения по массивам с целыми числами (поиск/обновление/копирование).
Интересно было бы увидеть реализацию на языке ассемблера с современными инструкциями, максимально использующими потенциал современного процессора. Насколько я знаю, коммерческие кодеки вроде H.264 активно используют язык ассемблера, а не чистый C.
Re: JS vs. Native: сравнение на реальном нетривиальном примере
Здравствуйте, D. Mon, Вы писали:
DM>Подробности тут:
Че-то в подробностях про натив ничего нет. Это отдельная реализация, или тоже автоматически переделанный код от флеша? А в каком он окружении работает?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[2]: JS vs. Native: сравнение на реальном нетривиальном примере
Здравствуйте, Ops, Вы писали:
Ops>Че-то в подробностях про натив ничего нет. Это отдельная реализация, или тоже автоматически переделанный код от флеша? А в каком он окружении работает?
Отдельная реализация на С++, на нее ссылка там есть. В тесте использовалась в виде Video-for-Windows кодека, примерно так.
Re[2]: JS vs. Native: сравнение на реальном нетривиальном примере
Здравствуйте, vsb, Вы писали:
vsb>Насколько я знаю, коммерческие кодеки вроде H.264 активно используют язык ассемблера, а не чистый C.
Скорее они интринсики используют
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re: JS vs. Native: сравнение на реальном нетривиальном примере
Здравствуйте, hardcase, Вы писали:
H>А чего там с расходом памяти?
Тщательно не сравнивал пока. На глазок — разница в разы. На разных примерах браузер съедал 150-400 МБ, из них данных именно кодека не так много, а вот при парсинге во время принятия данных и при декодировании звука может много лишней памяти тратиться. Ну и сам браузер. Детально в его куче я не копался.
Re: JS vs. Native: сравнение на реальном нетривиальном примере
DM>Выходит, что JS обогнал флэш, но от натива отстает в 2-4 раза. На задаче, где много целочисленной арифметики и очень много хождения по массивам с целыми числами (поиск/обновление/копирование).
А если C++ версию запустить в wasm?
Make flame.politics Great Again!
Re: JS vs. Native: сравнение на реальном нетривиальном примере
Здравствуйте, D. Mon, Вы писали:
DM>Выходит, что JS обогнал флэш, но от натива отстает в 2-4 раза. На задаче, где много целочисленной арифметики и очень много хождения по массивам с целыми числами (поиск/обновление/копирование).
А насколько плюсовый код качественный ? Как сильно он оптимизирован ?
Не совсем понятно про Haxe — насколько качественный выхлоп у него ?
Re[2]: JS vs. Native: сравнение на реальном нетривиальном примере
Здравствуйте, Ikemefula, Вы писали:
I>Не совсем понятно про Haxe — насколько качественный выхлоп у него ?
Кстати да, меня слегка смутили данные результаты. Т.к. при всех моих последних тестах JS в браузерах (причём тесты сходной тематики — циклы, массивы, вычисления и т.п.) на первых местах всегда был FF, а в этих результатах ситуация строго обратная. Правда я в своих тестах всегда использовал современный JS (например везде массивы int'ов и т.п.)...
Re: JS vs. Native: сравнение на реальном нетривиальном примере
Здравствуйте, D. Mon, Вы писали:
DM>Видеокодек был реализован на С++, на Flash и на JavaScript (последние два написаны на Haxe).
а что там с распаралеливанием? (сейчас не бывает одноядерных ПК разве что в музее)
У флэш проблемы и у чистого js — можно но через *** типа воркер, хотя у JS есть теперь
async функции которые на первый взгляд легко распаралеливает однако пока не видел чтобы кто-то
юзал его именно для распаралеливания... А этот хаске он умеет?
Re[2]: JS vs. Native: сравнение на реальном нетривиальном примере
Здравствуйте, vsb, Вы писали:
vsb>Интересно было бы увидеть реализацию на языке ассемблера с современными инструкциями, максимально использующими потенциал современного процессора. Насколько я знаю, коммерческие кодеки вроде H.264 активно используют язык ассемблера, а не чистый C.
Наивная реализация на ассемблере может проиграть реализации на Си, пропущенной через хороший компилятор.
Re: JS vs. Native: сравнение на реальном нетривиальном примере
Здравствуйте, D. Mon, Вы писали:
DM>Видеокодек был реализован на С++, на Flash и на JavaScript (последние два написаны на Haxe). DM>Немного замеров на тестовом видео (на разных файлах цифры будут разными) :
Спасибо. Интересно. А не делал оценку перегона именно C++ кода в JS через emscripten? Или хотя бы на синтетических примерах тесты?
Интересно будет ли быстрее, того что генерит haxe?
Re[2]: JS vs. Native: сравнение на реальном нетривиальном примере
Здравствуйте, loginx, Вы писали:
L>а что там с распаралеливанием?
Сжатие (в нативном кодеке) распараллелено где можно, а вот декодеры что нативный, что в браузере — однопоточные.
Насколько я помню, в JS для параллелизма есть web worker'ы, но там нельзя данные шарить, а копировать туда-сюда может быть слишком дорого. Ну и сам алгоритм кодека не очень-то позволяет декодирование параллелить без серьезных потерь в степени сжатия.
Re[2]: JS vs. Native: сравнение на реальном нетривиальном примере
Здравствуйте, Ikemefula, Вы писали:
I>А насколько плюсовый код качественный ? Как сильно он оптимизирован ?
Оптимизирован старательно. Мне сложно объективно оценить, насколько качественный, а публиковать исходники я не могу.
I>Не совсем понятно про Haxe — насколько качественный выхлоп у него ?
Насколько это плохой JS в плане скорости? Есть ли очевидные косяки?
Для целочиленных массивов везде использовались typed arrays, вызовы ф-й практически везде мономорфизированы.
То, что на Haxe выглядит как "for(i in 0...N)" в выхлопе превращается в while с заведением дополнительной переменной.
В целом код переводится почти один-в-один, только типы стираются, да ф-ии инлайнятся, те что помечены как inline.
Re[2]: JS vs. Native: сравнение на реальном нетривиальном примере
Здравствуйте, Young, Вы писали:
Y>А не делал оценку перегона именно C++ кода в JS через emscripten? Или хотя бы на синтетических примерах тесты? Y>Интересно будет ли быстрее, того что генерит haxe?
Здравствуйте, loginx, Вы писали:
L>У флэш проблемы и у чистого js — можно но через *** типа воркер, хотя у JS есть теперь L>async функции которые на первый взгляд легко распаралеливает однако пока не видел чтобы кто-то
Это не распараллеливание, а склеивание цепочек разных временных фреймах в одну логическую последовательность. Поскольку js выполняется в одном потоке, смысла от этого нет.
Можно распараллеливать через WebWorker или подобные механизмы.
Re[3]: JS vs. Native: сравнение на реальном нетривиальном примере
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, loginx, Вы писали:
L>>У флэш проблемы и у чистого js — можно но через *** типа воркер, хотя у JS есть теперь L>>async функции которые на первый взгляд легко распаралеливает однако пока не видел чтобы кто-то
I>Это не распараллеливание, а склеивание цепочек разных временных фреймах в одну логическую последовательность. Поскольку js выполняется в одном потоке, смысла от этого нет.
а насколько точно твое утверждение?
Я точно не рабирался, но по ощущения тяжелый длинный вычислительный цикл в асинк зпущенный никак не влияет на быстродействие ГУИ
из чего я интуитивно делаю заключение что оно все же в отдельной нити запускается (про отдельный процесс наверное все же нет)
Re[4]: JS vs. Native: сравнение на реальном нетривиальном примере
Здравствуйте, loginx, Вы писали:
L>Я точно не рабирался, но по ощущения тяжелый длинный вычислительный цикл в асинк зпущенный никак не влияет на быстродействие ГУИ L>из чего я интуитивно делаю заключение что оно все же в отдельной нити запускается (про отдельный процесс наверное все же нет)
Как я понимаю, в этом случае получается вроде Windows 3 — "приложение" регулярно отдает управление "системе", та обновляет UI, потом продолжает работу "приложений". Т.е. здесь основной поток в промежутках между вызовами асинхронных колбэков успевает и UI обновить, потому длинных пауз не видно.
Re[4]: JS vs. Native: сравнение на реальном нетривиальном примере
Здравствуйте, loginx, Вы писали:
I>>Это не распараллеливание, а склеивание цепочек разных временных фреймах в одну логическую последовательность. Поскольку js выполняется в одном потоке, смысла от этого нет.
L>а насколько точно твое утверждение?
L>Я точно не рабирался, но по ощущения тяжелый длинный вычислительный цикл в асинк зпущенный никак не влияет на быстродействие ГУИ
Шо, в самом деле ?
async function x() { while(true) await Promise.resolve(); }
Пускани эту функцию в консоли браузера, попробуй куда нибудь кликнуть мышом и сообщи сюда загрузку процессора.
L>из чего я интуитивно делаю заключение что оно все же в отдельной нити запускается (про отдельный процесс наверное все же нет)
async/await это сахар над Promise.then, что есть обертка над простыми колбеками + небольшая оптимизация в шедулинге.
сравни результат кода выше вот с этим
function loop() {
return Promise.resolve().then(loop);
}
Это эквивалентный код для варианта выше.
Оба варианта выше это аналоги такого кода:
function loop() {
setTimeout(loop, 0);
}
Разница только в той самой оптимизации в шедулинге
