4 ms·

# Firefox Sunspider: 182.5ms +/- 4.6% Octane: 21148 # Chrome Sunspider: 206.7ms +/- 1.2% Octane: 24921 I adore Mozilla and use Firefox as my primary browser.

# Firefox Sunspider: 182.5ms +/- 4.6% Octane: 21148 # Chrome Sunspider: 206.7ms +/- 1.2% Octane: 24921 I adore Mozilla and use Firefox as my primary browser. As a web developer I hope those benchmarks get tighter.

pcwalton 12y ago
Use http://arewefastyet.com/ http://arewefastyet.com/ for the most recent benchmarks. The results on there are rather different from what you quoted.
rcthompson 12y ago
Should GGC have a major impact on overall execution time? Or is it more about reducing "jank", or whatever they're calling it these days?
- sphink 12y ago
  It has some impact on overall execution time (throughput), mostly through being able to bump allocate. The benchmark I used in the article shows a large gain, though the real-world effect is much less. But GGC is mostly about reducing pause times (latency). (And yes, people have taken to calling that "jank". I still resist the term when I can, since it's no more precise than anything that came before but people seem to think it must mean something specific.)
nnethercote 12y ago
Sunspider is an ancient, awful benchmark suite that has been optimized to the point of insanity. For example, every major browser has a daylight savings offset cache that is no use to any real code but speeds up Sunspider significantly. It needs to die. You should ignore it. Octane is better, though still flawed: https://blog.mozilla.org/nnethercote/2012/08/24/octane-minus-v8/ https://blog.mozilla.org/nnethercote/2012/08/24/octane-minus.... The state of browser benchmarking isn't good. Here are my ideas on how to fix it: https://blog.mozilla.org/nnethercote/2014/06/16/a-browser-benchmarking-manifesto/ https://blog.mozilla.org/nnethercote/2014/06/16/a-browser-be.... The political/organizational challenges are as big or bigger than the technical challenges. And really, you should care most about how each browser performs on the workloads you are interested in.
- aidenn0 12y ago
  > The state of browser benchmarking isn't good. You can delete the word "browser" from that sentence and it's still true. Just one example: You wouldn't believe how many large projects rely on Dhrystone for benchmarking and selecting silicon.
  - nnethercote 12y ago
    I can believe it. But at least in the C/C++/Fortran world there are decent suites, e.g. SPEC, even if not everybody uses them. The browser world doesn't even have that.
- deleted 12y ago
  [deleted]
- cromwellian 12y ago
  I think the brouhaha over Mandreel vs Emscripten glosses over a deeper issue, which is, the vast majority of Web apps aren't C++ compiled to asmjs, and performance on asmjs is not going to be a good proxy for general web performance. "Real apps" using idiomatic JS should be used as benchmarks, and those apps should approximate apps in widespread deployment. For example, how fast can a reactjs re-render for a complex page run?

pcwalton 12y ago

Use http://arewefastyet.com/ http://arewefastyet.com/ for the most recent benchmarks. The results on there are rather different from what you quoted.

rcthompson 12y ago

Should GGC have a major impact on overall execution time? Or is it more about reducing "jank", or whatever they're calling it these days?

sphink 12y ago
It has some impact on overall execution time (throughput), mostly through being able to bump allocate. The benchmark I used in the article shows a large gain, though the real-world effect is much less. But GGC is mostly about reducing pause times (latency). (And yes, people have taken to calling that "jank". I still resist the term when I can, since it's no more precise than anything that came before but people seem to think it must mean something specific.)

nnethercote 12y ago

Sunspider is an ancient, awful benchmark suite that has been optimized to the point of insanity. For example, every major browser has a daylight savings offset cache that is no use to any real code but speeds up Sunspider significantly. It needs to die. You should ignore it. Octane is better, though still flawed: https://blog.mozilla.org/nnethercote/2012/08/24/octane-minus-v8/ https://blog.mozilla.org/nnethercote/2012/08/24/octane-minus.... The state of browser benchmarking isn't good. Here are my ideas on how to fix it: https://blog.mozilla.org/nnethercote/2014/06/16/a-browser-benchmarking-manifesto/ https://blog.mozilla.org/nnethercote/2014/06/16/a-browser-be.... The political/organizational challenges are as big or bigger than the technical challenges. And really, you should care most about how each browser performs on the workloads you are interested in.

aidenn0 12y ago
> The state of browser benchmarking isn't good. You can delete the word "browser" from that sentence and it's still true. Just one example: You wouldn't believe how many large projects rely on Dhrystone for benchmarking and selecting silicon.
- nnethercote 12y ago
  I can believe it. But at least in the C/C++/Fortran world there are decent suites, e.g. SPEC, even if not everybody uses them. The browser world doesn't even have that.
deleted 12y ago
[deleted]
cromwellian 12y ago
I think the brouhaha over Mandreel vs Emscripten glosses over a deeper issue, which is, the vast majority of Web apps aren't C++ compiled to asmjs, and performance on asmjs is not going to be a good proxy for general web performance. "Real apps" using idiomatic JS should be used as benchmarks, and those apps should approximate apps in widespread deployment. For example, how fast can a reactjs re-render for a complex page run?