CPU Performance: Web and Legacy Tests

While more the focus of low-end and small form factor systems, web-based benchmarks are notoriously difficult to standardize. Modern web browsers are frequently updated, with no recourse to disable those updates, and as such there is difficulty in keeping a common platform. The fast paced nature of browser development means that version numbers (and performance) can change from week to week. Despite this, web tests are often a good measure of user experience: a lot of what most office work is today revolves around web applications, particularly email and office apps, but also interfaces and development environments. Our web tests include some of the industry standard tests, as well as a few popular but older tests.

We have also included our legacy benchmarks in this section, representing a stack of older code for popular benchmarks.

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

WebXPRT 3: Modern Real-World Web Tasks, including AI

The company behind the XPRT test suites, Principled Technologies, has recently released the latest web-test, and rather than attach a year to the name have just called it ‘3’. This latest test (as we started the suite) has built upon and developed the ethos of previous tests: user interaction, office compute, graph generation, list sorting, HTML5, image manipulation, and even goes as far as some AI testing.

For our benchmark, we run the standard test which goes through the benchmark list seven times and provides a final result. We run this standard test four times, and take an average.

Users can access the WebXPRT test at http://principledtechnologies.com/benchmarkxprt/webxprt/

WebXPRT 3 (2018)

WebXPRT 2015: HTML5 and Javascript Web UX Testing

The older version of WebXPRT is the 2015 edition, which focuses on a slightly different set of web technologies and frameworks that are in use today. This is still a relevant test, especially for users interacting with not-the-latest web applications in the market, of which there are a lot. Web framework development is often very quick but with high turnover, meaning that frameworks are quickly developed, built-upon, used, and then developers move on to the next, and adjusting an application to a new framework is a difficult arduous task, especially with rapid development cycles. This leaves a lot of applications as ‘fixed-in-time’, and relevant to user experience for many years.

Similar to WebXPRT3, the main benchmark is a sectional run repeated seven times, with a final score. We repeat the whole thing four times, and average those final scores.

WebXPRT15

Speedometer 2: JavaScript Frameworks

Our newest web test is Speedometer 2, which is a accrued test over a series of javascript frameworks to do three simple things: built a list, enable each item in the list, and remove the list. All the frameworks implement the same visual cues, but obviously apply them from different coding angles.

Our test goes through the list of frameworks, and produces a final score indicative of ‘rpm’, one of the benchmarks internal metrics. We report this final score.

Speedometer 2

Google Octane 2.0: Core Web Compute

A popular web test for several years, but now no longer being updated, is Octane, developed by Google. Version 2.0 of the test performs the best part of two-dozen compute related tasks, such as regular expressions, cryptography, ray tracing, emulation, and Navier-Stokes physics calculations.

The test gives each sub-test a score and produces a geometric mean of the set as a final result. We run the full benchmark four times, and average the final results.

Google Octane 2.0

Mozilla Kraken 1.1: Core Web Compute

Even older than Octane is Kraken, this time developed by Mozilla. This is an older test that does similar computational mechanics, such as audio processing or image filtering. Kraken seems to produce a highly variable result depending on the browser version, as it is a test that is keenly optimized for.

The main benchmark runs through each of the sub-tests ten times and produces an average time to completion for each loop, given in milliseconds. We run the full benchmark four times and take an average of the time taken.

Mozilla Kraken 1.1

3DPM v1: Naïve Code Variant of 3DPM v2.1

The first legacy test in the suite is the first version of our 3DPM benchmark. This is the ultimate naïve version of the code, as if it was written by scientist with no knowledge of how computer hardware, compilers, or optimization works (which in fact, it was at the start). This represents a large body of scientific simulation out in the wild, where getting the answer is more important than it being fast (getting a result in 4 days is acceptable if it’s correct, rather than sending someone away for a year to learn to code and getting the result in 5 minutes).

In this version, the only real optimization was in the compiler flags (-O2, -fp:fast), compiling it in release mode, and enabling OpenMP in the main compute loops. The loops were not configured for function size, and one of the key slowdowns is false sharing in the cache. It also has long dependency chains based on the random number generation, which leads to relatively poor performance on specific compute microarchitectures.

3DPM v1 can be downloaded with our 3DPM v2 code here: 3DPMv2.1.rar (13.0 MB)

3DPM v1 Single Threaded3DPM v1 Multi-Threaded

x264 HD 3.0: Older Transcode Test

This transcoding test is super old, and was used by Anand back in the day of Pentium 4 and Athlon II processors. Here a standardized 720p video is transcoded with a two-pass conversion, with the benchmark showing the frames-per-second of each pass. This benchmark is single-threaded, and between some micro-architectures we seem to actually hit an instructions-per-clock wall.

x264 HD 3.0 Pass 1x264 HD 3.0 Pass 2

CPU Performance: Encoding Tests Gaming: World of Tanks enCore
Comments Locked

274 Comments

View All Comments

  • leexgx - Saturday, October 20, 2018 - link

    Can you please stop your website playing silent audio, very annoying as it stops playback on my other phone (dual connection headset)
  • moozooh - Sunday, October 21, 2018 - link

    To be fair, the 9900K seems like a suboptimal choice for a gaming rig despite the claims—the extra performance is marginal and comes at a very heavy price. Consider that in all the CPU-bound 95th percentile graphs (which are the only important ones in this context)—even in the more CPU-intensive games—the 9700K was within 5% of the 9900K, sometimes noticeably faster (e.g. Civ6 Low). And its overclocking potential is just *so* much better—all of this at ~3/4 the price and power consumption (and hence more relaxed cooling requirements and lower noise). I cannot possibly envision a scenario where a rational choice, all this considered, would point to 9900K for a gaming machine. The at most 5% extra performance just isn't worth the downsides.

    On a sidenote, I'd actually like to see how an overclocked 9700K fares against overclocked 8700K/8086K (delidded for fair comparison—you seem to have had at least one of those, no?) with regards to frame times/worst performance. For my current home PC I chose a delidded 8350K running at 4.9 GHz on 1–2 cores and at 4.7 GHz on 3–4, which I considered the optimal choice for my typical usage, where the emphasis lies on non-RTS games, general/web/office performance, emulation, demoscene, some Avisynth—basically all of the tasks that heavily favor per-thread performance and don't scale well with HT. In most of the gaming tests the OC 8350K showed frame times about on par with the twice more expensive 8700K at stock settings, so it made perfect sense as a mid-tier gaming CPU. It appears that 9700K would be an optimal and safe drop-in replacement for it as it would double the number of cores while enabling even better per-thread performance without putting too much strain on the cooler. But then again I'd be probably better off waiting for its Ice Lake counterpart with full (?) hardware Spectre mitigation, which should result in a "free" minor performance bump if nothing else. At least assuming it will still use the same socket, which you never can tell with Intel...
  • R0H1T - Sunday, October 21, 2018 - link

    Ryan & Ian, I see that the last few pages have included a note about Z390 used because the Z370 board was over-volting the chip? Yet on the Overclocking page we see the Z370 listed with max CPU package power at 168 Watts? Could you list the (default) auto voltage applied by the Asrock Z370 & if appropriate update the charts on OCing page with the Z390 as well?
  • Total Meltdowner - Sunday, October 21, 2018 - link

    Ryan, you do great work. Please don't let all these haters in the comments who constantly berate you over grammar and typos get you down.
  • Icehawk - Saturday, October 27, 2018 - link

    Ryan, I still haven't been able to find an answer to this - what are your actual HEVC settings? Because I've got an 8700 @4.5 no offset and it does 1080p at "1080p60 HEVC at 3500 kbps variable bit rate, fast setting, main profile" with passthrough audio and I get ~40fps not the 175 you achieved - how on earth are you getting over 4x the performance??? The only way I can get remotely close would be to use NVENC or QuickSync neither of which are acceptable to me.
  • phinnvr6@gmail.com - Wednesday, October 31, 2018 - link

    My thoughts are why would anyone recommend the 9900K over the 9700K? It's absurdly priced, draws an insane amount of power, and performs roughly identical.
  • DanNeely - Friday, October 19, 2018 - link

    Have any mobo makers published block diagrams for their Z390 boards? I'm wondering if the 10GB USB3.1 ports are using 2 HSIO lanes as speculated in the mobo preview article, or if Intel has 6 lanes that can run at 10gbps instead of the normal 8 so that they only need one lane each.
  • repoman27 - Friday, October 19, 2018 - link

    They absolutely do not use 2 HSIO lanes. That was a total brain fart in the other article. The datasheet for the other 300 series chipsets is available on ARK, and the HSIO configuration of the Z390 can easily be extrapolated from that.

    HSIO lanes are just external connections to differential signaling pairs that are connected internally to either various controllers or a PCIe switch via muxes. They’re analog interfaces connected to PHYs. They operate at whatever signaling rate and encoding scheme the selected PHY operates at. There is no logic to perform any type of channel bonding between the PCH and any connected ports or devices.
  • TEAMSWITCHER - Friday, October 19, 2018 - link

    My big question ... Could there be an 8 core Mobile part on the way?
  • Ryan Smith - Friday, October 19, 2018 - link

    We don't have it plotted since we haven't taken enough samples for a good graph, but CFL-R is showing a pretty steep power/frequency curve towards the tail-end. That means power consumption drops by a lot just by backing off of the frequency a little.

    So while it's still more power-hungry than the 6-cores at the same frequencies, it's not out of the realm of possibility. Though base clocks (which are TDP guaranteed) will almost certainly have to drop to compensate.

Log in

Don't have an account? Sign up now