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.
There are two separate claims being made by Intel, so let’s take them in order. First, Intel claims that AMD erred by not making use of the appropriate optimizations for its own platform and that if it had done so, performance on the comparative Intel platform improves by 30 percent, from 9.68ns/day to 12.65ns/day. That’s not enough to match Rome, but it’s still a large gain.
Second, Intel claims that its Cascade Lake-AP CPUs will offer much more competitive performance against Rome. The Xeon Platinum 9242 (48C/96T, 2.3GHz-3.8GHz clock) scores a 19.9 compared with AMD’s 19.6, while the Xeon Platinum 9282 (56C/112T, 2.6GHz – 3.8GHz) scores a 24.16, 1.23x faster than AMD’s Epyc Rome platform.
We’re going to discuss the CPU positioning question first. AMD has not revealed pricing on its new Epyc CPUs, but it would be extremely difficult to compare against Intel’s pricing even if they had. Intel doesn’t sell Cascade Lake-AP CPUs separately. They can only be bought as part of a complete Intel system, sold directly by the company. Before Cascade Lake-AP launched, rumors suggested at least some of these CPUs were being priced at $20,000 each. They also draw far more power than the expected consumption of Epyc. The TDP rating we’ve heard rumored for AMD’s new 7nm chip is 240W, and that seems perfectly plausible based on the TDP distribution in the Ryzen 3000 family. Intel’s Cascade Lake-AP CPUs, in contrast, draw 350W and 400W at base clock.
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.
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.