Видеокодек был реализован на С++, на Flash и на JavaScript (последние два написаны на Haxe).
Немного замеров на тестовом видео (на разных файлах цифры будут разными) :


Сам тестовый пример здесь.

Выходит, что JS обогнал флэш, но от натива отстает в 2-4 раза. На задаче, где много целочисленной арифметики и очень много хождения по массивам с целыми числами (поиск/обновление/копирование).

Подробности тут:
https://thedeemon.livejournal.com/122379.html
http://www.infognition.com/blog/2017/video-codec-in-javascript.html

Интересно было бы увидеть реализацию на языке ассемблера с современными инструкциями, максимально использующими потенциал современного процессора. Насколько я знаю, коммерческие кодеки вроде H.264 активно используют язык ассемблера, а не чистый C.

Здравствуйте, D. Mon, Вы писали:

DM>Подробности тут:
Че-то в подробностях про натив ничего нет. Это отдельная реализация, или тоже автоматически переделанный код от флеша? А в каком он окружении работает?

Здравствуйте, Ops, Вы писали:

Ops>Че-то в подробностях про натив ничего нет. Это отдельная реализация, или тоже автоматически переделанный код от флеша? А в каком он окружении работает?

Отдельная реализация на С++, на нее ссылка там есть. В тесте использовалась в виде Video-for-Windows кодека, примерно так.

Здравствуйте, vsb, Вы писали:

vsb>Насколько я знаю, коммерческие кодеки вроде H.264 активно используют язык ассемблера, а не чистый C.
Скорее они интринсики используют

Здравствуйте, D. Mon, Вы писали:

DM>Видеокодек был реализован на С++, на Flash и на JavaScript (последние два написаны на Haxe).

А чего там с расходом памяти?

Здравствуйте, hardcase, Вы писали:

H>А чего там с расходом памяти?

Тщательно не сравнивал пока. На глазок — разница в разы. На разных примерах браузер съедал 150-400 МБ, из них данных именно кодека не так много, а вот при парсинге во время принятия данных и при декодировании звука может много лишней памяти тратиться. Ну и сам браузер. Детально в его куче я не копался.

DM>Выходит, что JS обогнал флэш, но от натива отстает в 2-4 раза. На задаче, где много целочисленной арифметики и очень много хождения по массивам с целыми числами (поиск/обновление/копирование).
А если C++ версию запустить в wasm?

Здравствуйте, D. Mon, Вы писали:

DM>Выходит, что JS обогнал флэш, но от натива отстает в 2-4 раза. На задаче, где много целочисленной арифметики и очень много хождения по массивам с целыми числами (поиск/обновление/копирование).

А насколько плюсовый код качественный ? Как сильно он оптимизирован ?

Не совсем понятно про Haxe — насколько качественный выхлоп у него ?

Здравствуйте, Ikemefula, Вы писали:

I>Не совсем понятно про Haxe — насколько качественный выхлоп у него ?

Кстати да, меня слегка смутили данные результаты. Т.к. при всех моих последних тестах JS в браузерах (причём тесты сходной тематики — циклы, массивы, вычисления и т.п.) на первых местах всегда был FF, а в этих результатах ситуация строго обратная. Правда я в своих тестах всегда использовал современный JS (например везде массивы int'ов и т.п.)...

Здравствуйте, D. Mon, Вы писали:

DM>Видеокодек был реализован на С++, на Flash и на JavaScript (последние два написаны на Haxe).

а что там с распаралеливанием? (сейчас не бывает одноядерных ПК разве что в музее)
У флэш проблемы и у чистого js — можно но через *** типа воркер, хотя у JS есть теперь
async функции которые на первый взгляд легко распаралеливает однако пока не видел чтобы кто-то
юзал его именно для распаралеливания... А этот хаске он умеет?

Здравствуйте, vsb, Вы писали:

vsb>Интересно было бы увидеть реализацию на языке ассемблера с современными инструкциями, максимально использующими потенциал современного процессора. Насколько я знаю, коммерческие кодеки вроде H.264 активно используют язык ассемблера, а не чистый C.

Наивная реализация на ассемблере может проиграть реализации на Си, пропущенной через хороший компилятор.

Здравствуйте, D. Mon, Вы писали:

DM>Видеокодек был реализован на С++, на Flash и на JavaScript (последние два написаны на Haxe).
DM>Немного замеров на тестовом видео (на разных файлах цифры будут разными) :

Спасибо. Интересно. А не делал оценку перегона именно C++ кода в JS через emscripten? Или хотя бы на синтетических примерах тесты?
Интересно будет ли быстрее, того что генерит haxe?

Здравствуйте, loginx, Вы писали:

L>а что там с распаралеливанием?

Сжатие (в нативном кодеке) распараллелено где можно, а вот декодеры что нативный, что в браузере — однопоточные.

Насколько я помню, в JS для параллелизма есть web worker'ы, но там нельзя данные шарить, а копировать туда-сюда может быть слишком дорого. Ну и сам алгоритм кодека не очень-то позволяет декодирование параллелить без серьезных потерь в степени сжатия.

Здравствуйте, Ikemefula, Вы писали:

I>А насколько плюсовый код качественный ? Как сильно он оптимизирован ?

Оптимизирован старательно. Мне сложно объективно оценить, насколько качественный, а публиковать исходники я не могу.

I>Не совсем понятно про Haxe — насколько качественный выхлоп у него ?

Вот это хороший вопрос. Вот примеры, выдранные кусочки из выхлопа, без минимизации:
https://gist.github.com/thedeemon/615a0dfeff59820f4a65ba703d3e6e91

Насколько это плохой JS в плане скорости? Есть ли очевидные косяки?
Для целочиленных массивов везде использовались typed arrays, вызовы ф-й практически везде мономорфизированы.
То, что на Haxe выглядит как "for(i in 0...N)" в выхлопе превращается в while с заведением дополнительной переменной.
В целом код переводится почти один-в-один, только типы стираются, да ф-ии инлайнятся, те что помечены как inline.

Здравствуйте, Young, Вы писали:

Y>А не делал оценку перегона именно C++ кода в JS через emscripten? Или хотя бы на синтетических примерах тесты?
Y>Интересно будет ли быстрее, того что генерит haxe?

3 года назад делал. Тогда ASM.js очень нестабильно по скорости выходил, в некоторых браузерах сильно медленнее.
http://www.infognition.com/blog/2014/comparing_flash_haxe_dart_asmjs_and_cpp.html

В этом году не пробовал, и WebAssembly пока тоже не трогал.

Здравствуйте, loginx, Вы писали:

L>У флэш проблемы и у чистого js — можно но через *** типа воркер, хотя у JS есть теперь
L>async функции которые на первый взгляд легко распаралеливает однако пока не видел чтобы кто-то

Это не распараллеливание, а склеивание цепочек разных временных фреймах в одну логическую последовательность. Поскольку js выполняется в одном потоке, смысла от этого нет.
Можно распараллеливать через WebWorker или подобные механизмы.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, loginx, Вы писали:

L>>У флэш проблемы и у чистого js — можно но через *** типа воркер, хотя у JS есть теперь
L>>async функции которые на первый взгляд легко распаралеливает однако пока не видел чтобы кто-то

I>Это не распараллеливание, а склеивание цепочек разных временных фреймах в одну логическую последовательность. Поскольку js выполняется в одном потоке, смысла от этого нет.

а насколько точно твое утверждение?
Я точно не рабирался, но по ощущения тяжелый длинный вычислительный цикл в асинк зпущенный никак не влияет на быстродействие ГУИ
из чего я интуитивно делаю заключение что оно все же в отдельной нити запускается (про отдельный процесс наверное все же нет)

Здравствуйте, loginx, Вы писали:

L>Я точно не рабирался, но по ощущения тяжелый длинный вычислительный цикл в асинк зпущенный никак не влияет на быстродействие ГУИ
L>из чего я интуитивно делаю заключение что оно все же в отдельной нити запускается (про отдельный процесс наверное все же нет)

Как я понимаю, в этом случае получается вроде Windows 3 — "приложение" регулярно отдает управление "системе", та обновляет UI, потом продолжает работу "приложений". Т.е. здесь основной поток в промежутках между вызовами асинхронных колбэков успевает и UI обновить, потому длинных пауз не видно.

Здравствуйте, 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);
}

Разница только в той самой оптимизации в шедулинге