Single Threaded Integer Performance: SPEC CPU2006

Even in the server market where high core count CPUs are ruling the roost, high single threaded performance is still very desirable. It makes sure that a certain level of performance is guaranteed in every situation, not just in "throughput situations" of "embarrassingly parallel" software. 

SPEC CPU2017 has finally launched, but it did so while our testing was already under way. So SPEC CPU2006 was still our best option to evaluate single threaded performance. Even though SPEC CPU2006 is more HPC and workstation oriented, it contains a good variety of integer workloads.

It is our conviction that we should try to mimic how performance critical software is compiled instead of trying to achieve the highest scores. To that end, we:

  • use 64 bit gcc : by far the most used compiler on linux for integer workloads, good all round compiler that does not try to "break" benchmarks (libquantum...) or favor a certain architecture
  • use gcc version 5.4: standard compiler with Ubuntu 16.04 LTS. (Note that this is upgraded from 4.8.4 used in earlier articles)
  • use -Ofast -fno-strict-aliasing optimization: a good balance between performance and keeping things simple
  • added "-std=gnu89" to the portability settings to resolve the issue that some tests will not compile with gcc 5.x
  • run one copy of the test

The ultimate objective is to measure performance in non-"aggressively optimized" applications where for some reason – as is frequently the case – a "multi-thread unfriendly" task keeps us waiting. 

First the single threaded results. It is important to note that thanks to modern turbo technology, all CPUs will run at higher clock speeds than their base clock speed. 

  • The Xeon E5-2690 ("Sandy Bridge") is capable of boosting up to 3.8 GHz
  • The Xeon E5-2690 v3 ("Haswell") is capable of boosting up to 3.5GHz
  • The Xeon E5-2699 v4  ("Broadwell") is capable of boosting up to 3.6 GHz
  • The Xeon 8176 ("Skylake-SP") is capable of boosting up to 3.8 GHz
  • The EPYC 7601 ("Naples") is capable of boosting up to 3.2 GHz

First we look at the absolute numbers. 

Subtest Application type Xeon E5-2690
@ 3.8
Xeon E5-2690 v3
@ 3.5
Xeon E5-2699 v4
@ 3.6
EPYC 7601
Xeon 8176
400.perlbench Spam filter 35 41.6 43.4 31.1 50.1
401.bzip2 Compression 24.5 24.0 23.9 24.0 27.1
403.gcc Compiling 33.8 35.5 23.7 35.1 24.5
429.mcf Vehicle scheduling 43.5 42.1 44.6 40.1 43.3
445.gobmk Game AI 27.9 27.8 28.7 24.3 31.0
456.hmmer Protein seq. analyses 26.5 28.0 32.3 27.9 35.4
458.sjeng Chess 28.9 31.0 33.0 23.8 33.6
462.libquantum Quantum sim 55.5 65.0 97.3 69.2 102
464.h264ref Video encoding 50.7 53.7 58.0 50.3 67.0
471.omnetpp Network sim 23.3 31.3 44.5 23.0 40.8
473.astar Pathfinding 25.3 25.1 26.1 19.5 27.4
483.xalancbmk XML processing 41.8 46.1 64.9 35.4 67.3

As raw SPEC scores can be a bit much to deal with in a dense table, we've also broken out our scores on a percentage basis. Sandy Bridge EP (Xeon E5 v1) is about 5 years old, the servers based upon this CPU are going to get replaced by newer ones. So we've made "Single threaded Sandy Bridge-EP performance" our reference (100%) , and compare the single threaded performance of all other architectures accordingly.

Subtest Application type Xeon E5-2690
@ 3.8
Xeon E5-2690 v3
@ 3.5
Xeon E5-2699 v4 @ 3.6 EPYC 7601 @3.2 Xeon 8176 @ 3.8
400.perlbench Spam filter 100% 119% 124% 89% 143%
401.bzip2 Compression 100% 98% 98% 98% 111%
403.gcc Compiling 100% 105% 70% 104% 72%
429.mcf Vehicle scheduling 100% 97% 103% 92% 100%
445.gobmk Game AI 100% 100% 103% 87% 111%
456.hmmer Protein seq. analyses 100% 106% 122% 105% 134%
458.sjeng Chess 100% 107% 114% 82% 116%
462.libquantum Quantum sim 100% 117% 175% 125% 184%
464.h264ref Video encoding 100% 106% 114% 99% 132%
471.omnetpp Network sim 100% 134% 191% 99% 175%
473.astar Pathfinding 100% 99% 103% 77% 108%
483.xalancbmk XML processing 100% 110% 155% 85% 161%

SPEC CPU2006 analysis is complicated, and with only a few days spend on the EPYC server, we must admit that what follows is mostly educated guessing. 

First off, let's gauge the IPC efficiency of the different architectures. Considering that the EPYC core runs at 12-16% lower clockspeeds (3.2 vs 3.6/3.8 GHz), getting 90+% of the performance of the Intel architectures can be considered a "strong" (IPC) showing for the AMD "Zen" architecture. 

As for Intel's latest CPU, pay attention to the effect of the much larger L2-cache of the Skylake-SP core (Xeon 8176) compared to the previous generation "Broadwell". Especially perlbench, gobmk, hmmer and h264ref (the instruction part) benefit. 

Meanwhile with the new GCC 5.4 compiler, Intel's performance on the "403.gcc benchmark" seems to have regressed their newer rchitectures. While we previously saw the Xeon E5-2699v4 perform at 83-95% of the "Sandy Bridge" Xeon E5-2690, this has further regressed to 70%. The AMD Zen core, on the other hand, does exceptionally well when running GCC. The mix of a high percentage of (easy to predict) branches in the instruction mix, a relatively small footprint, and a heavy reliance on low latency (mostly L1/L2/8 MB L3) seems to work well. The workloads where the impact of branch prediction is higher (somewhat higher percentage of branch misses) - gobmk, sjeng, hmmer - perform quite well on "Zen" too, which has a much lower branch misprediction penalty than AMD's previous generation architecture thanks to the µop cache. 

Otherwise the pointer chasing benchmarks – XML procesing and Path finding – which need a large L3-cache, are the worst performing on EPYC. 

Also notice the fact that the low IPC omnetpp ("network sim") runs slower on Skylake-SP than on Broadwell, but still much faster than AMD's EPYC. Omnetpp is an application that benefited from the massive 55 MB L3-cache of Broadwell, and that is why performance has declined on Skylake. Of course, this also means that the fractured 8x8 MB L3 of AMD's EPYC processor causes it to perform much slower than the latest Intel server CPUs. In the video encoding benchmark "h264ref" this plays a role too, but that benchmark relies much more on DRAM bandwidth. The fact that the EPYC core has higher DRAM bandwidth available makes sure that the AMD chip does not fall too far behind the latest Intel cores. 

All in all, we think we can conclude that the single threaded performance of the "Zen architecture" is excellent, but it somewhat let down by the lower turbo clock and the "smaller" 8x8 MB L3-cache. 

Memory Subsystem: Latency SMT Integer Performance With SPEC CPU2006


View All Comments

  • CajunArson - Tuesday, July 11, 2017 - link

    And another followup: The time kernel compilation on the i9 7900X got almost a factor of 2 speedup over the Ubuntu 16.04 using more modern distros. Reply
  • tamalero - Tuesday, July 11, 2017 - link

    How is that different if AMD ran stuff that is extremely optimized for them? Reply
  • Friendly0Fire - Tuesday, July 11, 2017 - link

    That's kinda the point? You want to benchmark the CPUs in optimal scenarios, since that's what you'd be looking at in practice. If one CPU's weakness is eliminated by using a more recent/tweaked compiler, then it's not a weakness. Reply
  • coder543 - Tuesday, July 11, 2017 - link

    Rather, you want to test under practical scenarios. Very few people are going to be running 17.04 on production grade servers, they will run an LTS release, which in this case is 16.04.

    It would be good to have benchmarks from 17.04 as another point of comparison, but given how many things they didn't have time to do just using 16.04, I can understand why they didn't use 17.04.
  • Santoval - Wednesday, July 12, 2017 - link

    A compromise can be found by upgrading Ubuntu 16.04's outdated kernel. Ubuntu LTS releases include support for rolling HWE Stacks, which is a simple meta package for installing newer kernels compiled, modified, tested and packaged by the Ubuntu Kernel Team, and installed directly from the official Ubuntu repositories (not via a Launchpad PPA). With HWE 16.04 LTS can install up to the kernel of 18.04 LTS.

    I also use 16.04 LTS + HWE (it just requires installing the linux-generic-hwe-16.04 package), which currently provides the 4.8 kernel. There is even a "beta" version of HWE (the same package plus an -edge at the end) for installing the 4.10 kernel (aka the kernel of 17.04) earlier, which will normally be released next month.

    I just spotted various 4.10 kernel listings after checking in Synaptic, so they must have been added very recently. After that there are two more scheduled kernel upgrades, as is shown in the following link. Of course HWE upgrades solely the kernel, it does not upgrade any application or any of the user level parts to a more recent version of Ubuntu.
  • CajunArson - Tuesday, July 11, 2017 - link

    Considering the similarities between RyZen and Haswell (that aren't coincidental at all) you are already seeing a highly optimized set of RyZen results.

    But I have no problem seeing RyZen be tested with the newest distros, the only difference being that even Ubuntu 16.04 already has most of the optimizations for RyZen baked in.
  • coder543 - Tuesday, July 11, 2017 - link

    What similarities? They're extremely different architectures. I can't think of any obvious similarities. Between the CCX model, caches being totally different layouts, the infinity fabric, Intel having better AVX-256/512 stuff (IIRC), etc.

    I don't think 16.04 is naturally any more optimized for Ryzen than it is for Skylake-SP.
  • CajunArson - Tuesday, July 11, 2017 - link

    Oh please, at the core level RyZen is a blatant copy-n-paste of Haswell with the only exception being they just omitted half the AVX hardware to make their lives easier.

    It's so obvious that if you followed any of the developer threads for people optimizing for RyZen they say to just use the Haswell compiler optimizations that actually work better than the official RyZen optimization flags.
  • ddriver - Tuesday, July 11, 2017 - link

    Can't tell if this post is funny or sad. Reply
  • CajunArson - Tuesday, July 11, 2017 - link

    It's neither: It's accurate.

    Don't believe me? Look at the differences in performance of the holy 1800X over multiple Linux distros ranging from pretty new (OpenSuse Tumbleweed) to pretty old (Fedora 23 from 2015):

    Nowhere near the variation that we see with Skylake X since Haswell was already a solved problem long before RyZen lauched.

Log in

Don't have an account? Sign up now