Impact of CPU Cache on Hardware Benchmarking
CPU cache size and latency play a critical role in hardware benchmarking by dictating how quickly a processor can access the data required to execute instructions. This article examines the structure of the CPU cache hierarchy, explains how cache capacity and access speeds directly alter benchmark scores, and clarifies why different software tests react uniquely to cache variations.
The CPU Cache Hierarchy Explained
To understand benchmark results, you must first understand the proximity and speed of CPU cache compared to main system memory (RAM). Modern processors use a three-tier cache hierarchy:
- L1 Cache: The smallest and fastest memory, split into instruction and data caches. It is located closest to the CPU cores, operating with near-zero latency (typically 1 to 4 clock cycles), but only holds kilobytes of data.
- L2 Cache: Larger than L1 (usually measured in megabytes per core) but slightly slower, taking roughly 10 to 15 clock cycles to access.
- L3 Cache: The largest pool of memory on the chip, often shared across multiple cores. It holds tens or hundreds of megabytes of data, with latencies ranging from 30 to 70 clock cycles.
When the CPU needs data, it checks L1, then L2, and finally L3. Finding the data in the cache is called a "cache hit." If the data is not in the L3 cache, a "cache miss" occurs, forcing the CPU to fetch the data from the system RAM. Accessing RAM takes hundreds of clock cycles, causing the CPU cores to sit idle while waiting for data.
How Cache Size Influences Benchmark Outcomes
The size of each cache level determines the "working set" of data a processor can hold locally. This capacity directly manipulates benchmark scores depending on the footprint of the test being run.
The Cache Fit Phenomenon If a benchmark's active dataset fits entirely within the L3 cache, the processor rarely has to access the slow system RAM. This results in exponentially higher benchmark scores. For example, file compression benchmarks (like 7-Zip) rely heavily on dictionary sizes. A CPU with a massive L3 cache can store the entire lookup table on the chip, yielding a benchmark score that drastically outperforms a CPU with a higher clock speed but smaller cache.
Cache Thrashing Conversely, if a benchmark pushes a dataset that is slightly larger than the CPU's L3 cache, "cache thrashing" occurs. The CPU constantly overwrites old cache data with new data from the RAM. In this scenario, the benchmark is no longer measuring the raw compute power of the CPU cores; it is instead measuring the bandwidth and latency of the system RAM.
The Impact of Cache Latency
While a larger cache holds more data, it physically takes longer to search through a larger pool of memory. Therefore, increasing cache size often increases cache latency. This trade-off heavily influences specific types of benchmarks.
IPC and Single-Threaded Benchmarks Instructions Per Cycle (IPC) is a major factor in single-threaded benchmarks. If a CPU has high L1 or L2 latency, the execution engine stalls while waiting for instructions. Even a delay of two extra clock cycles at the L1 level can reduce a processor's score in latency-sensitive tests, such as code compilation or database querying, by significant margins.
Core-to-Core Communication In modern multi-core processors, the L3 cache is often divided into segments. If a benchmark thread on Core 1 needs data stored in the L3 cache segment located near Core 8, the data must travel across the CPU's internal interconnect. This increases latency. Benchmarks that rely on heavy thread synchronization will score much lower on CPUs with high cross-core L3 latency.
Synthetic vs. Real-World Testing Discrepancies
The interplay between cache size and latency creates major discrepancies between synthetic benchmarks and real-world application tests.
Synthetic Micro-Benchmarks Many synthetic benchmarks use small, repetitive code loops designed to test raw arithmetic or floating-point performance. Because the code is tiny, it fits entirely inside the L1 and L2 caches. Consequently, the CPU achieves a near-100% cache hit rate, producing a theoretical maximum performance score that you will rarely see in daily computing.
Gaming Benchmarks Video games are heavily dependent on L3 cache size and latency. Game engines constantly reuse small batches of data for physics calculations, AI logic, and draw calls. Because this data is erratic and cannot be easily predicted by the CPU, keeping it in a large L3 cache prevents sudden drops in performance. CPUs with massive L3 caches consistently win gaming benchmarks, particularly in "1% low" frame rate metrics, because they eliminate the stutters caused by fetching data from RAM.
Rendering and Encoding Benchmarks Workloads like 3D rendering (e.g., Cinebench) and video encoding stream massive amounts of continuous data that vastly exceed the capacity of any L3 cache. Because the data is only used once and then discarded, a larger cache offers very little benefit. Instead, these benchmarks rely on hardware prefetchers to pull data straight from RAM into the L1/L2 cache just in time to be processed. In these tests, core count and clock speed dictate the final score, rendering L3 cache size mostly irrelevant.