What Is CPU Cache? L1, L2, and L3 Explained

CPU cache is a small amount of very fast memory built into the processor itself, sitting between the cores and your computer's main memory. It exists for one reason: main memory is far slower than the cores that read from it, and without cache, a modern processor would spend most of its life waiting.

It is arranged in levels. L1 is the smallest and fastest, L2 is larger and slower, L3 is larger and slower still, and it is usually shared across all the cores. That trade between size and speed is the whole design.

Why cache exists at all

A processor core can execute several instructions per clock cycle. Fetching a value from main memory takes somewhere in the region of 200 to 300 cycles. If every instruction had to wait that long for its data, the core would sit idle for the overwhelming majority of its time, and buying a faster processor would change almost nothing.

Cache closes that gap by keeping recently used data, and data near it, physically closer to the core. It works because real programs are predictable in two specific ways. They tend to reuse the same data shortly after using it, which engineers call temporal locality. And they tend to use data stored next to data they just used, which is spatial locality. A loop over an array exhibits both.

The three levels

Each level is a compromise between how fast it can answer and how much it can hold. Smaller memory can be placed closer to the core and searched faster, so the hierarchy exists to give you a bit of very fast storage and a lot of reasonably fast storage at the same time.

L1 cache

The smallest and fastest, private to each core, and typically split in two: one half for instructions and one for data. Common sizes in 2026 silicon run from 32KB to 64KB per half, so 64KB to 128KB total per core. Access takes roughly 4 to 5 cycles. When people say a processor "has the data," this is usually the level they mean.

L2 cache

Larger, still usually private to each core, and slower to reach at roughly 12 to 15 cycles. Sizes commonly land between 256KB and 1MB per core. L2 catches what L1 could not hold, which matters for working sets slightly too big for L1 but far too small to justify a trip to main memory.

L3 cache

The largest level and usually shared by every core on the chip, which is what lets cores hand data to each other without going out to memory. Latency climbs to roughly 40 to 50 cycles. Capacity varies enormously: around 8MB on budget parts, and up to 96MB on AMD's 3D V-Cache designs, which stack additional cache vertically on top of the die.

Those latency figures are typical rather than universal. They shift with clock speed, architecture, whether the data is on the same chiplet, and how much contention there is from other cores.

Cache lines, and why they are 64 bytes

Cache does not move individual bytes. It moves fixed-size blocks called cache lines, and on every x86-64 processor that block is 64 bytes. Ask for a single byte and the processor fetches the whole 64-byte line containing it.

This is why walking an array in order is dramatically faster than jumping around it randomly. Sequential access uses all 64 bytes of each line it pulls in. Random access pulls in 64 bytes to use one of them, wasting the rest of the transfer and the cache space it occupies. The same effect explains why the layout of your data structures can matter more to performance than the algorithm operating on them.

Hits, misses, and what actually slows you down

A cache hit means the data was already there. A miss means it was not, and the processor has to look at the next level down, then eventually main memory. Miss rates matter more than raw cache size, because a large cache with poor access patterns still misses constantly.

Three kinds of miss are worth knowing. A compulsory miss happens the first time you touch data, and is unavoidable. A capacity miss happens because your working set is bigger than the cache. A conflict miss happens when several hot addresses map to the same cache location and keep evicting each other, even though the cache has room elsewhere.

Does more cache make a processor faster?

Sometimes, and the size of the effect depends almost entirely on the workload. Games and simulations with working sets that fit into a larger L3 can gain substantially, which is the entire commercial argument for 3D V-Cache parts. Workloads that stream through data once, like video encoding, barely notice, because there is nothing to reuse.

Cache is also not free. It occupies die area that could have been more cores, and it consumes power. A processor with a huge L3 and fewer cores is a deliberate trade, not simply a better chip.

How this relates to GPUs and NPUs

Every processor type faces the same problem, and each solves it differently. GPUs run thousands of threads and hide memory latency by switching to another thread whenever one stalls, so they lean on enormous memory bandwidth more than on deep cache hierarchies. NPUs go further still, using local scratchpad memory and predictable dataflow so that the weights of a neural network layer stay close to the arithmetic units for the duration of the work.

For how those units differ more broadly, see CPUs, GPUs, NPUs, and TPUs compared, and for the AI accelerator specifically, NPU explained.

Frequently asked questions

What is a good amount of CPU cache?

There is no threshold that makes a processor good or bad. Compare cache only between chips you are actually choosing between, in the workload you actually run. For gaming, a larger L3 often helps. For heavily parallel work, more cores usually beat more cache.

Is cache the same as RAM?

No. Both are volatile memory, but cache is built into the processor from SRAM, measured in kilobytes and megabytes, and reached in a handful of cycles. Main memory is separate DRAM, measured in gigabytes, and reached in hundreds of cycles. Cache is not something you can add or upgrade.

Can I upgrade or increase my CPU cache?

No. It is physically part of the processor die. The only way to change it is to change the processor.

What is cache thrashing?

Repeatedly evicting data you are about to need again, so the cache stays busy without ever helping. It typically comes from a working set slightly larger than the cache, or from an access pattern that keeps mapping to the same cache locations. It shows up as performance that falls off a cliff at a particular input size rather than degrading smoothly.

How much faster is L1 than L3?

Roughly ten times, in latency terms: about 4 to 5 cycles for L1 against 40 to 50 for L3. Main memory is slower again by a wide margin, in the region of 200 to 300 cycles. Each step down the hierarchy costs roughly an order of magnitude.