Dissecting Intel's EPYC Benchmarks: Performance Through the Lens of Competitive Analysis
by Johan De Gelas & Ian Cutress on November 28, 2017 9:00 AM EST- Posted in
- CPUs
- AMD
- Intel
- Xeon
- Skylake-SP
- Xeon Platinum
- EPYC
- EPYC 7601
Enterprise & Cloud Benchmarks
Below you can find Intel's internal benchmarking numbers. The EPYC 7601 is the reference (performance=1), the 8160 is represented by the light blue bars, the top of the line 8180 numbers are dark blue. On a performance per dollar metric, it is the light blue worth observing.
Java benchmarks are typically unrealistically tuned, so it is a sign on the wall when an experienced benchmark team is not capable to make the Intel 8160 shine: it is highly likely that the AMD 7601 is faster in real life.
The node.js and PHP runtime benchmarks are very different. Both are open source server frameworks to generate for example dynamic page content. Intel uses a client load generator to generate a real workload. In the case of the PHP runtime, MariaDB (MySQL derivative) 10.2.8 is the backend.
In the case of Node.js, mongo db is the database. A node.js server spawns many different single threaded processes, which is rather ideal for the AMD EPYC processor: all data is kept close to a certain core. These benchmarks are much harder to skew towards a certain CPU family. In fact, Intel's benchmarks seem to indicate that the AMD EPYC processors are pretty interesting alternatives. Surely if Intel can only show a 5% advantage with a 10% more expensive processor, chances are that they perform very much alike in the real world. In that case, AMD has a small but tangible performance per dollar advantage.
The DPDK layer 3 Network Packet Forwarding is what most of us know as routing IP packets. This benchmark is based upon Intel own Data Plane Developer Kit, so it is not a valid benchmark to use for an AMD/Intel comparison.
We'll discuss the database HammerDB, NoSQL and Transaction Processing workloads in a moment.
The second largest performance advantage has been recorded by Intel testing the distributed object caching layer memcached. As Intel notes, the benchmark was not a processing-intensive workload, but rather a network-bound workload. As AMD's dual socket system is seen as a virtual 8-socket system, due to the way that AMD has put four dies onto each processor and each die has a sub-set of PCIe lanes linked to it, AMD is likely at a disadvantage.
Intel's example of network bandwidth limitations in a pseudo-socket configuration
Suppose you have two NICs, which is very common. The data of the first NIC will, for example, arrive in NUMA node 1, Socket 1, only to be accessed by NUMA node 4, Socket 1. As a result, there is some additional latency incurred. In Intel's case, you can redirect a NIC to each socket. With AMD, this has to be locally programmed, to ensure that the packets that are sent to each NICs are processed on each virtual node, although this might incur additional slowdown.
The real question is whether you should bother to use a 2S system for Memached. After all, it is distributed cache layer that scales well over many nodes, so we would prefer a more compact 1S system anyway. In fact, AMD might have an advantage as in the real world, Memcached systems are more about RAM capacity than network or CPU bottlenecks. Missing the additional RAM-as-cache is much more dramatic than waiting a bit longer for a cache hit from another server.
The virtualization benchmark is the most impressive for the Intel CPUs: the 8160 shows a 37% performance improvement. We are willing to believe that all the virtualization improvements have found their way inside the ESXi kernel and that Intel's Xeon can deliver more performance. However, in most cases, most virtualization systems run out of DRAM before they run out of CPU processing power. The benchmarking scenario also has a big question mark, as in the footnotes to the slides Intel achieved this victory by placing 58 VMs on the Xeon 8160 setup versus 42 VMs on the EPYC 7601 setup. This is a highly odd approach to this benchmark.
Of course, the fact that the EPYC CPU has no track record is a disadvantage in the more conservative (VMware based) virtualization world anyway.
Facebook
Twitter
RSS
105 Comments
View All Comments
Ashari - Tuesday, November 28, 2017 - link
LOL, "GloFo 16nm"... tsts, one would think people like Johan De Gelas and Ian Cutress would know which node is GloFo and which one is TSMCIan Cutress - Tuesday, November 28, 2017 - link
That's my brain fart. I've been writing about other things recently. Edited.peevee - Tuesday, November 28, 2017 - link
"The benchmarking scenario also has a big question mark, as in the footnotes to the slides Intel achieved this victory by placing 58 VMs on the Xeon 8160 setup versus 42 VMs on the EPYC 7601 setup."Given how well AMDs SMT scales, a real client can put up to 128 single-CPU VMs on the EPIC 7601, and 58 VMs on Xeon 8160 would be tramped ridiculously.
Here Intel just had to rely on the shenanigans so obvious it is just fraud.
LordOfTheBoired - Tuesday, November 28, 2017 - link
Yeah, that really stuck out for me too. "We outperform AMD when running a different benchmark!"And to be frank, it casts a pall over Intel's entire PR release since it IS blatantly not how benchmarks work.
Andresen - Tuesday, November 28, 2017 - link
Many HPC task are memory bandwidth limited, and then AVX-512 is of little help. In Spec.org CFP2006 none of the recent results are using AVX-512 but instead rely on AVX2. The few tests posted using AVX-512 come out worse than the tests on similar systems using AVX2. For memory bandwidth limited tasks the EPYC has an advantage with its 8 memory channels compared to Intels 6 channels. For both architectures, a high end processor is not needed for bandwidth limited task, since the don't offer more memory channels.Johan Steyn - Monday, December 18, 2017 - link
AVX also heats up the CPU a lot and it has to throttle down. With AVX, Intel cannot run high clock speesds.ddriver - Tuesday, November 28, 2017 - link
Just when you think AT cannot possibly sink any lower, they now directly publish publish intel benchmarks of a competing product.Coldfriction - Tuesday, November 28, 2017 - link
I myself was confused and dissapointed reading the summary where agreement with Intel seems to be presented by the authors. Using prases like "there is no denying that the Intel Xeon is a 'safer bet' for VMware virtualization" without testing it pushes AT into the realm of paid for shills. Independent reviews wouldn't trust anyone's marketing and even if they were to publish an article on benchmarks from a competitor, they would fill the thing with hefty amounts of skepticism until they could test it themselves. What Intel presents could very realistically be true (personally, I don't doubt that their benchmarks are within the ballpark of being legit), but I want my independent review sites to have as little bias as possible and that means objectively testing the hardware and ignoring the marketing.wumpus - Wednesday, November 29, 2017 - link
These type of servers are rarely bought by customers for personal use. Instead, they are bought for a 'real job' where CYA decisions outweigh any performance benefits (to a degree, the end product has to work). If something really goes wrong, you can always expect to get the blame for buying the "off brand" instead of following the sheep, regardless of what really caused the failure (typically with highly annoyed management who can't tell *anything* about the server than it is the "off brand").If this isn't a consideration you have a "great job". Expect the owner to sell at some point or expand to the point it is controlled by MBAs and downgrade everybody's job to a "real job'. Sorry to say, but at least in the USA that is life.
Johan Steyn - Monday, December 18, 2017 - link
People sometimes really surprise me. What support doe you want from AMD? Yes if there is a booboo like Intel has (present tense) with its security flaw, you need support from them. I have sold numerous systems and servers in my life and never did I go to AMD or Intel to ask for support. It either the OEM, component supplier or component manufacturer (like motherboards etc) who you go to for support.If the CPU works as it should, you do not need support. CPU's were in my experience the one component that rarely if ever dies on you. So if you trust Tyan to make good products, which they do, they are the ones to give you support, not AMD. AMD has to help with Bioses etc. with which they are very good.
So please stop with this support issue and safer bet. If the system runs unstable because of hardware issues, sure they have to sort it out, but till now, none has been reported.
What has Intel done about the bug recently found? Did they come to you to fix it and support you? Nope, you have to fix it yourself, that is if the motherboard manufacturer has a bios update. So, for me it looks like AMD might just be the safer bet after all...