Cache Fundamentals: How Small, Fast Memory Predicts What You Need Next

A cache works because programs tend to access the same or nearby data repeatedly rather than randomly. This article explains the principle of locality that makes caching effective, how a direct-mapped cache locates data using an address, and what happens on a cache hit versus a cache miss.

Cache MemoryLocality of ReferenceDirect-Mapped Cache

~3 min read · Updated Sep 6, 2026

Why Caching Works: The Principle of Locality

A cache is only useful because real programs do not access memory in a purely random pattern. Instead, they exhibit Locality of Reference, which comes in two related forms: Temporal Locality, meaning a recently accessed memory location is likely to be accessed again soon, and Spatial Locality, meaning memory locations near a recently accessed one are also likely to be accessed soon, such as the next elements in an array.

What a Cache Actually Stores

A Cache is a small, fast memory that holds copies of recently used data from main memory, positioned between the processor and main memory in the hierarchy discussed earlier in this series. When the processor requests data already present in the cache, it can be retrieved far faster than fetching it from main memory.

Locating Data: The Direct-Mapped Cache

The simplest cache organization is called a Direct-Mapped Cache, where each memory address maps to exactly one specific location in the cache, determined by a portion of the address bits.

Memory address broken into fields:
[ Tag | Index | Block Offset ]

  • The Index bits select which cache location to check.
  • The Tag bits are stored alongside the data and compared against the requested address to confirm the correct data is present, since multiple different memory addresses can map to the same index.
  • The Block Offset bits select the specific byte within a larger stored block, since caches typically store data in fixed-size chunks rather than single bytes.

Cache Hits and Cache Misses

When the processor requests data and finds it already present in the cache with a matching tag, this is called a Cache Hit, and the data is returned quickly. When the requested data is not found, this is called a Cache Miss, and the processor must retrieve the data from a slower level of the memory hierarchy, then store a copy in the cache for potential future use.

On a cache hit:
Return data immediately from cache

On a cache miss:
Fetch data from main memory
Store a copy in the cache
Return data to the processor

Why Block Size Matters

Because of spatial locality, caches do not store just a single requested byte on a miss; they retrieve and store an entire Block (also called a Cache Line) of nearby memory at once, anticipating that neighboring data will likely be needed soon. Choosing an appropriate block size involves a tradeoff: larger blocks exploit spatial locality more effectively but take longer to transfer on a miss and can waste cache space if the extra data is not actually used.

Why Understanding These Basics Matters

Every more advanced caching topic discussed later in this series — measuring and improving cache performance, more flexible mapping strategies, and multi-level cache hierarchies — builds directly on these core concepts of locality, direct mapping, and the hit/miss distinction introduced here.

Written & researched by Dr. Shahin Siami

Related Articles

The Memory Hierarchy: Why Computers Use Several Kinds of Memory

No single memory technology is simultaneously fast, large, and cheap. This article introduces the concept of a memory hierarchy that combines several different memory technologies to approximate the speed of the fastest one at the cost of the cheapest, then walks through the core technologies that make up each level.

Continue

Common Misconceptions About Processor Design and Chapter Four's Big Picture

After covering datapaths, pipelining, hazards, and real-world processor comparisons, it is time to correct a handful of persistent misconceptions about how processors actually behave. This article addresses common fallacies about pipelining and performance, then ties together the full journey from simple datapaths to superscalar execution covered throughout this chapter.

Continue

Real-World Pipelines: Comparing ARM and Intel, and Speeding Up Matrix Multiply

Theoretical pipeline concepts take concrete shape in real commercial processors, which vary widely in pipeline depth and issue width depending on their design goals. This article compares how the ARM Cortex-A53 and Intel Core i7 implement pipelining differently for power efficiency versus raw performance, then shows how instruction-level parallelism accelerates matrix multiplication in practice.

Continue

Instruction-Level Parallelism: Executing More Than One Instruction at Once

A single pipeline can only advance one instruction into each stage per cycle, which caps its performance at roughly one instruction per clock. This article explains how processors go beyond that limit by issuing multiple instructions simultaneously, the hardware duplication this requires, and the fundamental limits imposed by dependencies between instructions.

Continue

How a Pipelined Processor Handles Exceptions

Not every instruction executes as expected — some trigger error conditions like an undefined opcode or an arithmetic overflow that the processor must respond to safely. This article explains what exceptions are, how a pipelined processor detects and handles them without corrupting program state, and why exceptions are treated similarly to control hazards.

Continue

Control Hazards: Handling Branches in a Pipelined Processor

Branches create a unique problem for pipelining: the processor must fetch the next instruction before it even knows whether a branch will be taken. This article explains what control hazards are, how branch prediction and delayed resolution attempt to minimize their cost, and what happens when a prediction turns out to be wrong.

Continue