Skip to main content ↑ ↓
Topic: TurboFan: Google V8's new Compiler (Read 65698 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

TurboFan: Google V8's new Compiler

I call shenanigans on that name. I was using the word "Turbo" in conjunction with V8 long before Google ever did! And, what, they're relating a component of a car's engine to a style of jet engine? That makes less sense than calling the compiler a crankshaft!

https://translate.google.com/translate?sl=auto&tl=en&js=y&prev=_t&hl=en&ie=UTF-8&u=http%3A%2F%2Fwww.golem.de%2Fnews%2Fturbofan-googles-neuer-v8-compiler-fuer-chrome-1408-108291.html&edit-text=&act=url

https://codereview.chromium.org/426233002

https://groups.google.com/forum/#!msg/v8-dev/ab8V5Z58_70/5-05DvysCt8J

This literally just landed in the Chromium branch of V8 a day ago, so that's the only source I can find that describes it. But someone I know at Mozilla says that this patch finally makes V8 faster than SpiderMonkey again. A long time ago, I said that I had faith that V8 would remain faster than SM. For about the last year, it was the other way around.

I did a tiny bit of profiling, and I think I see why TurboFan is so much better. V8's old high optimizer (Lithium? Or was it Hydrogen?) In Crankshaft had a really hard time spinning up--it would take thousands of loop runs, tens of thousands of function calls, sometimes it would spin up and down without reaching equilibrium. It seemed that the old compiler's optimizer was petrified of making an optimization that would need to be reversed. Newer SM does the opposite, optimizing after as few as ten loops or calls. And it seemed to pay off! I think that TurboFan has new optimizer (or perhaps just provides better info to the same old optimizer?), either way it spins up way faster and more consistently.

It also looks like TurboFan can compile to true 64-bit machine code, which is something V8 didn't do before! I'm excited to see this in action!

Re: TurboFan: Google V8's new Compiler

Reply #1 –
A jet engine?  I'm confused now.  V8 is a type of car engine, and car engines contain fans (well technically I guess the radiator does).  No mixed metaphor here.

Re: TurboFan: Google V8's new Compiler

Reply #3 –
Man you got access to some bleeding edge stuff there, I can't even find references to turbofan when searching for it. Only a few sentences here and there. I guess they are waiting to go public with this, it still looks a ways off.

I'm surprised a lot of interest was built around a code commit. Haha, looks like the gauntlet was thrown.
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

Re: TurboFan: Google V8's new Compiler

Reply #4 –
Quote from: Flying Jester – on

[...] this patch finally makes V8 faster than SpiderMonkey again. A long time ago, I said that I had faith that V8 would remain faster than SM. For about the last year, it was the other way around.


Wait, when did SpiderMonkey get faster than V8?  I thought V8 was always faster, guess I've been out of the loop...

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.

Re: TurboFan: Google V8's new Compiler

Reply #6 –
Hearing all the highs and lows of these makes me wish we could just grab the bits and pieces, the low optimizer and the high optimizer and all that, and just connect them for the best of both worlds. Sadly that plan obviously won't work for a multitude of reasons.

Re: TurboFan: Google V8's new Compiler

Reply #7 –
The reason why that won't work is precisely why SpiderMonkey become powerful, using Baseline and IonMonkey. The best JIT is the one that has a very well integrated set of compilers and tracers. It can provide good information to a high optimizer, and the high optimizer can graceful back down when it needs to.

Of course, mixing and matching JITs in a fantasy JIT league is pretty fun :D