CPU caches do not move memory one byte at a time; they transfer and track it in fixed-size aligned blocks called cache lines (commonly 64 bytes on mainstream hardware). What is a cache line, and what consequences does that granularity have for how a program performs?

## What a cache line is A CPU cache is a small fast memory holding recently used pieces of main memory. It does not store variables; it stores fixed-size, naturally aligned blocks of physical memory called **cache lines**. On most current mainstream CPUs a line is 64 bytes; some architectures use 32 or 128, and some prefetch lines in adjacent pairs. Nothing in a programming language promises a size, so portable code treats it as a tunable constant, not a fact. The line is the unit of three different things at once: - **Transfer** — a miss fetches the whole line from the next level or from DRAM. - **Tagging** — the cache stores one tag and one state per line, not per byte. - **Coherence** — when multiple cores cache the same memory, the hardware protocol negotiates ownership at line granularity. ## Why blocks instead of bytes Two reasons. First, **spatial locality**: programs that touch address X usually touch X+1 soon after, so fetching neighbours speculatively is usually free work that pays off. Second, **economics**: DRAM and interconnects are efficient in bursts, and per-byte tags would cost more storage than the data. Larger lines amortise both, at the cost of moving bytes you may never read. ## Consequence 1: locality dominates access cost Rough orders of magnitude on a modern core: an L1 hit is a few cycles, L2 around a dozen, L3 several dozen, DRAM a couple of hundred cycles. A sequential array walk hits memory once per line (16 four-byte elements), and hardware prefetchers recognise the stride and fetch ahead, so most accesses hit L1. A linked structure scattered across the heap pays a potential miss per node and defeats the prefetcher because the next address is only known after the current load returns. Same asymptotic complexity, very different wall-clock time. ## Consequence 2: layout is a performance decision If you iterate over a million records reading a single small field, an array-of-records layout drags every other field through the cache with it; a columnar layout (one array per field) packs only the field you need, so each line delivers 16 useful values instead of one. Similarly, splitting an object into a hot part (fields touched every iteration) and a cold part can multiply effective cache capacity. None of this changes what the program computes — only how many lines it must move. ## Consequence 3: sharing is per line Because coherence state is per line, two threads that write two distinct variables located in the same line are treated by hardware as if they were writing the same thing: the line bounces between the cores' caches. This is **false sharing** — no logical sharing, real hardware contention. The mirror image is **true sharing**, where the variable really is shared. Both are line-level effects, and both are invisible in the source code, which is exactly why they surprise people. ## Consequence 4: alignment and boundaries A value that straddles a line boundary needs two lines and, on some hardware, extra work for atomicity. Allocators typically align larger blocks to line boundaries, but small adjacent allocations frequently share one. That is why deliberate fixes (padding a structure to a full line, or aligning an allocation) are stated in terms of the line size. ## What to say in an interview Define the line as the unit of transfer, tagging and coherence; give the typical 64-byte figure while noting it is hardware-specific; then give one performance consequence for a single thread (locality and prefetching) and one for many threads (sharing is per line, hence false sharing). Finish by saying the practical implications are about **data layout**, which is usually a cheaper lever than changing algorithms.