If you need multi-core speeds, you'd be silly to not go AMD Epyc (~50% cheaper), or ARM.

People paid the IBM tax for decades. Intel is the new IBM. Wherever you look, Intel's lineup is not competitive and it is only surviving due to inertia.

If the operating margins in the article are realistic then there is a lot of room for undercutting Intel if you can convince the customer to take the plunge. That is, if you’re not in an IBM-vs-Amdahl situation where the lower price is not enough.

It isn't quite that simple, Intel has way more engineering resources than AMD and for some complicated setups like data centers, Intel really does have good arguments that their systems are better tested than the competition, and Intel does have better ability to bundle products together than AMD.

Intel is behind in fab technology. I don't think the problem is that Intel's chip designs are what's holding them back. AMD offered better multi core performance and Intel responded with more cores as well. However, I do believe that Intel suffers from an awful corporate environment. There was a story about ISPC [0] with one chapter [1] talking about the culture at the company.

[0] https://pharr.org/matt/blog/2018/04/30/ispc-all.html

[1] https://pharr.org/matt/blog/2018/04/28/ispc-talks-and-depart...

> their systems are better tested than the competition

Yes, Spectrum and Meltdown definitely proves that...

I think I heard that argument already, in the 90's. But instead of Intel it was Sun, it was SGI, it was Digital, etc

The truth is that money wins and while there is an inertia, it's more like a Cartoon inertia where your guy won't fall from the cliff until he looks down. But then it's too late.

If by tested you mean, getting eaten alive by vulnerability reports monthly and furthering degrading performance, sure. There isn't much rocket science otherwise to "better tested" in a server platform. Either it passes benchmarks of use case scenarios or it doesn't.

Yes there is. Server platforms are connected to more storage, higher bandwidth networking and more exotic sockets (more than one CPU). It is one thing to support lots of PCI express lots on paper. It is another thing to have a working solution that doens't suffer degraded performance when all the PCI express slots are in use at the same time.

None of this is rocket science but it takes money and engineers time to make these things happen. Intel has more of both at the moment.

There are plenty of applications where single-threaded clock speed matters, and Intel still wins by a wide margin there. Cache size is also a factor, and high end Xeon's have more cache than any competing CPU I've seen.

The just announced Intel Xeon Cooper Lake top end processor has about 38.5MB of cache. The AMD Rome top end has 256MB of cache.

https://ark.intel.com/content/www/us/en/ark/products/205684/...

https://www.amd.com/en/products/cpu/amd-epyc-7h12

I'm not sure this is the whole story, Intel has twice the L2 cache as AMD but I'm not sure that's enough to make a huge difference.

Epyc 7H12[1]:

- L1: two 32KiB L1 cache per core

- L2: 512KiB L2 cache per core

- L3: 16MiB L3 cache per core, but shared across all cores.

The L1/L2 cache aren't yet publicly available for any Cooper Lake processors, however the previous Cascade Lake architecture provided:

All Xeon Cascade Lakes[2]:

- L1: two 32 KiB L1 cache per core

- L2: 1 MiB L2 cache per core

- L3: 1.375 MiB L3 cache per core (shared across all cores)

Normally I'd expect the upcoming Cooper Lake to surpass AMD in L1, and lead further in L2 cache. However it looks like they're keeping the 1.375MiB L3 cache per core in Cooper Lake, so maybe L1/L2 are also unchanged.

0: https://www.hardwaretimes.com/cpu-cache-difference-between-l...

1: https://en.wikichip.org/wiki/amd/epyc/7h12

2: https://en.wikichip.org/wiki/intel/xeon_platinum/9282

Edit: Previously I showed EPYC having twice the L1 as Cascade Lake, this was a typo on my part, they're the same L1 per core.

Zen 2 has 4MiB L3 per core, 16 MiB shared in one 4-core CCX.

Thanks, I wrote that while burning the midnight oil and didn't double-check the sanity of those numbers. It's too late to edit mine but I hugely appreciate the clarification.

NP. It's still a huge amount of LLC compared to the status quo. Says something about how expensive it really is to ship all that data between the CCXs/CCDs.

Intel L3 does not equal AMD L3 cache regarding latencies. Depending on the application this can matter a lot. https://pics.computerbase.de/7/9/1/0/2/13-1080.348625475.png

You'd need that latency to be significant enough that AMD's >2x core count doesn't still result in it winning by a landslide anyway, and you need L3 usage low enough that it still fits in Intel's relatively tiny L3 size.

There's been very few cloud benchmarks where 1P Epyc Rome hasn't beaten any offering from Intel, including 2P configurations. The L3 cache latency hasn't been a significant enough difference to make up the raw CPU count difference, and where L3 does matter the massive amount of it in Rome tends to still be more significant.

Which is kinda why Intel is just desperately pointing at a latency measurement slide instead of an application benchmark.

Cache per tier matters a lot, total cache does not tell much. L1 is always per core and small, L2 is larger and slower, L3 is shared across many cores and access is really slow compared to L1 and L2. In the end performance per watt for a specific app is what matters, that is the end goal.

Interesting, that's news to me. Guess Intel just has clock speed then. That's why I still pay a premium to run certain jobs on z1d or c5 instances.

As another commenter pointed out, though, not all caches are equal. Unfortunately, I was not able to easily find access speeds for specific processors, so single-threaded benchmarks are the primary quantitative differentiator.

Given the IPC gains of Zen 2, the single-threaded gap is closing, and even reversed in some workloads.

And I think Xeon L3 cache tops out at about 40MB, whereas Threadripper & Epyc go up to 256MB.

Really? 'Entry-level' EPYC's (7F52) have 256MB of L3 cache for 16 cores.

I don't think there's any Intel CPU's with more than 36MB L3?

Xeon 9282s have 77MB: https://ark.intel.com/content/www/us/en/ark/products/194146/...

77MB for 56 cores. That's that ploy where they basically glued two sockets together so they could claim a performance per socket advantage even though it draws 400W and that "socket" doesn't even exist (the package has to be soldered to a motherboard).

IIRC the only people who buy those vs. the equivalent dual socket system are people with expensive software which is licensed per socket.

Those applications exist, but not enough to justify Intel’s market cap.

Do you have a source for any of the things you said?

Anecdotal: back then when SETI@home was a thing, I was running it on some servers; a 700 MHz Xeon was a lot faster (>50%, IIRC) than a 933 MHz Pentium 3, Xeon had a lot lower frequency and slower bus (100 vs 133MHz), but the cache was 4 times larger and probably the dataset or most of it was running in cache.

The same happened with the mobile Pentium-M with 1 (Banias) and 2MB (Dothan) cache - you could get the whole lot in cache and it just flew, despite the (relatively) low clock speed. There were people building farms of machines with bare boards on Ikea shelving.

Even worse for Intel, there are lots of important server workloads that aren't CPU intensive, but rely on the CPU coordinating DMA transfers between specialized chips (SSD/HDD controller, network controller, TPU/GPU) and not using much power or CapEx to do so.

> If you need multi-core speeds, you'd be silly to not go AMD Epyc (~50% cheaper), or ARM.

But Amdhal's Law shows us this doesn't make sense for most people.