# CPU Cache Flushing Fallacy

DevFeed: [CPU Cache Flushing Fallacy](<https://devfeed.tech/articles/cpu-cache-flushing-fallacy-13631.md>)

Original publisher: [Read original article](<https://mechanical-sympathy.blogspot.com/2013/02/cpu-cache-flushing-fallacy.html>)

Author: Martin Thompson (noreply@blogger.com)

Published: 2013-02-14T12:22:00Z

Content type: article

Language: en

Sources: [Mechanical Sympathy](<https://devfeed.tech/sources/mechanical-sympathy.md>)

Topics: [Cache](<https://devfeed.tech/topics/cache.md>), [cpu](<https://devfeed.tech/topics/cpu.md>), [x86](<https://devfeed.tech/topics/x86.md>), [Latency](<https://devfeed.tech/topics/latency.md>), [systems](<https://devfeed.tech/topics/systems.md>), [intel](<https://devfeed.tech/topics/intel.md>)

Tags: [cache-coherence](<https://devfeed.tech/tags/cache-coherence.md>), [core](<https://devfeed.tech/tags/core.md>), [cpu](<https://devfeed.tech/tags/cpu.md>), [cpu-cache](<https://devfeed.tech/tags/cpu-cache.md>), [intel](<https://devfeed.tech/tags/intel.md>), [ipc](<https://devfeed.tech/tags/ipc.md>), [latency](<https://devfeed.tech/tags/latency.md>), [memory-heirarchy](<https://devfeed.tech/tags/memory-heirarchy.md>), [performance](<https://devfeed.tech/tags/performance.md>), [systems](<https://devfeed.tech/tags/systems.md>), [x86](<https://devfeed.tech/tags/x86.md>)

## AI overview

The article explains why describing CPU-cache behavior as a cache "flush" can be misleading. It discusses cache hierarchies, interactions between caches and execution cores, memory latency, cache misses, and cache coherence, using Intel x86 server CPUs as a concrete example.

## Source excerpt

Even from highly experienced technologists I often hear talk about how certain operations cause a CPU cache to "flush". This seems to be illustrating a very common fallacy about how CPU caches work, and how the cache sub-system interacts with the execution cores. In this article I will attempt to explain the function CPU caches fulfil, and how the cores, which execute our programs of instructions, interact with them. For a concrete example I will dive into one of the latest Intel x86 server CPUs. Other CPUs use similar techniques to achieve the same ends. Most modern systems that execute our programs are shared-memory multi-processor systems in design. A shared-memory system has a single memory resource that is accessed by 2 or more independent CPU cores. Latency to main memory is highly variable from 10s to 100s of nanoseconds. Within 100ns it is possible for a 3.0GHz CPU to process up to 1200 instructions. Each Sandy Bridge core is capable of retiring up to 4 instructions-per-cycle (IPC) in parallel. CPUs employ cache sub-systems to hide this latency and allow them to exercise their huge capacity to process instructions. Some of these caches are small, very fast, and local to each core; others are slower, larger, and shared across cores. Together with registers and main-memory, these caches make up our non-persistent memory hierarchy. Next time you are developing an important algorithm, try pondering that a cache-miss is a lost opportunity to have executed ~500 CPU instructions! This is for a single-socket system, on a multi-socket system you can effectively double the lost opportunity as memory requests cross socket interconnects. Memory Hierarchy Figure 1. For the circa 2012 Sandy Bridge E class servers our memory hierarchy can be decomposed as follows: Registers: Within each core are separate register files containing 160 entries for integers and 144 floating point numbers. These registers are accessible within a single cycle and constitute the fastest memory a