▲ | loeg 6 days ago | |||||||||||||
HT provides a significant benefit to many workloads. The use cases that benefit from actually disabling HT are likely working around pessimal OS scheduler or application thread use. (After all, even with it enabled, you're free to not use the sibling cores.) Otherwise, it is an overgeneralization to say that disabling it will benefit arbitrary workloads. | ||||||||||||||
▲ | hedora 6 days ago | parent | next [-] | |||||||||||||
There’s some argument that you should jam stuff on to as few hyperthread pairs as possible to improve energy efficiency and cache locality. Of course, if the CPU governor is set to “performance” or “game mode”, then the OS should use as many pairs as possible instead (unless thermal throttling matters; computers are hard). | ||||||||||||||
▲ | mkbosmans 6 days ago | parent | prev | next [-] | |||||||||||||
Especially in HPC there are lots of workloads that do not benefit from SMT. Such workloads are almost always bottlenecked on either memory bandwidth or vector execution ports. These are exactly the resources that are shared between the sibling threads. So now you have a choice of either disabling SMT in the bios, or make sure the application correctly interprets the CPU topology and only spawns one thread per physical core. The former is often the easier option, both from software development and system administration perspective. | ||||||||||||||
| ||||||||||||||
▲ | robocat 6 days ago | parent | prev [-] | |||||||||||||
> use cases that benefit from actually disabling HT Other benefits: per-CPU software licencing sometimes, and security on servers that share CPU with multiple clients. |