AMD Rome Second Generation EPYC Review: 2x 64-core Benchmarked
by Johan De Gelas on August 7, 2019 7:00 PM ESTMulti-core SPEC CPU2006
For the record, we do not believe that the SPEC CPU "Rate" metric has much value for estimating server CPU performance. Most applications do not run lots of completely separate processes in parallel; there is at least some interaction between the threads. But since the benchmark below caused so much discussion, we wanted to satisfy the curiosity of our readers.
2P SPEC CPU2006 Estimates | ||||||
Subtest | Xeon 8176 |
EPYC 7601 |
EPYC 7742 |
EPYC 7742 |
Zen2 vs Zen1 |
EPYC 7742 Vs Xeon |
Cores | 56C | 64C | 128C | |||
Frequency | 2.8 G | 2.7G | 2.5-3.2G | 2.5-3.2G | ||
GCC | 7.4 | 7.4 | 7.4 | 8.3 | 7.4 | 7.4 |
400.perlbench | 1980 | 2020 | 4680 | 4820 | +132% | +136% |
401.bzip2 | 1120 | 1280 | 3220 | 3250 | +152% | +188% |
403.gcc | 1300 | 1400 | 3540 | 3540 | +153% | +172% |
429.mcf | 927 | 837 | 1540 | 1540 | +84% | +66% |
445.gobmk | 1500 | 1780 | 4160 | 4170 | +134% | +177% |
456.hmmer | 1580 | 1700 | 3320 | 6480 | +95% | +110% |
458.sjeng | 1570 | 1820 | 3860 | 3900 | +112% | +146% |
462.libquantum | 870 | 1060 | 1180 | 1180 | +11% | +36% |
464.h264ref | 2670 | 2680 | 6400 | 6400 | +139% | +140% |
471.omnetpp | 756 | 705 (*) | 1520 | 1510 | +116% | +101% |
473.astar | 976 | 1080 | 1550 | 1550 | +44% | +59% |
483.xalancbmk | 1310 | 1240 | 2870 | 2870 | +131% | +119% |
We repeat: the SPECint rate test is likely unrealistic. If you start up 112 to 256 instances, you create a massive bandwidth bottleneck, no synchronization is going on and there is a consistent CPU load of 100%, all of which is very unrealistic in most integer applications.
The SPECint rate estimate results emphasizes all the strengths of the new EPYC CPU: more cores, much higher bandwidth. And at the time it ignores one of smaller disadvantages: higher intercore latency. So this is really the ideal case for the EPYC processors.
Nevertheless, even if we take into account that AMD has an 45% memory bandwidth advantage and that Intel latest chip (8280) offers about 7 to 8% better performance, this is amazing. The SPECint rate numbers of the EPYC 7742 are - on average - simply twice as high as those of the best available socketed Intel Xeons.
Interestingly, we saw that most rate benchmarks ran at P1 clock or the highest p-state minus one. For example, this is what we saw when running libquantum:
While some benchmarks like h264ref were running at lower clocks.
The current server does not allow us to do accurate power measuring but if the AMD EPYC 7742 can stay within the 225W TDP while running integer workloads at all cores at 3.2 GHz, that would be pretty amazing. Long story short: the new EPYC 7742 seems to be able to sustain higher clocks than comparable Intel models while running integer workloads on all cores.
180 Comments
View All Comments
krumme - Thursday, August 8, 2019 - link
Because he is feeded by another hand.Enjoy the objectivity by Johan as its is very rare these days. It's not easy for AT to post this stuff. So kudos to them.
hoohoo - Thursday, August 8, 2019 - link
Nice review, but tbh I think you should run the AMD system as such, not limit it's RAM to what the Intel system maxes out at. I would not buy a system and configure it to limits of the competition: I would configure it to it's actual linits.yankeeDDL - Thursday, August 8, 2019 - link
Wow. "Blasted" is the only word that comes to mind. Good job AMD.eastcoast_pete - Thursday, August 8, 2019 - link
Thanks Johan and Ian! Impressive results, glad to see that AMD is once again making Intel sweat, all of which can only be good for us.Question: A bit out of left field, but why does AMD put the 7 nm dies in these close pairs, as opposed to leaving a little more space between them? Wouldn't thermals be better if each chip gets a little more "reserved" lid space? Just curious. Thanks!
sharath.naik - Thursday, August 8, 2019 - link
Now since we finally are entering the era where a single server(Yes backup is addition) is enough for most of smaller organizations. There is one thing that is needed, OS limits/zones which can limit the cpus and memory built in, instead of using VMs. This will save a lot on resources wasted on booting up an entire OS for individual applications. Linux has the ability for targeting specific cpus but not sure windows has it. But there is a need for standardized way to limit resources by process and by user.mdriftmeyer - Thursday, August 8, 2019 - link
Agreed.quorm - Thursday, August 8, 2019 - link
Is it possible you haven't heard of docker?abufrejoval - Sunday, August 11, 2019 - link
or OpenVZ/Virtuozzo or quite simply cgroups. Can even nest them, including with VMs.DillholeMcRib - Thursday, August 8, 2019 - link
destruction … Intel sat on their proverbial hands too long. It's over.crotach - Friday, August 9, 2019 - link
Bye Intel!!