AMD starts bringing its own tiny CPU cores to new Ryzen 7040 laptop chips | Hacker News Reader

AMD starts bringing its own tiny CPU cores to new Ryzen 7040 laptop chips

arstechnica.com

71 pointsYakBizzarro42 comments

Well thats the interesting thing. They're not really "tiny," they're just Zen 4 not optimized for crazy clockspeeds.

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.

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.

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).

Bergamo (server chips) are 4c-only machines, so you could look at benchmarks for those. They're pretty impressive.

And the key here is they are using 16-core CCDs.

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.

They need to ship these in a better SKU. 2 P-core and 4 E-core just isn't that great in today's market. The lousy 4 CU iGPU is even worse.

At a minimum, I'd like to see 4 P-cores and 4 E-cores plus 8 CU (preferably 16-24 CU).

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.

It does have less L3, and maybe it's routed for longer critical paths, thereby allowing for denser packing?

https://buy.hpe.com/us/en/options/processors/amd-epyc-proces...

Are the GPU cores that necessary?

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.

It depends on what you're using your system for. I want something I can use as a light Steam Laptop in addition to other workloads.

That's coming next year.

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.

that translation layer on windows exists, its just has pretty shit perfomance last time i checked it out.

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.

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.

Strix Point sounds pretty close to Oryon.

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?

Because the higher clock and cache still matter on the desktop in less-threaded tasks.

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.

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.

It's not accurate. They actually didn't chop anything; Zen 4c is exactly the same as Zen 4, just lower clocked.

It's the same ISA, but the thing is physically smaller so it's more than turning the frequency down

How does the OS/hardware decide how to schedule tasks to P or E cores?

AMD used to have one core identified as "best" that could boost a little higher.

"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 that microcontroller is an ARM.

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.

Why? All compact cores would be bad for many desktop workloads because the frequency is low.

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.

because most of us are not in the habit of swapping our processors between laptop and desktop.

Give us the power or give us the energy savings, this hybrid is both the best AND worst of both worlds.

Doing what ???. Very few folks have workloads that need so many cores.

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.

YMMV - I used to write apps with 60,000+ threads 10 years ago.

Reply on news.ycombinator.com