asm.js vs "a Javascript messze van a gepi kodtol"

The compiler can emit fast native code translations of JavaScript functions on the ARM, x86, and x86-64 platforms. It is the default engine since Firefox 18.

OdinMonkey

https://bugzilla.mozilla.org/show_bug.cgi?id=840282

(OdinMonkey is the project name for SpiderMonkey's optimizing compiler for asm.js (http://asmjs.org), built on top of the IonMonkey backend.)

At a high level, the interaction with the VM is as follows (see AsmJS.h):

1. After parsing (before emitting) a function, the frontend calls CompileAsmJS. CompileAsmJS performs type checking (a simple traversal of the parse tree) and simultaneously emits fully type-specialized IonMonkey MIR nodes.

2. If type checking succeeds, the entire asm.js module (collection of functions) is compiled by the IonMonkey backend and attached to the script. (Later, we'll do this in parallel and block in step 5.)

3. The frontend emits the script as bytecode with the first op being JSOP_LINKASMJS which, when executed, performs the dynamic validation of arguments as defined in the asm.js spec.

4. If the dynamic validation succeeds, the asm.js module's exports are returned as native functions that trampoline into the compiled code.

Things that slow down JavaScript

http://www.2ality.com/2013/02/asm-js.html

Current JavaScript is already quite fast, but a few mechanisms in engines limit its speed:
- Boxing (...),
- Just-in-time (JIT) compilation and runtime type checks (...),
- Automated garbage collection (...),
- Flexible memory layout (...)

asm.js code can produce executables that exhibit none of these drawbacks. They can be compiled “ahead of time” (before execution) and are faster than JIT-compiled ones.