ASM.JS. Источники знаний.

[kobezzza]

emscripten

Это транслятор из LLVM в ASM.js, т.е. пишешь на C/C++, компилишь через Clang, потом через emscripten в JS.

А так:

(function () {
    'use asm';

    // Тут пишем наш азм
})();

[Voronar]

Да, интересно услышать про манипуляции с DOM (всё-таки DOM - это фундамент классического веб-приложения то бишь сайта ). Есть ли ускорение по сравнению с JS?

[kobezzza]

Да, интересно услышать про манипуляции с DOM (всё-таки DOM - это фундамент классического веб-приложения то бишь сайта ). Есть ли ускорение по сравнению с JS?

У вас явное недопонимание, что же такое ASM.js.

DOM API - это браузерное АПИ, не имеющее абсолютно никакого отношения к JS, потому использование ASM.js никак не сможет повлиять на это.

ASM.js - это отсутствие сборщика мусора (т.е. ручное управление памятью), явная строгая типизация и AOT вместо JIT.

В общем основная задача ASM.js - это портирование низкоуровневых программ, например, на C/C++ в JS.

[Voronar]

Я поэтому и спрашиваю, что у меня есть недопонимание.

То есть не имеет смысла использовать asm.js для ускорения производительности в пользовательских веб-интерфейсах?

[kobezzza]

То есть не имеет смысла использовать asm.js для ускорения производительности в пользовательских веб-интерфейсах?

Нет (да и зачем? там и так всё летает, если не говнокодить)

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

Например, игровой движок Unreal Engine 4 умеет компилиться в ASM.js, а там производительность критична.

[Voronar]

А если говорить о desktop-подобных веб-приложениях и той же 2d-графики в <canvas>, реализованных на JS? Лично я заметил, что-подобные вещи очень сильно нагружают среднестатистический компьютер.

[kobezzza]

А если говорить о desktop-подобных веб-приложениях

Сейчас веб-приложение уже ничем не отличается от десктопа, но если нужно написать аналог Фотошопа, то для работы с графикой: трансормация, эффекты и т.д. ASM.js даст сильный профит.

<canvas>, реализованных на JS?

Canvas - это HTML5 тег который никакого отношения к JS не имеет.

У Canvas есть 2 контекста:

1) 2d - простой АПИ, изначально работало на CPU, но сейчас браузеры могут использовать и GPU для ускорения;

2) webGL - порт OpenGL ES, позволяет писать программы напряму на GPU (c помощью GLSL шейдеров - это С, а не JS) и может работать очень быстро.

Но опять таки, к JS это отношения не имеет. Вот если мы решим написать физический движок, то там будет много сложных вычислений и ASM.js даст сильный профит.

Пример 2D игры на Unreal Engine, скомпиленный в JS: https://www.unrealengine.com/html5
http://beta.unity3d.com/jonas/DT2/ - демка unity 5 скомпиленного в JS

Лично я заметил, что-подобные вещи очень сильно нагружают среднестатистический компьютер

Всё зависит от рук, современные браузеры работают ну очень быстро.

[Voronar]

Например, при активном использовании разных виджетов мой процессор (Intel® Core™ i5-4570 CPU @ 3.20GHz × 4, Ubuntu 14.04 32-bit) грузится больше чем на 60%. Это, если честно, неприлично много. Вот вам и "летает", но за какую цену.
Ну не подходит JS (ES5) для таких серьёзных вещей, а терять связь на уровне удобных манипуляций с HTML/CSS не хочется.
Кстати, в случае использования ES6 производительность повысится или всё таки лучше смотреть в сторону Dart/TypeScript или Cheerp?

Я правильно понимаю смысл EcmaScript? По сути, это просто стандарт языка, а его производительность будет зависеть от реализации интерпретатора в веб-движке? То есть с новым стандартом выйдет обновленный, более быстрый движок?

[kobezzza]

Я же вам уже 3-й раз обьясняю - DOM не имеет отношения к JS, поэтому смена языка никак не скажется на производительности. Вы для начала поймите что у вас тормозит, а потом уже рвитесь оптимизировать

Ну не подходит JS (ES5) для таких серьёзных вещей,

Ой вот не нужно фантазироваться, я 8 лет в этом деле и каких хреновин только не писал и всё замечательно работало. Касательно EXTJS - это просто интерпрайз тяжеловес, т.е. не нужно обвинять платформу, если у вас тормозит библиотека.

Кстати, в случае использования ES6 производительность повысится или всё таки лучше смотреть в сторону Dart/TypeScript или Cheerp?

ES6 - это не новый язык, а эволюционное развитие старого, поэтом VM у них одна и таже. Некоторые оптимизацию в ES6 есть, например, оптимизация хвостовых рекурсий, но в основном - это сахар.

TS, Dart и т.д. - это языки которые транслируются в JS (у Darta есть своя VM, но она нигде не юзается сейчас), т.е. на выходе тот же JS. Ещё раз, всё зависит от рук, т.к. сейчас JS один из самых быстрых скриптовых языков в мире (кстатим есть хорошее правило написания быстрого JS: пишите код так, как писали бы его на C), но никто не отменял гавнокод

Я правильно понимаю смысл EcmaScript? По сути, это просто стандарт языка, а его производительность будет зависеть от реализации интерпретатора в веб-движке?

Да, ES - это стандарт, реализаций у JS вагон: V8, SpiderMonkey, Nitro, Nashorn, Rhino, JSCore и т.д.

То есть с новым стандартом выйдет обновленный, более быстрый движок?

Нет, скорость движка зависит только от его создателей.

[kobezzza]

А вообще чего я вас отговариваю: пишите на ASM.js, только учтите, что там 90% ASM и только 10% JS