Yeah, that's what threw me for a loop. It's not really a significant shrink on-die, though it would be interesting to see how 4c-only machines perform for their power budget.
All in all a weird showing, but not entirely unexpected given how long AMD has avoided big.LITTLE for.
Its not as dramatic as Intel's E cores, but its still significant enough to save a lot of space (hence AMD could make slightly bigger 16-core CCDs. with them).
Every little bit of die shrinkage increases yield too. Defect rates during the lithography are proportional to mm^2 of die area, so these chips are likely more profitable for AMD to ship too.
Gives them a way to squeeze more money out due to less wasted defective chips.
The IO die is not even fully populated! I'm sure there is a technical reason they didn't make Bergamo bigger (bandwidth starvation?), but it almost feels like they are trying not to clobber Intel too hard.
I think the bigger part is that they are running out of bandwidth to feed the cores. They already bumped the ram up to 12 channel, and the chip is already mostly cache. They could pretty easily make a 256 core chip if they wanted, but those cores would spend all of their time waiting for data.
And if they build 3D cache capability into the Bergamo CCD, that would still blow up the die size (from the TSVs) and not alleviate some workloads anyway.
For the Zen 3 generation, AMD quietly mentioned that they skipped the 5950X3D because there was too much congestion between the CCDs, thanks to all the extra L3 they were trying to access. The IF links got saturated.
Maybe something similar would happen to Bergamo as well. Even if there's enough memory bandwidth, the IO die just gets saturated with all the CCD slots active.
It's a pretty significant shrink given that a huge chunk of the core's die area is L2 cache which doesn't really shrink at all. If I remember rightly this was better explained in previous coverage when Zen 4c was first announced.
"Intel’s Thread Director controller puts an embedded microcontroller inside the processor such that it can monitor what each thread is doing and what it needs out of its performance metrics. It will look at the ratio of loads, stores, branches, average memory access times, patterns, and types of instructions. It then provides suggested hints back to the Windows 11 OS scheduler about what the thread is doing, whether it is important or not, and it is up to the OS scheduler to combine that with other information about the system as to where that thread should go."
Don't think AMD has such a thing consider their all cores are "equal" approach.
I wonder if the die pictures in the article are accurate representations of the difference.
They surprised me, as they don't look like "adjusted layout for different process options", as the 4c variant has been previously described in the press. Instead it looks more like "chopped off entire controller or coprocessor subsystems, and also shrunk a tiny bit"...
That slide is clearly just an artist's imagination, not really derived from any die photo. Which is a little odd, because AMD has previously shown realistic depictions of the cores excerpted from real die shots.
Next year isn't great timing as they'll be going up against Qualcomm's new Oryon CPU which looks to be both powerful and tiny (165mm2 with 12 full-size cores).
Will we have a working ARM Windows version next year? A translation layer in Windows and Linux to run x86 apps, like games? If not, and I think we won't, then the Qualcomm chip won't be a relevant alternative to the Ryzen processor.
In linux you have a pretty good support for just recompiling everything as native arm binarys, atleast server side it works without any problems for me.
I ran into problems with that on the server back then, but always only some edge cases - so that might work mostly now. But mentioning games was no accident - a slow translation layer won't cut it for them, and you can't recompile proprietary games. We have steam on Linux -> not supporting them is a non-starter.
Worked for apple because they had no relevant gaming market share to begin with, and their translation layer actually worked well.
Native devs need to start always cross-compiling their apps for multiple ISAs from the start. Outside of a very tiny amount writing their own SIMD assembly, this isn't usually a huge deal.
WASM is also finally becoming a decent solution to not just cross-ISA, but cross-platform too. It's not yet performant enough for everything, but even among native stuff, I'd guess it's good enough for most.
We're talking about laptop processors so yeah, the GPU matters. Most laptops don't have a discrete GPU so whatever GPU is included in the main SoC is what you get.
These aren't really E-cores like the ones Intel or ARM have though - they're microarchtecturally identical to a full Zen 4 core with all the execution units, L1+L2 cache, and out-of-order magic and in theory perform identically to one when running at the same clock speed. They just use less die area at the cost of a lower maximum clock. This is different from Intel's E-cores or ARM's little cores which are simpler and have worse clock for clock performance.
> use less die area at the cost of a lower maximum clock.
This makes no sense to me. Lower die area means smaller feature sizes (ie a process size change) or fewer transistors (ie features change). I’m not sure how you have the same features in a smaller die area and (presumably) be at the same process node and “just” sacrifice clocks.
Do you have a source for that? Or more information about how that is possible?
Circuit design has some interesting nuances. For example, within a given process transistors are available in different sizes: low-Vt transistors are physically larger and faster while high-Vt are smaller but slower (and there are multiple in-between sizes). Using the same design but different transistors it's possible to trade off area and clock frequency, which is exactly what AMD has done in this case. There may also be thermal considerations; a dense high-frequency design could have unacceptable hot spots so they space it out a bit to spread the heat. At a lower frequency the hot spots would be less of a problem. I can also imagine that delivering high current to a small area could cause voltage droop in the power delivery network.
I didn't & don't understand why these zen 4c cores aren't everywhere? They were portrayed as a pure win in Bergamo, less cache but vastly smaller.
Wouldn't you want that everywhere? Same perf but smaller means less cost for AMD yes? Bergamo was excused as "this is just for high density since we have existing chios for medium density" but if you are making new chips why not use the smaller but equal one?
Either give me all Zen 4 cores or all 4c cores. I don't want any Intel-inspired "multithread-winning marketing" hybrids, thank you very much! Pure 16c Zen4 or 24c 4c would be great though.
Against hybrid - scheduler issues, like when Intel E-cores slowed down networking or NVMe massively. I can live without those surprises happily. And all small cores are great for home or small servers.
OK, so 8 cores. But homogeneous, either 4 or 4c but not mixed as schedulers are crappy and you end up having your slow cores in charge of your fast 25Gb LAN and be surprised it only gives you like 7Gb instead... Nightmare performance stuff like that common with Intel E-cores.
I have yet to see programs written with a multi-core approach in mind perhaps maybe except game programmers who had to suck it up with the PS3 with it's wacko PPE and SPU's or Xbox 360 with it's 3 PowerPC cores.
It is a pain to write multi-threaded app - so one browser tab = one core.
43 comments
[ 0.23 ms ] story [ 37.7 ms ] threadAll in all a weird showing, but not entirely unexpected given how long AMD has avoided big.LITTLE for.
Gives them a way to squeeze more money out due to less wasted defective chips.
The IO die is not even fully populated! I'm sure there is a technical reason they didn't make Bergamo bigger (bandwidth starvation?), but it almost feels like they are trying not to clobber Intel too hard.
For the Zen 3 generation, AMD quietly mentioned that they skipped the 5950X3D because there was too much congestion between the CCDs, thanks to all the extra L3 they were trying to access. The IF links got saturated.
Maybe something similar would happen to Bergamo as well. Even if there's enough memory bandwidth, the IO die just gets saturated with all the CCD slots active.
Don't think AMD has such a thing consider their all cores are "equal" approach.
They surprised me, as they don't look like "adjusted layout for different process options", as the 4c variant has been previously described in the press. Instead it looks more like "chopped off entire controller or coprocessor subsystems, and also shrunk a tiny bit"...
At a minimum, I'd like to see 4 P-cores and 4 E-cores plus 8 CU (preferably 16-24 CU).
https://learn.microsoft.com/de-de/windows/arm/apps-on-arm-x8...
In linux you have a pretty good support for just recompiling everything as native arm binarys, atleast server side it works without any problems for me.
Worked for apple because they had no relevant gaming market share to begin with, and their translation layer actually worked well.
WASM is also finally becoming a decent solution to not just cross-ISA, but cross-platform too. It's not yet performant enough for everything, but even among native stuff, I'd guess it's good enough for most.
Are the GPU cores that necessary?
This makes no sense to me. Lower die area means smaller feature sizes (ie a process size change) or fewer transistors (ie features change). I’m not sure how you have the same features in a smaller die area and (presumably) be at the same process node and “just” sacrifice clocks.
Do you have a source for that? Or more information about how that is possible?
Wouldn't you want that everywhere? Same perf but smaller means less cost for AMD yes? Bergamo was excused as "this is just for high density since we have existing chios for medium density" but if you are making new chips why not use the smaller but equal one?
It isn’t the same peak performance in the desktop, but it can be the same wide-scaling performance on highly threaded web server or database loads.
Give us the power or give us the energy savings, this hybrid is both the best AND worst of both worlds.
It is a pain to write multi-threaded app - so one browser tab = one core.