5.3.14 · D5 · HinglishAdvanced Microarchitecture
Question bank — Simultaneous multithreading (SMT - hyperthreading)
5.3.14 · D5· Hardware › Advanced Microarchitecture › Simultaneous multithreading (SMT - hyperthreading)
Yeh page un misconceptions aur boundary cases ko hunt karta hai jo Simultaneous Multithreading invite karta hai. Har item ek one-line reveal hai: prompt padho, apne dimaag mein answer karo, phir check karo. Har answer ek reason deta hai, kabhi bare yes/no nahi. Mechanics aur numbers ke liye Simultaneous multithreading (SMT - hyperthreading) pe wapas jao; Hinglish walkthrough ke liye 5.3.14 Simultaneous multithreading (SMT - hyperthreading) (Hinglish) dekho.
True or false — justify
True or false: SMT ek single thread ko faster chalata hai.
False — clock speed aur per-instruction latency improve nahi hoti; SMT throughput (tasks per second) badhata hai idle slots fill karke, aur single-thread latency aksar thodi worse ho jaati hai shared-resource contention ki wajah se.
True or false: 2-way SMT core mein execution units ki sankhya roughly double kar deta hai.
False — execution units (ALUs, FPUs, load/store ports) shared hote hain, duplicate nahi; sirf sasta per-thread state (PC, register file, flags) replicate hota hai (~5% die area).
True or false: Agar ek workload pehle se ek thread par 100% execution units use kar raha hai, toh SMT phir bhi bada speedup deta hai.
False — jab units saturated hain toh fill karne ke liye koi idle slot nahi hota, isliye doosra thread sirf compete karta hai; gain ~1.12× ke paas collapse ho jaata hai (do CPU-bound example dekho).
True or false: SMT aur coarse-grained time-slicing (context switch har kuch haazar cycles mein) ek hi idea hai.
False — time-slicing ek waqt mein ek hi thread chalata hai aur kabhi kabhi switch karta hai; SMT same cycle mein multiple threads se instructions issue karta hai, isliye ek thread ke idle units doosre thread se fill hote hain bina context switch ke.
True or false: SMT ke under do threads hamesha apne individual times ke sum mein khatam hote hain.
False — yeh sequential (no-SMT) cost hai; SMT ke under woh overlap karte hain aur roughly apne (thode stretched) times ke max mein khatam hote hain, isliye total work per unit time badhti hai.
True or false: SMT ek memory-stall ko stalled thread ke liye useful kaam mein badal sakta hai.
False — stalled thread abhi bhi memory ka wait karta hai; SMT doosre thread ko woh units use karne deta hai jo stalled thread ne idle chhode hain, isliye core busy rehta hai bhale hi stalled thread progress nahi karta.
True or false: Kyunki caches shared hain, doosra SMT thread add karne se pehle thread ki speed bhi kam ho sakti hai.
True — do threads finite cache capacity aur TLB entries ke liye compete karte hain, jisse dono ke liye zyada misses hote hain, aur isi wajah se speedup 2× se kaafi kam rehta hai.
True or false: SMT pipeline stalls khatam karta hai.
False — yeh stalls remove nahi karta; yeh unhe core level par hide karta hai, jab ek thread stalled hota hai toh doosre thread se ready instruction schedule karta hai.
True or false: Ek single-threaded program SMT-capable core par akele chalaya jaye toh normal superscalar core jaisa behave karta hai.
True — sirf ek active thread context hone par core ke saare shared resources uske paas hote hain, isliye koi contention nahi hoti aur performance non-SMT baseline se match karti hai.
Spot the error
Error dhundho: "2-way SMT mein har thread ko har cycle mein exactly aadhe execution units guaranteed milte hain."
Galat — scheduling fine-grained aur opportunistic hai, static 50/50 split nahi; ek stalled thread uss cycle mein 0% units use kar sakta hai jabki doosra 100% use karta hai.
Error dhundho: "SMT 2× throughput deta hai kyunki yeh single thread ke andar instruction-level parallelism double karta hai."
Do wajah se galat — SMT thread-level parallelism exploit karta hai (Thread-Level Parallelism (TLP)), ek thread ke andar extra ILP nahi, aur real gain ~1.2–1.4× hai shared-resource contention ki wajah se.
Error dhundho: "Kyunki branch predictors per-thread hote hain, threads prediction mein kabhi interfere nahi karte."
Galat — branch predictor shared hota hai, isliye do threads ek doosre ke history entries thrash kar sakte hain, jisse dono ke liye mispredictions badhti hain.
Error dhundho: "Agar 2 threads help karte hain, toh 8 SMT threads per core 4× zyada help karenge."
Galat — ~2–4 threads se zyada hone par shared caches thrash karte hain, state overhead badhta hai, aur returns diminish hote hain; isliye Intel 2-way par rukta hai aur IBM POWER ~4-way par.
Error dhundho: "SMT OS ko zyada logical CPUs deta hai, isliye yeh purely ek software feature hai."
Galat — SMT ek microarchitecture feature hai: hardware thread contexts replicate karta hai aur out-of-order scheduler har cycle mein select karta hai; OS jo extra logical CPUs dekhta hai woh ek consequence hai, mechanism nahi.
Error dhundho: "Do CPU-bound integer threads ideal SMT pairing hain."
Galat — yeh worst pairing hai kyunki dono same ALUs ke liye ladte hain; SMT complementary needs ke saath shine karta hai (jaise ek memory-bound, ek CPU-bound) taaki idle slots fill karne ke liye hon.
Error dhundho: "SMT total die area reduce karta hai kyunki ab extra execution units ki zaroorat nahi."
Galat — SMT existing units reuse karta hai lekin replicated per-thread state ke liye ~5% area add karta hai; yeh core ko shrink nahi karta, yeh wahan jo hai uski utilization badhata hai.
Why questions
SMT kyun almost koi benefit nahi deta un do threads ke liye jo dono ALUs saturate kar dete hain?
Kyunki fill karne ke liye koi idle execution slots nahi hote — units already fully busy hain, isliye doosra thread scheduler ko same capacity split karne par majboor karta hai, near-zero extra throughput milta hai.
SMT mein single-thread latency kabhi kabhi worse kyun hoti hai, bhale hi throughput badhti hai?
Shared caches, TLB, aur reorder-buffer slots ab threads ke beech split hote hain, isliye har thread zyada misses suffer karta hai aur effective out-of-order window chhoti ho jaati hai, jisse uski individual completion time stretch ho jaati hai.
SMT khaaskar ek memory-bound thread ke saath achha kyun kaam karta hai?
Memory-bound threads zyatar cycles cache-miss latency par stalled rehte hain, execution units idle chhod dete hain; ek CPU-bound partner exactly un idle cycles mein slot ho jaata hai, isliye core productive rehta hai.
Register file ko per thread replicate kyun karo lekin execution units share karo?
Register/PC state sasta hota hai (kuch KB) aur private hona zaroori hai taaki har thread apna architectural context rakhe; execution units mehnge aur aksar idle hote hain, isliye unhe share karna exactly wahi utilization win hai.
Amdahl-style modeling () SMT ke liye sirf approximation kyun hai?
Yeh assume karta hai ki memory-bound fraction exactly half-recover hota hai aur threads ke beech cache-thrashing feedback ignore karta hai; real speedup depend karta hai actual miss behavior par jo ek thread doosre par inflict karta hai.
SMT 2× kyun nahi pahunch sakta jab ek thread 70% waqt idle ho?
Active thread har ek freed slot hamesha fill nahi kar sakta (dependencies, limited ready instructions), aur do threads abhi bhi cache, TLB, aur reorder-buffer entries ke liye contend karte hain, jo gain ko 2× se neeche cap karta hai.
Edge cases
Edge case: Agar do thread contexts mein se ek idle ho (koi runnable thread nahi) toh SMT se kitna throughput gain expect karte ho?
~1× (baseline) — sirf ek active thread hone par uske idle slots fill karne ke liye kuch nahi hai, isliye core ek plain superscalar jaisa behave karta hai bina SMT benefit ke.
Edge case: Agar dono threads ke liye cache miss rate 0% tak pahunch jaye (perfectly cache-resident, dependency-heavy) toh SMT benefit ka kya hoga?
Benefit CPU-bound floor ki taraf shrink ho jaata hai — kam stalls matlab fill karne ke liye kam idle slots, aur dependency chains abhi bhi har thread ki issue rate limit karti hain.
Edge case: Do threads SMT ke under same shared memory location padh aur likh rahe hain — kaun sa subsystem abhi bhi correct hona chahiye?
Cache Coherence (aur memory-ordering model) abhi bhi unke writes ki visibility govern karta hai; ek physical core share karna unhe coherence rules se exempt nahi karta.
Edge case: Ek workload 100% memory-bound hai dono threads ke liye unbounded stall latency ke saath — kya SMT useful hai?
Marginally — agar dono threads almost hamesha stalled hain toh woh cycles bahut kam hain jab ek ready ho aur doosra stalled ho, isliye overlap opportunities scarce hain aur gain chhota hai.
Edge case: Tum ek teesra SMT thread add karte ho ek 2-way-designed core mein jisme sirf 4 execution units hain — likely outcome?
Zyada cache/TLB thrashing aur bada state overhead same shared units ke saath, isliye per-thread performance girta hai aur total throughput mein diminishing ya negative returns aate hain.
Edge case: Ek single-threaded latency-critical task (jaise real-time deadline) ek SMT core par ek batch job ke saath chal rahi hai — kya yeh advisable hai?
Aksar nahi — batch job shared cache aur units steal karta hai, jitter add karta hai aur critical task ki latency stretch karta hai; kai systems latency-critical kaam ko ek core par pin karte hain jahan SMT disabled ho ya sibling parked ho.
Recall Woh do facts jo almost har trap ka jawab dete hain
(1) SMT throughput badhata hai, clock speed nahi — core fuller chalta hai, faster nahi. (2) Threads expensive hardware share karte hain — isliye woh ek doosre ko slow kar sakte hain, aur yehi wajah hai ki gains ~1.2–1.4× hain aur kabhi clean 2× nahi hote.