Hyperthreading *is* interesting, but the cost is high. As soon as you have out-of-order execution you've freed instruction decode from the execution units. And then you start looking for more ways to increase utilization of those units. Part of it comes from your program's instruction stream (the reason you went out of order in the first place), but there's only so much parallelism available in a single instruction stream. So you add another stream, calling it hyper-threading, and increase your core utilization, though you simultaneously decrease the performance of each individual thread. And when you add in the risks of side-band attacks and realize you can't rent the hyperthreads to different customers you wind up with many more risks than makes sense. Which brings designs back to simpler cores like we see with RISC-V. Quite the 30 year dip into complexity and back out.
On Wed, Feb 19, 2025, 2:59 p.m. <tlaro...@kergis.com> wrote: > On Wed, Feb 19, 2025 at 12:17:48PM -0800, ron minnich wrote: > > your summary of hyperthreading is basically right. In 2011, the K8/K10 we > > were using did not have hyperthreading. > > > > Most HPC sites, including LANL, where I worked, tended to turn > > hyperthreading off, as it was at best a mixed blessing. I note that many > > cloud providers have turned it off, for security reasons. > > > > There are HPC researchers out there planning to use hyperthreading, BUT: > > intel has announced that hyperthreading has no future in its chips: > > > https://www.pcworld.com/article/2480487/hyperthreading-is-dead-in-intels-new-core-ultra-pc-chips.html#:~:text=Yes%2C%20hyperthreading%20has%20been%20banned,the%20feature%20from%20Lunar%20Lake > > . > > > > I was never a fan, and we did not make allowance for hyperthreading in > NIX. > > Thanks for the explanations! We are back to what you wrote about the > network and distributed computing (in your paper about the Linux > implementation of the 9P > protocol), but on the micro-level this time: this hyperthreading seems > also like a patchwork > applied afterwards, mimicking in hardware what was done (with notorious > unfelicities) in > software. (And the huge x86 ISA is a memorial to all the dead-ends that > have > been attempted; one more grave in the cemetery). > > > > > > On Tue, Feb 18, 2025 at 4:15?AM <tlaro...@kergis.com> wrote: > > > > > My knowledge being limited in this area, I guess that when x86 > > > announces, say, 8 cores / 16 threads, the two threads by core are > > > handled using superscalar (possibly pipelining): instead of executing > > > in parallel multiple instructions of one program, they allow to execute > > > in parallel multiple instructions of two distinct programs? > > > > > > But there are differences between physical cores and logical ones > > > (hardware threads): the local APIC table is uniq to the physical core. > > > > > > This does mean that the NIX approach will handle physical cores, and > > > that a kernel allocated to some physical core will be perhaps able to > > > use (in this case) two logical cores (hardware threads)? > > > > > > -- > > > Thierry Laronde <tlaronde +AT+ kergis +dot+ com> > > > http://www.kergis.com/ > > > http://kertex.kergis.com/ > > > Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C > > -- > Thierry Laronde <tlaronde +AT+ kergis +dot+ com> > http://www.kergis.com/ > http://kertex.kergis.com/ > Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tc2b75db61025b254-M9c87a29f3859e80316e16d4d Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
