How does this compare to Chrome?
V8 tends to win on stuff that depends on garbage collection since they have a generational collector, and SpiderMonkey only has incremental.
SpiderMonkey wins on some computation workloads because V8 still has a huge limitation where they often have to store floats as individual allocations on the heap (that's the best explanation I can come up with, at least; impossible to tell for sure from the Chrome profiler)
V8 also wins on some use cases that make use of new ES5 features like Object.defineProperty, because their optimizations do a better job with them.
IonMonkey is definitely a big improvement over the previous generation of SpiderMonkey, though. They're closing the gap.
P.S. It's a little hard to measure this stuff because V8 has some optimizations that happen to be perfect for benchmarks but provide a much smaller win for applications (Loop invariant code motion, for one). Nothing naughty going on here, you just need to be aware the numbers are lies.
(Incremental GC was completed recently, for Fx 16: https://bugzilla.mozilla.org/show_bug.cgi?id=641025.)
What it sounds like you're describing is that people are still writing terrible benchmarks. The days of this sort of thing on jsperf being useful are numbered:
function benchmark() { for (var i = 0; i < 1000000; i++) { var result = computationWithNoSideEffects(); } }
Yes, a good compiler will turn that into a noop. And no, that's not being naughty either. It's just a terrible benchmark.
(also, when using crankshaft, doubles in V8 are unboxed and not allocated on the heap).
If the difference is huge then it'll be appreciated if you take those workloads and file bugs based on them.
Each of the major browsers - Chrome, IE, Firefox, Safari, Opera - have benchmarks that they beat the competition at.
Competition has made all of them very fast.