Часто задаваемые вопросы про asm.js

[alexanderzaytsev]

На главный вопрос не ответили: «asm.js — что это вообще?»

[Mithgol]

Непосредственно по адресу http://asmjs.org/faq.html нет ответа на этот вопрос.

Впрочем, я могу взять на себя смелость забрать ответ с заглавной странице http://asmjs.org/ и поместить его в начало переведённого мною FAQ, оформив наподобие цитаты.

Благодарю за плодотворное замечание.

[alexanderzaytsev]

Так лучше, спасибо.

[Indexator]

Другою важною пользою

ликодлань

[jetman]

Похоже Mozilla собирается сделать asm.js официальным языком для возможного Native SDK под Firefox OS вместо обычного C++ SDK. Главное, чтобы POSIX API нормально эмулировался и, думаю, никто не будет против.

[Gorthauer87]

Чем же оно лучше, чем LLVM IR?

[megalol]

Не надо llvm?

[Gorthauer87]

А есть какие-то сложности с использованием llvm? Он вообще везде есть уже практически.

[megalol]

Зависимостью меньше. Javascript-то по-любому нужен. Я думаю, пункт «Почему бы тогда не NaCl или PNaCl вместо этого?» к llvm относится тоже. Текущий двухкратный оверхед их явно не парит.

[mraleph]

LLVM IR оно на самом деле IR и есть, т.е. промежуточное представление.

Есть очень хорошее письмо на эту тему от одного из разработчиков LLVM: lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/043719.html

У него есть проблемы с переносимостью, оно слишком низкоуровневое и быстренько сгенерировать из него хороший код не так-то просто.

Тут правда стоит заметить две вещи:

a) Emscripten генерирует JavaScript / asm.js как раз из LLVM IR (т.е. фактически asm.js это высокоуровневый переносимый формат для LLVM IR :-)),

b) Mozilla не сообщает накиках чисел о том, как быстро asm.js валидируется и компилируется (есть основания полагать, что там не все так радужно, David Herman даже писал, что они рассматривают вариант с кэшированием сгенерированного нативного кода).

[jetman]

Уже ведётся работа над портированием OdinMonkey (оптимизирующий компилятор asm.js) на ARM: bugzilla.mozilla.org/show_bug.cgi?id=840285

[Caiiiycuk]

Жду и надеюсь что это решит проблемы производительности emscripten. Однако, боюсь за то что корпорация добра их не поддержит. Сейчас FF серьезно отстает в производительности по сравнению с Chrome на моих проектах. Думаю asm.js подтянит их к результатам Chrome. Есть подозрение что v8 итак достаточно оптимален в этом плане и никакой asm.js ему уже не поможет. Хотя кто знает, если внедрение asm.js в Chrome даст двукратное увеличение производительности, то в TTD уже можно будет аще комфортно играть на больших картах.

[Caiiiycuk]

Кстате Alon Zakai (emscripten) в рассылки сообщил, что asm.js бэкенд уже готов и может быть использован повсеместно. Кроме проектов использующих исключения и setjmp/longjmp.

Оригинал

asm.js code generation mode (-s ASM_JS=1) no longer shows the «this is
experimental/not recommended» warning. It's fairly robust at this
point, appears to withstand fuzzing, generates faster code in most
cases even without special JS engine optimizations (but with such
optimizations is significantly faster still), and we've used it on
some large and complex codebases successfully.

It doesn't yet support C++ exceptions or setjmp/longjmp, but aside
from that should be considered ready for general use. It will likely
become the default code generation mode once those limitations are
fixed and we have a minifier for it.

[Mithgol]

Кстати упомяну, что он и в презентации нечто подобное про исключения и про setjmp/longjmp говорил.

[mraleph]

У V8 на самом деле есть ряд проблем с кодом, который emscripten выдает, многие из них правда asm.jsом не решаются, надо просто инфраструктуру чинить (например, проблемы при огромном количестве локальных переменных), некоторые решаются, но уж лучше их починить в общем случае (например, недостаточная хорошая протяжка информации о типах в пределах одного метода).

asm.js впрочем позволяет выделывать трюки, которые над обычным JS не так-то просто совершать: например, на x64 выкинуть все array bounds check и вместо это использовать перехват segfault для обнаружения доступа за границы кучи-типизированного массива.

[leotsarev]

Это сравнение производительности. Речь идет о программах на языке C, скомилированных Emscripten и исполненных разными движками.
odin — это FF с поддержкой asm.js, sm — чистый firefox, v8 — chrome.
odin (now) odin (next) sm v8 skinning 2.80 2.46 12.90 59.35 zlib 2.02 1.61 5.15 5.95 bullet 2.16 1.79 12.31 9.30

1.0 —это производительность той же программы, скомпилированной напрямую gcc.
bugzilla.mozilla.org/show_bug.cgi?id=840282

[rock]

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

[mraleph]

Мне вот интересно, для чего бы вы его использовали? Руками такой код писать удовольствия мало.

[rock]

Да, иметь дело исключительно с числами, математикой и кучей — типизированным массивом — не самое приятное, но уж лучше написать «use asm», чем гадать прошелся здесь оптимизирующий компилятор v8 или нет. Да, «все советы по оптимизации бесполезны в 99% случаев», но иногда, очень редко, хочется выжать максимум. Хотяб во фреймворке, который после много лет используешь.

Кстати, давно вас онлайн хотел поймать, была пара нубских вопросов по особенностям v8:)

[mraleph]

Да предсказуемость, это, конечно, один из козырей asm.js и она действительно тот самый 1% бъет в яблочко на некоторых задачах. Правда бъёт она не в стиле «а мы тут немного затюним», а в стиле «а сейчас надо вычислительное ядро переписать на С++». Как по мне, так уж лучше бы мы эти 99% медленно превратили в 99.9%, а потом в 99.99% и так далее, чем сразу такая капитуляция.

Кстати, давно вас онлайн хотел поймать, была пара нубских вопросов по особенностям v8:)

А меня просто поймать, можно написать в личку или на почту [e-mail] (или рабочую) :-)