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
@3.2
Xeon 8176
@3.8
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
Comments Locked

219 Comments

View All Comments

  • PixyMisa - Tuesday, July 11, 2017 - link

    No, the pricing is correct. The 1P CPUs really are half the price of a single 2P CPU.
  • msroadkill612 - Wednesday, July 12, 2017 - link

    Seems to me, the simplest explanation of something complex, is to list what it will not do, which they will not do :(.

    Can i run a 1p Epyc in a 2p mobo e.g., please?
  • PixyMisa - Thursday, July 13, 2017 - link

    Short answer is no. It might boot, but only half the slots, memory, SATA and so on will be available. Two 1P CPUs won't talk to each other.

    A 2P Epyc will work in a 1P board though.
  • cekim - Tuesday, July 11, 2017 - link

    One glaring bug/feature of AMD's segmentation relative to Intel's is the utter and obvious crippling of clock speeds for all but the absolute top SKUs. Fewer cores should be able to make use of higher clocks within the same TDP envelope. As a result Intel is objectively offering more and better fits up and down the sweep of cores vs clocks vs price spectrum.

    So, the bottom line is AMD is saying that you will have to buy the top-end, 4S SKU to get the top GHz for those applications in your mix that won't benefit from 16,18,32,128 cores.

    I say all of this as someone who desperately wants EPYC to shake things up and force Intel to remove the sand-bags. I know I'm in a small, but non-zero market of users who can make use of dozens of cores, but still need 8 or fewer cores to perform on par with desktop parts for that purpose.
  • KAlmquist - Wednesday, July 12, 2017 - link

    One possibility is that they have only a small percentage of the chips currently being produced bin well enough to be used in the highest clocking SKU's, so they are saving those chips for the most expensive offerings. Admittedly, that depends on what they are seeing coming off the production line. If they have a fair number of chips where with two very good cores, and two not so good, then it would make sense to offer a high clocking 16 core EPYC using chips with two cores disabled. But if clock speed on most chips is limited due to minor registration errors (which would affect the entire chip), then a chip with only two really good cores would require two localized defects in two separate cores, in addition to very good registration to get the two good cores. The combination might be too rare to justify a separate SKU.

    I would expect Global Foundries to continue to tweak its process to get better yields. In that case, more processors would end up in the highest bin, and AMD might decide to launch a higher clock speed 16 and 8 core EPYC processors, mostly using chips which bin well enough that they could have been used for the 32 core EPYC 7601.
  • alpha754293 - Tuesday, July 11, 2017 - link

    Why does the Intel Xeon 6142 cost LESS than the 6142M? (e.g. per the table above, 6142 is shown with a price of $5946 while the 6142M costs $2949)
  • ca197 - Tuesday, July 11, 2017 - link

    I assume that is the wrong way round on the list. I have seen it reported the other way round on other sites.
  • Ian Cutress - Tuesday, July 11, 2017 - link

    You're correct. I've updated the piece, was a misread error from Intel's tables.
  • coder543 - Tuesday, July 11, 2017 - link

    On page 6, it says that Epyc only has 64 PCIe lanes (available), but that's not correct. There are 128 PCIe lanes per chip. In a 1P configuration, that's 128 PCIe lanes available. On a 2P configuration, 64 PCIe lanes from each chip are used to connect to the other chip, leaving 64 + 64 = 128 PCIe lanes still available.

    This is a significant advantage.
  • Ian Cutress - Tuesday, July 11, 2017 - link

    You misread that table. It's quoting per-CPU when in a 2P configuration.

Log in

Don't have an account? Sign up now