3 ms·

As your workload grows in thread count, processors become limited by memory bandwidth per socket, as well as power and thermal constraints. The 'big' cores can

As your workload grows in thread count, processors become limited by memory bandwidth per socket, as well as power and thermal constraints. The 'big' cores can only perform at their peak frequency, power draw and IPC when not in a high multicore workload. So you end up wasting silicon resources, power in an all-big core design. Instead if you make the last several cores to be turned on smaller and optimized for a lower power state, you can fit more of them in, and achieve higher overall thread throughput for a given die size or power/thermal envelope. So imagine you set a given budget for silicon die size and chip power. You might then have 3 design possibilities. Say 8 big cores, 16 little or 12 in hybrid. The hybrid design should be able to match the all-big in single/lightly threaded loads, while beating the all-big in highly multithreaded. These tradeoffs of course work best in form-factors that are constrained by cost or battery power. Which is where you see amd using them in consumer. Or by space/power where you see AMD giving choice of small/dense core options in Epyc.

binkHN 3y ago
Do you have a URL or something that reviews this in greater detail? Perhaps in a laptop scenario?
elorant 3y ago
And what happens if you run something that's embarrassingly parallel and you need all the juice you can get from your cores. With hybrids you have to rely on the OS to decide when it will utilize everything and when not which in some heavy loads could cost you performance wise.
- wtallis 3y ago
  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.
  - elorant 3y ago
    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.
    - wtallis 3y ago
      > 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)?
      - elorant 3y ago
        I only mention threads because it's the only way to draw comparisons between dissimilar cpus.
        wtallis 3y ago
        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.
- yencabulator 3y ago
  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.
dtx1 3y ago
> The 'big' cores can only perform at their peak frequency, power draw and IPC when not in a high multicore workload. This is really not true. With a decent motherboard and sufficient cooling, you can force the big cores to stay virtually locked at peak clock speeds. Der8auer does it for a Ryzen 8000 APU here just as an example: https://youtu.be/VNYx72Elgss?t=335 https://youtu.be/VNYx72Elgss?t=335
- wtallis 3y ago
  Putting a laptop chip into a desktop platform and giving it water cooling and unlimited power delivery isn't a particularly strong counterexample. That's nowhere near the operating point the silicon was designed for, and the fact that AMD shipped a few SKUs that enable such usage as an afterthought doesn't disprove much.

binkHN 3y ago

Do you have a URL or something that reviews this in greater detail? Perhaps in a laptop scenario?

elorant 3y ago

And what happens if you run something that's embarrassingly parallel and you need all the juice you can get from your cores. With hybrids you have to rely on the OS to decide when it will utilize everything and when not which in some heavy loads could cost you performance wise.

wtallis 3y ago
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.
- elorant 3y ago
  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.
  - wtallis 3y ago
    > 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)?
    - elorant 3y ago
      I only mention threads because it's the only way to draw comparisons between dissimilar cpus.
      - wtallis 3y ago
        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.
yencabulator 3y ago
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.

dtx1 3y ago

> The 'big' cores can only perform at their peak frequency, power draw and IPC when not in a high multicore workload. This is really not true. With a decent motherboard and sufficient cooling, you can force the big cores to stay virtually locked at peak clock speeds. Der8auer does it for a Ryzen 8000 APU here just as an example: https://youtu.be/VNYx72Elgss?t=335 https://youtu.be/VNYx72Elgss?t=335

wtallis 3y ago
Putting a laptop chip into a desktop platform and giving it water cooling and unlimited power delivery isn't a particularly strong counterexample. That's nowhere near the operating point the silicon was designed for, and the fact that AMD shipped a few SKUs that enable such usage as an afterthought doesn't disprove much.