AFAIK this further complicates the IPC metric. What looks like a stalled core might actually be working on another thread. And at the other extreme, two very high IPC threads on one core would lower the observed IPC of each thread.
Turn off hyper-threading and boom, everything started to function normally.
The solution to not having enough food for one mouth often isn't to add another mouth.
I still see this in modern benchmarks on modern systems where multicore throughput on many benchmarks is just better when you just turn off SMT.
AMD's 3D chips go faster because of the huge cache. Every time we add another process to a core we just split the cache in half instead.
Clearly, this is workload dependent. But I immediately turn off SMT on new systems I get. I'm not core limited, I'm usually single thread limited. Like, always. No reason to keep SMT on for this case.
As things are, there is very little guarantee that the hyperthread will make any substantial progress.
We might see it again now that the server world is having an ARM CPU renaissance. But I doubt AMD or Intel will make anything that exotic.
Generation after generation, hyperthreads on almost every generation of Intel core have turned in mediocre to terrible benchmarks. Neither thread makes full progress , and on some versions you would see more IPC with them turned off.
AMD might have managed better, though I see benchmarks where theirs is also a wash. It doesn’t mean Arm or RISC-V will see any benefit.
But that's entirely beside the point and I'm not sure why you try to derail the conversation into different direciton.
SMT often does boost database heavy "cloud" workloads, but not client workloads like media processing, games, work apps and so on.
We have it on desktops/laptops because they use hand-me-down server cores. Its not worth redesigning the cores to bifurcate the architecture.
[1] outside of large SIMD FPUs, which indeed bulldozer tried to share with not great results.