Hacker News Reader

Comment by shereadsthenews | Hacker News Reader

On realistic workload (branchy C++ server code, not SPEC and the other crap that Phoronuts like to report) the AMD CPUs are 50% slower ... Intel could pile on the mitigations and still be way ahead. The reason these mitigations cost Intel so much is because they have these speculation features and AMD just didn't ever have them. At least with the Intel parts you can decide for yourself whether to enable or disable them.

View on HN

Please provide a single benchmark of any kind to support that. It sure sounds like you're stuck in 2016, though, before Zen happened with its +52% IPC improvement over Excavator. Otherwise basically all clock for clock battles shows Zen in single-digit percentage range of Intel on IPC. Combined with Intel having a clock speed advantage that does give Intel +10-20% in pure single-thread performance, but that was pre-mitigations. If this vulnerability fix really does cost 25% that'd erase that advantage entirely.

And no, Intel is not unique in speculation capability.

Xeon absolutely crushes EPYC on MySQL Sysbench. The top-of-the-line EPYC provides performance similar to the five-year-old Xeon E5 v3 (Haswell) from Intel, except at high thread counts where that obsolete Intel part also crushes the EPYC. These results are on Percona's own blog and are also backed up by Anandtech's reviews where Skylake Xeons are ~twice as fast as AMD's.

For large codes there is just no getting around the fact that the AMD parts have a weird and highly fragmented cache architecture, very slow memory access, NUMA memory latency even on the same socket, and a frankly broken branch target buffer. Xeon has none of these problems.

You mean this? https://www.percona.com/blog/2018/07/11/amd-epyc-performance...

If by crushing it you mean performed nearly identically, and if by 5 years old you mean the very latest E5 chip Intel offers[1], then yes.

Also, they were using EPYC through a cloud VM provider, which means not only is there the typical overhead of Xen, but also possibly some aggressive Spectre mitigations. Their Haswell machine was likely bare metal.

[1] Because E5 and E7 chips only migrate microarchitecture every few generations. But since Intels fab headaches they're actually stuck nearly 4 generations behind, rather than the typical 2-3. Only desktop and E3 series chips use the latest microarchitecture.

EDIT: I forgot they changed their naming scheme. The latest 56-thread capable Xeon Platinum chips available last year used Skylake. I was confirming my understanding with https://en.wikipedia.org/wiki/Xeon but didn't see this page: https://en.wikipedia.org/wiki/List_of_Intel_Xeon_microproces...

The E5 v3 is not the latest even under the old naming scheme. It is a chip from 2014. The E5 v4 "Broadwell" came out in 2016. Skylake SP came out in 2017 and Cascade Lake SP is the current SKU. The EPYC performance on that MySQL benchmark is 3 generations behind Intel.

> The EPYC performance on that MySQL benchmark is 3 generations behind Intel.

Intel's performance hasn't changed for 3 generations, either. They've been stagnant for years now with their 10nm roadmap being super late at this point, delaying their architecture updates at the same time.

Definitely wrong. Skylake SP is 50% faster than Broadwell on MySQL Sysbench, and Broadwell was 200% faster than Sandy Bridge. That's almost 500% improvement in 6 years. I haven't got a chance to evaluate Cascade Lake SP yet but I expect the pace of improvement to continue and they have hardware mitigations for Spectre/Meltdown/L1TF.

Horseshit. Unless you're comparing different core counts that'd make MySQL the extreme outlier against hundreds of other tests that have shown again and again and again and again that Intel's IPC has been stagnant for years now with OK but minimal frequency improvements.

With numbers like this you really need to link some benchmarks. I can't find anything remotely similar.

The blog post and cloud provider's website both say the servers are bare metal.

I stand corrected. I didn't see it mentioned on the page but assumed because it was a "cloud server" that they were using multi-tenant infrastructure. But apparently for all servers they're bare metal, presumably provisioned with IPMI.

I still disagree with the previous poster's claims and conclusions, but I really should've done my homework better. I tried but clearly not hard enough.

What do you mean by 'large codes'? Also you should provide a link.

I mean the working set of the executable program is much larger than the processor's L1 instruction cache. Virtually all realistic cloud workloads (search, databases, email, etc etc) meet this definition of "large" whereas almost all synthetic benchmark programs are very small. Not surprisingly AMD looks great on the latter and terrible on the former because the microarchitectural resources they've committed to branch prediction and speculation are meager and their weird memory architecture exacerbates the problem.

Nonsense. Epyc's memory latency is only slightly behind Intel's, and every test other than MySQL shows neck & neck IPC across dozens of real-world programs that definitely don't fit in L1.

POV-Ray doesn't fit in L1 and Epyc 7601 trivially bests the Xeon 8176, and does so while using a ton less power. Similarly NAMD, even with AVX & compiled with Intel's ICC, runs waaaay faster on Epyc 7601 than it does on Xeon 8176.

Maybe your workload is exclusively MySQL or looks a lot like it. If so, sure, go buy Intel. But there's a ton of cases where there is no where close to such a gap, including large cloud workloads. You keep taking a single benchmark result and massively over-extrapolating it to mean the entire cloud hosting world. That's not how this works.

You seem to be very invested in disparaging AMD, but haven't provided any links to back up your claims, some of which are completely bizarre.

Reply on news.ycombinator.com