Видеокодек был реализован на С++, на 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);
}

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

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

I>Шо, в самом деле ?

I>

I>async function x() { while(true) await Promise.resolve(); }
I>

А если так?
async function x() { for(i=0;i<10000000;i++{ y+=sin(i)} }

x();

то фурычит и не тормозит
:-O

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

I>>

I>>async function x() { while(true) await Promise.resolve(); }
I>>

L>А если так?
L>async function x() { for(i=0;i<10000000;i++{ y+=sin(i)} }



L>то фурычит и не тормозит
L>:-O

Не возражаешь, если пофиксим твои ошибки и добавим замер ?

async function x() {let y=0; console.time(); for(let i=0;i<10000000;i++){ y+=Math.sin(i);} console.timeEnd(); }

Код выполняется ажно 1 секунду и далее не тормозит Замени 10000000 на Infinity, узнаешь много нового.

Но вообще скучновато наблюдать, как ты открываешь для себя особенность JS, которой двадцать лет или больше

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

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

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

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

вроде для этого там есть функции-генераторы...

а если чисто читать описание async то там сразу после вызова ф-я вернется и вернет промис, значит далее по идее должно продолжится
выполнение следующей строки... и в доках момент начала выполнения кода внутри асинк ф-ии как-то не нашел я в доках...
т.е. судя по описанию оно может и в основной нити и в доп. выполнится, ... ну и есть же асинк типа чтения URL которые реально асинк
возможно пока нельзя создавать понастоящему асинк ф-ии прямо в коде, но встроенные реальные асинк уже есть, но сами доки про это ни слова...

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


I>

I>async function x() {let y=0; console.time(); for(let i=0;i<10000000;i++){ y+=Math.sin(i);} console.timeEnd(); }
I>

I>Код выполняется ажно 1 секунду и далее не тормозит Замени 10000000 на Infinity, узнаешь много нового.
да, согласен, мало итераци у меня было... однако со встроенным fetch(URL) работает не тормозя гуи хотя ччитать може и 1 час! (большой файд, медленный интернет)

I>Но вообще скучновато наблюдать, как ты открываешь для себя особенность JS, которой двадцать лет или больше

но async появились совсем недавно!! И из описания да и на практике для встроенных fetch(URL)
работает не тормозя гуи. Логично было ожидать что и самодельные async обладают свойствами встроенных в язык async ф-ий типа fetch()

И исходя из публичных док на мозиле
асинк должна немедлено после вызова НЕ начиная выполнять код внутри вернуть
в точку вызоа проимс. И далее что? Выполняется следующая строка и тд (но тогда когда же стартует выполнение тела асинк ф-ии?)
Или все же перед возвратом все же в самодельной ф-ии должно выполнится все тело внутри...?
Но тогда деза в доках!!

Вот в ф-иях генераторах в доках ясно — старт это вызов next() — возврат — yield()
А в асинк ф-иях где ".next()" ?! Получается на текущий момент самодельные не встроенные в язык async ф-ии это всего лишь кастрированные Генераторы?

Или я что-то не так запрограмил и async вообще не включается? (в этом коде никакого async не происходит!)
<script>
var x = 0;
var i = 0;
console.log("1 x=",x, " i=",i);

async function test()
{
console.log(" START async test");
for(i=0; i<10000000; i++)
{
x += Math.sin(i)+Math.cos(i*7.5);
};
console.log("END async test");
};

console.log("2 x=",x, " i=",i);
test();
console.log("3 x=",x, " i=",i);
</script>

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

L>а если чисто читать описание async то там сразу после вызова ф-я вернется и вернет промис, значит далее по идее должно продолжится
L>выполнение следующей строки...

Разумеется это не так. Промис то вернет. А следующая строка выполнится когда промис резолвнется.

>и в доках момент начала выполнения кода внутри асинк ф-ии как-то не нашел я в доках...

Нужно разобраться с Promise, callback и yield. async это yield промиса

https://hackernoon.com/6-reasons-why-javascripts-async-await-blows-promises-away-tutorial-c7ec10518dd9

L>т.е. судя по описанию оно может и в основной нити и в доп. выполнится, ... ну и есть же асинк типа чтения URL которые реально асинк

Асинк это инструмент для склеивания асинхронных цепочек. Чтение URL выполнится унутре браузера в другом потоке. К склеиванию это никакого отношения не имеет.

L>возможно пока нельзя создавать понастоящему асинк ф-ии прямо в коде, но встроенные реальные асинк уже есть, но сами доки про это ни слова...

API большей частью еще на колбеках. На промисах из широко известного fetch. Что такое по настоящему асинк функции прямо в коде ?

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

I>>

I>>async function x() {let y=0; console.time(); for(let i=0;i<10000000;i++){ y+=Math.sin(i);} console.timeEnd(); }
I>>

I>>Код выполняется ажно 1 секунду и далее не тормозит Замени 10000000 на Infinity, узнаешь много нового.
L>да, согласен, мало итераци у меня было... однако со встроенным fetch(URL) работает не тормозя гуи хотя ччитать може и 1 час! (большой файд, медленный интернет)

И при чем здесь async ? fetch и без него не морозит UI

I>>Но вообще скучновато наблюдать, как ты открываешь для себя особенность JS, которой двадцать лет или больше

L>но async появились совсем недавно!! И из описания да и на практике для встроенных fetch(URL)
L>работает не тормозя гуи. Логично было ожидать что и самодельные async обладают свойствами встроенных в язык async ф-ий типа fetch()

Логично проверить fetch безо всяких асинков и узнать, что асинк ни при чем.

L>И исходя из публичных док на мозиле
L>асинк должна немедлено после вызова НЕ начиная выполнять код внутри вернуть
L>в точку вызоа проимс. И далее что? Выполняется следующая строка и тд (но тогда когда же стартует выполнение тела асинк ф-ии?)
L>Или все же перед возвратом все же в самодельной ф-ии должно выполнится все тело внутри...?
L>Но тогда деза в доках!!

Нет дезы. Надо разобраться в промисах.

L>Вот в ф-иях генераторах в доках ясно — старт это вызов next() — возврат — yield()
L>А в асинк ф-иях где ".next()" ?! Получается на текущий момент самодельные не встроенные в язык async ф-ии это всего лишь кастрированные Генераторы?

Унутре. Именно.

I>Унутре. Именно.
А что это за невнятное мычание, сорри?
Оно же 1 млн. вхождений в гугле
let promise = fetch(url[, options]);

I>Нет дезы. Надо разобраться в промисах.

промисы тут вообще не причем...
просто в текущей реализации "самодельные" async ф-ии не работает так как описано в доках, хотя в node.js работает.
Вместо немедленного возврата промиса сейчас асинк ф-ия (САМОДЕЛЬНАЯ) возвращает его только после выполнения своего тела.
Фактически сейчас async это генератор-фия с немедленным вызовом .next()и без yield()

а встроенные разрабами мозилы async ф-ии, наприме fetch() работают по докам, немедленный возврат промиса и выполнение следующей строки.

покопавшись в отладчике — вроде fetch определен как генератор а не асинк или возможно и как оба сразу... но точно не как только async

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


I>Разумеется это не так. Промис то вернет. А следующая строка выполнится когда промис резолвнется.

вовсе нет, чтобы ожидать резолвинг надо на него повесить await
а так промис из fetch просто присвоится переменной и выполнение продолжится...

возможно я что-то тотально не понимаю, но вроде у меня так и работало....
надо ждать fetch жду через await — не надо, присваиваю промис с переменную и код идет дальше

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

I>>Нет дезы. Надо разобраться в промисах.

L>промисы тут вообще не причем...

Браво — в механике, которая прибита гвоздями к промисам, промисы оказывается ни при чем

L>просто в текущей реализации "самодельные" async ф-ии не работает так как описано в доках, хотя в node.js работает.

Все именно так, как надо работает, согласно докам. И в ноде идентично. Проблема только в API — не всё еще на промисы переведено.

L>Вместо немедленного возврата промиса сейчас асинк ф-ия (САМОДЕЛЬНАЯ) возвращает его только после выполнения своего тела.

Покажи код.

L>Фактически сейчас async это генератор-фия с немедленным вызовом .next()и без yield()

Фактически это две функции. Одна вызывает другую. Примерно так

async(*()=>{
   let value1 = yield fetch(url1);
   let value2 = yield fetch(url2);
})

function async(generator) {
  стартовать генератор
  вызывать then до посинения
}

L>а встроенные разрабами мозилы async ф-ии, наприме fetch() работают по докам, немедленный возврат промиса и выполнение следующей строки.

А как ты хотел ?

L>покопавшись в отладчике — вроде fetch определен как генератор а не асинк или возможно и как оба сразу... но точно не как только async

нет никакого специального async в АПИ. Есть функции, которые возвращают промисы. async это фича языка, которая умеет работать с такими функциями.
Просто сахар для promise.then().then().then().then().then().then()

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

I>>Унутре. Именно.
L>А что это за невнятное мычание, сорри?
L>Оно же 1 млн. вхождений в гугле
L>let promise = fetch(url[, options]);

А в асинк ф-иях где ".next()" ?! Получается на текущий момент самодельные не встроенные в язык async ф-ии это всего лишь кастрированные Генераторы?

асинк внутри использует yield. в этом плане async это кастрированый генератор — работает, как генератор, только ты не можешь получить аналогичного профита.

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

I>>Разумеется это не так. Промис то вернет. А следующая строка выполнится когда промис резолвнется.

L>вовсе нет, чтобы ожидать резолвинг надо на него повесить await

Смотри внимательно, эквивалентный код:

async function get(url) {
  let url2 = async fetch(url);
  return await fetch(url2);
}

function get(url) {
  return fetch(url).then((url2)=>fetch(url2));
}

Весь асинхронный код обязан быть внутри колбеков, что передаёшь в then.

вот сравниваю fetch() которая возвращает проимс МГНОВЕННО в состоянии ПЕНДИНГ
и далее никто не ждет резолвинга, как ты утверждаешь, далее код идет выполнятся на следующие строки.
Вот так должны работать асинки по докам.!!

А в реальности...
async функцию, любую, которую мы сами объявляем в нашем коде...

сразу запускает тело на выполнение!

НИЧЕГО НЕ ВОЗВРАЩАЕТ ПОКА ТЕЛО НЕ ВЫПОЛНЕНО!
(этот пункт как надо, но в сочетании с предыдущим и следующим — ж..а)

гуи висит и ожидает окончания выполнения тела якобы асинхронной ф-ии.

Проще говоря самописных async ф-ий нет, они сейчас остаются синхронными.
async — Фуфло, а жаль, я уж подумал наконец сделали удобную паралельность в JS

имхо дело в том что у нас нет метода pending() а есть только reject() и resolved()
по смыслу асинков метод pending() должен был бы возвращать пендинг промис не останавливая
выполнения тела асинк ф-ии, вызываться в начале тела ф-ии. Но его нет. А оствщиеся
два играют роль return — вызывают остановку выполнения тела ф-ии.

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

L>вот сравниваю fetch() которая возвращает проимс МГНОВЕННО в состоянии ПЕНДИНГ
L>и далее никто не ждет резолвинга, как ты утверждаешь, далее код идет выполнятся на следующие строки.

Разумеется. fetch возвращает промис, мгновенно и в состоянии pending. Именно с такими функциями работает async/await

L>Вот так должны работать асинки по докам.!!

fetch появился в браузере когда асинками там и не пахло. Как он работал без асинков ?

L>А в реальности...
L> async функцию, любую, которую мы сами объявляем в нашем коде...

Я не понимаю, что ты назваешь асинком. У меня асинк это функция вида async function () { ... } а у тебя похоже всё подряд.

L>Проще говоря самописных async ф-ий нет, они сейчас остаются синхронными.

Весь код в JS на самом деле 100% синхронный, однопоточный и асинхронность исключительно логическая.

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


I>fetch появился в браузере когда асинками там и не пахло. Как он работал без асинков ?

а какая разница, сейчас он возвращает промис. тчк.

Windows 3.1 как указал один из предыдущих ораторов тем не менее создавала удобную иллюзию многозадачности
чего-то подобного я и ожидал исходя по докам от асинков но оказалось они только на встроенных ф-иях
работают как по докам. Нечто вроде автоматических генератор-ф-ий...
Хотя была надежда что и в нитях запустят... воркеры то сделали... значит хотят все же когда-гить
запилить нормальную паралельность...

все же логично и просто, добавить return_pending()
после него запретить обращение к гуи. А саму паралельность либо как в виндах 3 или на истинных трэдах

сейчас же не только async фиктивная так и new promise — точно также вещает гуи пока тело не закончит.
Причем возврат пендинг ничего не меняет — все равно гуи подвешивает.

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

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


I>>fetch появился в браузере когда асинками там и не пахло. Как он работал без асинков ?

L>а какая разница, сейчас он возвращает промис. тчк.

Я тебя ужасну — он и тогда промис возвращал. И работал так же.

Ты все хочешь блокирующий асинхронный вызов. Таких в JS нет и не будет.

Именно потому появилисб промисы. А async/await это инструмент работы с промисами. Это всего лишь фича языка.

Хочешь разобраться — качай промисы.

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

L>Windows 3.1 как указал один из предыдущих ораторов тем не менее создавала удобную иллюзию многозадачности
L>чего-то подобного я и ожидал исходя по докам от асинков но оказалось они только на встроенных ф-иях
L>работают как по докам. Нечто вроде автоматических генератор-ф-ий...
L...

Еще раз — что ты называешь асинком? Ты адекватный? У тебя и fetch асинк, и языковые фичи это асинк и какойто мусор тоже асинк.

Проблемы Windows 3 очень похожи на проблемы JS — одна функция вешает вообще все. И там, и там кооперативная многозадачность. Разница только в том, что в JS она логическая.

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

DM>Видеокодек был реализован ... и на JavaScript

JS — это не язык, это отрыжка дьявола и порождение тупой обезьяны. Зачем каждый раз откапывать это "нечто" и трясти им как чем-то значимым?? Ну Фортран ещё достаньте, PL/1 где-то завалялся... почему у вас нехватает ума, чтобы один раз и навсегда предать анафеме этот язык-урод?? Всё, времена ЛИСПов и Брэйнфаков прошли, молодёжь! Втыкайте уже в отрасль, хватит этого хипстерства, линупсятины и прочего задротства.

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

K>JS — это не язык, это отрыжка дьявола и порождение тупой обезьяны.

Совершенно верно.

K> Зачем каждый раз откапывать это "нечто"

Ссылки не читай
@
Сразу отвечай!

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

PS. В данном случае код-то писался на другом языке, более приличном, а в JS потом транслировался компилятором, так что ужасы JS-как-языка тут нерелевантны.

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

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

DM>>Видеокодек был реализован ... и на JavaScript

K>JS — это не язык, это отрыжка дьявола и порождение тупой обезьяны. Зачем каждый раз откапывать это "нечто" и трясти им как чем-то значимым?? Ну Фортран ещё достаньте, PL/1 где-то завалялся... почему у вас нехватает ума, чтобы один раз и навсегда предать анафеме этот язык-урод?? Всё, времена ЛИСПов и Брэйнфаков прошли, молодёжь! Втыкайте уже в отрасль, хватит этого хипстерства, линупсятины и прочего задротства.

Вот согласен 100 раз! Все правильно сказал!

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

L>сейчас же не только async фиктивная так и new promise — точно также вещает гуи пока тело не закончит.
L>Причем возврат пендинг ничего не меняет — все равно гуи подвешивает.

Странно, что ты ожидал другого на однопоточной модели.

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

K>JS — это не язык, это отрыжка дьявола и порождение тупой обезьяны. Зачем каждый раз откапывать это "нечто" и трясти им как чем-то значимым?? Ну Фортран ещё достаньте, PL/1 где-то завалялся... почему у вас нехватает ума, чтобы один раз и навсегда предать анафеме этот язык-урод?? Всё, времена ЛИСПов и Брэйнфаков прошли, молодёжь! Втыкайте уже в отрасль, хватит этого хипстерства, линупсятины и прочего задротства.

Все бы ничего, только не пойму: что не так с Фортраном? На нем работают не хипстеры, а взрослые бородатые дядьки.

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


I>Ты все хочешь блокирующий асинхронный вызов. Таких в JS нет и не будет.

во-первых, оно есть и будет, например fetch

во вторых, я всего лишь хочу чтобы промис и асинк ф-ии работали в точности как доках,
т.е. чтобы поведение было как у встроенных промис-асинк например как у fetch()

ты кажется никак не можешь врубиться и осознать что для встроенных объектов JS типа промис и асинк ф-ии
функционал реализован полностью, а для тех что програмер пишет сам в JS — нет,
(через new Promise и/или asyn function x())
в частности нет доступа к состоянию промиса который однако можно увидеть через console.log
про это кстати много на стэк оверфлоу статей — народ требует и сабмити баг репорты, а их удаляют...

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

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

L>>сейчас же не только async фиктивная так и new promise — точно также вещает гуи пока тело не закончит.
L>>Причем возврат пендинг ничего не меняет — все равно гуи подвешивает.

I>Странно, что ты ожидал другого на однопоточной модели.

да, хотелось, тем более что в доках мозилы нигде нет что однопоточность это навсегда.
Наоборот в Лисе 57 (квантум) версии открыто написано что css, анимация и эффекты вынесены в многопоточность и гуи более не блокируют

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

I>>Странно, что ты ожидал другого на однопоточной модели.

L>да, хотелось, тем более что в доках мозилы нигде нет что однопоточность это навсегда.
L>Наоборот в Лисе 57 (квантум) версии открыто написано что css, анимация и эффекты вынесены в многопоточность и гуи более не блокируют

В огороде бузина, а в Киеве дядька

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

I>>Ты все хочешь блокирующий асинхронный вызов. Таких в JS нет и не будет.

L>во-первых, оно есть и будет, например fetch

ну и мешанина. Совсем недавно некто loginx утверждал следующее:
"fetch() которая возвращает проимс МГНОВЕННО в состоянии ПЕНДИН"
Вот это и есть неблокирующий вызов — для того и нужен промис. Т.е. возвращается не сам результат, а нечто, с помощью чего ты получишь его, когда нибудь.

То есть, сейчас ты похоже поменял мнение, и фетч стал блокирующим ?
Блокирующий асинхронный вызов это когда fetch удерживает поток до получения всего результата целиком, т.е. пока не вытащит по http все что надо.

Такие вызовы ты можешь наблюдать в ноде, скажем в модуле FileSystem имена функций *Sync.

L>во вторых, я всего лишь хочу чтобы промис и асинк ф-ии работали в точности как доках,

Что такое "асинк ф-ии" ? Я не понимаю твой терминологии, никто ей кроме тебя не пользуется.

L>т.е. чтобы поведение было как у встроенных промис-асинк например как у fetch()

Что такое "встроеные промис-асинк" ?

L>ты кажется никак не можешь врубиться и осознать что для встроенных объектов JS типа промис и асинк ф-ии

Я не знаю, что ты называешь словом "асинк" а пояснять ты отказываешься.

L>функционал реализован полностью, а для тех что програмер пишет сам в JS — нет,
L>(через new Promise и/или asyn function x())

Пример кода в студию.

L>в частности нет доступа к состоянию промиса который однако можно увидеть через console.log
L>про это кстати много на стэк оверфлоу статей — народ требует и сабмити баг репорты, а их удаляют...

Ужос, заговор против нубов !!!!111расрасодинодин

Что тебе даст этот доступ к состоянию промиса ? Все уже сто лет как научились пользоваться промисами. ты что, из прошлого века пишешь или как ?

DM>PS. В данном случае код-то писался на другом языке, более приличном, а в JS потом транслировался компилятором, так что ужасы JS-как-языка тут нерелевантны.

Пардон за буквоедство, но вроде ж существует распространенный термин для трансляции ЯВУ в ЯВУ — transpiler (транспилятор).

Ты пошто LISP сюда приплел, изверг?

В подобного типа задачах важен не только оптимизированный исполняемый код на выходе, но и правильные структуры данных с cache-friendly раскладкой по памяти, и хитрый lock–free (в случае параллелизма с разделяемой памятью).

Параллелизм с разделяемой памятью, я так понимаю, в текущем js принципиально невозможен?
Остается кастомизируемость отображения структур данных на память и дружественность к кешу. Как с этим обстоят дела в javascript?

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

SE>Пардон за буквоедство, но вроде ж существует распространенный термин для трансляции ЯВУ в ЯВУ — transpiler (транспилятор).

Haxe умеет как компилировать в байткод нескольких платформ (например Flash и Neko), так и транслировать в исходники на нескольких языках.
https://haxe.org/documentation/introduction/compiler-targets.html
И каким словом его называть?

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

SE>В подобного типа задачах важен не только оптимизированный исполняемый код на выходе, но и правильные структуры данных с cache-friendly раскладкой по памяти, и хитрый lock–free (в случае параллелизма с разделяемой памятью).

Все так. И именно тут средний JS будет сильно сливать С++, ибо банально индирекций больше и с кэшированием похуже. Это одна из основных причин различия в скорости в этом примере. Еще одна — проверка индексов массивов, а с массивами тут очень много работы.

SE>Параллелизм с разделяемой памятью, я так понимаю, в текущем js принципиально невозможен?

Насколько мне известно, именно так.

SE>Остается кастомизируемость отображения структур данных на память и дружественность к кешу. Как с этим обстоят дела в javascript?

Там есть плоские типизированные массивы чисел, и если очень постараться, можно все данные разместить в одном таком массиве и получить "как в Си", только с постоянными bounds checks. Так как раз делалось в ASM.js, так же (?) вроде обстоят дела в WebAssembly. Разумеется, писать код в таком режиме тяжело, и накладных расходов на извлечение и конверсию данных может быть немало.
Помимо этих массивов дела могут обстоять довольно по-разному в разных реализациях JS (читай — в разных браузерах). Основная структура данных — объект, и как там ложатся данные зависит от того, как он создается и используется. Например, v8 (Хром и родственники) выделит заранее место под все поля, что упоминаются в функции-конструкторе, а если потом будут поля добавляться, они уже идут в хэш-таблицу дополнительную. Банальные целые числа тоже могут храниться по-разному в зависимости от того, что за число и что с ним делают. Маленькие целые лежат одним образом, большие — другим, вещественные — третьим. Большие целые и float'ы часто могут бокситься. И опять все зависит от конкретного интерпретатора, сам язык особых гарантий не дает. Явным образом не покастомизируешь, только подгадывать под поведение популярных JS движков. В итоге боксинга и индирекций получается заметно больше, чем в С/С++, что сказывается на скорости.

DM>по-разному в разных реализациях JS (читай — в разных браузерах).
DM>v8 (Хром и родственники) ...
DM>И опять все зависит от конкретного интерпретатора, сам язык особых гарантий не дает.

Oтсутствие спецификаций и отданные на откуп вендорам детали реализации — это как раз то, что очень сильно раздражает в JS. Уж лучше Java с тоннами JSR на каждый чих.

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

SE>Уж лучше Java с тоннами JSR на каждый чих.

Увы, в браузерах джава себя не оправдала и теперь по сути забанена.