On Firefox (which originally introduced it), finding "use asm" at the top of the script makes a subset of JavaScript faster by enabling an Ahead-Of-Time optimizing compiler. See http://badassjs.com/post/43420901994/asm-js-a-low-level-high.... From what I understand, "asm.js" code without the "use asm" directive in Firefox would run slower because it wouldn't check it for compliance with the asm.js subset and enable the specialized AOT codepath.
It's an interesting approach but feels a bit like over-specialization. The V8 guys on the other hand, decided to ignore the directive entirely and have been able to improve their (more "generic") JIT compiler to get it to run the same code almost as fast as Firefox's Ahead-Of-Time compiler in a lot of cases.
There is no difference in approach between Firefox and Chrome there, both believe JITs can achieve excellent performance, and are always pushing that further. So both browsers "ignore" the "use asm" hint in that sense. The only difference is that Firefox, in addition, has an asm.js AOT module that detects asm.js and can optimize it very well (using the same backend as the JIT, but taking advantage of type information from the asm.js type system). But that AOT does not mean anything about the rest of the JS engine.
So conceptually, the only thing that "use asm" does (in Firefox) is to tell the optimizer/JIT/whatever to assume certain types in advance rather than having it infer them at runtime?
Pretty much, yeah. The normal JIT is used, but first Firefox type checks the asm.js code, during which it detects all the types. Then it just tells the JIT what those types are. This reuses existing functionality in the JIT, as all modern JITs have mechanisms to receive type information - it's typically collected by monitoring types at runtime, the only difference is that here the types are collected through the asm.js type checker.
There are also a few runtime changes as well with asm.js code. For example, the JS engine knows that asm.js code cannot throw exceptions (asm.js code is very low-level, so JS exceptions are not possible), so it can avoid emitting some things it would normally emit in order to handle deopts due to exceptions and so forth. (Of course this does not require an AOT, a JIT could also detect the lack of need for that overhead, perhaps this is already done in some cases, but the AOT guarantees it is done for all asm.js code.)
One key benefit to asm.js is that it turns of garbage collection. Given that GC pauses are still a major nuisance (seriously, try simply flashing a div or canvas in a requestAnimationFrame loop, and you'll see it even in recent versions of Chrome), that is potentially a major win for game development.
Of course, the real solution is to fix the garbage collector, or (maybe) better yet, give user code a way to switch GC algorithms based on app-specific needs. Until then, the ability to manually manage memory is nothing to sneeze at.
asm.js does not turn off garbage collection. Instead, programs written in this style do not allocate many objects, so the garbage collector does not need to run much. asm.js programs allocate a single giant block of memory, and then do their own psuedo-manual-memory-management within that block.
>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.
He's saying it eliminates garbage collection by emitting code that doesn't dynamically allocate any objects. The GC is still active it just never needs to do anything. If you remove the 'use asm' pragma the code will still not allocate any objects and hence the GC will still never need to do anything.
Ah, I see what you're saying. The point being that you still have the GC for any non-asm.js code on the same page. And I suppose by the same token, you could "opt out" of GC without asm.js by using various techniques to eliminate allocations.
It's an interesting approach but feels a bit like over-specialization. The V8 guys on the other hand, decided to ignore the directive entirely and have been able to improve their (more "generic") JIT compiler to get it to run the same code almost as fast as Firefox's Ahead-Of-Time compiler in a lot of cases.