Or if you use a single queue... which I would expect to be the default.

Blindly dividing work units across cores sounds like a terrible strategy for a general program that's sharing those cores with who-knows-what.

> run multithreaded algorithms that are aware of the different performance and split the work unevenly to compensate.

This is what the Intel Thread Director [0] solves.

For high-intensity workloads, it will prioritize assigning them to P-cores.

[0] https://www.intel.com/content/www/us/en/support/articles/000...

The P cores being presented as two logical cores and E cores presented as a single logical core results in this kind of split already.

It’s kind of funny and reminiscent of the AMD bulldozer days where they had a ton of cores compared to the contemporary Intel chips, especially at low/mid price points but the AMD chips were laughably underwhelming for single core performance which was even more important then.

I can’t speak to the Intel chips because I’ve been out of the Intel game for a long time but my 5700X3D does seem to happily run all cores at max clock speed.

> I'm not sure what we're comparing them to. They should be capable of higher clock than the E cores.

Oh, just higher clocked than the E cores. Yeah that's true, but if you're using that many cores at once you probably only care about total speed.

You said 12 core with higher clock versus 8, so I thought you were comparing to the performance cores.

> I thought all the AMD cores had the ability to hit the max frequency (but not necessarily at the same time).

The cores under the 3D cache have a notable clock penalty on existing CPUs.

> And some of the cores might not be able to take advantage of the 3D cache, but that doesn't limit their frequency, from my understanding.

Right, but my point is it's misleading to call out higher core count and the advantages of 3D stacking. The 3D stacking mostly benefits the cores it's on top of, which is 6-8 of them on existing CPUs.