Javascript:SpiderMonkey:OdinMonkey: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
Line 11: Line 11:
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) and are right around 2x, so we are almost done with experimental evaluation.
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) and are right around 2x, so we are almost done with experimental evaluation.


Remaining experimental questions:
Remaining experimental work:
* Get BananaBread and Box2D working.  This will give us 4 sizeable codebases: zlib (pure int), BananaBread (int and float), Bullet (heavy float), Box2D (heavy float).
* Get BananaBread working in the browser (with Alon's sweet deterministic harness).  That will give us 3 big codes: BananaBread, zlib, Bullet.
* 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).
** So far: removing the mask is a 20% boost on zlib.


== Major tasks ==
== Tasks before initial landing ==
 
That is, after the experimental evaluation and assuming we go forward with the full engineering project.


* Tier 1 platform support (remaining):
* Tier 1 platform support (remaining):
Line 25: Line 20:
** x86 (Windows, Unix)
** x86 (Windows, Unix)
** ARM
** ARM
* Signal handler support
* Safety
** Measure the win on non-synthetic benchmarks to see whether this is even necessary
** Add slow-script and stack-overflow checks (to be removed later)
** DataView: avoid masking loads/stores
** Stack-overflow check
** Operation callback check
* Quality
* Quality
** Get all LLVM tests passing
** Fuzz (with decoders mutation-based fuzzer based on existing asm.js programs)
** Fuzz (with decoders mutation-based fuzzer based on existing asm.js programs)
* Optimize asm.js-to-Ion transition
* Engine integration
* Full engine integration
** Error.stack should include asm.js frames
** Error.stack
** SPS's profiler stack should work as well
** SPS's profiler stack
** (Have debug-mode disable asm.js optimization for now)
** (Have debug-mode disable asm.js optimization for now)
* Get NaCL/PNaCL running on the same benchmarks, compare perf
== Minor tasks ==
* Audit Odin code for OOM-safety.
* Audit Odin code for OOM-safety.
* Better error messages that include dynamic values (types/numbers involved).
* Better error messages that include dynamic values (types/numbers involved).
* Fix IonSpew
* Unbreak IonSpew


== Eventual tasks (not blocking initial release) ==
== 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
* Avoid slow-script and stack overflow checks with signal handler support
* Add a float32 type to asm.js to allow 32-bit float arithmetic
* 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)
* FunctionBlob (TODO: link to proposal)
** Efficient transfer between workers
** Efficient transfer between workers
Line 54: Line 50:
* Full GVN/range analysis support for all the new asm.js IM MIR nodes
* Full GVN/range analysis support for all the new asm.js IM MIR nodes
* ToInt shouldn't generate so much code
* ToInt shouldn't generate so much code
* Signal handler support for:
** Integer division/modulus
** Double-to-int conversion


== General IonMonkey optimizations ==
== General IonMonkey optimizations ==

Revision as of 03:18, 29 January 2013

Goal

Provide an optimized implementation of the (co-evolvoing) asm.js spec which achieves near-native performance (within 2x of -O2) on JS generated from C/C++ (with the pilot project being Emscripten).

Status

The project is currently in a research phase with the major evaluation criteria being to get several large-scale Emscripten apps (BananaBread, zlib, Bullet, and Box2D) 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 patch queue based on mozilla inbound. Unit tests (which can serve as example code) are in js/src/jit-tests/tests/asm.js/.

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) and are right around 2x, so we are almost done with experimental evaluation.

Remaining experimental work:

  • Get BananaBread working in the browser (with Alon's sweet deterministic harness). That will give us 3 big codes: BananaBread, zlib, Bullet.

Tasks before initial landing

  • Tier 1 platform support (remaining):
    • x64 (Windows)
    • x86 (Windows, Unix)
    • ARM
  • Safety
    • Add slow-script and stack-overflow checks (to be removed later)
  • 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
    • (Have debug-mode disable asm.js optimization for now)
  • Audit Odin code for OOM-safety.
  • Better error messages that include dynamic values (types/numbers involved).
  • 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
  • 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

  • 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)
Retrieved from "https://wiki.mozilla.org/index.php?title=Javascript:SpiderMonkey:OdinMonkey&oldid=507565"