In my test, Octane numbers improved by 25%. Improved benchmarks are Richards and DeltaBlue, which the blog post already analyzed in depth, and Mandreel and zlib, which are asm.js-like.
There is a discontinuity about a month ago, which is around when FTL was enabled, I believe. There you can see the nice speedups on Mandreel and the others you mention.
To me, the most stunning part is JavaScriptCore's much better performance on Typescript. And it seems it always has been that way, even before FTL was enabled. I wonder why.
It's a good question. I think I know why. WebKit's preexisting JITs were tuned for fast code load. Even the DFG JIT, the third-tier optimizing JIT, is deliberately tuned to generate code quickly even if it means not optimizing as much. Typescript is a ton of code so low-latency compilation is crucial.
Of course the FTL is tuned for the opposite - slower to compile but generates great code. That shows through on asm.js tests, which tend to be longer-running, and some of the other tests in Octane which also have a high running-time/code-size ratio.
That's the cool thing about having four tiers. Each tier has some scenarios on which it shines.
So in terms of compiler speed, DFG > V8 > FTL, and in terms of code quality, FTL > V8 > DFG, so DFG+FTL wins both against V8? I guess that makes sense.
Even then, I'm not sure it's a simple linear relationship. Crankshaft is better on some code, and FTL is better on some code. There's even cases where DFG (plus the tiers below it) does better than Crankshaft. (Talking about speed her; for compile time you are probably right for a wide range of code.)
