|
|
| (264 intermediate revisions by 4 users not shown) |
| Line 1: |
Line 1: |
| == Goal ==
| | OdinMonkey was the optimizing AsmJS compiler. |
|
| |
|
| Provide an optimized implementation of the (co-evolvoing) [https://github.com/dherman/asm.js/blob/master/tex/def.pdf asm.js spec] which achieves near-native performance (within 2x of -O2) on JS generated from C/C++ (with the pilot code generator being [https://github.com/kripken/emscripten Emscripten]).
| | [[File:Odinmonkey800.jpg]]<br> |
| | | Credit to John Howard |
| == Status ==
| |
| | |
| The project is currently in a '''research''' phase with the major evaluation criteria being to get several large-scale Emscripten apps ([https://developer.mozilla.org/en-US/demos/detail/bananabread BananaBread], zlib, and Bullet) running and showing the target performance. At this point, we can make the informed decision to transition to an engineering project.
| |
| | |
| The code is currently available as a [http://hg.mozilla.org/users/lwagner_mozilla.com/inbound-patches patch queue] based on [https://hg.mozilla.org/integration/mozilla-inbound mozilla inbound]. Unit tests (which can serve as example code) are in <code>js/src/jit-tests/tests/asm.js/</code>.
| |
| | |
| The entire asm.js language has been implemented. Most of the (smaller) Emscripten benchmarks are running and coming in under 2x. The three big benchmarks are in: zlib is right at 2x, Bullet is more like 2.3x (we think it needs float32), BananaBread doesn't have a comparison w/ native yet but we are seeing a 4x speedup over general IonMonkey/V8.
| |
| | |
| Remaining experimental work:
| |
| * Get BananaBread working in the browser (with Alon's sweet deterministic harness).
| |
| | |
| == Tasks before initial landing ==
| |
| | |
| * Tier 1 platform support (remaining):
| |
| ** x64 (Windows)
| |
| ** x86 (Windows, Unix), using segment registers
| |
| ** ARM
| |
| * Safety
| |
| ** Add slow-script and stack-overflow checks (to be removed later).
| |
| ** Fix that pesky x64 call-out-of-range TODO by using a single linear allocation.
| |
| * Quality
| |
| ** Fuzz (with decoders mutation-based fuzzer based on existing asm.js programs)
| |
| * Engine integration:
| |
| ** Error.stack should include asm.js frames
| |
| ** SPS's profiler stack should work as well
| |
| * Audit Odin code for OOM-safety.
| |
| * Final polish on error messages
| |
| * Unbreak IonSpew
| |
| | |
| == Further work (after initial landing) ==
| |
| | |
| * Optimize asm.js-to-Ion transition with custom-generated exit stub
| |
| * Add DataView to asm.js to allow us to avoid masking on loads/stores
| |
| ** Measure how much it'll win us (so far, 20% on zlib)
| |
| ** Signal-handler support
| |
| ** Investigate this 32-bit/64-bit register slicing issue
| |
| ** Investigate using fs/gs on x64
| |
| * Avoid slow-script and stack overflow checks with signal handler support
| |
| * Add a float32 type to asm.js to allow 32-bit float arithmetic
| |
| ** Measure how much it'll win us
| |
| ** Add float32 versions of all the IM float64 ops.
| |
| * Optimize idiv (using signal handler for FP exception)
| |
| * Optimize double-to-int conversion (using signal handler for FP exception)
| |
| * FunctionBlob (TODO: link to proposal)
| |
| ** Efficient transfer between workers
| |
| ** Efficient IndexedDB serialization/deserialization
| |
| * Full GVN/range analysis support for all the new asm.js IM MIR nodes
| |
| * ToInt shouldn't generate so much code
| |
| | |
| == General IonMonkey optimizations ==
| |
| * Optimize control flow to minimize jumping (we tend to a lot worse than GCC here since we don't even try to optimize this)
| |
| ** Rearrange loops to put the condition at the end
| |
| ** Fold jump-to-jump into single jump
| |
| ** Reorder blocks to replace jumps with fall-through.
| |
| * Use 32-bit register encoding on x64 for when the MIRType is int32
| |
| * Use pc-relative constant double loads instead of trying to use immediates (GCC does, need to measure perf)
| |
