simultaneous multithreading

A wide superscalar core is like a kitchen with eight burners, but a single recipe rarely needs all eight at once — while one dish simmers (a cache miss), several burners sit idle. Instead of wasting them, you let a second cook work the spare burners on a different recipe at the same time. Simultaneous multithreading (SMT) is this: a single physical core runs instructions from two (or more) independent threads in the same cycle, filling the execution units that any one thread would leave empty.

It helps to see the family. Coarse-grained multithreading switches to another thread only on a big stall (like a cache miss), hiding long latencies. Fine-grained multithreading switches threads every cycle in round-robin, hiding shorter stalls. SMT goes further: it does not switch — it issues instructions from multiple threads in the very same cycle, drawing from each thread's ready instructions to pack the core's issue slots more fully. Mechanically, the core duplicates the per-thread architectural state (each thread has its own program counter and architectural registers, mapped through a shared, larger physical register file via renaming) but shares the expensive execution units, caches, and predictors. To software, one SMT core looks like two (or more) logical processors. Intel calls its version hyper-threading.

SMT raises throughput cheaply because it reuses existing hardware to soak up the idle slots and stall cycles that single-thread ILP cannot fill — often a 20–30% throughput gain for a small area cost. The honest caveats are real and several: the threads contend for shared caches and execution units, so per-thread performance can drop, and two threads on one core do not equal two real cores; gains are workload-dependent and sometimes negative. And because SMT siblings share microarchitectural resources (caches, predictors, ports), they have repeatedly been a channel for side-channel and speculative attacks across threads.