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
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 bles
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
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 instruc
