AMD Rome Second Generation EPYC Review: 2x 64-core Benchmarked
by Johan De Gelas on August 7, 2019 7:00 PM ESTSingle-Thread SPEC CPU2006 Estimates
While it may have been superceded by SPEC2017, we have built up a lot of experience with SPEC CPU2006. Considering the trouble we experience with our datacenter infrastructure, it was our best first round option for raw performance analysis.
Single threaded performance continues to be very important, especially in maintainance and setup situations. These examples may include running a massive bash script, trying out a very complex SQL query, or configuring new software - there are lots of times where a user simply does not use all the cores.
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 7.4 and 8.3: standard compiler with Ubuntu 18.04 LTS and 19.04.
- 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
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. The disadvantage is there are still quite a few situations where gcc generates suboptimal code, which causes quite a stir when compared to ICC or AOCC results that are optimized to look for specific optimizations in SPEC code.
First the single threaded results. It is important to note that thanks to turbo technology, all CPUs will run at higher clock speeds than their base clock speed.
- The Xeon E5-2699 v4 ("Broadwell") is capable of boosting up to 3.6 GHz. Note: these are old results compiled w GCC 5.4
- 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.
- The EPYC 7742 ("Rome") boosts to 3.4 GHz. Results are compiled with GCC 7.4 and 8.3
Unfortunately we could not test the Intel Xeon 8280 in time for this data. However, the Intel Xeon 8280 will deliver very similar results, the main difference being that it runs a 5% higher clock (4 GHz vs 3.8 GHz). So we basically expect the results to be 3-5% higher than the Xeon 8176.
As per SPEC licensing rules, as these results have not been officially submitted to the SPEC database, we have to declare them as Estimated Results.
| Subtest | Application Type | Xeon E5-2699 v4 |
EPYC 7601 |
Xeon 8176 |
EPYC 7742 |
EPYC 7742 |
| Frequency | 3.6 GHz | 3.2 GHz | 3.8 GHz | 3.4 GHz | 3.4 GHz | |
| Compiler | gcc 5.4 | gcc 7.4 | gcc 7.4 | gcc 7.4 | gcc 8.3 | |
| 400.perlbench | Spam filter | 43.4 | 31.1 | 46.4 | 41.3 | 43.7 |
| 401.bzip2 | Compression | 23.9 | 24.0 | 27.0 | 26.7 | 27.2 |
| 403.gcc | Compiling | 23.7 | 35.1 | 31.0 | 42.3 | 42.6 |
| 429.mcf | Vehicle scheduling | 44.6 | 40.1 | 40.6 | 39.5 | 39.6 |
| 445.gobmk | Game AI | 28.7 | 24.3 | 27.7 | 32.8 | 32.7 |
| 456.hmmer | Protein seq. | 32.3 | 27.9 | 35.6 | 30.3 | 60.5 |
| 458.sjeng | Chess | 33.0 | 23.8 | 32.8 | 27.7 | 27.6 |
| 462.libquantum | Quantum sim | 97.3 | 69.2 | 86.4 | 72.7 | 72.3 |
| 464.h264ref | Video encoding | 58.0 | 50.3 | 64.7 | 62.2 | 60.4 |
| 471.omnetpp | Network sim | 44.5 | 23.0 | 37.9 | 23.0 | 23.0 |
| 473.astar | Pathfinding | 26.1 | 19.5 | 24.7 | 25.4 | 25.4 |
| 483.xalancbmk | XML processing | 64.9 | 35.4 | 63.7 | 48.0 | 47.8 |
A SPEC CPU analysis is always complicated, being a mix of what kind of code the compiler produces and CPU architecture.
| Subtest | Application type | EPYC 7742 (2nd gen) vs 7601 (1st gen) |
EPYC 7742 vs Intel Xeon Scalable |
Gcc 8.3 |
| 400.perlbench | Spam filter | +33% | -11% | +6% |
| 401.bzip2 | Compression | +11% | -1% | +2% |
| 403.gcc | Compiling | +21% | +28% | +1% |
| 429.mcf | Vehicle scheduling | -1% | -3% | 0% |
| 445.gobmk | Game AI | +35% | +18% | +0% |
| 456.hmmer | Protein seq. analyses | +9% | -15% | +100% |
| 458.sjeng | Chess | +16% | -16% | -1% |
| 462.libquantum | Quantum sim | +5% | -16% | -1% |
| 464.h264ref | Video encoding | +24% | -4% | -3% |
| 471.omnetpp | Network sim | +0% | -39% | 0% |
| 473.astar | Pathfinding | +30% | +3% | 0% |
| 483.xalancbmk | XML processing | +36% | -25% | 0% |
First of all, the most interesting datapoint was the fact that the code generated by gcc 8 seems to have improved vastly for the EPYC processors. We repeated the single threaded test three times, and the rate numbers show the same thing: it is very consistent.
hmmer is one of the more branch intensive benchmarks, and the other two workloads where the impact of branch prediction is higher (somewhat higher percentage of branch misses) - gobmk, sjeng - perform consistingly better on the second generation EPYC with it's new TAGE predictor.
Why the low IPC omnetpp ("network sim") does not show any improvement is a mystery to us, we expected that the larger L3 cache would help. However this is a test that loves very large caches, as a result the Intel Xeons have the advantage (38.5 - 55 MB L3).
The video encoding benchmark "h264ref" also relies somewhat on the L3 cache, but that benchmark relies much more on DRAM bandwidth. The fact that the EPYC 7002 has higher DRAM bandwidth is clearly visible.
The pointer chasing benchmarks – XML procesing and Path finding – performed less than optimal on the previous EPYC generation (compared to the Xeons), but show very significant improvements on EPYC 7002.
Facebook
Twitter
RSS
180 Comments
View All Comments
wrkingclass_hero - Sunday, August 11, 2019 - link
What does AMD have to do to get a Gold or Platinum recommendation?oRAirwolf - Thursday, August 15, 2019 - link
This is a good questionimaskar - Sunday, August 11, 2019 - link
Single thread performance is very important for those who lives in cloud. A quick example: suppose I provision 2 core/4gig vm (this is of course hyperthreads). And on AWS I have a choice - m5 and m5a, where AMD is cheaper. What do I sacrifice? Not really throughput, because you don't run your prod workloads at 100% CPU. But there is the latency. If those cores clocked lower, I would get the same amount of responses, but slower. And since in microservice world you have a chain of calls, you get this decrease 10 times. Is it worth it?That was the case for 1st gen EPYC. Would 2nd gen have latency parity?
notashill - Sunday, August 11, 2019 - link
It's hard to say until the cloud instances actually launch.The current m5a instances are using a custom SKU which is clocked at 2.5GHz max boost.
Rome's IPC is ~15% higher and clock speeds are all around higher so single threaded performance should be quite a bit better, but ultimately the exact numbers will depend on which SKUs the cloud vendors decide to use and how high they clock.
duploxxx - Tuesday, August 13, 2019 - link
did you actually ever work with hypervisors?there are other things than raw clock speed.... its all about scheduling and when there are more cores / socket available the scheduling is more relaxed, less ready time..... EPYC generation 1 is already awesome for hypervisor way better choice than most Intel counter parts for sure if you look at socket cost... but than again I am probably talking to a typical retard ****
JoeBraga - Wednesday, August 14, 2019 - link
Can you Explain better? But the license isn't bought by the quantity of coresor Per socket?imaskar - Wednesday, August 14, 2019 - link
He probably talks about VmWare, which is licensed per socket, not per core. So with EPYC gen2 you need twice less licenses for the same cloud capacity (assuming cores are equal).JoeBraga - Wednesday, August 14, 2019 - link
Now I understoodimaskar - Wednesday, August 14, 2019 - link
Rather than calling others retards, you could first dig a little deeper into an issue. No, I don't work with hypervisors directly, I'm from the other side. I write software and I want good latency (not insane one like for HFT, but still a good one). Because for throughput we could just spin one more instance. You can't buy latency horizontally.I'm not taking numbers out of the blue. There is a benchmark for AMD instances vs Intel instances on AWS. I'm not sure if we are allowed to post links to other resources here. Put this string into Google and you will surely find it: "A Look At The AMD EPYC Performance On The Amazon EC2 Cloud". Despite this article being very enthusiastic about those instances, you can really see that per core performance on Intel is better, meaning better latencies for web apps.
I will probably write my own set of benchmarks, because that one seems to completely ignore web servers. I am very enthusiastic about AMD instances, but they are definitely not a no-brainer.
quadibloc - Tuesday, August 13, 2019 - link
The new Ryzen chips compete well with what Intel is currently producing. But while they doubled AVX 2 support, so as to match what Intel has, Ice Lake will double that - as has been known for some time. So if this is what AMD thought would be competitive with Ice Lake, as Forrest Norrod said, AMD was not trying hard enough - and they're just lucky Ice Lake was late. AMD's position relative to Intel with its previous generations of Ryzens seems to be the limit of their ambitions. Combine that with Intel reacting to its current issues, and it looks to me that AMD will have to rethink some aspects of its strategy to avoid Intel being ahead when it comes time for next year's chips from both companies.