I don't think there is a "victory" here. Just an important milestone for Safari/JavaScriptCore. They have done some amazing engineering here! In the broader co

I don't think there is a "victory" here. Just an important milestone for Safari/JavaScriptCore. They have done some amazing engineering here! In the broader context, this shows that the JSC approach of taking LLVM and using it as a JIT - called FTL - can beat Chrome/v8 on large long-running computational code. That means that LLVM is significantly better than v8's backend JIT at some things. This is not too surprising since LLVM is much larger and sophisticated - it has a more powerful register allocator, supports things like float32, etc. Those two examples weren't random - Firefox has added an LLVM-like register allocator and float32 support (not just for asm.js code, in general). So there are two paths here: Safari takes LLVM, and Firefox implements some bits from LLVM in its own JIT. v8 so far has done neither, but hopefully has plans to do one of the two, or some other cool thing. In addition there is the issue of asm.js. Safari doesn't detect it, and beats Chrome but still trails Firefox. But it's far from clear that is the last word - Safari's new JIT just landed, it can be tuned a lot more, presumably. So it might still end up showing that a general JIT can beat custom asm.js optimizations, time will tell. What is clear though is that the Safari's FTL JIT took far more work than Firefox's asm.js optimizations. If the LLVM-based JIT mostly helps asm.js code anyhow - it shows little benefits in other benchmarks so far - then that raises interesting questions (if the benefit is mostly for asm.js, why not focus on asm.js specifically, if it's simpler and more effective?). But again, FTL just landed, perhaps with more tuning it will show general benefits. Exciting times!