asm.js - frequently asked questions

A. No, it's just (a subset of) JavaScript. An asm.js program will behave identically whether it is run in an existing JavaScript engine or an ahead-of-time (AOT) compiling engine that recognizes and optimizes asm.js—except for speed, of course!

A. It's early to say, but our preliminary benchmarks of C programs compiled to asm.js are usually within a factor of 2 slowdown over native compilation with clang. We will publish more benchmarks as we collect them.

A. Mozilla is working on a first implementation of an optimizing asm.js compiler for SpiderMonkey. Mozilla also has a development roadmap for future features and optimizations. If other JavaScript engines publish plans to implement asm.js compilers we'll include them here.

A. For compilers like Emscripten or Mandreel, the syntax of a bytecode language simply isn't that important. In fact, most bytecode and machine languages have non-human-readable binary formats. However, we may create a more human-readable surface syntax for asm.js, which could be used for convenient disassembly and human read/write-ability.

A. An ahead-of-time (AOT) compiler for asm.js can generate code with very predictable performance, because validated asm.js code is limited to an extremely restricted subset of JavaScript that provides only strictly-typed integers, floats, arithmetic, function calls, and heap accesses.

A. The principal benefit of asm.js over whole new technologies like NaCl and PNaCl is that it works today: existing JavaScript engines already optimize this style of code quite well. This means that developers can ship asm.js today and it'll simply get faster over time. Another important benefit is that it's far simpler to implement, requiring very little additional machinery on top of existing JavaScript engines and no API compatibility layer.

A. No need to stop! But JIT compilers have less predictable performance based on complicated heuristics. The asm.js model provides a model closer to C/C++ by eliminating dynamic type guards, boxed values, and garbage collection.

A. Because of the directive prologue, a JavaScript engine can immediately recognize asm.js code at compile-time and immediately compile it to assembly language, with no need to ever run the code through an interpreter.

A. The directive prologue identifies the developer's intention that code should be considered valid asm.js. If the code fails to validate, the engine can report the validation error to e.g. a developer console or other developer tools.

A. This is a problem in general with compiling for the web. Source maps can help, but browsers do have more work to do to make debugging compiled code a smoother experience.

A. Right now, asm.js has no direct access to garbage-collected data; an asm.js program can only interact indirectly with external data via numeric handles. In future versions we intend to introduce garbage collection and structured data based on the ES6 structured binary data API, which will make asm.js an even better target for managed languages.

A. Absolutely! Compilation of an asm.js module happens at parse time of the source code. If you trigger that parse time with `eval` or `Function` then you get dynamic compilation.

A. Validation and compilation are pretty fast but they do incur a compile-time cost, but only for asm.js code—code that does not contain the asm.js directive prologue does not need any additional processing. If you want to avoid the up-front cost of validating and compiling asm.js code, you can use `eval` or `Function` to delay compilation to a later point.

A. We intend to propose additional web API's to make it possible to compile asm.js in background threads and to store the results of compilation in offline storage, making it possible to start up faster in future application loads.