Last Comment Bug 840282 - Land OdinMonkey (asm.js optimizing compiler)
: Land OdinMonkey (asm.js optimizing compiler)
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: unspecified
: All All
-- normal with 12 votes (vote)
: mozilla22
Assigned To: Luke Wagner [:luke]
: Steven DeTar [:sdetar]
Depends on: odinfuzz 840280 840281 840283 840285 850052 851787 852107 852356 913876 970643
Blocks: 851880 868184
  Show dependency treegraph
Reported: 2013-02-11 14:38 PST by Luke Wagner [:luke]
Modified: 2018-06-03 11:46 PDT (History)
75 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image Luke Wagner [:luke] 2013-02-11 14:38:54 PST
This is the tracking bug for landing OdinMonkey.  (OdinMonkey is the project name for SpiderMonkey's optimizing compiler for asm.js (, built on top of the IonMonkey backend.)

Current results on large Emscripten codebases are as follows, reported as factor slowdown compared to gcc -O2 (so 1.0 would mean "same speed"):

             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

"odin (now)" is what you get on trunk.  "odin (next)" is after we remove some dynamic checks by using signal handlers.  BananaBread is also compiling and running asm.js and showing a nice speedup over SM/V8 (2-4x) when running headless, but we'll need to get float32 support before we can do an apples-to-apples comparison vs. C++.

There are several further optimizations we know of for which we don't have measurements yet:
but we feel that the current results are convincing enough to land now and continue optimizing afterwards.

The code is currently in a user repo ('hg diff -r trunk' to see the diff):

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.  (No further invalidation/deoptimization can occur.)

This bug can be used for reviewing the code for landing.  Before that, though, there are several remaining work items which I'll file as blocking this bug.
Comment 1 User image Luke Wagner [:luke] 2013-03-15 04:32:45 PDT
Desktop x86/x64 is in a good initial state: we're continuing to see a nice 2-3x speedup on large JS-bound codebases and we've gotten a significant amount of testing: the Emscripten/LLVM test-suite, a C fuzzer feeding into Emscripten into Odin, and decoder's mutation-based fuzzer running on existing asm.js codes.  Based on this, I've seen consensus that it is a good idea to land desktop-Odin support now and continue work incrementally on trunk.  In particular, ARM (bug 840285) and some big load-time improvements for huge codes (bug 850070 and bug 851421) are coming soon.

Since we expect asm.js to change (in response to feedback from other JS engine teams and our own future work), I've put Odin behind the pref javascript.options.experimental_asmjs. Following current practices for other new features in FF, this pref defaults to "on" on nightly/aurora and "off" on beta/release.  We can rename it to just "asmjs" when we've reached a fixed point on asm.js (v.1).

I'll leave this bug open until ARM is done and then we can move on to a new [meta] bug for future work.
Comment 2 User image Ted Mielczarek [:ted] [:ted.mielczarek] 2013-03-15 05:09:58 PDT
We never fixed bug 842728. Does that need to block something?
Comment 3 User image Luke Wagner [:luke] 2013-03-15 09:04:12 PDT
(In reply to Ted Mielczarek [:ted.mielczarek] from comment #2)
> We never fixed bug 842728. Does that need to block something?

It would/will help with testing, but it doesn't block anything.
Comment 4 User image Landry Breuil (:gaston) 2013-03-16 01:16:50 PDT
js/src/ion/RegisterSets.h:461:2: error: #error "Bad architecture"

This broke powerpc.
Comment 5 User image Phil Ringnalda (:philor) 2013-03-16 15:56:58 PDT
Comment 6 User image Luke Wagner [:luke] 2013-03-17 15:17:24 PDT
Unfortunately, I've had to temporarily disable OdinMonkey on OSX:

Bug 851964 filed to reenable.

Note You need to log in before you can comment on or make changes to this bug.