4 ms·

It sounds like it could be very useful for performance debugging. Using 50% of available CPU is very different when 50% and 50% than 100% and 0% of each availab

It sounds like it could be very useful for performance debugging. Using 50% of available CPU is very different when 50% and 50% than 100% and 0% of each available CPU. It could also be helpful for debugging performance with heterogeneous CPUs such as SMT, NUMA or performance/efficiency cores.

jeffbee 3y ago
SMTs are not heterogenous. It's right there in the name.
- kevincox 3y ago
  If you have 4 threads and 2 cores there is very likely going to be a noticeable difference between running both of your threads on the same physical core vs one thread on each of the two cores. (Of course it depends what is running on the other thread of each core). Sure, maybe heterogeneous isn't the right word, much like NUMA is often not heterogeneous. But these do make CPU placement matter.
  - jeffbee 3y ago
    There's a widespread mental model of SMT that is totally incorrect, that holds there is one "real" thread and another one that only gets to fill in the gaps with unused resources. In reality, there is no such bias.
    - kevincox 3y ago
      I haven't heard of that bias before. But even without that bias it still does affect performance how your threads are distributed across physical cores. This is why the kernel is aware of SMT threads and uses that knowledge to make the best scheduling decisions.
    - shitlord 3y ago
      If you have three threads running on two cores, will the thread on its own significantly outperform the others?
      - jeffbee 3y ago
        I don't understand the question. A hardware core, thread, context, or whatever term you prefer can only run one software thread at a given time. The operating system can interrupt the processor and switch to a different piece of software, but this only gives the illusion of two threads running concurrently when looked at over long time scales. If you have three software threads A, B, C and two CPUs X and Y, and thread A runs on CPU X from T0 to T2, thread B runs on Y from T0 to T1, and C runs on Y from T1 to T2, then thread A made more progress than the others, all else equal.
      - toast0 3y ago
        Maybe, maybe not. If all three threads are spending most of their time doing pointer chasing (dependent memory loads) then not really: each core has bandwidth to do more than one memory load at a time, so there's not resource contention and each SMT can make progress in turn on the shared core. If all three threads are well pipelined math heavy computation, then yes, the core running two threads has to split its adders among the two threads and the core running a single thread doesn't. If it's a mix of workloads, sometimes you get lucky and the two threads don't contend much and you get a nice throughput increase, and sometimes you get unlucky and they do contend but throughput is about the same. If you get really unlucky, the two threads running causes the working set (memory or instructions) to grow beyond the cache and you get a reduction in throughput. But it really depends on your workloads.
        rbanffy 3y ago
        OTOH, if the two threads on the first core end up priming each other's instruction and data caches, the might as well speed up both tasks, because each will see only a subset of what would be their cache misses, where the one running alone will encounter all its cache misses because no other task primed the caches for them.

jeffbee 3y ago

SMTs are not heterogenous. It's right there in the name.

kevincox 3y ago
If you have 4 threads and 2 cores there is very likely going to be a noticeable difference between running both of your threads on the same physical core vs one thread on each of the two cores. (Of course it depends what is running on the other thread of each core). Sure, maybe heterogeneous isn't the right word, much like NUMA is often not heterogeneous. But these do make CPU placement matter.
- jeffbee 3y ago
  There's a widespread mental model of SMT that is totally incorrect, that holds there is one "real" thread and another one that only gets to fill in the gaps with unused resources. In reality, there is no such bias.
  - kevincox 3y ago
    I haven't heard of that bias before. But even without that bias it still does affect performance how your threads are distributed across physical cores. This is why the kernel is aware of SMT threads and uses that knowledge to make the best scheduling decisions.
  - shitlord 3y ago
    If you have three threads running on two cores, will the thread on its own significantly outperform the others?
    - jeffbee 3y ago
      I don't understand the question. A hardware core, thread, context, or whatever term you prefer can only run one software thread at a given time. The operating system can interrupt the processor and switch to a different piece of software, but this only gives the illusion of two threads running concurrently when looked at over long time scales. If you have three software threads A, B, C and two CPUs X and Y, and thread A runs on CPU X from T0 to T2, thread B runs on Y from T0 to T1, and C runs on Y from T1 to T2, then thread A made more progress than the others, all else equal.
    - toast0 3y ago
      Maybe, maybe not. If all three threads are spending most of their time doing pointer chasing (dependent memory loads) then not really: each core has bandwidth to do more than one memory load at a time, so there's not resource contention and each SMT can make progress in turn on the shared core. If all three threads are well pipelined math heavy computation, then yes, the core running two threads has to split its adders among the two threads and the core running a single thread doesn't. If it's a mix of workloads, sometimes you get lucky and the two threads don't contend much and you get a nice throughput increase, and sometimes you get unlucky and they do contend but throughput is about the same. If you get really unlucky, the two threads running causes the working set (memory or instructions) to grow beyond the cache and you get a reduction in throughput. But it really depends on your workloads.
      - rbanffy 3y ago
        OTOH, if the two threads on the first core end up priming each other's instruction and data caches, the might as well speed up both tasks, because each will see only a subset of what would be their cache misses, where the one running alone will encounter all its cache misses because no other task primed the caches for them.