Updating JavaScript Benchmarks for Modern Browsers
Wednesday, May 04, 2011
Labels: benchmarks, v8
Benchmarks are incredibly important for influencing the direction of JavaScript engines. Over the past two years, JavaScript has gotten dramatically faster across all major browsers, particularly in areas that popular benchmarks measure. As it turns out, browser developers are a competitive bunch. However, as JS engines get faster, benchmarks must evolve in order to keep pushing them in the right direction.
We’ve been constantly updating our V8 benchmark suite to force us to get faster in areas that are important to web developers. We’ve fixed bugs and added new tests for regular expressions and memory management. We’re very focused on JavaScript performance, so we scrutinize our benchmark carefully to make sure that it’s as useful a measuring stick as possible.
The two other widely cited JS benchmarks are SunSpider from Apple, and Kraken, a new benchmark from Mozilla.
SunSpider was one of the first suites of tests, first appearing in 2007. It’s done a lot to help improve JS engines, but many of the tests in the suite are less relevant to the web in 2011. Even for the more relevant tests, JavaScript has gotten so fast that many finish in only a few milliseconds. This just isn’t long enough to figure out which engine is faster--a golf cart and a Tesla will finish a 10-foot race in nearly the same time.
To make the benchmark more meaningful, we’ve experimented by making the race longer by running each of the tests in SunSpider 50 times consecutively. While repeating a trivial test many times isn’t a great solution, it does provide an opportunity for some optimization. With this change, the results begin to reflect Chrome’s true performance. It’s more than 30% faster on the SunSpider suite overall and up to 4x faster on some of the individual tests.
Kraken, a more modern benchmark, is in better shape. Unfortunately, the canonical version of the benchmark has not been updated to reflect all the latest changes which address at least one important bug. As a result, the benchmark is less useful and has even (mis)led us to spend time making some irrelevant optimizations in Chrome. To help us focus on the right things, we’re now testing the latest version of Kraken built directly from Mozilla’s source code repository.
We’re posting a modified version of SunSpider and the latest version of Kraken to make it easy to run the benchmarks in your own browser and compare results.

18 comments:
Manish said...
Excellent!
May 4, 2011 1:13 PM
null said...
Yeah great, I can't use Chrome today because every site uses java and the java is all screwed up. Thanks
May 4, 2011 2:19 PM
Julio said...
WHY IS CALLED CANARY?
HI FROM CANARY ISLANDS!!!!!
May 4, 2011 2:59 PM
Luke Hutchison said...
Most benchmarks are designed wrongly: They should measure *number of operations per second*, not *number of seconds to complete a given number of operations*. This allows your benchmark code to continue to work even after individual operations start taking negligible time.
A good benchmark should do the following:
(1) set a global variable "stopNow" to false
(2) schedule a separate thread to run after 10 seconds or so, after which stopNow is set to true
(3) the main thread should start its own stopwatch and then it should run repeated iterations through the benchmark in question until stopNow is true, counting how many iterations are completed before the timer goes off and stops the loop
(4) the total amount of time on the stopwatch should be measured after the last iteration, and this should be divided by the total number of iterations.
You could also try running the same code with just the benchmark itself removed to calculate how much overhead is incurred by each loop iteration, if you cared about removing the overhead from the calculation.
May 4, 2011 5:20 PM
Luke Hutchison said...
Oops, with the one caveat that the result you want is the reciprocal of what I just wrote: it should be the number of iterations divided by the time taken -- i.e. operations per second. This number should only grow with time, and so is not limited by timing precision.
May 4, 2011 5:22 PM
Luke Hutchison said...
Julio: Canary as in "canary in the coal mine" -- Wikipedia explains it.
May 4, 2011 5:23 PM
Nicholas said...
"It’s more than 30% faster on the SunSpider suite overall and up to 4x faster on some of the individual tests."
Faster than what? Can you show some numbers?
May 4, 2011 9:44 PM
Luke Hutchison said...
Nicholas: you can run it yourself, see the link to their version of Sunspider at the end of the article. You can run it in browsers of your choice.
I actually like that Google didn't give their own detailed performance numbers, it's better when detailed performance analyses are performed by unaffiliated parties.
May 4, 2011 9:51 PM
Darth said...
Would be nice to also keep an eye on benchmarks using popular webapps like mentioned by Douglas Crockford - http://crockford.com/javascript/performance.html
May 5, 2011 12:30 AM
Jonathan Kingston said...
How about google makes something much better:
- Spider websites
-Collect javascript and anonymise it
- Create an ajax loader to load each script and execute one by one
- Run statistics and measure how well the execution went
- Repeat till a fair % of the internets most popular javascript has been tested.
Also make sure chrome experiments are all included in this test, some are really slow on my laptop
May 5, 2011 3:13 AM
Alan said...
May 5, 2011 3:22 AM
Alan said...
It would be nice to see that benchmarks are not just focused on JavaScript. I would like to see a benchmark that is more evenly test the performance of many different elements... Video, Audio & Canvas to name a few... These sorts of benchmarking will also be important moving forward as the web moves away from FLASH.
May 5, 2011 3:24 AM
Alan said...
May 5, 2011 3:27 AM
Luke Hutchison said...
I agree with the comments about testing browser speed, but "canvas" usually refers to the canvas element specifically. This definitely needs to be optimized, but an even more important thing to optimize is operations on the DOM. Manipulating the DOM is a major performance bottleneck in AJAXy applications, and far too few benchmarks are really exercising the DOM. I hope that the next optimization feeding frenzy (once Javascript optimization starts to reach asymptotic limits) will be about relayouting and DOM manipulation.
May 5, 2011 3:42 AM
Eric D said...
I noticed something funny with the gaussian-blur test on Kraken with Chrome. When you just run the full benchmark, Chrome apparently performs faster than Firefox. When you click on the link for the explanation of the test, and click the "Blur Test" button to try it, Chrome performs significantly slower while Firefox runs at roughly the same speed as the test results.
May 5, 2011 12:11 PM
BPM Demo Blog said...
Javascript performance certainly has come a long way.
I put together a simple test that supports that hypothesis. It renders a simple MandelBrot Set, which is often used to benchmark runtime performance.
The code and the executables are here ... http://www.bulkdatafeeds.com/mandelbrot.zip
The results on my Windows 7 x64 AMD 3.7 GHz processor with 8 gigs of memory are as follows (smaller is better)
Python-> 1700ms (Python.exe Mandelbrot.py)
C-> 345ms (Mandelbrot.exe)
Java-> 261ms (Java.exe Mandelbrot)
C#-> 215ms (MandelbrotCS.exe)
Javascript-> 47ms (Shell.exe Mandelbrot.js)
The Javascript engine is Google's Chrome V8
We've come a long way in terms of what a Javascript runtime is capable off.
May 5, 2011 1:44 PM
krtulmay said...
@Darth, V8 has since been fixed/optimized for the Douglas Crockford test:
JSLint showing performance slower than expected, slowest among modern browsers
http://code.google.com/p/v8/issues/detail?id=1345
May 5, 2011 2:36 PM
Luke Hutchison said...
BPM Demo Blog: the only explanation for some of these numbers, in particular the C and Java numbers, is that your compiler and/or runtime suck/sucks! C is pretty bare-metal, and most C compilers optimize really well, so JS should not be 7 times faster than C.
I tried running your code on my Opteron machine. The first problem is that measurement error is huge: I measure a mean of 39.9ms for the JS code on current Chromium v8, but the standard deviation in runtime is 10.4ms! Some of this may be due to the unpredictability of I/O. I removed all the print statements and ran the main loop 100 times. Here are the results for 100 iterations without I/O:
v8: 2395ms
C:
no optimization: 4054ms
gcc -O2: 2059ms
Java: 1909 ms
Basically these days most JIT compilers approach the speed of AOT (ahead-of-time) compilation -- in the case of Java on this test case, it actually beats "gcc -O2".
The thing that is really slow for Javascript is the dynamic type system and even more so method invocation, because functions can be added to an object at any time. v8 was the first JS engine to speed up method invocation using some sort of method signature hashing scheme -- and all the other JS engines followed suit. Your code would be a more interesting test case if in involved a lot of method calls.
May 5, 2011 3:26 PM
Post a Comment