IonMonkey now has Scalar Replacement and Branch Pruning optimizations
blog.mozilla.orgI'm working on some numerical code and this sounds like a relevant optimization. How can I tell if my code is correctly taking advantage of it?
More generally, how should I optimize JS at the level of an individual function? In C++ I would just inspect the emitted assembly code to understand how my code is being compiled. But the assembly seems hard to access in a JS world.
We have an addon called the "Jit Inspector" [1], which should report the Assembly produced by IonMonkey. Last time I tried it not all panels where functional because it was still making attempts at reporting data from JaegerMonkey, which got removed since.
The lastest solution I have seen so far is what we call the "Jit Coach" [2]. This is a devtools panel under the performance tab which reports if your function sticks in IonMonkey compiled code. Based on the MDN page this is behind a preference in "about:config".
When we compile, we record the hypothesis made by the compiler, and use these to annotate the deoptimization paths which are taken. Each time we jump back to Baseline the tool reports why we jump back to Baseline.
So far, only the front-end of IonMonkey and the deoptimization path are recorded. No other optimization phases are recorded at the moment. Sadly, it does not report the Assembly produced by IonMonkey.
[1] https://addons.mozilla.org/en-US/firefox/addon/jit-inspector...
There's some information about how to collect (and visualize!) JS compilation artifacts in the IRHydra documentation [1]. It's v8 specific, though.
The other writings on that site are worth studying if you want to learn more about how v8 optimizes code [2].
[1] http://mrale.ph/irhydra/2/
[2] http://mrale.ph
Thanks for the links. Rebuilding V8 is a bit much though. Maybe this is an opportunity for a web service akin to gcc.godbolt.org
What's the difference between IonMonkey and Firefox' SpiderMonkey?
IonMonkey is the name of one of the JITs in SpiderMonkey.
(For entertainment purposes, the JITs have names ending in -Monkey.)
IonMonkey is to SpiderMonkey as TurboFan[0] is to V8
I'd compare IonMonkey in SM to Crankshaft in V8. Ion was actually started in response to Crankshaft.
TurboFan is a new even-higher-tier, even-more-expensive-to-compile, but potentialy even-more-optimized compiler backend the V8 team is working on.
Spelled out, TurboFan and IonMonkey are JITs that take longer to run but can do more optimizations. The idea is to run them on code that executes a _lot_ of times, so the faster code generated pays for the extra JIT time. If you wrote a game in straight JS and it contains some code that runs for a bunch of in-game objects every frame, that's the kind of thing these JITs could really help with.