Write-through vs write-back: Visual walkthrough — Hinglish deep dive

5.4.6 · D2 · Hardware › Memory Hierarchy & Caches › Write-through vs write-back

Hum parent note se deeper ja rahe hain. Agar aapne pehle kabhi cache nahi dekha, toh pehle 5.4.01-CacheFundamentals padho — lekin aapko strictly zaroorat nahi hai, kyunki hum yahan har idea rebuild karte hain.

Step 1 — "Memory mein likhne" ka actually kya cost hai

KYA. Do boxes stacked ek doosre ke upar imagine karo. Upar wala box hai cache: ek tiny, blazing-fast notebook jo CPU ke bilkul paas rakhi hai. Neeche wala box hai main memory (DRAM — dekho 5.3.02-DRAM-Architecture): ek badi, slow warehouse jo door hai.

KYUN. Pehle policies compare karne se pehle, hum ek physical fact pe agree karna chahte hain jis par sab kuch depend karta hai: dono boxes ko likhne mein wildly alag time lagta hai.

PICTURE. Figure mein, cache mein jaane wala arrow chhota hai (ek quick pen-flick). Memory mein jaane wala arrow lamba hai (ek delivery truck). Hum in dono times ko naam dete hain:

$T_{m} ≫ T_{c}$

Symbol $≫$ ko padho "is enormously bigger than." Yahan $T_{m} / T_{c} = 100$ , toh ek memory write time mein ek sau cache writes ke barabar hai. Woh ratio yaad rakho — yahi poori story ka hero hai.

Step 2 — Write-through: har baar truck ka payment karo

KYA. Write-through policy mein, har baar jab CPU likhta hai, hum cache aur memory dono update karte hain — seedha memory tak. Dono boxes, hamesha.

KYUN. Yeh dono boxes ko har waqt identical rakhta hai — memory kabhi stale nahi hoti. Yahi write-through ka poora point hai. Lekin safety ka ek price hai, aur picture woh dikhati hai.

PICTURE. Har pen-flick cache mein memory tak jaane wale ek truck se chained hai. Truck ride ( $T_{m}$ ) itni lambi hai ki uske paas tiny pen-flick ( $T_{c}$ ) invisible lag rahi hai.

Step 3 — Write-back: pen-flick ka payment karo, yaad rakho ki truck ka bhi baqaya hai

KYA. Write-back mein, ek write sirf cache ko update karta hai. Phir hum us cache line par ek single flag flip karte hain — dirty bit — 0 se 1 mein, matlab "yeh line ab memory se disagree karti hai; mujhe memory ko update karna baaki hai."

KYUN. Abhi truck bhejne ka matlab hai expensive part. Toh hum nahi bhejte. Sirf ek note-to-self scribble karte hain ("dirty!") aur aage badhte hain. CPU $T_{c}$ mein unblocked ho jaata hai.

PICTURE. Cache mein wohi pen-flick — lekin koi truck nahi. Bajaaye uske, line par ek chhota sa flag pop up hota hai.

Ek single write ke liye immediate speedup: $Speedup_{one write} = \frac{T _{WT}}{T _{WB}} = \frac{T _{m}}{T _{c}} = \frac{100}{1} = 100 \times$

Step 4 — Lekin udhaar chukana padega: eviction

KYA. Cache chhota hota hai. Aakhirkar jo line hum pe scribble kar rahe the use doosre data ke liye jagah banana ke liye bahar nikalna padega (yeh "bahar nikalna" ek replacement policy se choose hota hai). Woh moment eviction kehlaata hai.

KYUN. Humne memory write defer ki thi — lekin cancel nahi ki. Eviction par, agar dirty bit 1 hai, toh hum finally truck bhejte hain. Yahan write-back woh "wapas karta hai" jo usne borrow kiya tha.

PICTURE. Line cache se nikalti hai. Kyunki uska flag $D = 1$ kehta hai, ek truck memory ki taraf rowaana hota hai poori line lekar. Agar flag $D = 0$ kehta, toh line simply erase ho jaati — koi truck nahi, free.

Toh write-back ek $T_{m}$ pay karta hai har dirty line ke liye, chahe kitni baar bhi woh line cache mein rehte hue likhi gayi ho. Woh "chahe kitni baar bhi" wahi amortization hai jise hum dhundh rahe hain.

Step 5 — Head-to-head race: ek line par $n$ writes

KYA. Ab hum fair experiment set up karte hain. Maano CPU ek hi cache line par $n$ baar row mein likhta hai, phir woh line evict ho jaati hai. Har policy ka total time dekhte hain.

KYUN. Yahi exactly "temporal locality" pattern hai — ek spot ko baar baar hammer karna (ek loop counter, ek running sum). Yahan dono policies sabse zyaada diverge karti hain, toh yeh sabse saaf jagah hai jeet dekhne ki.

PICTURE. Do timelines stacked. Write-through: row mein $n$ full trucks. Write-back: $n$ tiny flicks, phir bilkul ant mein ek truck.

T_{WT} (n) T_{WB} (n) = n \cdot (T_{c} + T_{m}) \approx n T_{m} = n flicks n T_{c} + one eviction truck T_{m}

Write-back ke liye term by term: $n T_{c}$ saari sasti in-cache writes hain; akela $T_{m}$ woh single truck hai jab line finally nikalti hai.

Step 6 — Timelines divide karo: speedup formula

KYA. Write-through ka total write-back ke total se divide karo.

KYUN. Ek ratio units hata deta hai aur humein batata hai ki write-back $n$ ke function ke roop mein kitne factor se jeetta hai.

Speedup (n) = \frac{T _{WT} ( n )}{T _{WB} ( n )} = \frac{n T _{m}}{n T _{c} + T _{m}}

Is fraction ko ek machine ki tarah padho jo $n$ ke saath badhti hai:

Upar $n T_{m}$ : write-through ki cost linearly badhti hai — har write ek fresh truck hai.
Neeche $n T_{c} + T_{m}$ : write-back ki cost slowly badhti hai, kyunki $T_{c}$ tiny hai aur $+ T_{m}$ ek one-time constant hai.

Plug in karo $T_{m} = 100, T_{c} = 1, n = 1000$ :

Speedup (1000) = \frac{1000 \cdot 100}{1000 \cdot 1 + 100} = \frac{100000}{1100} \approx 91 \times

Yahi exactly parent note ka $91 \times$ hai — ab kuch bhi assume kiye bina build kiya gaya.

Step 7 — Limiting cases (reader ko kabhi stranded mat chhodo)

KYA. Ek formula jis par aap trust karo use apni extremes survive karni chahiye. Hum $n$ ko uske edges tak push karte hain.

KYUN. Edge cases wahan hain jahan galat intuitions chhup jaati hain. Chalte hain sab dekhte hain.

Case $n = 1$ (ek baar likho, phir evict). Bilkul koi reuse nahi. $Speedup (1) = \frac{1 \cdot 100}{1 \cdot 1 + 100} = \frac{100}{101} \approx 0.99$ 1 se thoda neeche — ek tie. Write-back ne ek flick ( $T_{c}$ ) phir ek truck ( $T_{m}$ ) pay kiya; write-through ne ek truck pay kiya. Isliye "write-back hamesha faster hai" galat hai — koi reuse nahi toh amortize karne ke liye kuch nahi.

Case $n \to \infty$ (ek hi spot hamesha ke liye likho). $lim_{n \to \infty} \frac{n T _{m}}{n T _{c} + T _{m}} = \frac{T _{m}}{T _{c}} = 100$ Denominator mein $+ T_{m}$ negligible ho jaata hai, aur ceiling exactly hamara Step-1 ratio $T_{m} / T_{c} = 100$ hai. Write-back yahan $100 \times$ se better nahi ho sakta — woh hard ceiling memory/cache speed gap se set hoti hai.

Case dirty bit $D = 0$ eviction par (humne line sirf read ki, kabhi likha nahi). Write-back koi truck nahi bhejta — cost 0. Write-through ne bhi memory touch nahi ki (reads nahi karte). Toh dono free hain; koi difference nahi. Write-back ka faida sirf write-side phenomenon hai.

Degenerate case: kaafi alag lines, har ek ek baar likhi gayi (streaming, zero locality). Har line ek baar dirty hoti hai, toh write-back $T_{c} + T_{m}$ per line pay karta hai — write-through ke $\approx T_{m}$ per line ke identical. Phir tie. Yahi streaming pattern hai jahan ek no-write-allocate design ya plain write buffer utna hi accha hai.

Ek-picture summary

Poori story ek curve hai: Speedup vs. reuse $n$ , $n = 1$ par tie se shuru hokar $100 \times$ ki ceiling tak jaata hai.

Recall Feynman retelling — ise zor se bolo

Cache ek fast pocket notebook hai; memory sheher ke doosri taraf ek slow warehouse hai. Har baar jab tum ek number change karte ho tum could warehouse tak ek truck bhej sakte ho (yahi write-through hai — hamesha correct, hamesha slow). Ya tum sirf apni pocket mein number fix kar sakte ho aur page par ek "mujhe update bhejna hai" flag laga sakte ho (yahi write-back hai). Tum kabhi sirf ek truck bhejte ho — jab page finally tumhari notebook se nikala jaata hai, aur sirf tab jab flag upar ho. Agar tumne us page par hazaar baar scribble kiya, tumne 999 truck trips bachaaye. Agar tumne page ko sirf ek baar touch kiya, tumne kuch nahi bachaaya — same truck waise bhi. Aur chahe tum kitna bhi reuse karo, tum pocket aur warehouse ke beech raw speed gap se better kabhi nahi kar sakte, jo 100 to 1 hai. Woh ceiling, aur woh tie-at-one, do cheezein hain jo log bhool jaate hain.

Recall Quick self-check

Kaunsa single fact write-back ko kaafi writes par fast banata hai? ::: Tum zyada se zyada ek memory write (truck) per line bhejte ho, chahe kitni bhi cache writes us par hui hon — dirty bit ek baar debt record karta hai. Write-back kab write-through se faster nahi hota? ::: Jab koi reuse nahi hota ( $n = 1$ , ya kaafi distinct lines har ek ek baar likhi gayi) — amortize karne ke liye kuch nahi, toh tie hai. Maximum possible speedup kya set karta hai? ::: Ratio $T_{m} / T_{c}$ (memory write time over cache write time), yahan $100/1 = 100 \times$ .

Yeh kahan le jaata hai: write-back ka "delayed truck" exactly wahi cheez hai jo multi-core life hard banati hai — doosra core stale memory read kar sakta hai. Woh problem 5.4.07-Cache-Coherence mein solve hoti hai aur 6.2.03-Memory-ConsistencyModels mein formalize hoti hai.

🇮🇳 Hinglish version of the parent: 5.4.06 Write-through vs write-back (Hinglish)