Intel Claims AMD Misrepresented 7nm Epyc Performance vs. Xeon

Intel Claims AMD Misrepresented 7nm Epyc Performance vs. Xeon

At Computex this past week, AMD CEO Lisa Su revealed new details on the company’s upcoming line of 7nm Epyc CPUs, codenamed Rome. AMD has claimed that Rome will offer a substantial performance uplift over first-generation Epyc, courtesy of new 256-bit AVX2 registers and its higher core counts. On stage, Su presented benchmark information showing two AMD 64-core Rome CPUs outperforming two Intel Xeon Platinum 8280s. The Xeon Platinum 8280 is a 28-core Cascade Lake CPU (Cascade Lake). It isn’t particularly surprising that AMD’s 128 core configuration turns in more than 2x the performance of the Intel system. The Intel platform was capable of 9.68ns/day of folding, while the AMD platform hit 19.6ns/day.

Intel, however, has taken exception to these benchmark results and released its own data implying AMD made a poor comparison here.

Intel Claims AMD Misrepresented 7nm Epyc Performance vs. Xeon

CPU Positioning

AMD most likely chose the Platinum 8280 as its comparison point because it wanted to make an argument about price. We have no idea how it will price its upcoming 64-core CPUs, but an Epyc 7601 (32-core) is currently $4464 on Newegg. It isn’t crazy to think AMD might bring a 64-core to market in the $8K – $10K range, making the 8280 a solid choice of competitor. Intel’s Cascade Lake AP may be faster core-for-core than Rome once optimized, but it’s also going to cost far more — and draw considerably more power.

Optimization Claims

The other claim being made is that AMD misrepresented Intel performance by not performing certain optimizations before running the benchmark. Intel’s website gives specific compiler flags that should be called for this benchmark and suggests some other performance optimizations as well. AMD may not have done this.

But there’s a tiny footnote in Intel’s slide that undercuts the company’s argument here. The first sentence reads: “Software and workloads used in performance tests may have been optimized for performance only on Intel microprocessors.

A little later, there’s another significant disclosure:

Intel’s compilers may or may not optimize to the same degree for non-Intel microprocessors for optimizations that are not unique to Intel microprocessors. These optimizations include SSE2, SSE3, and SSSE3 instruction sets and other optimizations. Intel does not guarantee the availability, functionality, or effectiveness of any optimization on microprocessors not manufactured by Intel. Microprocessor-dependent optimizations in this product are intended for use with Intel microprocessors.

If you recall the AMD versus Intel antitrust lawsuit from the mid-2000s, you might be chuckling right now. To make a long story short, Intel’s compiler used to refuse to generate SSE or SSE2 code that would run on AMD CPUs, even though AMD paid for a license to use SSE and SSE2 technology. This fact wasn’t well-known, and Intel got into some trouble for representing its own compiler as the fastest x86 solution without necessarily disclosing that it refused to output code that would run optimally on non-Intel chips.

Intel’s legal statements emphasize that Intel has absolutely no legal duty to make any of its products work well on competition hardware. And that seems to matter when discussing what obligation one company has to another when it comes to optimizing for a benchmark run.

There is a difference — a significant difference — between harming someone’s performance in a way that makes their score lower than it otherwise would be as opposed to testing in a default state. And according to THG, who broke the story, there’s no evidence that AMD set out to harm the Intel test run or that it used other compiler flags or settings that would make the Intel CPU look bad. Yes, AMD used a different compiler for Epyc than it did for Intel (for example) — but look at the boilerplate legal language up there and you’ll immediately understand why they did. Intel explicitly makes no promise that its compiler will output good code for a non-Intel CPU.

Intel’s argument here isn’t very strong, particularly given the long-term history around compiler optimizations and competitive advantage. Of course, there are people who would argue that manufacturer performance comparisons should put the competition’s best foot forward, in any comparison — but that kind of ethos is something you typically only see when a company knows it has a product that will win the match-up.

Always take manufacturer-provided benchmarks with a grain of salt, no matter who they’re coming from.

Continue reading

MSI’s Nvidia RTX 3070 Gaming X Trio Review: 2080 Ti Performance, Pascal Pricing
MSI’s Nvidia RTX 3070 Gaming X Trio Review: 2080 Ti Performance, Pascal Pricing

Nvidia's new RTX 3070 is a fabulous GPU at a good price, and the MSI RTX 3070 Gaming X Trio shows it off well.

RISC-V Tiptoes Towards Mainstream With SiFive Dev Board, High-Performance CPU
RISC-V Tiptoes Towards Mainstream With SiFive Dev Board, High-Performance CPU

RISC V continues to make inroads across the market, this time with a cheaper and more fully-featured test motherboard.

Ryzen 9 5950X and 5900X Review: AMD Unleashes Zen 3 Against Intel’s Last Performance Bastions
Ryzen 9 5950X and 5900X Review: AMD Unleashes Zen 3 Against Intel’s Last Performance Bastions

AMD continues its onslaught on what was once Intel's undisputed turf.

Intel Is Spreading FUD About Supposedly Huge Ryzen 4000 Performance Drops on Battery
Intel Is Spreading FUD About Supposedly Huge Ryzen 4000 Performance Drops on Battery

Intel believes it has presented evidence that negates the value of AMD's Ryzen 4000 product stack. Intel is mistaken.