3 ms·

> hyperthreading does not really work so well on sustained, homogenuous workloads what would distinguish this description from, say, compression and compiling?

> hyperthreading does not really work so well on sustained, homogenuous workloads what would distinguish this description from, say, compression and compiling? based on the experience on my machine (which of course is limited), HT does give a boost in those two cases, which could be classified as homogeneous and sustained.

dragontamer 8y ago
Compiling isn't homogeneous IMO. Lots of branches, lots of waiting of RAM, lots of corner cases. Lots of ways to get those hyperthreads working in parallel. Compression would be closer to homogeneous. But something REALLY homogeneous is like, Prime95. You're only hitting SSE and/or AVX instructions over-and-over again. All threads try to only use AVX instructions, so hyperthreading doesn't help too much.
- berti 8y ago
  HT also doesn't help as much on FP workloads simply because there are less FP execution units to share, e.g. Skylake: https://en.wikichip.org/wiki/intel/microarchitectures/skylake_(client)#Individual_Core https://en.wikichip.org/wiki/intel/microarchitectures/skylak...
nordsieck 8y ago
>> hyperthreading does not really work so well on sustained, homogenuous workloads > what would distinguish this description from, say, compression and compiling? The real difference is between integer and floating point workloads. Integer workloads typically have lots of branch mis-predicts and cache misses which cause pipeline stalls. Any time you've got pipeline stalls, hyper-threading will be great. Floating Point workloads typically are just huge amounts of number crunching with very simple access patterns. There are few branches and memory accesses typically have a consistent stride and so are pre-fetch friendly. Typically, this kind of workload is memory bandwidth limited because your CPU can run full bore without any bubbles in the pipeline. Hyper-threading isn't much use in this case: if any functional units are going unused, it's only because the CPU can't vacuum data up fast enough. This is one of the big reasons GPUs are so popular for doing FP workloads: they have a ton of functional units and they are paired with very high speed on-board memory. In the grandparent's defense, floating point workloads tend to be sustained and homogenous. They are, however, not the only kind of sustained, homogenous workloads, as you so accurately point out.

dragontamer 8y ago

Compiling isn't homogeneous IMO. Lots of branches, lots of waiting of RAM, lots of corner cases. Lots of ways to get those hyperthreads working in parallel. Compression would be closer to homogeneous. But something REALLY homogeneous is like, Prime95. You're only hitting SSE and/or AVX instructions over-and-over again. All threads try to only use AVX instructions, so hyperthreading doesn't help too much.

berti 8y ago
HT also doesn't help as much on FP workloads simply because there are less FP execution units to share, e.g. Skylake: https://en.wikichip.org/wiki/intel/microarchitectures/skylake_(client)#Individual_Core https://en.wikichip.org/wiki/intel/microarchitectures/skylak...

nordsieck 8y ago

>> hyperthreading does not really work so well on sustained, homogenuous workloads > what would distinguish this description from, say, compression and compiling? The real difference is between integer and floating point workloads. Integer workloads typically have lots of branch mis-predicts and cache misses which cause pipeline stalls. Any time you've got pipeline stalls, hyper-threading will be great. Floating Point workloads typically are just huge amounts of number crunching with very simple access patterns. There are few branches and memory accesses typically have a consistent stride and so are pre-fetch friendly. Typically, this kind of workload is memory bandwidth limited because your CPU can run full bore without any bubbles in the pipeline. Hyper-threading isn't much use in this case: if any functional units are going unused, it's only because the CPU can't vacuum data up fast enough. This is one of the big reasons GPUs are so popular for doing FP workloads: they have a ton of functional units and they are paired with very high speed on-board memory. In the grandparent's defense, floating point workloads tend to be sustained and homogenous. They are, however, not the only kind of sustained, homogenous workloads, as you so accurately point out.