Really cool article. Posts like this always make me wonder what the state of the programming would be if browsers hadn't sucked up almost all of the world's compiler optimizers.
Good to see the Webkit team (mostly Apple) continue putting serious energy into JS performance. Take a bit of guts to throw out the whole LLVM layer in order to get compilation performance...<p>It's also encouraging to see them opening up about future directions rather than just popping full-blown features from the head of Zeus every so often. (Not that they owe us anything... ;-)<p>(Edit: it's also damned impressive for 2 people in 3-4 months.)
tl;dr: B3 will replace LLVM in the FTL JIT of webkit. LLVM isn't performing fast enough for JIT mainly because it's so memory hungry and misses optimisations that depend on javascript semantics. They got an around 5x compile time reduction and from 0% up to around 10% performance boost in general.
>> "tl;dr: B3 will replace LLVM in the FTL JIT of webkit. LLVM isn't performing fast enough for JIT mainly because it's so memory hungry and misses optimisations that depend on javascript semantics. They got an around 5x compile time reduction and from 0% up to around 10% performance boost in general." [1]<p>Is this a knock on LLVM then?<p>I wonder then specifically if this brings to light any concerns over Swift (another dynamic language, and was created by the same person who created LLVM as well). [2]<p>Seems weird that the original creator of LLVM was able to make a dynamic language such as Swift - without any problems.<p>[1] <a href="https://news.ycombinator.com/item?id=11105231" rel="nofollow">https://news.ycombinator.com/item?id=11105231</a><p>[2] <a href="http://nondot.org/sabre/" rel="nofollow">http://nondot.org/sabre/</a>
It's worth noticing that most of the optimizations here are for "space" -- reducing the working set size or the number of memory accesses. CPUs have gotten much faster than memory blah blah. This is the sort of thing where microbenchmarks may mislead you, because you WSS is probably not realistic.<p>I think we don't have great tools for helping with this sort of optimization. One can use perf to find cache misses, but that doesn't necessarily tell the whole story, as you might blame some <i>other</i> piece of code for causing a miss. Maybe I should try cachegrind again...
Interestingly, much of their complaints around pointer chasing, etc, are things LLVM plans on solving in the next 6-8 months. i'm a bit surprised they never bothered to email the mailing list and say "hey guys, any plans to resolve this" before going and doing all of this work. But building new JITs is fun and shiny, so ...
tl;dr<p><a href="https://webkit.org/blog-files/kraken.png" rel="nofollow">https://webkit.org/blog-files/kraken.png</a><p><a href="https://webkit.org/blog-files/octane.png" rel="nofollow">https://webkit.org/blog-files/octane.png</a><p>seriously though, dang, how many years of coding to get to that level of expertise
I'm really wondering about the politics behind all this. I mean both LLVM and WebKit are Apple projects (even though they're Open Source). So it would have been reasonable to expect an improvement of LLVM instead of ditching it altogether.