Sizing Up Servers: Intel's Skylake-SP Xeon versus AMD's EPYC 7000 - The Server CPU Battle of the Decade?
by Johan De Gelas & Ian Cutress on July 11, 2017 12:15 PM EST- Posted in
- CPUs
- AMD
- Intel
- Xeon
- Enterprise
- Skylake
- Zen
- Naples
- Skylake-SP
- EPYC
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.
219 Comments
View All Comments
ddriver - Wednesday, July 12, 2017 - link
LOL, buthurt intel fanboy claims that the only unbiased benchmark in the review is THE MOST biased benchmark in the review, the one that was done entirely for the puprpose to help intel save face.Because if many core servers running 128 gigs of ram are primarily used to run 16 megabyte databases in the real world. That's right!
Beany2013 - Tuesday, July 11, 2017 - link
Sure, test against Ubuntu 17.04 if you only plan to have your server running till January. When it goes end of life. That's not a joke - non LTS Ubuntu released get nine months patches and that's it.https://wiki.ubuntu.com/Releases
16.04 is supported till 2021, it's what will be used in production by people who actually *buy* and *use* servers and as such it's a perfectly representative benchmark for people like me who are looking at dropping six figures on this level of hardware soon and want to see how it performs on...goodness, realistic workloads.
rahvin - Wednesday, July 12, 2017 - link
This is a silly argument. No one running these is going to be running bleeding edge software, compiling special kernels or putting optimizing compiler flags on anything. Enterprise runs on stable verified software and OS's. Your typical Enterprise Linux install is similar to RHEL 6 or 7 or it's variants (some are still running RHEL 5 with a 2.6 kernel!). Both RHEL6 and 7 have kernels that are 5+ years old and if you go with 6 it's closer to 10 year old.Enterprises don't run bleeding edge software or compile with aggressive flags, these things create regressions and difficult to trace bugs that cost time and lots of money. Your average enterprise is going to care about one thing, that's performance/watt running something like a LAMP stack or database on a standard vanilla distribution like RHEL. Any large enterprise is going to take a review like this and use it as data point when they buy a server and put a standard image on it and test their own workloads perf/watt.
Some of the enterprises who are more fault tolerant might run something as bleeding edge as an Ubuntu Server LTS release. This review is a fair review for the expected audience, yes every writer has a little bias but I'd dare you to find it in this article, because the fanboi's on both sides are complaining that indicates how fair the review is.
jjj - Tuesday, July 11, 2017 - link
Do remember that the future is chiplets, even for Intel.The 2 are approaching that a bit differently as AMD had more cost constrains so they went with a 4 cores CCX that can be reused in many different prods.
Highly doubt that AMD ever goes back to a very large die and it's not like Intel could do a monolithic 48 cores on 10nm this year or even next year and that would be even harder in a competitive market. Sure if they had a Cortex A75 like core and a lot less cache, that's another matter but they are so far behind in perf/mm2 that it's hard to even imagine that they can ever be that efficient.
coder543 - Tuesday, July 11, 2017 - link
Never heard the term "chiplet" before. I think AMD has adequately demonstrated the advantages (much higher yield -> lower cost, more than adequate performance), but I haven't heard Intel ever announce that they're planning to do this approach. After the embarrassment that they're experiencing now, maybe they will.Ian Cutress - Tuesday, July 11, 2017 - link
Look up Intel's EMIB. It's an obvious future for that route to take as process nodes get smaller.Threska - Saturday, July 22, 2017 - link
We may see their interposer (like used with their GPUs) technology being used.jeffsci - Tuesday, July 11, 2017 - link
Benchmarking NAMD with pre-compiled binaries is pretty silly. If you can't figure out how to compile it for each every processor of interest, you shouldn't be benchmarking it.CajunArson - Tuesday, July 11, 2017 - link
On top of all that, they couldn't even be bothered to download and install a (completely free) vanilla version that was released this year. Their version of NAMD 2.10 is from *2014*!http://www.ks.uiuc.edu/Development/Download/downlo...
tamalero - Tuesday, July 11, 2017 - link
Do high level servers update their versions constantly?I know that most of the critical stuff, only patch serious vulnerabilities and not update constantly to newer things just because they are available.