I wish we had some more data on SNC4 vs SNC-OFF modes. Would give a lot more insight on what workloads, if any, benefit.
I wish we had some more data on SNC4 vs SNC-OFF modes. Would give a lot more insight on what workloads, if any, benefit.Yes, it is of course more than monolithic but there is more to it than might meet the eye at first sight:
Intel had this idea of a unified L3 cache across several tiles. That is why there are huge amounts of traffic across EMIB for next to no benefit. AMD OTOH has much less bandwidth via IFoP at much higher power per bit transferred to begin with. But because their L3 is exclusive per CCD, there is only a tiny bit of coherency traffic going on. And this is why they are much more efficient.
Of course there might be edge cases - but it is more than questionable why Intel took that design direction in the grand scheme.
Pretty sure thats in chips and cheese's article about SPRI wish we had some more data on SNC4 vs SNC-OFF modes. Would give a lot more insight on what workloads, if any, benefit.
They touched on it a bit. I remember they saw a significant decrease in average L3 latency with SNC on. But I don't think they really did a deep dive.Pretty sure thats in chips and cheese's article about SPR
SPEC, Linpack, etc. probably aren't the benchmarks that would show the most difference. Feel like we need some big database workloads on there to get a real understanding of the tradeoffs. After all, with those numbers, Intel should have just done die to die UPI instead of stretching the mesh across.A modicum of benefit at best.
I think AMD planned from the outset of the Zen/EPYC programme to maximise core count and steadily increase it generation on generation - which means appropriately scaling efficiency with core count.A monolithic 24C SPR vs 24C Zen 3 is like 15% more efficient in CB23, but a 56C SPR uses >30% more energy for the same score as a 64C Zen 3 TR? Yes the TR has more cores, but it still shouldn't be this bad.
Delays in 10nm(Ice Lake) just messed everything, further delays in Sapphire Rapids compounded the Issues, Sierra Forest and Granite Rapids SP were designed many years ago.Even SRF and GNR seem to be designed according to an outdated philosophy.
They will catch up. Once Intel has node parity, AMD will have a tough fight.Delays in 10nm(Ice Lake) just messed everything, further delays in Sapphire Rapids compounded the Issues, Sierra Forest and Granite Rapids SP were designed many years ago.
It's probably just a relic of the tried-and-true Intel design approach where all cores needed to be connected to each other with as uniform memory access as possible. Remember, Intel mocked AMD when AMD first unveiled first gen EPYC because AMD had a NUMA architecture while Intel boldly claimed that their approach was superior. For Intel to admit that AMD's approach is actually the correct one because it can scale better would be a big blow to their credibility in my opinion. AMD will eventually have more cores per CCX moving forward, but they do it judiciously because I suppose they are letting the math dictate when it should be done, rather than Intel's approach of "We have to connect all cores via a mesh because it's how we've always done it". Ironically, Intel doing things a certain way because that's how they've always done it is precisely what got them into this pickle. If they want to compete, they need to be more agile and be willing to scrap old ideas.Yes, it is of course more than monolithic but there is more to it than might meet the eye at first sight:
Intel had this idea of a unified L3 cache across several tiles. That is why there are huge amounts of traffic across EMIB for next to no benefit. AMD OTOH has much less bandwidth via IFoP at much higher power per bit transferred to begin with. But because their L3 is exclusive per CCD, there is only a tiny bit of coherency traffic going on. And this is why they are much more efficient.
Of course there might be edge cases - but it is more than questionable why Intel took that design direction in the grand scheme.
No, it is not just you. I would go as far as to say that this is common knowledge. Now the exact "why" is still up for discussion. It surely is a mix of process as well as design choices.Is it just me or does GLC use way more power iso frequency compared to Zen 3, esp at higher clocks?
Server Golden Cove core size is twice as large as a Zen3 core.Is it just me or does GLC use way more power iso frequency compared to Zen 3, esp at higher clocks?
Twice the size by area, or twice the size by xtor count?Server Golden Cove core size is twice as large as a Zen3 core.
There must be some significant customer demand for such large coherency domains. It's not like Intel lacks the tech to make a more "traditional" NUMA-type arrangement. They could have just used their existing UPI protocol over EMIB for lower power/latency and called it a day, and yet they went to all this effort. So the two options are they were just being stupid, or they had some real engineering reason for it (even if those reasons ultimately led to poor tradeoffs). In the absence of compelling evidence one way or the other, the latter seems more likely. Though I'm frustrated at the lack of proper server benchmarking for us to really work off of. Cinebench and even SPEC just don't cut it. ServeTheHome has some data, but it feels like we're working with scraps.This is something I can not get my head wrapped around:
EPYC Rome was released in 2019. So Intel will have had detailed information somewhere around 2018 at the latest. This has been five years ago and still their roadmap does not show good signs of reaction. Even SRF and GNR seem to be designed according to an outdated philosophy.
It's worth noting that Naples never really got much traction. It's Rome where AMD really took off in server, both from the doubling of core count, and the move away from a NUMA architecture. Still chiplet, but clearly NUMA wasn't the future for them either.Remember, Intel mocked AMD when AMD first unveiled first gen EPYC because AMD had a NUMA architecture while Intel boldly claimed that their approach was superior. For Intel to admit that AMD's approach is actually the correct one because it can scale better would be a big blow to their credibility in my opinion
Die size Area mm2Twice the size by area, or twice the size by xtor count?
I mean I always thought it was marginally more, but from what I'm seeing it's like drastically worse. Not just marginally, but like way, way worse.No, it is not just you. I would go as far as to say that this is common knowledge. Now the exact "why" is still up for discussion. It surely is a mix of process as well as design choices.
I don't think AMD ever moved away from a NUMA architecture, even with Rome and beyond, because there is a latency penalty for accessing data between CCDs. I'd have to see what the core-to-core latency table is for SPR, but I wouldn't be surprised if it's more uniform.It's worth noting that Naples never really got much traction. It's Rome where AMD really took off in server, both from the doubling of core count, and the move away from a NUMA architecture. Still chiplet, but clearly NUMA wasn't the future for them either.
AMD's chiplet architecture also burns tremendous power, but unlike SPR we don't have a monolithic reference point and they have enough advantages elsewhere (process, core, etc) to more than make up for it compared to the competition.
Honestly, I think the focus on SPR's chiplet architecture is misplaced. You'd expect a ~60c GLC product to perform similarly to Milan, and that's more or less what we see. What's more notable is the gaps with the process and CPU core, and the resulting inefficiency. Well, that, and of course the delays. If GNR/SRF can close the process and schedule gaps, then that would go a long way regardless of the uncore.
I mean I always thought it was marginally more, but from what I'm seeing it's like drastically worse. Not just marginally, but like way, way worse.
In CB, for example 8 P cores use >80% more energy than 8 Zen 3 cores while clocking <200MHz faster (~4.7 vs ~4.5). And it only scores ~20% better.
At 6 cores, the 12400f scores 10% better than the 5600x while boosting 300MHz lower, (4 vs 4.3), but still consumes 28% more power.
And yet for perf/watt, with ISO or near ISO perf, they look competitive.
The 12400f scores 10% better points/watt which is even more impressive considering it scores higher.
I would love to find more data at frequencies/power draw for these CPUs but it looks like that data is nonexistent :/
It looks like, especially at higher clocks, Intel is heavily depending on their PPC advantage to carry them through efficiency, but if that PPC advantage is less than expected, the efficiency craters as a result.
Node for node though, Intel 7 and TSMC 7nm should be around the same.It s because the Intel 7 process used for ADL was not as good as the one used for RPL.
Perf/Watt was sIgnificantly improved with the ESF process variant, if SPR is fabbed using the former process then there s no wonder that it has terrible perf/watt, although ESF wont close the gap with TSMC s 5nm as can be seen in DT parts comparisons.
That being said server chips uncore is much more power hungry than the ones found in DT parts, and fewer power percentage goes to the cores comparatively.
Yeah, though technically the memory latency isn't actually uniform for each CCD, and AMD's introduced a "NUMA nodes per socket" feature that's conceptually similar to Intel's SNC. But it's definitely less "NUMA-like" than Naples.Edit: Ah, I see what you were getting at. Yes, the latency from accessing RAM is now uniform across the entire package for Rome and beyond, i.e. it's all just one NUMA node within package. There is still a penalty going between CCDs though, which is less prevalent on SPR since those off-die connections are all silicon bridges.
IFOP is definitely significant, but the IO die consumes quite a bit of power in its own right. I think AMD's current uncore takes roughly half of the total TDP. Definitely interesting to speculate what different packaging tech would bring them.Yes, AMD's approach burns more power because IFOP uses more J/bit, but that's largely an issue with the selection of interconnect. If AMD hypothetically could use a silicon bridge for all of its IOD-to-CCD connections, I think the power consumption goes down significantly.
Hm... Half of the TDP seems a little high. Was that belief based on this AT article? https://www.anandtech.com/show/16529/amd-epyc-milan-review/5IFOP is definitely significant, but the IO die consumes quite a bit of power in its own right. I think AMD's current uncore takes roughly half of the total TDP. Definitely interesting to speculate what different packaging tech would bring them.