3 ms·
Sure, though most workloads will take a hit from this. Probably the right move but painful regardless.
by anotherhue 3y ago
Sure, though most workloads will take a hit from this. Probably the right move but painful regardless.
- brucethemoose2 3y agoTBH a lot of consumer stuff doesn't really benefit from hyperthreading. And thats if the scheduling is working perfectly. You mostly want it for, say, low IPC server database workloads where the cores are largely just sitting there, twiddling their thumbs waiting for something from DRAM, where the very fancy branch predictors and cache hierarchies we have now can't help much.
- anotherhue 3y agoI read a paper recently that basically said 'about a dozen threads' is optimal for most workloads. If they can deliver 12 'real' threads then the hyperthreads are redundant. Also, last time I checked (late penryn) the branch prediction and other elements necessary for good HT take up egregious amounts of die space -- which can probably be put to better use.
- brucethemoose2 3y agoYeah that is the other big thing, what is the opportunity cost of HT? In the past Intel has claimed its not very much area, but (as you said) I am not so sure.
- yjftsjthsd-h 3y agoSurely it would be a question of how parallel the workload is? I was under the impression that hyperthreading actually reduced performance per core, it just gives you sort of twice as many cores to work with.
- anotherhue 3y agoRelatively few workloads live in tight-loops, they tend to jump around (busting the pipeline and idling for relative eons). Those that do (and are important) tend to get run on HPC clusters. Media encoding is a good example but even that is being HW offloaded these days. Look up some of the Jim Keller interviews on YouTube if you're interested in learning more.