|
|
| (276 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++ (in particular, [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 a large-scale Emscripten app (such as [https://developer.mozilla.org/en-US/demos/detail/bananabread BananaBread]) 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 with the exception of DataView. Most of the (smaller) Emscripten benchmarks are running and coming in under 2x. Bigger benchmarks are now coming in (zlib, Bullet) are coming in and also right around 2x, so almost done with experimental evaluation.
| |
| | |
| Remaining experimental questions:
| |
| * Get BananaBread and Box2D working.
| |
| * Compare to NaCL/PNaCL performance.
| |
| * Would a float32 type provide a substantial performance boost (and can we add this type soundly with a ToFloat32 coercion)?
| |
| * What is the comparative performance of signal handler-based load/store safety vs. masking vs. branching? (This affects the asm.js spec, viz., whether we should include DataView (which doesn't have the alignment problems and thus allows mask/branch-free access).
| |
| | |
| == Major tasks ==
| |
| | |
| That is, after the experimental evaluation and assuming we go forward with the full engineering project.
| |
| | |
| * Tier 1 platform support (remaining):
| |
| ** x64 (Windows)
| |
| ** x86 (Windows, Unix)
| |
| ** ARM
| |
| * Signal handler support
| |
| ** Measure the win on non-synthetic benchmarks to see whether this is even necessary
| |
| ** DataView: avoid masking loads/stores
| |
| ** Stack-overflow check
| |
| ** Operation callback check
| |
| * Quality
| |
| ** Get all LLVM tests passing
| |
| ** Fuzz (with decoders mutation-based fuzzer based on existing asm.js programs)
| |
| * Optimize asm.js-to-Ion transition
| |
| * Full engine integration
| |
| ** Error.stack
| |
| ** SPS's profiler stack
| |
| ** (Have debug-mode disable asm.js optimization for now)
| |
| | |
| == Minor tasks ==
| |
| | |
| * Audit Odin code for OOM-safety.
| |
| * Better error messages that include dynamic values (types/numbers involved).
| |
| * Fix IonSpew
| |
| | |
| == Eventual tasks (not blocking initial release) ==
| |
| | |
| * Add a float32 type to asm.js to allow 32-bit float arithmetic
| |
| * 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
| |
| * Signal handler support for:
| |
| ** Integer division/modulus
| |
| ** Double-to-int conversion
| |
| | |
| == General IonMonkey optimizations ==
| |
| * Rearrange loops to put the condition at the end
| |
| * Fold jump-to-jump into single jump
| |
| * 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)
| |
