5.3.14 · D5Advanced Microarchitecture
Question bank — Simultaneous multithreading (SMT - hyperthreading)
This page hunts the misconceptions and boundary cases that Simultaneous Multithreading invites. Each item is a one-line reveal: read the prompt, answer in your head, then check. Every answer gives a reason, never a bare yes/no. For the mechanics and numbers, go back to Simultaneous multithreading (SMT - hyperthreading); for the Hinglish walkthrough see 5.3.14 Simultaneous multithreading (SMT - hyperthreading) (Hinglish).
True or false — justify
True or false: SMT makes a single thread run faster.
False — the clock speed and per-instruction latency don't improve; SMT raises throughput (tasks finished per second) by filling idle slots, and single-thread latency often gets slightly worse due to shared-resource contention.
True or false: 2-way SMT roughly doubles the number of execution units in the core.
False — execution units (ALUs, FPUs, load/store ports) are shared, not duplicated; only the cheap per-thread state (PC, register file, flags) is replicated (~5% die area).
True or false: If a workload already uses 100% of the execution units on one thread, SMT still gives a big speedup.
False — with the units saturated there are no idle slots to fill, so a second thread just competes; gain collapses toward 1× (see the two-CPU-bound example, ~1.12×).
True or false: SMT and coarse-grained time-slicing (context switch every few thousand cycles) are the same idea.
False — time-slicing runs one thread at a time and switches occasionally; SMT issues instructions from multiple threads in the same cycle, so idle units in one thread are filled by another without a context switch.
True or false: Two threads under SMT always finish in the sum of their individual times.
False — that's the sequential (no-SMT) cost; under SMT they overlap and finish in roughly the max of their (slightly stretched) times, which is why total work per unit time rises.
True or false: SMT can turn a memory-stall into useful work for the stalled thread.
False — the stalled thread still waits on memory; SMT lets the other thread use the units the stalled thread left idle, so the core stays busy even though the stalled thread doesn't progress.
True or false: Because caches are shared, adding a second SMT thread can make the first thread slower.
True — two threads compete for finite cache capacity and TLB entries, causing more misses for each, which is exactly why the speedup is well under 2×.
True or false: SMT eliminates pipeline stalls.
False — it doesn't remove stalls; it hides them at the core level by scheduling a ready instruction from another thread while one thread is stalled.
True or false: A single-threaded program run alone on an SMT-capable core behaves like a normal superscalar core.
True — with only one active thread context, the whole core's shared resources belong to it, so there's no contention and performance matches the non-SMT baseline.
Spot the error
Find the error: "In 2-way SMT each thread is guaranteed exactly half the execution units every cycle."
Wrong — scheduling is fine-grained and opportunistic, not a static 50/50 split; a stalled thread may use 0% of the units while the other uses 100% that cycle.
Find the error: "SMT gives 2× throughput because it doubles instruction-level parallelism within a single thread."
Wrong on two counts — SMT exploits thread-level parallelism (Thread-Level Parallelism (TLP)), not extra ILP inside one thread, and real gain is ~1.2–1.4× because of shared-resource contention.
Find the error: "Since branch predictors are per-thread, threads never interfere in prediction."
Wrong — the branch predictor is shared, so two threads can thrash each other's history entries, raising mispredictions for both.
Find the error: "If 2 threads help, 8 SMT threads per core will help 4× more."
Wrong — beyond ~2–4 threads the shared caches thrash, state overhead grows, and returns diminish; this is why Intel stops at 2-way and IBM POWER at ~4-way.
Find the error: "SMT works by giving the OS more logical CPUs, so it's purely a software feature."
Wrong — SMT is a microarchitecture feature: the hardware replicates thread contexts and the out-of-order scheduler selects per cycle; the extra logical CPUs the OS sees are a consequence, not the mechanism.
Find the error: "Two CPU-bound integer threads are the ideal SMT pairing."
Wrong — that's the worst pairing since both fight for the same ALUs; SMT shines with complementary needs (e.g. one memory-bound, one CPU-bound) so idle slots exist to fill.
Find the error: "SMT reduces total die area because you no longer need extra execution units."
Wrong — SMT reuses existing units but adds ~5% area for replicated per-thread state; it doesn't shrink the core, it raises utilization of what's there.
Why questions
Why does SMT give almost no benefit for two threads that both saturate the ALUs?
Because there are no idle execution slots to fill — the units are already fully busy, so a second thread only forces the scheduler to split the same capacity, yielding near-zero extra throughput.
Why is single-thread latency sometimes worse under SMT even though throughput rises?
Shared caches, TLB, and reorder-buffer slots are now split between threads, so each thread suffers more misses and a smaller effective out-of-order window, stretching its individual completion time.
Why does SMT pair especially well with a memory-bound thread?
Memory-bound threads spend most cycles stalled on cache-miss latency, leaving execution units idle; a CPU-bound partner slots into exactly those idle cycles, so the core stays productive.
Why replicate the register file per thread but share the execution units?
Register/PC state is cheap (a few KB) and must be private so each thread keeps its own architectural context; execution units are expensive and often idle, so sharing them is precisely where the utilization win comes from.
Why is Amdahl-style modeling () only an approximation for SMT?
It assumes the memory-bound fraction is exactly half-recovered and ignores cache-thrashing feedback between threads; real speedup depends on the actual miss behavior each thread inflicts on the other.
Why can't SMT reach 2× even when one thread is idle 70% of the time?
The active thread cannot always fill every freed slot (dependencies, limited ready instructions), and the two threads still contend for cache, TLB, and reorder-buffer entries, capping the gain below 2×.
Edge cases
Edge case: What throughput gain do you expect from SMT if one of the two thread contexts is idle (no runnable thread)?
~1× (baseline) — with only one active thread there's nothing to fill its idle slots, so the core behaves like a plain superscalar with no SMT benefit.
Edge case: What happens to SMT benefit as cache miss rate approaches 0% for both threads (perfectly cache-resident, dependency-heavy)?
The benefit shrinks toward the CPU-bound floor — few stalls means few idle slots to steal, and dependency chains still limit each thread's issue rate.
Edge case: Two threads read and write the same shared memory location under SMT — what subsystem must still be correct?
Cache Coherence (and the memory-ordering model) still governs visibility of their writes; sharing a physical core does not exempt them from coherence rules.
Edge case: A workload is 100% memory-bound with unbounded stall latency for both threads — is SMT useful?
Marginally — if both threads are almost always stalled there are few cycles where one is ready while the other stalls, so overlap opportunities are scarce and gain is small.
Edge case: You add a third SMT thread to a 2-way-designed core with only 4 execution units — likely outcome?
More cache/TLB thrashing and larger state overhead with the same shared units, so per-thread performance drops and total throughput sees diminishing or negative returns.
Edge case: A single-threaded latency-critical task (e.g. real-time deadline) runs on an SMT core alongside a batch job — advisable?
Often no — the batch job steals shared cache and units, adding jitter and stretching the critical task's latency; many systems pin latency-critical work to a core with SMT disabled or the sibling parked.
Recall The two facts that answer almost every trap
(1) SMT raises throughput, not clock speed — the core runs fuller, not faster. (2) Threads share the expensive hardware — so they can slow each other down, which is why gains are ~1.2–1.4× and never a clean 2×.