Out-of-order execution: Worked examples — Hinglish deep dive

5.3.2 · D3 · Hardware › Advanced Microarchitecture › Out-of-order execution

Ye page Out-of-order execution ka drill floor hai. Parent note ne ideas build kiye the: renaming, reservation stations, reorder buffer (ROB), ready condition. Yahan hum har tarah ki situation ko un ideas pe throw karte hain aur har ek ko haath se grind karte hain.

Shuru karne se pehle, ek promise: jo bhi symbol tum yahan dekhoge wo parent note mein earn kiya gaya hai, aur main pehli baar aane par use re-anchor karta hoon. Agar koi term naya lagta hai, wo ek bug hai — mujhe batao.

Definition Fast vocabulary refresh (ek baar padho, phir drill karo)

In-flight instruction :: wo jo fetch ho chuki hai lekin abhi tak committed nahi hui. Ye pipe ke front aur ROB head ke beech kahin rehti hai.
Latency :: kitne cycles ek instruction executing mein lagati hai jab tak uska result exist kare. Register add = 1 cycle; yahan memory LOAD = 3 cycles.
Result-ready cycle :: wo cycle jiske end mein value Common Data Bus (CDB) par exist karti hai — wo shared wire jis par har reservation station "snoop" karta hai.
IPC (Instructions Per Cycle) :: speed ka hamaara headline score — CPU har clock cycle mein finish karne wale instructions ki average number. Agar $N$ instructions $C$ cycles lete hain, to $IPC = N / C$ . Zyada = fast. Is page par sab kuch ultimately IPC badhane ki fight hai, aur neeche ke "ceilings" wo cheezein hain jo ise cap karti hain.
RAW / WAR / WAW :: teen tarike jab do instructions same register ko touch karte hain. Read-After-Write ek true dependency hai (real data flow). Write-After-Read aur Write-After-Write false hain — ye exist karte hain sirf isliye kyunki humne register naam reuse kiya, aur register renaming unhe delete kar deta hai.
Commit / retire :: wo in-order moment jab result officially real ho jata hai (architectural state).
ILP (Instruction-Level Parallelism) :: kitne independent instructions code ke ek piece mein ek saath run ho sakte hain. "Window-limited ILP" = wo parallelism jo tum current window ke andar actually dekh sakte ho; "critical-path-limited ILP" = wo parallelism jo longest dependency chain kuch ordering force karne ke baad bachi rehti hai. Dekho instruction-level parallelism.
Physical register (P1, P2, … likha jata hai) :: CPU ke andar ek real storage slot, jinmein ~168 hote hain. Renaming un named registers ko (R1, R2, …, sirf 16–32) in bahut saare physical slots par map karta hai. Is page par P-prefix ka matlab hai "ek physical register jo renamer ne diya"; R-prefix ka matlab hai "ek architectural register jo programmer ne likha."
Symbol $\infty$ :: ise padho "unlimited / jitna chahiye utna." Jab koi example kehta hai " $\infty$ ports," matlab hai: pretend karo CPU same cycle mein koi bhi number ke instructions start kar sakta hai, to ports kabhi nahi khatam hote. Hum iska use ek saath ek ceiling isolate karne ke liye karte hain.

Is poori page par hum do timing rules follow karte hain taaki har jawab reproducible ho. Inhe ek baar dhyan se padho — ye baad mein har "3 cycles hain ya 4?" sawaal ko resolve karte hain.

Formula "Total cycles" ke liye EK rule (sari inconsistency hatata hai)

Total cycles = wo cycle jisme last instruction commit hota hai. Hum ise do independent steps mein compute karte hain aur bada lete hain: $Total = max (execution-bound last-result-ready cycle + 1, retire-bound ⌈ N / R ⌉ measured from first commit)$

Execution term par +1 us last result ke liye single write-back-to-architectural-state cycle hai.
Retire term tab hi matter karta hai jab bahut saare results $R$ /cycle se zyada fast pile up ho jaate hain. Commit "hide" kab hota hai? Jab results $R$ /cycle se zyada fast nahi nikalte (jaise ek dependency chain), retire pace rakhta hai aur retire term bada nahi hota — to wo kuch nahi jodhta. Commit kab bind karta hai? Jab results ek burst mein khatam hote hain jo $R$ se zyada wide hai (jaise wide ports par bahut saare independent ops), to retire term jeet jaata hai. Examples 4, 5 aur 8 har case ko explicitly dikhate hain. Ab se hum hamesha ye $max$ apply karte hain, to commit cycles add karne ke baare mein kabhi ambiguity nahi rahegi.

The scenario matrix

Jo bhi OoOE tumhare saath kar sakta hai wo in cells mein se kisi ek mein aata hai. Neeche ke examples un cell(s) ke saath labeled hain jinhe wo cover karte hain, aur saath mein wo har row ko hit karte hain.

#	Case class	Kya mushkil banata hai	Covered by
A	No dependencies (fully parallel)	sirf execution width se limited	Ex 1
B	RAW chain (true dependency)	critical path — ise beat nahi kar sakte	Ex 2
C	WAW / WAR false dependency	parallelism unlock karne ke liye rename karna chahiye	Ex 3
D	Mixed: slow LOAD + independents + dependent	latency ke around reorder karo	Ex 4
E	Not enough ports (execution-width limit)	ready ≠ can-fire	Ex 5
F	Exception / speculative squash	ROB ke through precise state	Ex 6
G	Degenerate: window too small	independent work nahi dekh sakte	Ex 7
H	Limiting case: zero dependencies, infinite width	IPC → execution/retire width	Ex 8
I	Real-world word problem (cache miss)	memory-level parallelism	Ex 9
J	Exam twist: is a reorder legal?	true vs false hazard spot karo	Ex 10

Parent note ke teen ceilings har cell ko govern karte hain (IPC = Instructions Per Cycle, upar define kiya): $IPC \leq min (Window-limited ILP, Execution width, Critical-path-limited ILP)$ Har example asal mein ye puch raha hai: in teen ceilings mein se kaunsa yahan binding hai? (Example 8 ek hidden chautha ceiling unmask karega: retire bandwidth.)

Neeche ki figure un teen ceilings ko teen bars ki illustrative heights ke roop mein draw karti hai. Green dashed line sabse chhote bar par baithe hai — wo wahi hai jo actually IPC ko limit karta hai. Har example ek hunt hai ki kaunsa bar sabse chhota hai: blue "window" bar (kya tum kaam dekh sakte ho?), yellow "execution width" bar (kya ise run karne ki jagah hai?), ya red "critical path" bar (kya tum sequence karne ke liye majboor ho?).

Example 1 — Cell A: fully independent instructions

Worked example Chaar adds, kuch share nahi

I1: R1 = R2 + R3
I2: R4 = R5 + R6
I3: R7 = R8 + R9
I4: R10 = R11 + R12

Sab 1-cycle. Machine mein 2 add ports hain (2 adds per cycle start kar sakta hai) aur retire bandwidth $R = 2$ per cycle. Saanon char ko finish (commit) karne mein kitne cycles lagenge?

Forecast: padhne se pehle guess karo — kya ye 1, 2, ya 4 cycles hai?

Dependencies check karo. Koi bhi instruction woh register nahi padhta jo dusra likhta hai. To koi RAW, WAR, WAW nahi. Ye step kyun? Dependencies ek hi reason hain jab OoOE serialize karne par majboor hota hai. Zero dependencies matlab critical-path ceiling = 1 (koi bhi single instruction poori chain hai).
Resources check karo. 4 ready instructions, lekin sirf 2 add ports. To cycle 1 mein I1, I2 fire hote hain (ready end cyc 1); cycle 2 mein I3, I4 (ready end cyc 2). Ye step kyun? Ready hona zaroori hai lekin kaafi nahi — tumhe ek free port bhi chahiye. Yahan execution-width ceiling = 2/cycle binding wala hai.
Total-cycles rule apply karo. Execution-bound = last-ready (cyc 2) + 1 = 3. Retire-bound = $⌈ 4/ R ⌉ = ⌈ 4/2 ⌉ = 2$ cycles of committing. $R = 2$ ke saath port width se matched, commit pace rakhta hai aur dominate nahi karta; last pair ka total commit cycle 3 mein land karta hai. Ye step kyun? Humne deliberately $R = 2$ set kiya taaki retire issue se match ho — ye "commit hides" wala case hai.
Total = 3 cycles (compute karne ke liye 2, + final pair commit karne ke liye 1).

Verify: last result ready cyc 2, +1 commit ⇒ 3. Sustained IPC $= 4/3 \approx 1.33$ ; jab ports saturate hote hain to steady-state throughput 2/cycle = execution width hai, binding ceiling. ✓

Example 2 — Cell B: ek pure RAW chain

Worked example Har ek pehle wale par depend karta hai

I1: R1 = R2 + R3    ; 1 cycle
I2: R4 = R1 + R5    ; R1 chahiye
I3: R6 = R4 + R7    ; R4 chahiye
I4: R8 = R6 + R9    ; R6 chahiye

$\infty$ ports (unlimited — vocab note dekho), retire $R = 1$ /cycle. Finish hone mein cycles?

Forecast: unlimited execution units ke saath, kya ye 1 cycle mein run karta hai?

Data-flow graph draw karo: I1 → I2 → I3 → I4, ek single strand. Ye step kyun? Ek RAW edge ek true dependency hai — I2 ko literally wo number chahiye jo I1 produce karta hai. Koi renaming, koi extra port ise nahi hatata.
Har fire time karo. I1 cyc 1 mein fire, ready end of cyc 1. I2 cyc 2 mein fire karta hai (apne operand ke baad). I3 cyc 3. I4 cyc 4. Ye step kyun? Ye critical-path ceiling kaam kar raha hai. Ye wo ek limit hai jo koi bhi hardware beat nahi kar sakta — Apple ka 600-entry window bhi I4 ko I3 ke khatam hone se pehle run nahi kar sakta.
Total-cycles rule apply karo. Results ek-ek cycle mein nikalte hain (I1 ready cyc1, …, I4 ready cyc4). Execution-bound = last-ready (cyc 4) + 1 = 5. Retire-bound = $⌈ 4/1 ⌉ = 4$ commits, lekin wo I1 ke khatam hone par start hote hain aur 1/cycle pace rakhte hain — kabhi execution term se bada nahi. To $max$ execution term pick karta hai. Ye step kyun? Chains wahi case hain jahan commit hide hota hai: ek cycle mein ek result exactly $R = 1$ se match karta hai.
Total = 5 cycles (4 ki chain + ek final commit). IPC $= 4/5 = 0.8$ ; chain ke saath steady-state throughput 1/cycle hai, critical-path-limited ILP se match karta hai.

Verify: chain length 4 ⇒ last ready cyc 4, +1 commit ⇒ 5. Ports add karna kuch nahi karta: $min (\infty width, \infty window, critical path)$ chain ko phir bhi force karta hai. ✓

Example 3 — Cell C: renaming se false dependency khatam

Worked example Woh R1 jo jhooth bolta hai (WAW + WAR)

I1: R1 = R2 + R3
I2: R4 = R1 + R5    ; R1 par RAW (true)
I3: R1 = R6 + R7    ; I1 ke saath WAW, I2 ke saath WAR (dono false)
I4: R8 = R1 + R9    ; I3 ke R1 par RAW (true)

2 add ports, retire $R = 2$ /cycle. Renaming ke saath cycles vs bina renaming ke?

Forecast: kya I3 ko I1 ke khatam hone ka intezaar karna padta hai?

R1 ke har shared use ko classify karo. I2 I1 ka R1 padhta hai (true RAW). I3 phir R1 likhta hai — naam I1 ki write se (WAW) aur I2 ki read se (WAR) collide karta hai. Wo dono false hain: ye sirf isliye exist karte hain kyunki assembler ne naam R1 reuse kiya. Ye step kyun? False dependencies naming ke artifacts hain, data ke nahi. Parent note ki insight: unhe rename karke hatao.
Physical registers par rename karo. Yaad raho P-prefixed names CPU ke bahut saare real storage slots hain. I1 ke result ko physical slot P1 do aur I3 ke result ko ek alag slot P2. Ab:
- I2 P1 padhta hai, I4 P2 padhta hai. Dono chains {I1→I2} aur {I3→I4} alag physical slots touch karti hain, to wo independent hain. Ye step kyun? Do distinct physical slots use karna do R1 writes ke liye real data-flow graph expose karta hai — ek tangle ki jagah do alag 2-long strands.
Schedule karo (2 ports). Cyc 1: I1 aur I3 fire karo (dono ready, independent), ready end cyc 1. Cyc 2: I2 aur I4 fire karo, ready end cyc 2. Execution-bound = 2 + 1 = 3; retire-bound $R = 2$ ke saath pace rakhta hai. Total = 3 cycles.
Bina renaming ke: I3 tab tak stall karta hai jab tak I1 ki write retire ho aur I2 ki read complete ho → serial-ish: cyc1 I1, cyc2 I2, cyc3 I3, cyc4 I4, last ready cyc 4, +1 commit ⇒ 5 cycles.

Verify: speedup $= 5/3 \approx 1.67 \times$ . Renaming ke saath, steady-state throughput = 2/cycle = execution width, binding ceiling jab false deps khatam ho jaate hain. ✓

Figure ye split visually dikhati hai: top row wo tangled single strand hai jo naam reuse se force hoti hai (blue → red edges), aur bottom row wo do clean, parallel strands hain jab P1/P2 unhe separate karta hai.

Example 4 — Cell D: slow LOAD + independents + dependent (parent ka showcase, re-derived)

Worked example Memory load ke around reorder karo

I1: R1 = LOAD [addr]   ; 3 cycles
I2: R2 = R3 + R4       ; 1 cycle, independent
I3: R5 = R1 + R2       ; I1 AUR I2 chahiye
I4: R6 = R7 * R8       ; 1 cycle, independent

Ek LOAD port, ek ALU port, retire $R = 1$ /cycle program order mein. In-order vs out-of-order mein cycles?

Forecast: LOAD 3 cycles leta hai — kya I2 aur I4 ko uske peeche baithna padega?

In-order. I1 cyc 1–3 occupy karta hai. I2 tab tak start nahi ho sakta jab tak I1 leave na kare → cyc 4. I3 → cyc 5. I4 → cyc 6. Total 6. Ye step kyun? In-order issue matlab ek stall sabko uske peeche poison karta hai, innocent I2/I4 ko bhi.
Out-of-order — independents ko jaldi fire karo. I2 ka koi operand wait nahi kar raha → cyc 1 mein ALU port par fire karo (ready end cyc 1). I4 → cyc 2 mein ALU port par fire karo (ready end cyc 2). LOAD I1 apne port par cyc 1–3 run karta hai. Ye step kyun? Alag ports = I2/I4 LOAD ke saath compete nahi karte. Ye poora OoOE ka point hai.
Dependent I3 ko fire karo. I3 ko I1 (ready end cyc 3) aur I2 (ready end cyc 1) chahiye. Last operand ready end of cyc 3 → I3 cyc 4 mein fire karta hai, result ready end cyc 4. Ye step kyun? I3 genuine dependency chain I1 → I3 par baitha hai; wo chain, ports nahi, uski earliest fire set karti hai.
Total-cycles rule apply karo. I3 program order mein last hai; uska result ready end cyc 4. Execution-bound = 4 + 1 = 5. Retire-bound: sirf 4 instructions, $R = 1$ par order mein committed lekin koi burst nahi (I2 ready cyc1, I4 cyc2, I1 cyc3, I3 cyc4 — ek per cycle) to retire pace rakhta hai aur dominate nahi karta. $max$ 5 deta hai. Ye step kyun? Parent note ka "≈5 cycles including commit settling" exactly yahi hai: +1 wo last result I3 ka in-order commit hai.

Verify: speedup $6/5 = 1.2 \times$ , parent note se match. Residual latency = genuine chain I1→I3 plus ek in-order commit step. ✓

Timeline figure dono schedules stack karta hai: top block in-order hai (I2/I4 red LOAD ke peeche stranded, red dashed finish line at 6), bottom block out-of-order hai (I2/I4 jaldi pull hue, green dashed finish line at 5).

Example 5 — Cell E: ready ≠ can-fire, AUR retire bandwidth bite karta hai

Worked example Chhah ready adds, do ports, ek retire slot

I1..I6: chhah independent 1-cycle adds, saare operands cycle 0 par ready

Do add ports, retire $R = 1$ /cycle. Saanon chhah commit hone mein kitne cycles?

Forecast: sab chhah turant ready hain — to kya 1 cycle? Ya kuch aur cap karta hai?

Sab ek saath ready. Koi dependency delay nahi. Critical-path ceiling = 1. Window kaafi bada hai (window ceiling ≥ 6). Ye step kyun? Do ceilings kehte hain "jao fast"; humein binding wala dhundhna hai.
Ports starting ko limit karte hain. 2 per cycle: cyc 1 mein I1,I2 fire (ready end 1); cyc 2 mein I3,I4 (ready end 2); cyc 3 mein I5,I6 (ready end 3). Ye step kyun? Execution-width ceiling = 2/cycle. Execution akela end of cyc 3 tak results produce karna khatam kar deta.
Ab total-cycles rule honestly apply karo. Chhah results ek burst mein ready hote hain (2 per cycle) lekin retire sirf $R = 1$ per cycle drain karta hai. Retire-bound = $⌈ 6/1 ⌉ = 6$ commit cycles. Committing cyc 2 mein start hoti hai (I1/I2 ready hone ke ek cycle baad) aur 1/cycle proceed karta hai: I1 cyc2, I2 cyc3, I3 cyc4, I4 cyc5, I5 cyc6, I6 cyc7. Ye step kyun? Sirf ek retire slot ke saath, chhah results sabhi cycle 4 tak committed nahi ho sakte. Retire term $max$ jeet jaata hai. Execution-bound = 3+1 = 4, retire-bound cyc 7 tak pahunche → Total = 7 cycles.
Yahan binding ceiling retire bandwidth hai, ports nahi. Ports ROB ko finished results se bhar dete hain usse zyada fast jitna commit publish kar sakta hai.

Verify: results end cyc 3 tak produce hue, lekin $⌈ 6/1 ⌉ = 6$ in-order commits cyc 2 se start ⇒ last commit cyc $2 + 6 - 1 = 7$ . Sustained IPC $= 6/7 \approx 0.86 = R$ (retire bandwidth), asli bottleneck. ✓ Lesson: readiness tumhe choose karne deti hai, ports decide karte hain kitne start hote hain, retire decide karta hai kitne real bante hain.

Example 6 — Cell F: exception speculative kaam squash karta hai

Worked example ROB head par fault

ROB (program order, head on left):
[ I3(fault) | I4 done | I5 done ]
   ^head

I1, I2 already committed. I3 zero se divide karta hai. I4, I5 already out-of-order execute ho chuke hain. Handle karne ke baad architectural state kya hai?

Forecast: kya I4 aur I5 ke results survive karte hain, kyunki wo finish ho gaye?

I3 head par hai aur fault hua. Commit rule: Can_Commit(I_h) = Complete(I_h) ∧ ¬Exception(I_h). Yahan Exception true hai → commit nahi ho sakta. Ye step kyun? Sirf head commit kar sakta hai, aur wo exception-free hona chahiye. Ye sequential execution ka illusion enforce karta hai.
Head ke baad sab kuch flush karo. I4, I5 faulting I3 se younger hain. Unki computed values sirf ROB mein rehti hain, kabhi architectural registers/memory mein nahi → unhe discard karo. Ye step kyun? Precise exceptions demand karte hain: "I3 fault hua, uske baad kuch nahi hua." Speculative results invisible hone chahiye.
Roll back. Architectural state = I2 ke baad wali state (I3 ke inputs). OS ko signal karo.

Verify: committed set = {I1, I2}; discarded = {I4, I5}; I3 pending. Visible results ki count = 2, exactly pre-fault instructions. ✓ (Same principle speculative execution aur branch prediction recovery ko power karta hai.)

Example 7 — Cell G: window itna chhota ki kaam dikhi hi nahi

Worked example Independent instruction pahunch se bahar hai

I1: R1 = LOAD [addr]   ; 100-cycle cache miss
I2..I5: chaar adds, har ek previous par RAW-dependent (chain, I1 chahiye)
I50: R99 = R98 + R97   ; har cheez se bilkul independent

Instruction window = 4 entries, retire 1/cycle. Kya I50 100-cycle miss ke dauran execute ho sakta hai?

Forecast: I50 par free independent work hai — kya OoOE use pakdega?

Window sirf 4 in-flight instructions hold karta hai. Jab I1 miss par stall karta hai, window I1..I4 se bhar jaata hai aur aage nahi badh sakta (I1 ROB head ko commit karne se rokta hai). Ye step kyun? Window ceiling cap karta hai ki CPU kitna aage dekh sakta hai. I50 window edge se 46 instructions aage hai — invisible.
CPU ~100 cycles stalls karta hai kuch useful kiye bina, chahe I50 run ho sakta tha. Ye step kyun? Independent kaam jo tum dekh nahi sakte wo independent kaam hai jo tum use nahi kar sakte. Exactly isliye modern chips windows 200–600 entries tak badhate hain.
Fix: window ≥ 50 I50 ko andar pull karta aur miss latency ko uske peeche hide karta.

Verify: window 4 ke saath, miss ke dauran reachable-independent-work = 0 → binding ceiling window-limited ILP ≈ 0 useful IPC un cycles ke liye. Window 50 se bada karo → I50 reachable. ✓

Example 8 — Cell H: clean limit (infinite width) — retire bandwidth unmask karna

Worked example Execution width ko infinity tak push karo

N independent 1-cycle instructions, saare operands cycle 0 par ready.
Execution width = W ports. Window ≥ N. Retire bandwidth = R per cycle.

Jab $W \to \infty$ (width bina bound ke badhti hai — vocab note se $\infty$ ), sustained IPC kya hai?

Forecast: kya IPC forever badhta hai, ya kisi wall se takrata hai?

Execution jaldi khatam hota hai. Zero dependencies ke saath critical-path ceiling = 1 (kabhi bind nahi karta) aur window ≥ N (kabhi bind nahi karta), to execution sirf $⌈ N / W ⌉$ cycles chahiye. $W \to \infty$ ke saath, wo 1 cycle hai: har result cycle 1 ke end mein ready hai. Ye step kyun? Humne teen ceilings deliberately hataye jo bhi bacha hai use expose karne ke liye.
Lekin results abhi bhi committed hone chahiye order mein $R$ /cycle par. Saare $N$ results publish karne mein $⌈ N / R ⌉$ commit cycles lagte hain. Total-cycles rule apply karo: $Total = max (⌈ N / W ⌉ + 1, ⌈ N / R ⌉)$ . Ye step kyun? Infinite ports useless hain agar tum sirf $R$ /cycle par results real bana sako. Ye hidden fourth ceiling hai — retire bandwidth.
Limit lo. $W \to \infty$ ke saath, sustained IPC $= N / max (1, ⌈ N / R ⌉) \to R$ ( $N \geq R$ ke liye). To IPC retire width $R$ par saturate hota hai, kabhi nahi infinite execution width par. Ye step kyun? Ye pin down karta hai ki kaunsa ceiling truly independent kaam ke burst ko cap karta hai: ports nahi, balki commit.

Verify: $N = 8$ . $R = 1$ ke saath: total $= max (1, 8) = 8$ , IPC $= 8/8 = 1 = R$ . $R = 8$ ke saath: total $= max (1, 1) = 1$ , IPC $= 8/1 = 8 = R$ (aur $= N$ , kyunki $R \geq N$ ). $R = 16 \geq N$ ke saath: IPC $= N = 8$ , $W$ nahi $N$ se capped. ✓ IPC $\to R$ , confirm karta hai retire bandwidth wall hai.

Example 9 — Cell I: real-world word problem (memory-level parallelism)

Worked example Do cache misses — serial ya overlapped?

Ek loop do independent LOADs issue karta hai jo dono L1 miss karte hain aur main memory jaate hain (100 cycles each). Window dono hold karne ke liye kaafi bada hai.

I1: R1 = LOAD [addrA]   ; miss, 100 cycles
I2: R2 = LOAD [addrB]   ; miss, 100 cycles, I1 se independent
I3: R3 = R1 + R2        ; dono chahiye

Kitna time, in-order (blocking) vs out-of-order (non-blocking loads), retire 1/cycle?

Forecast: do 100-cycle misses — kya wo 200 cycles hai ya 100?

In-order (blocking). I1 pipe ko 100 cycles stall karta hai, phir I2 aur 100 stall karta hai → ~200 cycles, phir I3. Ye step kyun? Ek blocking machine misses serialize karta hai chahe wo independent hoon.
Out-of-order + non-blocking loads. I1 aur I2 independent hain → dono miss requests same window mein launch hote hain. Memory unhe overlapped serve karta hai (memory-level parallelism). Dono ~cycle 100 par wapas. I3 cycle 101 mein fire karta hai. Ye step kyun? OoOE ka window dono miss addresses ek saath outstanding rehne deta hai — misses ~100-cycle wait share karte hain stack karne ki jagah. 100-cycle miss ke against sirf 3 instructions ka commit at 1/cycle trivially bottleneck nahi hai.

Verify: in-order ≈ 200 cyc; OoO ≈ 101 cyc; speedup $200/101 \approx 1.98 \times \approx 2 \times$ . ✓ (Jab doosre cores involved hoon to cache coherence aur memory consistency ke saath interact karta hai.)

Example 10 — Cell J: exam twist — "kya ye reorder legal hai?"

Worked example Hazard type spot karo

Compiler I2 aur I3 swap karna chahta hai. Kya OoOE engine ke liye I2 se pehle I3 execute karna legal hai?

I1: R1 = R2 + R3
I2: R4 = R1 + R5     ; R1 padhta hai
I3: R1 = R6 + R7     ; R1 likhta hai

Forecast: I2 R1 padhta hai, I3 R1 overwrite karta hai — I3 pehle run karna safe hai?

I2 aur I3 ke beech hazard identify karo. I2 reads R1; I3 writes R1. Write-After-Read = WAR = ek false dependency. Ye step kyun? WAR real data flow nahi hai — ye sirf kehta hai "I2 ke R1 padhne se pehle R1 mat chhedo."
Renaming apply karo. I3 ki write ko ek fresh physical register P2 do (I1 ke P1 se alag jo I2 padhta hai). Ab I3 P2 likhta hai, I2 P1 padhta hai — koi conflict nahi. Ye step kyun? Renaming ordering constraint ko ek naming fact mein convert karta hai. Alag physical slots ke saath, execution order free hai.
Conclusion: Haan, legal hai — renaming ke baad, I3 I2 se pehle execute ho sakta hai. Engine unhe abhi bhi program order mein commit karta hai (ROB, 1/cycle), to architectural R1 execution order se regardless I3 ki value hold karta hai.

Verify: hazard = WAR (false) → rename se removable → reorder legal. Contrast: agar I3 ne R1 padha hota (RAW), to reorder illegal hota. ✓

Recall Self-test (jawab dene ke baad reveal karo)

IPC ek sentence mein ::: instructions finished per clock cycle, $N / C$ — headline speed score Cell A binding ceiling ::: execution width (matched retire ke saath), commit ek settling cycle jodhta hai Cell B binding ceiling ::: critical path (dependency chain length) Ek bada window RAW chain kyun beat nahi kar sakta? ::: chain ek true data dependency hai — baad ke instructions ko literally pehle ke results chahiye WAR aur WAW hataye jaate hain ::: register renaming se (ye false / naming-only hain) Is page par P-prefixed naam ka matlab kya hai? ::: ek physical register — ek real CPU storage slot jo renamer ne diya (vs R = architectural register jo programmer ne likha) In examples mein $\infty$ ka matlab kya hai? ::: unlimited — pretend karo wo resource kabhi nahi khatam hota, taaki hum ek ceiling isolate kar sakein Example 4 total 5 kyun aur 4 nahi? ::: last instruction (I3) ka in-order commit uska result ready hone ke baad ek settling cycle jodhta hai Example 5 total 7 kyun aur 3 nahi? ::: chhah results burst hote hain lekin retire sirf 1/cycle drain karta hai — retire bandwidth bind karta hai Example 8 kaunsa hidden fourth ceiling unmask karta hai? ::: retire / commit bandwidth — sustained IPC R par saturate hota hai, kabhi infinite execution width par nahi I3 fault ke baad I4/I5 discardable kyun hain? ::: wo faulting head se younger hain; unke results sirf ROB mein rehte hain, kabhi committed nahi Cache miss ke dauran, OoOE kaam karte rehne ke liye kya karta hai? ::: independent kaam tak pahunchne ke liye kaafi bada instruction window Do independent misses ~100 nahi ~200 cycles isliye kyun lete hain ::: memory-level parallelism — dono requests ek saath outstanding hain