asm.js - frequently asked questions

Q. Is asm.js a new language?
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!

Q. What kind of performance benefits can I expect to get with asm.js?
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.

Q. How can I track implementation progress?
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.

Q. Why don't you specify a bytecode syntax instead of strange JavaScript idioms?
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.

Q. Does the fact that asm.js is JavaScript mean you can't get predictable performance?
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.

Q. Why not NaCl or PNaCl instead? Are you just being stubborn about JavaScript?
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.

Q. Why not just keep optimizing JavaScript JIT compilers instead?
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.

Q. Isn't it inefficient to have to run the code through a JavaScript interpreter before compiling?
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.

Q. How can developers get good feedback if their code fails to validate?
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.

Q. How can developers debug asm.js code?
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.

Q. Can asm.js serve as a VM for managed languages, like the JVM or CLR?
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.

Q. Is asm.js compatible with `eval` and `Function`? Can you dynamically invoke the asm.js compiler?
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.

Q. How much of a compile-time hit does asm.js incur?
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.

Q. Can asm.js help with application startup times?
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.