5.4.3 · D3 · HinglishMemory Hierarchy & Caches

Worked examplesSet-associative and fully associative caches

3,468 words16 min read↑ Read in English

5.4.3 · D3 · Hardware › Memory Hierarchy & Caches › Set-associative and fully associative caches

Yeh page ek drill hall hai. Parent note ne tumhe machinery di thi — ki ek address kaise tag, set index aur block offset mein split hota hai, aur direct-mapped, set-associative, aur fully associative caches mein kya fark hai. Yahan hum us machinery par har tarah ke questions throw karte hain taaki koi bhi exam scenario tumhe surprise na kare.

Shuru karne se pehle, ek promise: har symbol wahan explain hoga jahan woh pehli baar aata hai, aur neeche har number verify block mein machine-check kiya gaya hai.


Woh symbols jo hum baar baar use karenge

Yeh paanch letters yaad rakho — har example mein exactly inhi mein numbers daale jaate hain.


Scenario matrix

Cache-mapping problem ko ek aisi machine samjho jisme teen input dials hain:

  • Associativity dial — ek block kitni jagahon par ja sakta hai: (direct-mapped), koi beech ka number (set-associative), ya har line (fully associative).
  • Address dial — ek specific memory address, jo kahin bhi land kar sakta hai, including kisi boundary par (offset ) ya block ki last byte par.
  • Question type dial — "fields decode karo", "kaun sa set?", "hit hai ya miss?", "kitne bits?", ya ek real-world word problem.

Neeche ki table mein har case class list hai jo yeh topic throw kar sakta hai. Baad ke har example mein us cell ka tag lagega jise woh cover karta hai.

Cell Case class Kya stress kiya gaya hai
A (direct-mapped) field decode associativity ka degenerate low end
B middle (4-way) field decode normal set-associative case
C sari lines (fully associative) degenerate high end — koi index field nahi
D Direct-mapped cache mein do addresses ka collision conflict-miss ka janam
E Wohi do addresses 2-way cache mein associativity se conflict avoid karna
F Offset = 0 (block boundary) vs offset = max (last byte) degenerate / limiting offsets
G Ek hit/miss trace replacement policy ke saath time ke saath temporal behaviour
H Word problem — bit budget mein associativity chunna design decision
I Exam twist — block size badlo, dekho har field kaisa move karta hai ek dial ke badle sensitivity

Quick vocabulary refresh (taaki kuch bhi unexplained na rahe)

Recall

kyun, plain division kyun nahi? ka jawab hai "mujhe cheezein name karne ke liye kitne yes/no bits chahiye?" ::: Kyunki har bit count ko double karti hai: bits se cheezein name ho sakti hain, isliye cheezein name karne ke liye woh chahiye jisme ho, yaani .

Neeche ka field ruler yeh split scale mein dikhata hai (Example B ki widths use karke). Har baad wale example mein, mentally apna address is ruler par rakhna: orange slab right mein low bits leta hai (offset), teal slab beech mein agli bits leti hai (index), aur plum slab left mein baaki rakhta hai (tag). Caption ki yeh reminder note karo ki teen widths hamesha tak sum karti hain.

Figure — Set-associative and fully associative caches

Example A — Direct-mapped decode (cell A)

Forecast: Pehle andaza lagao — ke saath, kitne sets hain? (Hint: utne hi jitni lines hain.)

  1. Lines (yahan bytes, bytes). Yeh step kyun? Har line ek -byte block rakhti hai; bytes mein blocks fit hote hain, toh yahi line count hai.
  2. Sets . Yeh step kyun? Direct-mapped matlab ek line per set, isliye sets lines. Yeh matrix ka degenerate low end hai.
  3. Fields: offset ; index ; tag . Yeh step kyun? Fields ka sum address width ke barabar hona chahiye; jo offset ya index nahi hai woh tag hai.
  4. Decode 0x0000ABCD .
    • Offset = low 5 bits .
    • Index = agle 10 bits, yaani bits .
    • Tag = baaki high 17 bits (bits ) . Yeh step kyun? Hum right se slice karte hain taaki har field apna numeric meaning rakhe: address ko se right shift karo phir index ke liye bits mask karo, tag ke liye se right shift karo.

Verify: ✓. Offset ek valid byte index hai () ✓. Line/set range mein hai ✓. (Numeric split Verify block mein checked hai.)


Example B — 4-way set-associative decode (cell B)

Forecast: Example A se zyada ways — kya tumhein zyada ya kam index bits lagti hain?

  1. Lines (yahan bytes, bytes). Yeh step kyun? Wahi purana rule — capacity divided by block size batata hai kitne blocks fit hote hain.
  2. Sets . Yeh step kyun? Chaar lines ek set share karti hain, isliye sets ki sankhya lines ki sankhya se ek-fourth hogi. Direct-mapped case se kam sets — index bits shrink hote hain, tag bits grow karti hain.
  3. Fields: , , . Yeh step kyun? Offset block ke bytes cover karta hai, index sets mein se ek name karta hai, tag bacha hua hai.
  4. Decode 0x00DEAD00 .
    • Offset = low 6 bits .
    • Index = agle 8 bits, bits .
    • Tag = high 18 bits (bits ) . Yeh step kyun? Wohi right-to-left slicing; sirf field widths badi hain.

Verify: ✓. Set ✓. Offset matlab address block boundary par baith raha hai — ek cell F limiting case jo yahan bhi ho raha hai (neeche checked).


Example C — Fully associative decode (cell C)

Forecast: Jab block kahin bhi ja sakta hai, toh index field ka kya hota hai?

  1. Lines (yahan bytes, bytes). Yeh step kyun? Capacity-over-block rule phir se; yeh 256 lines total parking spots hain.
  2. Sets (saari lines ek giant set mein). Yeh step kyun? Fully associative degenerate high end: koi partitioning nahi, isliye index bits . Index field gayab ho jaata hai.
  3. Fields: , , . Yeh step kyun? Offset ke upar sab kuch ab tag hai — tag ko memory ke saare blocks mein se block ko uniquely name karna hoga, kyunki search narrow karne ke liye koi set nahi hai.
  4. Decode 0x00DEAD00: offset ; tag address .

Verify: ✓. Usi address par Example B se compare karo: 4-way tag tha 8-bit index ke saath. Yahan tag un 8 index bits ko nigal leta hai, isliye fully-associative tag ke barabar hai — Verify mein checked. Yahi kahani hai "index bits tag mein migrate ho jaate hain."


Example D — Do colliding addresses, direct-mapped (cell D)

Forecast: Do alag addresses, same line — acha hai ya bura?

  1. Config: lines, , , , . Yeh step kyun? Kisi bhi address ko slice karne se pehle field widths chahiye; capacity/block 64 lines deta hai, direct-mapped 64 sets banata hai, toh index 6 bits ka hai.
  2. 0x0120 ka index: bits . 0x0120 ; low 4 bits offset hain, agle 6 bits . Yeh step kyun? Hum 4 offset bits ke aage right shift karke agle 6 bits padhte hain — yahi set name karta hai.
  3. 0x0520 ka index: bits . 0x0520 ; agle 6 bits bhi. Yeh step kyun? Doosre address par same slice; dono dete hain → dono us set ki ek aur sirf ek line mein map hote hain.
  4. Tags alag hain: 0x0120 tag = bits ; 0x0520 tag . Yeh step kyun? Same set, alag tag = dono blocks ek hi line ke liye ladte hain.

Result: Inhe alternately access karne par har baar ek doosre ko evict karte hain → ek endless string of conflict misses, jabki 63 doosri lines khali baithi hain. Yahi parking-lot dard hai jiske baare mein parent note ne warning di thi.

Verify: dono indices ✓, tags aur (distinct) ✓.

Neeche ki picture exactly yahi dikhati hai: 64 lines ka ek column, sirf line highlight hai, dono address arrows us ek orange slot par point kar rahe hain. Red caption seedha bolta hai kyun baaki 63 lines madad nahi kar sakti.

Figure — Set-associative and fully associative caches

Example E — Wohi do addresses, ab 2-way mein (cell E)

Forecast: Humne har set mein choices double kar di. Kya ping-pong ruk jaayega?

  1. Config: , sets, , , . Yeh step kyun? Sets halve karne se index window shift ho jaati hai: index ab 5 bits ka hai (bits ), 6 ka nahi, aur jo bit free hui woh tag mein join ho gayi.
  2. 0x0120 ka index: bits . 0000\,0001\,0010\,0000_2 se, 4 offset bits drop karke 5 bits padhne par milta hai. Yeh step kyun? Wohi slicing idea, lekin window ab 5 bits wide hai, toh field ke top par ek bit kam padhi.
  3. 0x0520 ka index: bits . 0000\,0101\,0010\,0000_2 se, 5-bit slice hai. Yeh step kyun? Bit (jo dono addresses mein alag tha) ab tag ka hissa hai, index ka nahi — isliye dono ab bhi set share karte hain.
  4. Lekin har set mein 2 lines hain. Dono blocks side by side fit ho jaate hain: ek way 0 mein, ek way 1 mein. Koi eviction nahi. Yeh step kyun? Associativity same set mein ek doosra parking spot deta hai, toh shared index ab fight force nahi karta.

Result: Ab alternating accesses pehle do loads ke baad dono hit ho jaate hain. Associativity ne conflict misses ki stream ko hits mein convert kar diya — exactly woh sweet-spot argument.

Verify: dono indices ✓; do ways available hain toh dono simultaneously resident hain ✓.


Example F — Offset extremes: boundary vs last byte (cell F)

Forecast: ke fark wale do addresses — same block ya neighbours?

  1. , toh offset low 6 bits. Yeh step kyun? Extremes test karne ke liye sirf offset width chahiye; chhe bits block ke 64 bytes count karti hain.
  2. 0x1000: low 6 bits → uske block ka pehla byte (degenerate zero-offset boundary case). Yeh step kyun? Offset sabse chhota possible offset hai — block ka starting byte.
  3. 0x103F: low 6 bits usi block ka aakhri byte (maximum-offset limiting case). Yeh step kyun? Offset sabse bada offset hai, aur bit 5 ke upar ke bits 0x1000 se match karte hain, isliye tag+index identical hain → ek line.
  4. Block base address 0x1000; block 0x10000x103F tak phailta hai. Yeh step kyun? Kisi bhi address ke low 6 bits mask kar do, ek hi base milta hai, jo ek shared block confirm karta hai.

Result: 0x1000 par ek single cache miss se saare 64 bytes load ho jaate hain, toh baad mein 0x103F ka access ek hit hota hai — yahi spatial locality concrete form mein hai, aur yeh dono offset limits ( aur ) ek hi block ke andar dikhata hai.

Verify: offsets aur ✓; identical block base (address AND ) ✓.


Example G — LRU ke saath Hit/miss trace (cell G)

Forecast: Paanch accesses, do homes, LRU evictions decide kar raha hai. Kitne hits?

Hum set ko [MRU ... LRU] (most-recently-used pehle) track karte hain.

  1. A → set khali hai → MISS, A load karo. Set: [A]. Yeh step kyun? Cold start — abhi kuch bhi cache mein nahi hai, toh A ka pehla touch hit nahi ho sakta.
  2. B → present nahi, spare way free hai → MISS, B load karo. Set: [B, A]. Yeh step kyun? B ek naya block hai aur set mein abhi ek free way hai, toh bina evict kiye load karte hain; B most-recent ban jaata hai.
  3. A → present hai → HIT. A ko front par laao. Set: [A, B]. Yeh step kyun? A step 1 se abhi bhi resident hai; temporal locality kaam aaya, aur LRU order update hota hai toh A ab most-recent hai.
  4. C → present nahi, set full → MISS. LRU B hai (peeche) → B evict karo, C load karo. Set: [C, A]. Yeh step kyun? Dono ways full hain, toh hume sabse thanda evict karna hoga; LRU B ko least-recently used mark karta hai.
  5. B → present nahi (humne abhi evict kiya tha!) → MISS, LRU = A evict karo, B load karo. Set: [B, C]. Yeh step kyun? B ek access der se wapas aaya — step 4 mein throw out ho gaya tha, toh yeh fresh miss hai; A ab sabse thanda hai aur evict ho jaata hai.

Result: hits (sirf step 3), misses . Final set [B, C].

Verify: hit count , miss count , final (ek chhote LRU simulator se checked).

Figure in paanch snapshots ko left se right dikhata hai, HIT ko green aur MISS ko orange color karta hai, top box hamesha most-recently-used way hai — dekho B peeche girti hai aur evict ho jaati hai.

Figure — Set-associative and fully associative caches

Example H — Word problem: bit budget mein associativity chunna (cell H)

Forecast: Zyada associativity → bade tags. Kahan tag 20 bits cross karta hai?

  1. Lines . Offset . Yeh step kyun? Index bits sets mein kaise split hote hain yeh jaanne ke liye line count chahiye; capacity/block 512 lines deta hai.
  2. ke function ke roop mein tag: sets , index , toh Yeh step kyun? ke har doubling se sets half ho jaate hain, ek index bit remove hoti hai aur tag mein add ho jaati hai — toh tag exactly har doubling par bit badhta hai.
  3. Evaluate karo:
    • : . ✓
    • : . ✓
    • : . ✓
    • : . ✓ (exactly budget par)
    • : . ✗ (budget se zyada) Yeh step kyun? Hum har associativity ko mein plug karke 20-bit ceiling se compare karte hain.
  4. Answer: 8-way 20-bit tag budget ke andar highest associativity hai.

Verify: ✓ aur ✗ (dono checked).


Example I — Exam twist: block size badlo, har field dekho (cell I)

Forecast: Block double karna — kaunse fields grow karte hain, kaunse shrink?

  1. Block 64 B: ; ; ; ; . Yeh step kyun? Baseline case: chhote block ke liye standard field computation.
  2. Block 128 B: ; ; ; ; . Yeh step kyun? double karne se ek offset bit add hoti hai (har block twice the bytes cover karta hai) aur line count half ho jaati hai, ek index bit remove hoti hai. Yeh do changes tag par equal aur opposite hain — toh tag par hi rehta hai.
  3. Interpretation:
    • Offset: (bade blocks ko ek aur byte-selector bit chahiye).
    • Index: (kam, bade blocks → kam sets).
    • Tag: (unchanged — shifts cancel ho jaate hain).

Result: Cache size aur associativity fixed rakhne par, block size double karna ek index bit ko ek offset bit ke liye trade karta hai; tag invariant rehta hai. Examiners ko yeh neat fact test karna pasand hai.

Verify: dono tag values ke barabar ✓; offset , index ✓.

Aakhri figure do field rulers stack karta hai taaki tum dekh sako index aur offset ke beech ki boundary ek bit left slide karti hai jabki tag edge frozen rehti hai — arrow us single migrating bit ko mark karta hai.

Figure — Set-associative and fully associative caches

Wrap-up recall

Recall Jab size fixed rakhe associativity badhti hai, toh index aur tag bits ka kya hota hai?

Index bits ke har doubling par 1 se shrink hote hain; tag bits ke har doubling par 1 se grow hote hain; offset unchanged rehta hai. ::: Kyunki toh , aur index se jo bit jaati hai woh tag mein add ho jaati hai.

Recall Example G mein, B apni doosri appearance par miss kyun kiya?

Kyunki B ke dono accesses ke beech mein, block C ne eviction force kiya aur LRU ne B (sabse thanda) choose kiya. ::: B ek access der se wapas aaya — yeh ek textbook LRU thrash hai.

Related deeper dives: Cache performance metrics (in hit/miss traces ko AMAT mein convert karo), Write policies (ek store miss kya karta hai), Cache coherence (multiple caches racing), aur Translation Lookaside Buffer (TLB) jo khud ek small fully associative cache hai.