缓存基础：为什么CPU缓存这么重要？从冯诺依曼瓶颈说起

做算子融合优化这么多年，我经常被问到同一个问题：「为什么非要搞算子融合？直接写代码不就行了？」

嗯，这个问题背后，其实藏着一个计算机体系结构里最经典的矛盾——冯诺依曼瓶颈。说白了，就是CPU算得飞快，但内存跟不上。你想想看，CPU的主频已经跑到几GHz，而内存的访问延迟还在几十纳秒级别。这中间的差距，就像高铁和牛车的速度差。

冯诺依曼瓶颈：CPU在等数据

冯诺依曼架构的核心是「存储程序」——指令和数据放在同一块内存里，CPU一条条取出来执行。这个设计本身没问题，问题出在内存访问速度上。

我举个例子。假设CPU执行一条加法指令，只需要0.3纳秒。但要从内存里把操作数取出来，可能要花50纳秒。也就是说，CPU有99%的时间在干等。这就是所谓的「内存墙」。

看到这个差距了吗？从主存读一次数据，CPU可以执行160多条指令。这还只是单次访问。要是循环里反复读内存，性能直接崩盘。

缓存：离CPU更近的「小仓库」

为了解决这个瓶颈，硬件工程师想了个办法——在CPU和内存之间加一层缓存。缓存容量小，但速度极快。它把最近用过的数据存起来，下次CPU再要，直接从缓存拿，不用去慢吞吞的内存。

我个人习惯把缓存理解成「工作台」。你写代码时，常用的工具放在手边，不常用的放抽屉里。缓存就是这个手边的工作台。

缓存能生效，靠的是两个原理：

• 时间局部性：刚用过的数据，很可能马上再用。比如循环里的变量。
• 空间局部性：刚用过的数据附近的数据，很可能也会用到。比如数组的连续访问。

我在项目中遇到过一个问题：一个矩阵乘法，按行遍历比按列遍历快了好几倍。原因就是按行遍历利用了空间局部性，缓存命中率高；按列遍历则跳来跳去，缓存频繁失效。

缓存行：数据搬运的最小单位

缓存不是按字节搬运的，而是按缓存行（cache line）搬运。x86架构下，一个缓存行通常是64字节。也就是说，你读一个4字节的int，CPU会把相邻的60字节也一起搬进缓存。

这有什么影响？你想想看，如果你写代码时，数据是连续存放的，那一次缓存行搬运就能覆盖后续多次访问。但如果你把数据打散存放，每次访问都要重新搬一个缓存行，效率自然低。

缓存未命中：性能杀手

缓存未命中分三种：

1. 强制未命中：第一次访问某个数据，缓存里肯定没有。不可避免。
2. 容量未命中：缓存太小，装不下所有需要的数据。数据被挤出去，再访问时又得重新加载。
3. 冲突未命中：多个数据映射到同一个缓存位置，互相踢来踢去。

算子融合主要解决的是容量未命中和冲突未命中。举个例子，两个独立的算子，各自要读一遍数据。如果分开执行，数据在缓存里进进出出，浪费大量带宽。融合之后，数据只读一次，在缓存里完成所有计算，再写回去。

知识体系：缓存与算子融合的关系

下面这张图，是我梳理的缓存与算子融合的核心逻辑。你看一眼就明白了。

从图里能清楚看到：冯诺依曼瓶颈催生了缓存，缓存命中与否直接影响性能，而算子融合正是通过减少数据搬运次数来提升缓存命中率。

为什么算子融合能提升缓存命中率？

传统做法是「算子分离」——每个算子独立遍历数据。比如一个图像处理流水线：

// 分离版本：两次遍历
for (int i = 0; i < N; i++) {
    out1[i] = op1(in[i]);   // 第一次遍历
}
for (int i = 0; i < N; i++) {
    out2[i] = op2(out1[i]); // 第二次遍历
}

这个写法，第一次遍历把数据从内存读到缓存，算完写回去。第二次遍历又得重新读。数据量大时，缓存根本装不下，每次都要从内存重新加载。

融合之后：

// 融合版本：一次遍历
for (int i = 0; i < N; i++) {
    float tmp = op1(in[i]);
    out[i] = op2(tmp);      // 一次遍历完成两个算子
}

数据只读一次，在缓存里完成所有计算，再写回去。缓存命中率自然高。

小结

缓存是解决冯诺依曼瓶颈的关键。算子融合的核心思路，就是让数据在缓存里多待一会儿，少去内存里折腾。你想想看，一次缓存命中只要1纳秒，一次内存访问要50纳秒。融合之后，命中率从30%提到90%，性能翻几倍是很正常的事。

下一章，我会深入讲缓存行对齐和伪共享问题。这两个坑，我在项目里踩过不止一次。