вебмастер, фидошник
0,0
рейтинг
4 марта 2013 в 17:36

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

asm.js — необыкновенно оптимизируемое, низкоуровневое подмножество JavaScript. asmjs.org

asm.js — новый язык?


Нет, это просто подмножество JavaScript. Программа на asm.js одинаково поведёт себя и в существующих движках JavaScript, и в движке с предварительной (ahead-of-time, AOT) компиляцией, способном распознавать и оптимизировать asm.js; различаться будет её скорость, разумеется!

Какой выигрыш в производительности можно ожидать от asm.js?


Сейчас ещё рано утверждать. Однако наши предварительные измерения производительности программ, скомпилированных из Си в asm.js, показывают не более чем двукратное замедление по сравнению с компилированными в машинный код посредством clang. Мы опубликуем дальнейшие измерения, когда насобираем их.

Как я могу следить за ходом реализации?


Мозилла работает над первой реализацией оптимизирующего компилятора asm.js для SpiderMonkey. В вики Фонда Мозиллы также опубликован план разработки дальнейших выпусков и оптимизаций. Если авторы других движков JavaScript опубликуют собственные планы реализации компиляторов asm.js, мы их здесь упомянем.

Почему бы вам не разработать синтаксис байткода вместо необычного диалекта джаваскрипта?


Для компиляторов наподобие Emscripten или Mandreel синтаксис байткодового языка попросту не особенно значим. Притом большинство байткодов и вообще машинных языков имеют двоичный формат, не читаемый людьми. Однако мы можем создать на уровне asm.js более человеко-читаемый синтаксис, который будет и удобным в дизассемблировании, и пригодным для чтения и записи людьми.

То обстоятельство, что asm.js — это JavaScript, не обернётся ли непредсказуемым выполнением кода?


Предварительная (ahead-of-time, AOT) компиляция asm.js может генерировать код, выполнение которого весьма предсказуемо, потому что валидный код asm.js ограничен крайне небольшим подмножеством JavaScript, состоящим только из строго типизированных целых чисел, чисел с плавающей точкою, арифметических операций, вызовов функций и обращения к куче.

Почему бы тогда не NaCl или PNaCl вместо этого? Вы просто упорствуете насчёт JavaScript?


Принципиальным достоинством asm.js по сравнению с новыми технологиями вроде NaCl и PNaCl является то, что asm.js работает сегодня: существующие движки JavaScript ужé неплохо оптимизируют код, написанный в таком стиле. Что означает, что разработчики могут выпускать код на asm.js сегодня, а со временем его работа будет ускоряться. Другою важною пользою является заметно бóльшая простота реализации, для которой потребуется совсем немного дополнительных механизмов поверх существующих движков JavaScript — и не понадобится слой совместимости API.

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


А и нет нужды останавливать её! Однако поведение JIT-компиляторов менее предсказуемо, будучи основано на сложных эвристиках. Модель asm.js более подобна модели Си или Си++, избавляя язык от динамической типизации, от обёрнутых значений, от сборки мусора.

Разве не неэффективно — прогонять код через интерпретатор JavaScript, а затем через компилятор?


Пролог-директива позволяет движку JavaScript немедленно распознать код asm.js на этапе компиляции и немедленно переводить его на язык ассемблера. Такой код вообще не попадает в интерпретатор.

Какая обратная связь предусматривается для разработчиков на тот случай, если их код не проходит валидацию?


Пролог-директива указывает на намерение разработчика считать последующий код валидным asm.js. Если код не проходит валидацию, то об ошибке движок может сообщить разработчику, например, в отладочной консоли, или другими средствами.

Как разработчики могут отлаживать код asm.js?


В целом эта проблема ещё не решена по отношению к языкам, компилируемым для WWW. Карты исходного кода (source maps) могут помочь делу, но браузерам предстоит ещё много работы по улучшению процессов отладки компилированного кода.

Может ли asm.js служить виртуальною машиною для управляемых языков, наподобие JVM или CLR?


В настоящее время код asm.js не имеет прямого доступа к данным, подвергаемым сборке мусора: программа на asm.js может обращаться ко внешним данным лишь косвенно, по числовым идентификаторам их. В будущих версиях мы намерены внедрить сборку мусора и структурированные данные на основе API структурированных двоичных данных ES6, что повысит привлекательность asm.js в качестве средства выполнения управляемых языков.

Совместим ли asm.js с вызовами eval и Function? Можно ли динамически запускать компилятор asm.js?


Безусловно! Компиляция модуля asm.js происходит во время обработки его исходного кода. Если вы запустите эту обработку, вызвав eval или Function, то полýчите динамическую компиляцию.

Сколь велики издержки, вызываемые временем компиляции asm.js?


Валидация и компиляция происходят довольно быстро, но всё же это приводит к некоторым издержкам, хотя и только по отношению к коду asm.js: если код JavaScript не содержит пролога-директивы asm.js, то не подвергается никакой дополнительной обработке. Если вы желаете избегнуть задержки, связанной с немедленной валидацией и компиляцией кода asm.js, то можете позже использовать eval или Function и отложить компиляцию до того времени.

Может ли asm.js благотворно повлиять на время запуска приложений?


Мы планируем предложить дополнительные API, которые обеспечат веборазработчикам возможность компиляции asm.js в фоне, а также сохранение результатов компиляции в оффлайновое хранилище, что ускорит последующие начальные запуски приложения.
Перевод: Фонд Мозиллы
Mithgol the Webmaster @Mithgol
карма
60,5
рейтинг 0,0
вебмастер, фидошник
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (21)

  • +28
    На главный вопрос не ответили: «asm.js — что это вообще?»
    • +1
      Непосредственно по адресу http://asmjs.org/faq.html нет ответа на этот вопрос.

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

      Благодарю за плодотворное замечание.
      • +1
        Так лучше, спасибо.
      • +4
        Классное объяснение!

        Переведите лучше вот этот документ, из него хотя бы становится понятно, что такое asm.js.
  • +24
    Другою важною пользою
    ликодлань
  • +3
    Похоже Mozilla собирается сделать asm.js официальным языком для возможного Native SDK под Firefox OS вместо обычного C++ SDK. Главное, чтобы POSIX API нормально эмулировался и, думаю, никто не будет против.
    • +1
      Чем же оно лучше, чем LLVM IR?
      • +2
        Не надо llvm?
        • 0
          А есть какие-то сложности с использованием llvm? Он вообще везде есть уже практически.
          • 0
            Зависимостью меньше. Javascript-то по-любому нужен. Я думаю, пункт «Почему бы тогда не NaCl или PNaCl вместо этого?» к llvm относится тоже. Текущий двухкратный оверхед их явно не парит.
      • 0
        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 даже писал, что они рассматривают вариант с кэшированием сгенерированного нативного кода).
    • 0
      Уже ведётся работа над портированием OdinMonkey (оптимизирующий компилятор asm.js) на ARM: bugzilla.mozilla.org/show_bug.cgi?id=840285
  • +2
    Жду и надеюсь что это решит проблемы производительности emscripten. Однако, боюсь за то что корпорация добра их не поддержит. Сейчас FF серьезно отстает в производительности по сравнению с Chrome на моих проектах. Думаю asm.js подтянит их к результатам Chrome. Есть подозрение что v8 итак достаточно оптимален в этом плане и никакой asm.js ему уже не поможет. Хотя кто знает, если внедрение asm.js в Chrome даст двукратное увеличение производительности, то в TTD уже можно будет аще комфортно играть на больших картах.
    • +2
      Кстате 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.
      • 0
        Кстати упомяну, что он и в презентации нечто подобное про исключения и про setjmp/longjmp говорил.
    • +1
      У V8 на самом деле есть ряд проблем с кодом, который emscripten выдает, многие из них правда asm.jsом не решаются, надо просто инфраструктуру чинить (например, проблемы при огромном количестве локальных переменных), некоторые решаются, но уж лучше их починить в общем случае (например, недостаточная хорошая протяжка информации о типах в пределах одного метода).

      asm.js впрочем позволяет выделывать трюки, которые над обычным JS не так-то просто совершать: например, на x64 выкинуть все array bounds check и вместо это использовать перехват segfault для обнаружения доступа за границы кучи-типизированного массива.
    • 0
      Это сравнение производительности. Речь идет о программах на языке 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
  • +1
    Все это замечательно, с удовольствием бы использовал. Но как с перспективами внедрения в другие javascript движки?
    • 0
      Мне вот интересно, для чего бы вы его использовали? Руками такой код писать удовольствия мало.
      • 0
        Да, иметь дело исключительно с числами, математикой и кучей — типизированным массивом — не самое приятное, но уж лучше написать «use asm», чем гадать прошелся здесь оптимизирующий компилятор v8 или нет. Да, «все советы по оптимизации бесполезны в 99% случаев», но иногда, очень редко, хочется выжать максимум. Хотяб во фреймворке, который после много лет используешь.

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

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


          А меня просто поймать, можно написать в личку или на почту me@mrale.ph (или рабочую) :-)

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.