Visual walkthrough — NUMA architectures

This page rebuilds the parent note's headline result — the NUMA factor and the average-latency formula $t_{avg}=t_{local}[(1-f)+f\cdot F_{NUMA}]$ — starting from a single memory request and a stopwatch. We assume you know nothing except that a processor sometimes needs a number out of memory. Everything else is drawn.

If a word here feels heavy, the parent NUMA architectures note has the wider context; prerequisite ideas about caches and coherence live in memory consistency models and multicore synchronization.

---

Step 1 — What "memory access time" even means

WHAT. A processor is a machine that, many billions of times per second, says "give me the number stored at address $A$." The time between asking and receiving is one memory access. We give that duration a name: $t$, measured in nanoseconds (ns) — billionths of a second.

WHY start here. Every later symbol is built from stopwatch readings. If we never nail down "what are we timing," ratios like $F_{NUMA}$ are meaningless. So the very first object is a single arrow from a core to a memory bank, with a clock on it.

PICTURE. One core, one memory bank, one request travelling out and the data coming back. The green bar is the elapsed time on the stopwatch.

---

Step 2 — Two kinds of request: local and remote

WHAT. In a NUMA machine the memory is chopped into nodes. Each node is a core-group glued to its own nearby memory bank. A request can land in your own node (short trip) or someone else's node (long trip across the interconnect wire). Same operation, two very different distances.

WHY two names. A single symbol $t$ can no longer describe reality, because the same core sees different times depending on where the data sits. The moment one number splits into two outcomes, we must give each outcome its own name — otherwise we cannot compare them.

$t_{local}=\underset{\text{core to its own memory controller}}{\underbrace{t_{proc\to controller}}}+\underset{\text{reading the memory chips}}{\underbrace{t_{DRAM}}}$

• $t_{proc\to controller}$ — the tiny hop from the core to the memory controller sitting in the same node.
• $t_{DRAM}$ — the physical time to pull bits out of the DRAM chips. Unavoidable, same everywhere.

$t_{remote}=\underset{\text{everything above, still happens}}{\underbrace{t_{local}}}+\underset{\text{crossing the wire to another node}}{\underbrace{t_{interconnect}}}$

• $t_{interconnect}$ — the extra toll for leaving your node: onto the interconnect (QPI / Infinity Fabric), across to the far node's controller, and the data's return trip. This term is zero for a local access and positive for a remote one.

PICTURE. Two arrows from the same core: a short green one into its own bank, a long red one across the interconnect into a neighbour's bank. The red arrow is visibly longer — that length is $t_{interconnect}$.

---

Step 3 — Turn "how much slower" into one clean number: $F_{NUMA}$

WHAT. We do not care about raw nanoseconds as much as we care about the ratio: how many times slower is a remote trip than a local one? Divide $t_{remote}$ by $t_{local}$ and give the result a name.

$F_{NUMA}=\frac{t_{remote}}{t_{local}}$

• The bar means divide. We put remote on top and local on the bottom so the answer reads as "remote is this-many times a local access."
• If remote $=$ local, the fraction is $\frac{80}{80}=1$. So $F_{NUMA}=1$ means "no penalty at all" — a plain UMA machine.
• If remote is twice as slow ($160$ vs $80$), $F_{NUMA}=\frac{160}{80}=2$.

WHY a ratio and not a subtraction? We could have written $t_{remote}-t_{local}$, but that is a raw duration tied to one machine's clock speed. A ratio is unit-free — it survives across different machines and lets us say "this box has a NUMA factor of 1.8" as a single portable quality score. That is the exact question we want answered: how bad is remote here?

PICTURE. A number line of latencies with the local mark at $1\times$ and remote marks pushed out to the right; the horizontal gap, expressed as a multiplier, is $F_{NUMA}$.

---

Step 4 — Real programs mix the two: introduce the fraction $f$

WHAT. A running program does millions of accesses. Some hit local memory, some go remote. Let $f$ be the fraction that go remote — a number between $0$ and $1$.

$f=\frac{\text{number of remote accesses}}{\text{total accesses}}$

• $f=0$ → every access is local (perfect locality, the dream).
• $f=1$ → every access is remote (worst case).
• $f=0.2$ → one in five accesses crosses the interconnect (the parent note's 80/20 example: 80% local, so $f=0.2$).

WHY a fraction? Because reality is a mixture, not all-local or all-remote. To predict the time of a whole program we need to know how often each kind happens. A single fraction $f$ captures "how leaky is my locality" in one dial we can turn.

PICTURE. A bar of 100 tick marks; a fraction $f$ of them coloured red (remote), the rest green (local). Slide $f$ and the bar recolours.

---

Step 5 — Averaging: the weighted mean that gives $t_{avg}$

WHAT. If a fraction $(1-f)$ of accesses cost $t_{local}$ and a fraction $f$ cost $t_{remote}$, the typical access time is their weighted average — each cost multiplied by how often it happens, then added:

$t_{avg}=\underset{\text{share that is local}}{\underbrace{(1-f)}}{t}_{local}+\underset{\text{share that is remote}}{\underbrace{f}}{t}_{remote}$

WHY weighting and not a plain average? A plain average $\frac{t_{local}+t_{remote}}{2}$ would pretend the two happen equally often. They don't — you might have 95% local and 5% remote. Weighting each cost by its actual frequency is the only honest way to get the long-run mean.

Now substitute the Step-2 fact $t_{remote}=t_{local}\cdot F_{NUMA}$ (which is just Step 3 rearranged) to collect everything into $t_{local}$:

$t_{avg}=(1-f)t_{local}+f(t_{local}{F}_{NUMA})=t_{local}[(1-f)+f{F}_{NUMA}]$

• $(1-f)$ — the local slice, each paying $1\times$.
• $f{F}_{NUMA}$ — the remote slice, each paying $F_{NUMA}\times$.
• $t_{local}[\dots ]$ — factor $t_{local}$ out front so the bracket is a pure multiplier telling you how many local-latencies an average access costs.

PICTURE. A see-saw / weighted-beam: the local weight at $1\times$ and the remote weight at $F_{NUMA}\times$, with the balance point landing at the value of the bracket.

---

Step 6 — Speedup: how much locality buys you

WHAT. Compare your mixed program to the disaster baseline where every access is remote, $t_{all\_remote}=t_{local}\cdot F_{NUMA}$. The speedup $S$ is how many times faster the mixed program is:

$S=\frac{t_{all\_remote}}{t_{avg}}=\frac{t_{local}{F}_{NUMA}}{t_{local}[(1-f)+f{F}_{NUMA}]}$

The $t_{local}$ on top and bottom cancel (a common factor divides out), leaving a clean, machine-independent expression:

$S=\frac{F_{NUMA}}{(1-f)+f{F}_{NUMA}}$

• Numerator $F_{NUMA}$ — how bad all-remote is.
• Denominator — the bracket from Step 5 — how bad you actually are.
• Big $S$ = your locality effort paid off relative to the worst case.

WHY divide by the all-remote case? Because it isolates the value of locality itself. It answers "compared to a NUMA-oblivious program that flails across the interconnect, how much did keeping data local win me?"

PICTURE. A curve of $S$ versus $f$: at $f=1$ the curve sits at $1\times$ (you are the baseline); as $f\to 0$ it climbs toward $F_{NUMA}$ (all-local is the whole factor faster).

---

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

WHAT & WHY. A formula you trust must survive its extremes. Let's push $f$ and $F_{NUMA}$ to their limits and confirm each answer is sane.

Case	Plug in	Result	Meaning
Perfect UMA ($F_{NUMA}=1$)	$S=\frac{1}{(1-f)+f}$	$S=1$ for any $f$	No penalty exists, so locality can't help — correct.
All local ($f=0$)	$S=\frac{F_{NUMA}}{1+0}$	$S=F_{NUMA}$	You beat the all-remote baseline by the full factor.
All remote ($f=1$)	$S=\frac{F_{NUMA}}{0+F_{NUMA}}$	$S=1$	You are the baseline — no speedup, as expected.
Extreme NUMA ($F_{NUMA}\to \infty$)	$S=\frac{F_{NUMA}}{(1-f)+f{F}_{NUMA}}\to \frac{1}{f}$	$S\to 1/f$	Speedup is capped by your remote fraction — a hard Amdahl-style ceiling.

• The $1/f$ ceiling is the punchline: even an infinitely fast local memory can't rescue you if a fraction $f$ of accesses still crawl across the interconnect. Your remote traffic is the anchor.

PICTURE. The speedup curve again, this time with the $S=1/f$ ceiling drawn as a dashed line the curve presses against as $F_{NUMA}$ grows.

---

The one-picture summary

Everything above, on one canvas: a request splits into local (green, $\times 1$) and remote (red, $\times F_{NUMA}$); the fraction $f$ mixes them on a weighted beam into $t_{avg}$; dividing the all-remote baseline by $t_{avg}$ gives the speedup curve with its $1/f$ ceiling.

Recall Feynman retelling — say it back in plain words

A computer sometimes fetches numbers from memory right next to it (fast) and sometimes from memory in another room across a wire (slow). We time one fetch and call it $t$. Because the same core sees two different times, we split $t$ into $t_{local}$ and $t_{remote}$, where remote is just local plus the toll for crossing the wire. To describe "how much worse remote is" in one portable number we divide them: $F_{NUMA}$. A real program does a mixture, so we track $f$, the share of fetches that go remote. The typical fetch time is the two costs weighted by how often each happens — that weighted average, tidied up, is $t_{avg}=t_{local}[(1-f)+f{F}_{NUMA}]$. Comparing this to a program that goes remote every time gives a speedup $S=F_{NUMA}/[(1-f)+f{F}_{NUMA}]$. Testing the extremes shows it behaves: no penalty means no speedup, all-local means full speedup, and — the key lesson — even infinitely fast local memory caps you at $1/f$. So the whole game is shrinking $f$: keep your data where your thread lives.

Recall Quick self-test

What does $f$ mean, and what value does "80% local" give it? ::: $f$ is the fraction of accesses that are remote; 80% local means $f=0.2$. Why use the ratio $F_{NUMA}$ instead of the difference $t_{remote}-t_{local}$? ::: A ratio is unit-free and portable across machines; a difference is tied to one machine's clock. With $f=0.2$, $F_{NUMA}=2$, what is the speedup? ::: $S=2/(0.8+0.4)=1.67\times$. As $F_{NUMA}\to \infty$, what is the speedup ceiling? ::: $S\to 1/f$ — your remote fraction is the hard limit.