Re: TurboFan: Google V8's new Compiler
Reply #5 –
There's a lot of hype around that one commit because the whole thing was created in secret, and then all committed in one go.
SpiderMonkey got faster about a year ago, when OdinMonkey (?) landed.
Basically, they replaced TraceMonkey with a new low optimizer (OdinMonkey) that has one goal: provide the best type information possible to the high optimizer. The thing is, when V8's high optimizer kicked in, it was miles ahead of SpiderMonkey. It just had a really hard time kicking in. So even though JaegerMonkey (the high optimizer) and IonMonkey (which inlines machine code) are kind of worse than V8's Lithium (which produces more efficient machine code), they were kicking in much more often and with better info going in (which helped them reach equilibrium much more reliably). So in actual use, especially in medium-lived functions (more than 10 runs, less than 10,000), SpiderMonkey was kicking V8's butt. In very long lived scripts, it was mostly a question of whether Lithium could stay spun up. If it could, V8 stayed faster. When it couldn't, V8 was very slow.
The thing is, not that many functions that run a ton of times are difficult to optimize (a case where Lithium could outdo JaegerMonkey), so V8 had a very difficult time flexing its muscles.
I'm actually kind of curious if TurboFan is a new high or low optimizer--is it replacing Hydrogen, letting Lithium spin up faster and with better info, or is taking the place of Lithium and staying spun up more reliably? Or is it just faster than Lithium? I kind of doubt that, given that Lithium, when it spins up and stays engaged, is one of the fastest JITs--if not the fastest--around.