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

We are going deeper than the parent note. If you have never seen a cache before, read 5.4.01-CacheFundamentals first — but you do not strictly need it, because we rebuild every idea here.

Step 1 — What "writing to memory" actually costs

WHAT. Picture two boxes stacked on top of each other. The top box is the cache: a tiny, blazing-fast notebook sitting right next to the CPU. The bottom box is main memory (DRAM — see 5.3.02-DRAM-Architecture): a huge, slow warehouse far away.

WHY. Before we can compare policies, we must agree on the one physical fact everything depends on: the two boxes take wildly different times to write.

PICTURE. In the figure, the arrow into the cache is short (a quick flick of the pen). The arrow into memory is long (a delivery truck). We name these two times:

$T_{m} ≫ T_{c}$

Read the symbol $≫$ as "is enormously bigger than." Here $T_{m} / T_{c} = 100$ , so a memory write is worth one hundred cache writes in time. Hold onto that ratio — it is the hero of the whole story.

Step 2 — Write-through: pay the truck every single time

WHAT. In the write-through policy, every time the CPU writes, we update the cache and send the value all the way to memory. Both boxes, always.

WHY. This keeps the two boxes identical at every instant — memory is never stale. That safety is the whole point of write-through. But safety has a price, and the picture shows it.

PICTURE. Every pen-flick into the cache is chained to a truck to memory. The truck ride ( $T_{m}$ ) is so long that the tiny pen-flick ( $T_{c}$ ) beside it is invisible.

Step 3 — Write-back: pay the pen-flick, remember you owe the truck

WHAT. In write-back, a write updates only the cache. Then we flip a single flag on that cache line — the dirty bit — from 0 to 1, meaning "this line now disagrees with memory; I owe memory an update."

WHY. Sending the truck right now is the expensive part. So we don't. We just scribble a note-to-self ("dirty!") and carry on. The CPU is unblocked in $T_{c}$ .

PICTURE. Same pen-flick into the cache — but no truck. Instead a little flag pops up on the line.

Immediate speedup for a single write: $Speedup_{one write} = \frac{T _{WT}}{T _{WB}} = \frac{T _{m}}{T _{c}} = \frac{100}{1} = 100 \times$

Step 4 — But the debt comes due: eviction

WHAT. A cache is small. Eventually the line we've been scribbling on must be kicked out to make room for other data (this "kicking out" is chosen by a replacement policy). That moment is called eviction.

WHY. We deferred the memory write — but we never cancelled it. On eviction, if the dirty bit is 1, we finally send the truck. This is where write-back "pays back" what it borrowed.

PICTURE. The line leaves the cache. Because its flag says $D = 1$ , one truck departs to memory carrying the whole line. If the flag had said $D = 0$ , the line is simply erased — no truck, free.

So write-back pays one $T_{m}$ per dirty line, no matter how many times that line was written while it lived in the cache. That "no matter how many times" is the amortization we are chasing.

Step 5 — The head-to-head race: $n$ writes to one line

WHAT. Now we set up the fair experiment. Suppose the CPU writes to the same cache line $n$ times in a row, then that line is evicted. Let's total each policy's time.

WHY. This is exactly the "temporal locality" pattern — hammering one spot repeatedly (a loop counter, a running sum). It's where the two policies diverge the most, so it's the cleanest place to see the win.

PICTURE. Two timelines stacked. Write-through: $n$ full trucks in a row. Write-back: $n$ tiny flicks, then one truck at the very end.

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}

Term by term for write-back: $n T_{c}$ is all the cheap in-cache writes; the lone $T_{m}$ is the single truck when the line finally leaves.

Step 6 — Divide the timelines: the speedup formula

WHAT. Divide write-through's total by write-back's total.

WHY. A ratio strips away the units and tells us the factor by which write-back wins as a function of $n$ .

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

Let's read this fraction as a machine that grows with $n$ :

Top $n T_{m}$ : write-through's cost grows linearly — every write is a fresh truck.
Bottom $n T_{c} + T_{m}$ : write-back's cost grows slowly, because $T_{c}$ is tiny and the $+ T_{m}$ is a one-time constant.

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

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

This is exactly the parent note's $91 \times$ — now built from nothing.

Step 7 — The limiting cases (never leave the reader stranded)

WHAT. A formula you trust must survive its extremes. We push $n$ to its edges.

WHY. Edge cases are where mistaken intuitions hide. Let's see all of them.

Case $n = 1$ (write once, then evicted). No reuse at all. $Speedup (1) = \frac{1 \cdot 100}{1 \cdot 1 + 100} = \frac{100}{101} \approx 0.99$ Barely below 1 — a tie. Write-back paid one flick ( $T_{c}$ ) then one truck ( $T_{m}$ ); write-through paid one truck. This is why "write-back is always faster" is false — with no reuse there is nothing to amortize.

Case $n \to \infty$ (write the same spot forever). $lim_{n \to \infty} \frac{n T _{m}}{n T _{c} + T _{m}} = \frac{T _{m}}{T _{c}} = 100$ The $+ T_{m}$ in the denominator becomes negligible, and the ceiling is exactly our Step-1 ratio $T_{m} / T_{c} = 100$ . Write-back can never beat 100× here — that hard ceiling is set by the memory/cache speed gap.

Case dirty bit $D = 0$ at eviction (we only read the line, never wrote it). Write-back sends no truck — cost 0. Write-through never touched memory either (reads don't). So both are free; no difference. Writeback's advantage is a write-side phenomenon only.

Degenerate case: many different lines, each written once (streaming, zero locality). Every line is dirty-once, so write-back pays $T_{c} + T_{m}$ per line — identical to write-through's $\approx T_{m}$ per line. Tie again. This is the streaming pattern where a no-write-allocate design or a plain write buffer is just as good.

The one-picture summary

The whole story is one curve: Speedup vs. reuse $n$ , riding from a tie at $n = 1$ up to the ceiling of $100 \times$ .

Recall Feynman retelling — say it out loud

The cache is a fast pocket notebook; memory is a slow warehouse across town. Every time you change a number you could send a truck to the warehouse (that's write-through — always correct, always slow). Or you could just fix the number in your pocket and stick a "I owe an update" flag on the page (that's write-back). You only ever send one truck — when the page finally gets torn out of your notebook, and only if the flag is up. If you scribbled on that page a thousand times, you saved 999 truck trips. If you touched the page just once, you saved nothing — same truck either way. And no matter how much you reuse it, you can never do better than the raw speed gap between pocket and warehouse, which is 100 to 1. That ceiling, and that tie-at-one, are the two things people forget.

Recall Quick self-check

What single fact makes write-back fast on many writes? ::: You send at most one memory write (truck) per line, no matter how many cache writes happened to it — the dirty bit records the debt once. When is write-back not faster than write-through? ::: When there is no reuse ( $n = 1$ , or many distinct lines each written once) — nothing to amortize, so it's a tie. What sets the maximum possible speedup? ::: The ratio $T_{m} / T_{c}$ (memory write time over cache write time), here $100/1 = 100 \times$ .

Where this leads: the "delayed truck" of write-back is exactly what makes multi-core life hard — another core might read stale memory. That problem is solved in 5.4.07-Cache-Coherence and formalized in 6.2.03-Memory-ConsistencyModels.

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