The OS doesn't decide how many threads the application spawns. Is there a hybrid system you're aware of where the OS will refuse to schedule N threads across N cores due to the cores not all being the same type?

The only such example I'm aware of is Intel's recently-launched Meteor Lake laptop chips that include an extra two low-power E cores on a separate chiplet from the rest of the CPU cores, running at half the performance of the regular E cores and with no L3 cache, so whether they're used or not only makes a few percent difference to embarrassingly parallel workloads.

I didn’t say that the OS refuses to utilize cores. But I’ve seen examples of embarrassingly parallel tasks that utilize 80% of the cpu to run faster on CPUs with only performance cores when compares to hybrids with the same number of threads. There might be some other reason for that, but my gut feeling is to stick with all performance designs.

> I’ve seen examples of embarrassingly parallel tasks that utilize 80% of the cpu to run faster on CPUs with only performance cores when compares to hybrids with the same number of threads

The "same number of threads" bit is throwing me off. A hybrid config will generally have more CPU cores allowing it to handle more threads for a chip of the same size, so testing with a fixed thread count can only tell you that the performance of each small core is less than the performance of a large core. But maybe the examples you have in mind are complicated by SMT/HyperThreading (which Intel has on P cores but not E cores, while AMD has it on both)?

I only mention threads because it's the only way to draw comparisons between dissimilar cpus.

You already specified that we're discussing embarrassingly parallel tasks, so putting a constraint on thread count is of no use here. We can compare on the basis of performance, power and die size.

The smaller cores are not really much different from having other applications / kernel / device drivers running concurrently with your workload.

Bad design: see N cores, split work into N partitions, start N threads, each thread processes one partition.

Good design: see N cores, start ~N threads, each thread takes 1/M of work at a time, M>>N.