3 ms·
Well! That's actually an effective defense against most if not all of the Spectre-family attacks, right?
by yjftsjthsd-h 3y ago
Well! That's actually an effective defense against most if not all of the Spectre-family attacks, right?
- anotherhue 3y agoSure, 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.
- eigenform 3y agoProbably makes verification easier because you don't have to worry about the case of "sharing resources between hardware threads" - instead you can focus on worrying about the only-slightly-less-complicated "sharing resources between privilege domains on a single hardware thread". edit: Instead running two hardware threads interleaved and sharing the resources on a single core, the implication is that you're turning it into a problem of scheduling work on separate cores with some provably separate resources. That probably makes it easier to have certain guarantees, and leaves you more time to worry about resources that you really do need to share but cannot afford to duplicate/distribute across the machine. Sometimes you really want two threads to share memory!