Instruction-level vs thread-level parallelism: Question bank

6.1.2 · D5 · Hardware › Parallelism & Multicore › Instruction-level vs thread-level parallelism

Yeh page Instruction-level vs thread-level parallelism ke liye conceptual traps ka ek set hai. Yahan koi number-crunching nahi hai — har item ek misconception, ek definition boundary, ya ek edge case ko target karta hai. Har answer real reasoning hai, sirf haan/nahi nahi.

Shuru karne se pehle, teen plain-word anchors lock kar lete hain taaki neeche kuch bhi ambiguous na rahe.

Figure — Instruction-level vs thread-level parallelism

Is page ke har item ke peeche ek hi formula

Neeche har trap Amdahl's Law quote karta hai, toh chalte hain isse ek baar plain words mein build karte hain, koi bhi symbol use karne se pehle.

Definition Is page par use hone wale har symbol ki ek baar definition

Ek kaam lo aur uske saare kaam ko total work ke fraction ke hisaab se do buckets mein baanto:

parallel fraction = kaam ka woh hissa jo parallel mein chal sakta hai. Hum ise $p$ likhte hain jab hum poore threads ek problem split karne ki baat karte hain (TLP), aur $f$ jab hum ek stream ke andar independent instructions ki baat karte hain (ILP). Same idea, do naam intentionally — number ek alag source se aata hai (algorithm split vs instruction independence), isliye hum letters alag rakhte hain taaki yaad rahe hum kis duniya mein hain.
serial fraction = bacha hua $1 - p$ (ya $1 - f$ ) jo step-by-step chalna hi padega. Yeh un-speedable bucket hai.
== $N$ == = cores/threads ki sankhya jo hum parallel part par lagaate hain (TLP).
== $n$ == = average instructions finished per cycle, yani kitni independent instructions overlap hoti hain (ILP). Ise IPC (instructions per cycle) bhi kehte hain.

Ab, $p$ , $f$ , $N$ , $n$ , aur IPC sab define ho gaye hain aur formula table par hai, neeche ke traps fair game hain.

True ya false — justify karo

Har answer kyun explain karta hai, sirf verdict nahi.

8 floats ka ek SIMD add, 8 instructions worth of ILP count hota hai.

False. SIMD pipeline mein ek instruction hoti hai jo kaafi saare data elements carry karti hai, toh yeh DLP mein contribute karta hai, ILP mein nahi — pipeline ise phir bhi ek single op ke roop mein issue karti hai.

Superscalar issue width ko double karne se real-world ILP speedup hamesha double ho jaati hai.

False. Dependency chains — Amdahl's Law mein serial fraction

(1 - f)

— ILP ko cap karti hain; jab wide-issue slots results ka wait karke idle baithti hain, tab extra width kuch nahi kharidti.

TLP aur ILP mutually exclusive hain — chip ek choose karta hai.

False. Ye stack hote hain: har core internally ILP exploit karta hai aur kaafi saare cores threads parallel mein chalate hain, toh total speedup roughly dono ka product hota hai.

"Embarrassingly parallel" workload woh hota hai jo parallelize karna embarrassingly mushkil ho.

False. Iska matlab bilkul ulta hai — kaam fully independent pieces mein split ho jaata hai almost koi communication nahi hoti, isliye TLP nearly linearly scale karta hai.

Out-of-order execution program ka final result badal deta hai.

False. Hardware sirf un instructions ko reorder karta hai jo independent hain aur results program order mein commit karta hai, isliye observable outcome sequential execution jaisi hi hoti hai.

Zyada cores add karna ek bade sequential fraction wale program ki utni hi madad karta hai jitni ek highly parallel wale ki.

False. Amdahl's Law kehta hai serial fraction

(1 - p)

hard ceiling ban jaata hai; ek bada serial fraction extra cores ke liye speed up karne ke liye bahut kam chodta hai.

Pipelining ILP ka ek form hai, bhaale hi woh sirf ek instruction per cycle issue kare.

True. Pipelining ek saath flight mein consecutive instructions ke stages ko overlap karta hai, jo instruction-level overlap hai bhaale issue width ek hi ho.

Ek single-core CPU phir bhi thread-level parallelism exploit kar sakta hai.

True. Hardware multithreading / SMT ke zariye ek core stalls hide karne ke liye threads interleave karta hai — yeh multiple cores ke bina TLP hai, haalaanki throughput limited hai.

Linked-list traversal mainly arithmetic unit se limited hoti hai, memory se nahi.

False. Yeh pointer chasing se limited hoti hai — har next load finish hona chahiye pehle ki agle load ka pata bhi chale, yeh ek memory/dependency chain hai, compute nahi.

Error dhundo

Har item mein ek galat statement hai; reveal usse naam deta hai aur fix karta hai.

"Humne AVX vectors use kiye, toh hamara thread-level parallelism improve hua."

Error mislabeling hai: AVX vectors SIMD / DLP hain, TLP nahi. Vectorizing karne se instruction per data zyada ho jaata hai lekin independent threads nahi bante.

"Loop inherently serial hai, toh chalte hain ise wider superscalar issue ke roop mein rewrite karte hain fix karne ke liye."

Tum dependency chain ko wider issue se fix nahi kar sakte — superscalar sirf independent instructions ke saath help karta hai. Fix algorithmic hai: chain todo (jaise, multiple accumulators) ya data restructure karo.

"IPC of 4 ka matlab CPU hamesha har cycle mein 4 instructions finish karta hai."

Error peak issue width (design maximum

n = 4

) aur sustained IPC (long-run average) ko confuse karta hai. Real average IPC bahut kam hoti hai kyunki hazards, cache misses, aur dependencies issue slots zyada cycles mein khali chodti hain — figure s02 ke right panel mein lane picture dekho.

"Kyunki matrix multiply perfectly parallelize hoti hai, Amdahl's Law apply nahi hota."

Amdahl's Law hamesha apply hota hai; yeh sirf ek favorable answer deta hai jab

p \approx 1

. Setup, memory allocation, aur final reduction serial fraction

(1 - p) > 0

rakhti hain.

"Ek SMT core par do threads ek thread se do guna fast chalte hain."

Ve ek core ke execution units share karte hain, isliye combined throughput gains typically sirf 10–30% hote hain,

2 \times

nahi. SMT latency hide karta hai, hardware duplicate nahi karta.

"Hamare code mein koi data hazards nahi hain, toh out-of-order execution bekar hai."

Data hazards na hone par bhi, out-of-order execution phir bhi baad ka independent kaam dhundhke memory latency aur control stalls hide karta hai — iska value sirf data hazards ke baare mein nahi hai.

"Sirf 3 of 8 lanes active ke saath ek masked SIMD add, useful work ka ek-aathwaan karta hai lekin phir bhi ek full vector instruction cost karta hai."

Yeh correct hai, koi error nahi — inactive lanes ("masked off") phir bhi instruction ke cycle occupy karti hain, isliye partial vectors DLP throughput waste karte hain; yeh woh vector-length edge case hai jo figure s01 mein dikhaya gaya hai.

"Humne linked list ko 8 threads mein split kiya, toh hume near-8× speedup milega."

Linked list split karne ke liye boundaries dhundhne ke liye traversal chahiye aur threads ke beech cache thrashing hota hai; results combine karne mein overhead aata hai, isliye real speedup chhoti aur 8× se bahut kam hoti hai.

Why questions

Mechanisms ke peeche deeper "why" reasoning.

Real code mein ILP sirf 2–6 IPC par kyun saturate hoti hai?

Kyunki real programs dependent instructions aur branches ki chains hain; ek baar jab kuch nearby independent instructions issue ho jaati hain, hardware ke paas ready work khatam ho jaata hai — dekho Pipelining-Hazards.

ILP aur TLP dono ke liye same Amdahl's Law formula kyun use hota hai?

Dono kaam ko ek serial part mein split karte hain jo overlap nahi ho sakta aur ek parallel part jo ek parallelism factor se divide hota hai (

n

IPC ke liye,

N

cores ke liye); algebra identical hai — fraction ka meaning alag hai, yahi reason hai kyun hum letters

f

aur

p

alag rakhte hain (dekho Amdahls-Law).

TLP hundreds of units tak scale kyun karta hai jabki ILP nahi?

TLP poore threads ke beech algorithmic independence exploit karta hai, jo bade problems mein bahut hoti hai; ILP ek stream ke andar short dependency distances se bounded hoti hai.

Sum-reduction loop mein multiple accumulators add karne se zyada ILP expose kyun hota hai?

Ek accumulator har add ko pichle add ka wait karne par majboor karta hai (ek serial chain); kaafi saare partial accumulators kai independent chains create karte hain jinhein superscalar core overlap kar sakta hai, combine sirf end mein.

DLP ko ILP mein fold karne ki bajaye ek alag category kyun rakha jaata hai?

Ek SIMD instruction ek single instruction hai, toh uske lanes ko ILP count karna parallelism ko double-count karega aur hardware analysis confuse karega; DLP ko alag rakhna (dekho SIMD-Vector-Processing) woh error avoid karta hai.

Linked list se array mein move karne se ILP aur TLP dono kyun unlock hote hain?

Array indices pehle se known hote hain, isliye loads independent hain (ILP) aur index ranges threads mein cleanly split hoti hain (TLP); linked lists next address tab tak chhupate hain jab tak current load complete na ho, dono ko block karte hue.

Zyada cores kuch parallel programs ko actually slow down kyun kar sakte hain?

Communication, synchronization, aur cache-coherence traffic core count ke saath badhti hai (dekho Cache-Coherence-Protocols); ek point ke baad yeh overhead shrinking per-core work se zyada ho jaata hai, isliye net speedup girta hai.

Edge cases

Boundary aur degenerate scenarios jinse tum surprise nahi hone chahiye. Har ek upar wale Amdahl formula mein ek limiting value plug karta hai.

Jab parallel fraction

f = 0

ho (fully dependent code) tab ILP speedup kya hoga?

f = 0

set karo:

S_{I L P} = \frac{1}{( 1 - 0 ) + 0/ n} = \frac{1}{1} = 1 \times

— koi overlap possible nahi hai chahe

n

kitna bhi wide ho, kyunki har instruction pichli ka wait karti hai.

Jab

f = 1

ho (har instruction independent) tab ILP speedup kya hoga?

f = 1

set karo:

S_{I L P} = \frac{1}{0 + 1/ n} = n

— speedup issue width

n

ke saath linearly badhta hai aur sirf

n

ke hardware limit par saturate hota hai (real code kabhi

f = 1

nahi pahunchta, yahi reason hai ki sustained IPC kam rehti hai).

Serial fraction

(1 - p)

ke saath core count

N \to \infty

par TLP speedup kya hoga?

Jab

N \to \infty

tab term

p / N \to 0

, isliye

S_{T L P} \to \frac{1}{1 - p}

— parallel part khatam ho jaata hai lekin serial part bacha rehta hai, toh infinite cores finite speedup dete hain.

Agar

p = 1

(perfectly parallel) ho, toh TLP speedup ko kya limit karta hai?

p = 1

ke saath formula

S = \frac{1}{0 + 1/ N} = N

deta hai, toh math akela poora

N \times

predict karta hai; practice mein sirf physical resources ise cap karte hain — core count

N

, memory bandwidth, aur power/thermal limits.

Jab issue width

n = 1

ho (ek scalar, non-superscalar core) tab ILP speedup kya hoga?

n = 1

set karo:

S_{I L P} = \frac{1}{( 1 - f ) + f} = \frac{1}{1} = 1 \times

chahe

f

kuch bhi ho — ek issue slot ke saath kahan overlap karein, isliye instruction independence waste ho jaata hai.

Ek single instruction (ek-instruction program) ke liye kitna ILP available hai?

Kuch nahi — ILP ko overlap karne ke liye multiple instructions chahiye; ek instruction ke saath uske saath kuch bhi nahi chala sakte, isliye IPC zyada se zyada 1 hai.

Ek workload totally independent instructions ki stream hai lekin phir bhi low speedup milti hai — kyun?

Agar woh independent instructions sab cache mein miss karti hain ya ek execution port par contend karti hain, toh bottleneck memory ya ports par shift ho jaata hai, instruction dependency par nahi — high

f

akela kaafi nahi hai jab

n

resources se throttled ho.

SMT benefit kya hoti hai jab dono threads same unit par compute-bound hoon?

Almost kuch nahi — SMT tab jeetta hai jab stalls se bacha idle slots fill karta hai; agar dono threads shared unit ko busy rakhein, toh ve simply compete karte hain aur bahut kam gain milta hai.

Recall Fast self-check

ILP overlap karta hai ::: ek stream se kaafi saari instructions ko TLP overlap karta hai ::: kaafi saare independent instruction streams ko DLP/SIMD hai ::: kaafi saare data elements par ek instruction Amdahl's Law mein hard ceiling aati hai ::: serial fraction $(1 - p)$ se Do letters $f$ aur $p$ kyun? ::: $f$ = instruction independence (ILP), $p$ = algorithmic split (TLP); same formula, alag source ILP speedup at $f = 1$ equals ::: the issue width $n$ Pointer chasing hurt karta hai kyunki ::: har load finish hona chahiye pehle ki next address pata chale