I hope that's the biggest outcome from this. My inside sources tell me that Intel has their briefs in a bind over AMDs latest technology, and are certainly kerfuffling over it, but I'm not sure how quickly they can respond. It seems like the disparity in this cycle has grown wider than in the past. But that is just my subjective take - I'm not really conversant on the manufacturing part. I'm just historically reviewing the power consumption and benchmarks.
AMD won't be in the position to just rest on their laurels for years to come. So the fact that Intel is scrambling to come up with a competitive response shouldn't be a concern as far as competition goes in the short-medium term.
I'd say we have at least a few CPU generations coming from AMD without worrying that they become complacent, even if Intel still comes up short.
True, it has more cores, but it seems Xeon's have to clock down when executing AVX-512 ops to stay within their power budget.
It's also doing this at almost half the cost and consuming less power ... that's nothing short of astounding.
Xeon's do have a benefit for workloads that can stay in L3 cache as their mesh means latency is stable, whereas Epyc is 16MB per CCX.
Overall memory latency is also lower, which is the tradeoff with the IO die, but it will be interesting to see what real world numbers for DB's etc. say about that.
The problem with the AVX2/AVX512 clocks with Intel is not the fact that they must clock lower to use them (for pure AVX code, running wider but at the lower clock speed is still worth it!), it's that they need to clock lower pre-emptively for any such instructions, and must remain at this lower clock for a while. This means that code that executes a few AVX instructions every now and then mixed in with a lot of integer code needs to run the whole program at a lower clocks.
In contrast, AMD runs their chip power supply from a huge mimcap built in the chip, meaning that they have margin so they can start executing exceptionally power-hungry instructions, and only clock down reactively if it's actually needed. And also do the clocking down and up with a much finer granularity, clocking up immediately after the need to clock down passes.
* With heavy avx instructions churning, AVX should still be a net positive performance-wise even when clocking down.
* It's when you're running AVX mixed with non-vector code that you can see the performance effects of clocking down, since you can drop way down from Turbo on non-vector instructions. Here are the different ranges [1]
[1] - Pages 14-21 https://www.intel.com/content/dam/www/public/us/en/documents...
So there's both AVX-512 vs. clockspeed & AVX-512 vs. silicon budget going on. For many usecases having extra cores is a good trade-off.
I've only followed casually in the last decade+ but I was under the impression that the ATI merger was meant to support a long term bet on better chips by AMD and we're starting to see the fruit of that labor.
So it would appear AMD was ahead of the game.
I guess, at the time, the thinking was that GPUs were a core threat to the CPU business itself, since a lot of the buzz was around using the GPU to do CPU activities.
To be honest for a while I thought that was where everything but servers would be going. You can tune your OS and applications around the slower GDDR5 and it seemed a no brainer: instead of 8GB of system memory topping out and then 4GB of VRAM doing jack shit you could have 12GB that could be dynamically assigned to whatever you wanted!
Alas, that dream was never meant to be.
Edit: I posted about this a while a back and apparently Arch Linux has a hacky way to use your VRAM as system RAM. Good stuff.
* Integrated graphics in their CPUs is important for lower-end systems and APU/SoCs. Intel had an integrated GPU at the time, AMD didn't.
* It allowed them to provide the CPU+GPU for all Xbox and Playstation consoles since the acquisition
* It might have allowed them better deals with chip factories because their volume increased
Also, most computers come with integrated graphics today. It's the no brainer choice for most uses.
But the chiplet architecture, supported by fast Infinity Fabric interconnect is what puts AMD ahead. Intel will have to go same route to stay competitive. And now they are two steps behind.
The smaller dies and modular setup even on the same die gives them so much flexibility in their binning and package integration and must keep defect rates much lower than Intel’s monolithic high core count chips.
Exactly this. Funny Intel is no longer mocking this as dies "glued together".
[1] http://www.daemonology.net/papers/htt.pdf by none other than our resident cpercival!
One thing missing from discussions as the results of Zen 2 EPYC is ARM on Server is now pretty much dead. I don't think any HyperScaler really want ARM on server per se, they simply want better pricing. And having AMD competing with Intel will provide just that.
I don't see ARM Server being a viable alternative in the next 5 years.
Ampere has a chance too, if they get big gains from 7nm and/or massively improve their microarchitecture while keeping the current prices, they'll be unbeatable in price/performance.
> I don't think any HyperScaler really want ARM on server per se
There definitely seems to be a concern with the AMD/Intel duopoly, and Amazon clearly just wants absolute control, since they've already deployed in-house chips that mix ARM cores with <s>Bezos Backdoors</s> fancy cloudy networking and verified boot stuff.
Seems AMD is back