3 ms·

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.

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.