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.
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.


== Milestones ==
== Major tasks ==


# Experimental evaluation (large Emscripten apps)
That is, after the experimental evaluation and assuming we go forward with the full engineering project.
#* Bug fixing, Emscripten work
 
# Safe, works on all tier-1 platforms
* Tier 1 platform support (remaining):
#* Major tasks
** x64 (Windows)
#** x64 (Windows)
** x86 (Windows, Unix)
#** x86 (Windows, Unix)
** ARM
#** ARM
* Signal handler support
#** Signal handler support
** Measure the win on non-synthetic benchmarks to see whether this is even necessary
#*** DataView: avoid masking loads/stores
** DataView: avoid masking loads/stores
#*** Stack-overflow check
** Stack-overflow check
#*** Operation callback check
** Operation callback check
#** Quality
* Quality
#*** Get all LLVM tests passing
** 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
* Optimize asm.js-to-Ion transition
#** VM stack integration
* Full engine integration
#*** Error.stack
** Error.stack
#*** SPS's profiler stack
** SPS's profiler stack
#*** (Have debug-mode disable asm.js optimization for now)
** (Have debug-mode disable asm.js optimization for now)
#* Minor tasks
 
#** Test (and ease) IonMonkey internal limits for: number of locals, number of instructions, number of parameters, etc.
== Minor tasks ==
#** Make sure Odin code is OOM-safe.
 
#** Better error messages that include dynamic values (types/numbers involved).
* Test (and loosen, as necessary) IonMonkey internal limits for: number of locals, number of instructions, number of parameters, etc.
#** Fix IonSpew
* Audit Odin code for OOM-safety.
#* Optional optimizations
* Better error messages that include dynamic values (types/numbers involved).
#** Add a float32 type to asm.js to allow 32-bit float arithmetic
* Fix IonSpew
#** FunctionBlob (TODO: link to proposal)
 
#*** Efficient transfer between workers
== Optional tasks ==
#*** Efficient IndexedDB serialization/deserialization
 
#** Full GVN/range analysis support for all the new asm.js IM MIR nodes
* Add a float32 type to asm.js to allow 32-bit float arithmetic
#** ToInt shouldn't generate so much code
* FunctionBlob (TODO: link to proposal)
#** Signal handler support for:
** Efficient transfer between workers
#*** Integer division/modulus
** Efficient IndexedDB serialization/deserialization
#*** Double-to-int conversion
* Full GVN/range analysis support for all the new asm.js IM MIR nodes
#** General IonMonkey backend optimizations
* ToInt shouldn't generate so much code
#*** Rearrange loops to put the condition at the end
* Signal handler support for:
#*** Fold jump-to-jump into single jump
** Integer division/modulus
#*** Use 32-bit register encoding on x64 for when the MIRType is int32
** Double-to-int conversion
#*** Use pc-relative constant double loads instead of trying to use immediates (GCC does)
 
== 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)

Revision as of 22:57, 23 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++ (in particular, Emscripten).

Status

The project is currently in a research phase with the major evaluation criteria being to get a large-scale Emscripten app (such as BananaBread or sqlite 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.

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

  • Test (and loosen, as necessary) IonMonkey internal limits for: number of locals, number of instructions, number of parameters, etc.
  • Audit Odin code for OOM-safety.
  • Better error messages that include dynamic values (types/numbers involved).
  • Fix IonSpew

Optional tasks

  • 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)