5.1Ghz of wishful thinking

LittleBroIn the end, be it a compact core or non compact one, it IS same damn architecture, with same IPC, same L1 caches, L2 caches, same execution engine. Intel's/Qualcomm's e cores are totally different architecture and on top of that they are optimized for efficiency. Different architectures working jointly mean you require advanced scheduler, as that standard one that OS has is not good enough to handle cores with different IPCs. With AMD's approach you continue to rely on standard OS scheduler, as IPCs of c and non-c cores is same. Clocks are different but clocks don't matter when we're talking about IPC.

See difference now?

That the C cores are based in the same architecture doesn't mean you also don't need more clever scheduling with them because one still have less cache, notable lower frequencies and higher core to core latency access times on the C cores.

As an example if I remember well at Strix Point launch bad scheduling management of resources between normal Zen cores and Zen C cores was causing performance issues in some game related tasks.

Sigh.
Intel's fabs have never had any trouble achieving high clocks, the problem has been making a product that has performance and lifespan to match those clocks.
I wish Intel would stop chasing clockspeed as a marketing tool, and stop with the overall core count inflation, too. These are quad-core chips with backup dancers on stage. These Skymont/Darkmont cores could be decent if they weren't crippled by their cache config, but in reality they don't even match a Zen1 core from 8 years ago. They exist only to fuel short Cinebench runs at unsustainable TDPs.

LittleBroDifferent architectures working jointly mean you require advanced scheduler, as that standard one that OS has is not good enough to handle cores with different IPCs.

This is right and is all you need to understand on Windows.

The Windows scheduler really supports homogeneous cores only atm. Any heterogeneous scheduler needs support from both the OS and the apps. The apps need to be able to say "For this thread we want efficiency and these instructions extensions" and "For this thread we want performances and these instructions extensions" and "For this thread we want low power with these instructions extensions", and the OS must implement a quite evolved scheduler that optimizes the threads on the available cores to achieve the best performances.

As it is now, threads are started on more or less random cores, then depending on i/o and other wait states these threads are moved between efficient cores and performant cores, then if they try to use an instruction extension that is not available on that core an exception is raised and the OS "promotes" them to a more suitable core, just for a bit. This sampling logic updates occur once every 15-30ms, and each time a thread moves from core to core it's a mess of memory latency and cache/pipelines invalidations.

This is very inefficient and impractical, especially for short lived threads, and is the reason why heterogeneous cores look good on paper but do not perform well in reality. Until an infrastructure is added to the OS scheduler, and the apps start using it, all the complexity of these CPUs is as useful as a brick.

Squared"C is for cloud", quoted from this article:
www.hwcooling.net/en/big-little-by-amd-zen-4c-has-the-same-ipc-as-the-big-zen-4-architecture-analysis/


www.tomshardware.com/pc-components/cpus/exclusive-amd-to-begin-disclosing-zen-4c-clock-speeds-and-list-the-missing-core-counts-on-official-spec-pages

OK, let's wrap it up on this one. C cores are in fact smaller (densier), thus compact. But believe what you want.

RulumiThat the C cores are based in the same architecture doesn't mean you also don't need more clever scheduling with them because one still have less cache, notable lower frequencies and higher core to core latency access times on the C cores.

As an example if I remember well at Strix Point launch bad scheduling management of resources between normal Zen cores and Zen C cores was causing performance issues in some game related tasks.

And yet Strix Point scheduling issues were solved with OS and AGESA updates, no hardware scheduling (like Thread Director) was required. Strix Halo did not require even that.
I'm not saying there cannot be issues, I'm saying that because of different ISAs, a more delicate approach is required and that involves hardware layer between OS and CPU.

This is why c cores should not be called e-cores:



That last two rows (all cores are efficiend and can improve gaming) take with grain of salt.

I'm not aware of any OS that supports its apps telling it how efficiency to run, not Windows, MacOS, iOS, Android, nor Linux. Yet for years most phone and Apple processors have had big and little cores, and Intel joined the party years ago and AMD joined a couple years ago. Qualcomm's first Windows-first CPU (Snapdragon X) did not, but its successor coming next year does.

Little cores are as much about die area as they are about low power use. It's how Intel fit 24 cores into Raptor Lake on a monolithic die and 14 cores into Meteor Lake on a new node, and how AMD fit 12 cores and 16 CUs into Strix Point on a monolithic chip.

Choosing the right core to schedule a thread onto for lowest power use can be fairly simple. The processor chooses how much it will boost, and so the OS needs to put threads the processor will boost onto big cores and the rest onto little cores. Now I think budgeting power between the iGPU and CPU has always been a challenge. One thing Intel said with Panther Lake is that the little cores are going to be used for gaming more than Arrow Lake did, because boosting the CPU limits the iGPU clock speed, and usually games benefit more from higher iGPU clock speed.

SquaredChoosing the right core to schedule a thread onto for lowest power use can be fairly simple. The processor chooses how much it will boost, and so the OS needs to put threads the processor will boost onto big cores and the rest onto little cores. Now I think budgeting power between the iGPU and CPU has always been a challenge. One thing Intel said with Panther Lake is that the little cores are going to be used for gaming more than Arrow Lake did, because boosting the CPU limits the iGPU clock speed, and usually games benefit more from higher iGPU clock speed.

It's way more complex than you think. Not fairly simple. Clocks don't matter that much as architecture does.
Alder Lake e-cores could not handle same instructions. Even if they had same clocks as P-cores, there was a huge difference.
Instructions-wise, Intel promoted e-cores to P-cores. But IPC-wise, not. That's why a hardware scheduler is required to tell the OS ...

In other words: performance hit when a heavy workload is given to a e-cores instead of P-core on Intel CPU without Thread Director is much worse than when OS gives an AMD c core task instead of a standard core (because the IPC is same).

LittleBroIt's way more complex than you think. Not fairly simple. Clocks don't matter that much as architecture does.
Alder Lake e-cores could not handle same instructions. Even if they had same clocks as P-cores, there was a huge difference.
Instructions-wise, Intel promoted e-cores to P-cores. But IPC-wise, not. That's why a hardware scheduler is required to tell the OS ...

The first Alder Lake BIOS would allow AVX-512 to be enabled if and only if all of the E cores were disabled. But when P and E cores are both active they have always accepted the same instructions. Intel has always disabled all instructions that are not common among all the cores. No operating system can support cores with differing instruction sets.

LittleBroIn other words: performance hit when a heavy workload is given to a e-cores instead of P-core on Intel CPU without Thread Director is much worse than when OS gives an AMD c core task instead of a standard core (because the IPC is same).

It's not always true that IPC is the same between Zen 5 and Zen 5c. In Strix Point (e.g. Ryzen 370) the Zen 5c cores have 8 MB of L3 cache (1 MB / core) and the Zen 5 cores have 16 MB of L3 cache (4 MB / core), and more cache allows for more IPC. And the performance penalty for assigning a task to a little core that ought to be on a big core is much smaller today than when Alder Lake released. In Meteor Lake Crestmont improved when Redwood Cove did not, and again in Arrow Lake Skymont improved more than Lion Cove. I have not seen any benchmarks comparing Skymont in Arrow Lake to Zen 5c in Strix Point, so I don't know that Skymont is slower.

SquaredThe first Alder Lake BIOS would allow AVX-512 to be enabled if and only if all of the E cores were disabled. But when P and E cores are both active they have always accepted the same instructions. Intel has always disabled all instructions that are not common among all the cores. No operating system can support cores with differing instruction sets.

It's not always true that IPC is the same between Zen 5 and Zen 5c. In Strix Point (e.g. Ryzen 370) the Zen 5c cores have 8 MB of L3 cache (1 MB / core) and the Zen 5 cores have 16 MB of L3 cache (4 MB / core), and more cache allows for more IPC. And the performance penalty for assigning a task to a little core that ought to be on a big core is much smaller today than when Alder Lake released. In Meteor Lake Crestmont improved when Redwood Cove did not, and again in Arrow Lake Skymont improved more than Lion Cove. I have not seen any benchmarks comparing Skymont in Arrow Lake to Zen 5c in Strix Point, so I don't know that Skymont is slower.

L3 cache is beneficial when a particular workload (app) can utilize it. L1 cache is most crucial, as a CPU's front end heavily depends on it.
Larger L3 cache is beneficial when app is highly dependent on RAM. That's why AMD decided to sacrifice half of L3 cache in Zen-c chiplet for additional cores.
In servers you don't need so much L3 cache, as servers' performance depends mainly on L1 and L2 caches.
Having more cores (threads) instead of more L3 is way more beneficial for servers. For games and rendering it's the exact opposite.
You should really take a deep dive into how CPUs work. I wonder whether you're just trolling or ... I'm done with this bullshit anyway.

PS: IPC of Ryzen 5800X and 5800X3D is same, even though the latter has triple that much L3 memory. How come?