Benchmarking Performance: CPU Web Tests

One of the issues when running web-based tests is the nature of modern browsers to automatically install updates. This means any sustained period of benchmarking will invariably fall foul of the 'it's updated beyond the state of comparison' rule, especially when browsers will update if you give them half a second to think about it. Despite this, we were able to find a series of commands to create an un-updatable version of Chrome 56 for our 2017 test suite. While this means we might not be on the bleeding edge of the latest browser, it makes the scores between CPUs comparable.

All of our benchmark results can also be found in our benchmark engine, Bench.

SunSpider 1.0.2: link

The oldest web-based benchmark in this portion of our test is SunSpider. This is a very basic javascript algorithm tool, and ends up being more a measure of IPC and latency than anything else, with most high-performance CPUs scoring around about the same. The basic test is looped 10 times and the average taken. We run the basic test 4 times.

Web: SunSpider on Chrome 56

SunSpider has a single threaded focus, and we see the Kaby Lake-X processors take their spots at the top of the graph.

Mozilla Kraken 1.1: link

Kraken is another Javascript based benchmark, using the same test harness as SunSpider, but focusing on more stringent real-world use cases and libraries, such as audio processing and image filters. Again, the basic test is looped ten times, and we run the basic test four times.

Web: Mozilla Kraken 1.1 on Chrome 56

Mozilla too relies on single threaded IPC and frequency. 

Google Octane 2.0: link

Along with Mozilla, as Google is a major browser developer, having peak JS performance is typically a critical asset when comparing against the other OS developers. In the same way that SunSpider is a very early JS benchmark, and Kraken is a bit newer, Octane aims to be more relevant to real workloads, especially in power constrained devices such as smartphones and tablets.

Web: Google Octane 2.0 on Chrome 56

Octane is an interesting benchmark, requiring cores and ST performance, but mostly the latter. It also seems that either Intel's design is optimized for the benchmark or vice versa, given the substantial difference in performance. There's no way for the benchmark to use all of the threads from AMD, nor the 12 threads in the Core i7-7800X which has a lower single thread performance.

WebXPRT 2015: link

While the previous three benchmarks do calculations in the background and represent a score, WebXPRT is designed to be a better interpretation of visual workloads that a professional user might have, such as browser based applications, graphing, image editing, sort/analysis, scientific analysis and financial tools.

Web: WebXPRT 15 on Chrome 56

WebXPRT is a mix of ST and MT, but still based in the web and relies on ST performance a lot. Given the variable loading on the benchmark, Intel's newest features such as Speed Shift help keep it at the top.

Benchmarking Performance: CPU Rendering Tests Benchmarking Performance: CPU Encoding Tests
Comments Locked

176 Comments

View All Comments

  • iwod - Monday, July 24, 2017 - link

    Intel has 10nm and 7nm by 2020 / 2021. Core Count is basically a solved problem, limited only by price.

    What we need is a substantial breakthrough in single thread performance. May be there are new material that could bring us 10+Ghz. But those aren't even on the 5 years roadmap.
  • mapesdhs - Monday, July 24, 2017 - link

    That's more down to better sw tech, which alas lags way behind. It needs skills that are largely not taught in current educational establishments.
  • wolfemane - Monday, July 24, 2017 - link

    Under Handbrake testing, just above the first graph you state:
    "Low Quality/Resolution H264: He we transcode a 640x266 H264 rip of a 2 hour film, and change the encoding from Main profile to High profile, using the very-fast preset."

    I think you mean to say "HERE we transcode..."

    Great article overall. Thank you!
  • Ian Cutress - Monday, July 24, 2017 - link

    Thanks, corrected :)
  • wolfemane - Monday, July 24, 2017 - link

    I wish your team would finally add in an edit button to comments! :)

    On the last graph ENCODING: Handbrake HEVC (4k) you don't list the 1800x, but it is present in the previous two graphs @ LQ and HQ. Was there an issue with the 1800x preventing 4k testing? Quite interested in it's results if you have them.
  • Ian Cutress - Monday, July 24, 2017 - link

    When I first did the HEVC testing for the Ryzen 7 review, there was a slight issue in it running and halfway through I had to change the script because the automation sometimes dropped a result (like the 1800X which I didn't notice until I was 2-3 CPUs down the line). I need to put the 1800X back on anyway for AGESA 1006, which will be in an upcoming article.
  • IanHagen - Monday, July 24, 2017 - link

    One thing that caught my eye for a while is how compile tests using GCC or clang show much better results on Ryzen compared to using Microsoft's VS compiler. Phoronix tests clearly shows that. Thus, I cannot really believe yet on Ian's recurring explanation of Ryzen suffering from its victim L3 cache. After all, the 1800X beats the 7700K by a sizable margin when compiling the Linux kernel.

    Isn't Ryzen relatively poor performance compiling Chromium due to idiosyncrasies of the VS compiler?
  • Ian Cutress - Monday, July 24, 2017 - link

    The VS compiler seems to love L3 cache, then. The 1800X does have 2x threads and 2x cores over the 7700K, accounting for the difference. We saw a -17% drop going from SKL-S with its fully inclusive L3 to SKL-SP with a victim L3, clock for clock.

    Chromium was the best candidate for a scripted, consistent compile workflow I could roll into our new suite (and runs on Windows). Always open for suggestions that come with an ELI5.
  • ddriver - Monday, July 24, 2017 - link

    So we are married to chromium, because it only compiles with msvc on windows?

    Or maybe because it is a shitty implementation that for some reason stacks well with intel's offerings?

    Pardon my ignorance, I've only been a multi-platform software developer for 8 years, but people who compile stuff a lot usually don't compile chromium all day.

    I'd say go GCC or Clang, because those are quality community drive open source compilers that target a variety of platforms, unlike msvc. I mean if you really want to illustrate the usefulness of CPUs for software developers, which at this point is rather doubtful...
  • Ian Cutress - Monday, July 24, 2017 - link

    Again, find me something I can rope into my benchmark suite with an ELI5 guide and I try and find time to look into it. The Chromium test took the best part of 2-3 days to get in a position where it was scripted and repeatable and fit with our workflow - any other options I examined weren't even close. I'm not a computer programmer by day either, hence the ELI5 - just years old knowledge of using Commodore BASIC, batch files, and some C/C++/CUDA in VS.

Log in

Don't have an account? Sign up now