1. 缓存优化的整体思路与设计拆解1.1 为什么六成高性能应用都卡在缓存上先说一个我自己的判断高性能计算领域超过六成应用性能上不去根本不是算法复杂度的问题而是数据搬运的速度跟不上计算速度。CPU动辄几十核甚至上百核每秒能执行几十亿次运算但内存的访问延迟还在百纳秒级别SSD更是在微秒级别。算力和数据供给之间这条鸿沟全靠缓存来弥合。所以缓存Cache的命中率基本决定了你的程序是跑在CPU峰值算力上还是在等数据的路上干耗。很多开发者习惯把性能优化等同于优化循环、减少乘除运算或者调整编译器参数。但如果你把一个复杂运算的内循环跑一遍用性能分析工具看一眼大概率会发现最耗时的并不是计算指令而是加载数据、等待数据返回的那段时间。CPU的流水线为了等一个缓存未命中Cache Miss可能需要停顿几十个周期如果内层循环频繁访问的数据没有在缓存里那整个循环的耗时会被拉长好几倍。这也是这篇分享想解决的问题。缓存优化听起来门槛高但它有一套相当固定的方法论从理解硬件的缓存层级出发识别你的程序访存模式哪里不友好然后用数据布局调整、访问顺序调整、并行粒度调整这些手段去匹配硬件特性。这套方法论不太依赖具体业务图像处理、科学计算、数据库引擎还是推荐系统优化思路都差不多。适合看这篇文章的人我猜是这样几类写数值计算或者图像算法的工程师发现自己程序CPU占用很高但速度上不去的做后台服务、需要支撑高并发低延迟接口的开发者还有刚接触高性能计算的研究生想系统了解性能优化到底在优化什么。这篇文章不涉及太底层的汇编级优化但会把缓存优化的核心思路和实操手段讲透让你拿到自己的项目里能上手、能见效。1.2 从访存路径看懂缓存的三个层级要优化缓存得先搞清楚数据从硬盘到CPU寄存器要经过多少道关卡。处理器内部一般有三级缓存L1缓存最靠近计算核心通常分成指令缓存和数据缓存容量最小的只有几十KB但访问延迟在1纳秒左右几乎是零等待L2缓存是每个核心私有的容量在几百KB到几MB之间延迟也就几个纳秒L3缓存是多个核心共享的容量从几MB到几十MB不等延迟在几十纳秒。如果数据在L1里CPU几乎不需要等待在L2里等几个周期在L3里可能要等几十个周期如果L3都没命中就得去内存里取这就是上百纳秒的开销了。我之前给一个模拟类项目做优化时做过一次估算数据从内存加载进CPU寄存器这个过程比CPU执行一条浮点运算指令要慢两个数量级。换句话说如果你的程序每个数组元素只用一次就丢掉那么绝大部分时间都是在做数据搬运真正有用的计算只占很小比例。这个层级关系里有一个特别关键的点就是缓存行Cache Line。CPU读写缓存不是按单个字节操作的而是按固定大小的块来读x86架构下通常是64字节。这意味着你访问一个4字节的整数CPU实际上会把包含这个整数的64字节一并载入缓存。这是缓存优化的一个原点如果一段程序访问的数据在内存地址上是挨着的那么一次缓存行加载就能喂饱后面好几轮计算这是“空间局部性”发挥作用的物理基础。理解了这个机制你就明白了缓存优化的本质其实是把程序的访存行为尽量切成和缓存行大小匹配的块并让这些块在被计算之前就已经预载到合适的缓存层级里。1.3 优化目标让时间局部性和空间局部性同时生效内存访问有两个局部性原则一个叫时间局部性同一个地址的数据如果短时间内被多次访问它可以一直留在缓存里不用每次去内存搬另一个叫空间局部性如果程序访问了某个地址那么它周围的数据大概率马上也会被用到所以加载的时候把周围的数据一起搬进来是划算的。但实际代码里这两个局部性经常打架。举个例子处理一个很大的二维矩阵做转置如果外层循环按行遍历、内层按列遍历或者反过来总有一种访问方式会让内存跳来跳去每次取一个元素都要新载入一个缓存行前面的数据全被浪费了。这就是典型的缓存命中率低下场景。我当时优化一个跨平台系统的图像处理模块时就遇到过类似问题。一张百万像素的灰度图做卷积滤波按最直观的写法每次取像素都要访问相邻好几行如果顺序不对频繁换行会让缓存行反复被替换性能比预期慢三倍。后来通过调整循环的遍历顺序让每个缓存行加载的数据尽可能被多个卷积窗口复用性能立刻上来了。所以优化目标不是单纯减少指令条数而是让CPU取数据这件事尽量发生在缓存里。怎么衡量这个目标最直观的指标是缓存命中率可以从硬件计数器里直接读出来。一般来说L1数据缓存命中率上了95%程序的访存效率才算基本合格如果低于90%优化空间非常大。L2、L3缓存的命中率结合访存带宽一起看L3命中率如果长期低于50%说明你的数据集规模可能远超缓存容量需要换一种切分数据的策略。2. 核心细节解析与实操要点2.1 缓存行64字节才是王道别和编译器对着干缓存行这个概念值得反复强调因为几乎所有缓存优化的技巧最后都要落到“凑满64字节”和“别跨64字节边界”这两件事上。先解释下为什么缓存行大小这么关键。每次未命中加载CPU要把完整的一个缓存行从内存搬到缓存。如果你设计的结构体大小不是缓存行整倍数或者结构体成员顺序安排不合理那么一个结构体对象可能会横跨两个缓存行。访问一个对象要等两个缓存行都加载完这等于缓存未命中的罚时翻倍。数据被频繁访问的场景里这种浪费非常可观。我见过一段处理粒子模拟的程序每个粒子结构体定义成一串字段坐标三个double、质量一个double、速度三个float、还有一些标志位。看起来挺合理但算一下大小三个double是24字节、一个double是8字节、三个float是12字节、标志位算4字节加起来48字节恰好接近64字节缓存行。问题是字段分布不均匀经常导致一个粒子横跨两个缓存行。后来调整了字段排列把flag和数据分开每个粒子都对齐到64字节的整数倍边界访问效率明显上升。具体操作上可以用alignas(64)让结构体按64字节对齐或者把结构体里高频访问的字段集中放在前面低频和偶发的字段放一起。低耦合的热数据堆在一起既能凑满一个缓存行又避免无关字段污染高命中率的缓存区域。另外一个常见的坑是数组元素大小和缓存行不匹配。比如一个数组的每个元素是32字节你在循环里按步长访问每隔一个元素取一次那么每次取数据都要跨两个缓存行效率极低。这种场景要么改数组元素类型把两个成员打包成一个64字节的结构体要么改成连续内存块切片访问让每个缓存行的数据都被用足。2.2 循环怎么写缓存命中率差三倍循环是缓存优化的主战场因为绝大多数计算密集逻辑都集中在循环体内。循环的写法决定了访存顺序访存顺序决定了空间局部性好坏。这里有几个核心原则我逐个说。第一内层循环遍历的方向要和内存中数据的存放顺序保持一致。C/C里二维数组按行优先存储也就是a[i][j]的j相邻元素在内存里也是相邻的。那么循环应该是外层i、内层j这样内存访问是连续的顺便把整行都拉进缓存。反过来如果外层j、内层i每次取一个元素都要跳一行缓存行基本全部浪费。第二循环分块Loop Blocking/Tiling。如果数据集特别大比如矩阵有几千乘几千整个矩阵塞不进L2甚至L3缓存那就要用分块策略。把矩阵切分成多个小方块让每个小方块的大小能匹配L2缓存容量然后一块一块地处理。这样每一块被加载到缓存之后后续的多次计算都在这块数据上完成时间局部性也上来了。矩阵乘法里经典的分块优化就是把普通的三重循环改成六重循环多了两个分块维度分块大小一般取32×32或64×64具体要测L2缓存容量来定。第三合理利用编译器自动向量化。现代编译器支持自动生成SIMD向量指令但前提是循环内访存连续、数据对齐、没有复杂分支。我写循环的时候会刻意保持循环体简单避免在循环里写if判断尽量把分支提到循环外。像if (x[i] threshold) y[i] 1; else y[i] 0;这种循环我会改写成一个查表或者用掩码操作因为分支的跳转会让向量化和预取失效。第四循环展开Loop Unrolling。将循环体复制多份减少循环控制语句对指令流水线的打断。但盲目展开不一定是好事展开过度会增加代码体积、挤占指令缓存L1I反而可能更慢。我的经验是一般展开4倍或8倍然后结合流水线压满的实际效果测试展开后指令级并行度更高数据加载和运算指令能重叠执行。写循环贴一个最典型的示例// 普通写法矩阵按行存储如果内层按列访问慢 for (int i 0; i N; i) { for (int j 0; j N; j) { sum a[j][i]; // 内层按列访问a[0][i]、a[1][i]、a[2][i] 每次跳一行 } }改成行优先连续访问for (int i 0; i N; i) { for (int j 0; j N; j) { sum a[i][j]; // 按行连续缓存友好 } }这两种写法在矩阵特别大的时候性能差距可以到3到5倍。别不信我实际测试过当矩阵超过L2缓存容量后列优先访问的缓存未命中率会飙到80%以上而连续访问的命中率能保持在90%以上。2.3 数据对齐与填充小心伪共享这个隐形杀手多核并行场景里缓存优化还藏着一个特别容易踩的坑叫伪共享False Sharing。它的本质是两个不同核心上的线程各自主宰一个变量正常情况下各管各的互不干扰。但如果这两个变量恰好落在同一个64字节缓存行里情况就变了。核心0修改了它的变量这个缓存行被标记为脏数据硬件为了保证缓存一致性要把整个缓存行同步给核心1。核心1发现自己这个缓存行被更新了哪怕它关心的那个变量根本没变也得等缓存行重新加载。两个核心频繁互相通知、互相等待性能急剧下降但表面上看谁都没有共享同一个变量。伪共享在高性能计算里太常见了。我之前为一个并行计算框架调优时设计了一个线程任务队列每个线程有一个工作状态字段放在一个结构体数组里。因为结构体很小恰好几个线程的状态字段挤在一个缓存行里导致两个线程一前一后更新状态时互相拖累三个线程并行比单线程还慢。排查了很久才发现是伪共享。解决办法很简单填充Padding和对齐。确保每个线程高频更新的变量独占一个缓存行。最粗暴的做法是给每个变量后面加填充字节让结构体占用64字节的整数倍struct ThreadStatus { int flag; char padding[60]; // 让整个结构体占用64字节独占一个缓存行 };或者直接用alignas(64)对齐结构体再配合编译器将不同线程的变量分配到独立缓存行上。这种技巧在并行算法里非常关键特别是任务队列、计数器、状态标记这种多个线程频繁读写的场景。填充也有副作用就是浪费内存。如果你的并行线程数很少浪费几十个字节问题不大但如果数据结构特别大、线程特别多填充会导致缓存行利用率下降。这种情况下可以考虑把每个线程的状态收集到一个局部变量里最后统一合并而不是让每个线程一直在公共区域刷标记。2.4 预取让数据提前到站而不是临时抱佛脚现代CPU都支持硬件预取器也就是CPU预测程序即将访问的地址提前把数据加载进缓存。硬件预取的覆盖面有限它主要识别固定步长的连续访问模式。如果程序访问模式不规则比如链表跳转、索引数组访问硬件预取就失效了可以人为插入预取指令。x86架构下有prefetcht0、prefetchnta这类指令C语言下可以通过编译器内置函数来触发比如GCC的__builtin_prefetch。用法是先计算后面几轮循环要访问的地址提前发出预取请求等循环真正执行到那里时数据已经在缓存里了。我整理过一套预取的使用原则分享下预取的距离要适中。太近了数据来不及到达缓存就派上用场太远了缓存被预取数据占满又挤掉了其他热数据。一般经验是提前预取几轮循环的地址或者提前数百字节。预取不能过量。每个缓存行预取都会占用内存带宽过量预取反而拖慢正常访问。只对确定要访问的地址做预取不要对所有地址无差别预取。纯计算密集的循环本身就连续顺序访问硬件预取器已经做得很好再手动预取可能是负优化。手动预取主要用在不规则访存的场景比如通过索引数组间接取数。实际项目里我遇到更多的情况是不规则但可预测的访问模式。举例说明稀疏矩阵的非零元素存储在一组连续数组里但行索引和列索引是乱的。访问非零值数组是连续的但访问相邻行时实际元素在内存里跳来跳去这种场景下硬件预取器帮不上太多忙如果数据量特别大可以考虑对列索引数组做预取把后续要访问的地址提前加载。不过说句实话预取优化属于“最后再碰”的类型。常规的连续数组访问只要循环写对了硬件已经处理得很好了。手动预取非常考验对底层流水线的理解收益很多时候只有你们测试之后才能确认不做详细评估不建议大范围使用。3. 实操过程与核心环节实现3.1 性能分析工具先量化再动手任何缓存优化都必须先量化现状再动手改代码。凭感觉优化的结果通常是把问题挪了个地方并没有真正解决。高性能Linux环境里最常用的工具是perf它通过读取硬件性能计数器直接给出缓存未命中的具体数据。用perf stat跑一次程序出来的结果包含很关键的几列perf stat ./your_app重点关注这几项指标cache-misses缓存未命中总次数cache-references缓存访问总次数两者比例就是未命中率L1-dcache-load-missesL1数据缓存加载未命中次数dTLB-load-missesTLB页表缓存未命中次数这个指标如果很高说明访存随机性太大我习惯第一步先看L1未命中率如果超过10%说明局部性不好值得继续查再看L3未命中率如果超过30%说明数据集太大或者访问跳跃太严重。TLB指标很多人会忽略但程序访问的内存页如果分布太散TLB未命中会导致每次访存都要查页表开销极大。perf还能用perf record记录采样数据结合perf report看热点函数。我一般在优化迭代过程中用perf stat做全量对比用perf record做热点分析这两者结合基本能定位绝大部分缓存问题。除了perfLinux下还有valgrind的cachegrind工具可以用它模拟缓存行为给出每行代码的缓存命中率。cachegrind准确度虽然和真实硬件计数器有差距但它能精确到源代码行级别的未命中统计这对定位问题代码很有帮助。我遇到大型项目时会先用cachegrind跑一遍小规模输入快速排除明显的访存问题再用perf在真实数据集上确认。3.2 典型案例一图像卷积滤波的缓存重排之前提到的一个图像处理Demo是一个对灰度图做5×5高斯模糊的模块。原代码直接开四重循环对每个像素做25次乘法累加。看起来运算量不大但实际测下来处理一张1920×1080的图原算法大约耗时85毫秒。用perf看L1数据缓存未命中率高达23%L3未命中率9%。问题很明显5×5卷积核需要访问当前像素周围5行5列的数据而原来的循环是逐像素移动的。每移动一行就要重新载入好几个新的缓存行部分行在滑动窗口移开后就被替换等到靠近窗口底部的数据需要时又得重新读取。优化思路是用分块加滑动窗口的方式。我把图像按横向条带切分每个条带的高度刚好能覆盖卷积核的垂直范围加上几条额外的行。然后逐条带处理处理每个条带时从缓存里复用的数据变多了。具体实现上还有个技巧把卷积核的x方向和y方向拆开来做先做水平方向滤波再做垂直方向滤波。这样每次只需要访问当前行前后几个像素两个方向都变成一维访存缓存友好程度大幅提升。改造后同样一张图的处理时间降到了31毫秒L1未命中率降到9%L3未命中率降到4%。整个优化核心就是把二维访存变成两次一维访存以及让卷积窗口扫过图时同一个缓存行的数据可以被更多相邻像素复用。这个例子最大的启示是遇到卷积、滤波、模板匹配这类滑动窗口类算法优先考虑拆分成行方向和列方向两次一维处理。很多开发者会去优化卷积核内的乘法次数那个优化空间可能只有百分之二三十但访存模式的优化直接可以带来两到三倍的提升优先级完全不同。3.3 典型案例二矩阵分块乘法的线程同步优化另一个做过的优化是一个模拟类项目里高频调用的矩阵乘法。矩阵规模是512×512已经超出L2缓存容量。最初的实现是教科书式三重循环结果在8核机器上跑加速比只有4.2远低于8核的理论值。perf record抓热点发现大量时间花在等数据上缓存未命中很高还有个副作用是多线程并行时线程间存在伪共享。我当时做了三件事。第一矩阵分块把大矩阵切成64×64的小块让每次参与计算的一块能留在L2缓存里。第二把分块后的乘法逻辑用连续内存排列让同一块的行和列在内存里尽量连续存放。第三给每个线程分配独立的累加缓冲区避免多个线程写同一个共享计数数组。分块矩阵乘法的核心代码结构可以看这个伪代码#define BLOCK_SIZE 64 for (int i0 0; i0 N; i0 BLOCK_SIZE) { for (int j0 0; j0 N; j0 BLOCK_SIZE) { for (int k0 0; k0 N; k0 BLOCK_SIZE) { for (int i i0; i i0 BLOCK_SIZE; i) { for (int k k0; k k0 BLOCK_SIZE; k) { // 内层取A的行块和B的列块都是连续访问 for (int j j0; j j0 BLOCK_SIZE; j) { C[i][j] A[i][k] * B[k][j]; } } } } } }这里BLOCK_SIZE的选取很关键。理论上要保证三块小矩阵A的一个行块、B的一个列块、C的一个块能同时装进L2缓存。512×512的矩阵每个元素8字节double64×64的块占64×64×832KB两块是64KB再加C块总共96KB装进常见的256KB L2绰绰有余。如果块太小复用力度不够块太大又会溢出缓存这是需要实际测试权衡的。优化后的加速比从4.2提升到了7.1缓存未命中率下降了六成。我后来把这个分块方法继续用到了其他几个矩阵运算密集的模块里效果都比较稳定。3.4 调优验证A/B测试和多组数据复核缓存优化有个容易误导人的地方改完代码后因为系统状态、CPU频率动态变化、后台进程干扰等单次测试结果波动很大。我自己的习惯是任何修改必须做三轮以上对照测试每轮用相同输入、相同机器状态取中位数或者平均值。最好用perf stat的计数器数据来做判断而不只看运行时间因为运行时间受调度影响大缓存命中率是硬件计数的更客观。还有一个重要的点要拿多组不同规模的数据来验证。有些优化在小规模数据下效果不明显是因为数据集本身就小于缓存容量任何写法都能全装载但数据集一旦超过缓存容量优化的差距才会真正拉开。所以在优化过程中一定要准备小、中、大三组规模的测试数据分别观察缓存未命中的变化趋势。举个例子矩阵乘法分块矩阵规模64×64时分块和普通写法差距可能不到10%因为L2缓存轻松装下规模256×256时差距开始拉开规模1024×1024时分块写法的优势可以达到3倍以上。如果只用小规模数据验证很容易得出“改动没用”的错误结论。4. 常见问题与排查技巧实录4.1 伪共享排查指南性能计数器帮你看穿伪装伪共享最恶心的地方是你的代码逻辑完全正确各线程之间也没有真正的数据竞争但性能就是上不去。排查时首先要看并行扩展性单线程性能还行两个线程略有提升四个线程不但没提升反而下降这种现象要高度怀疑伪共享。perf可以用来确认。运行多线程版本看cache-misses是否随着线程数增加而飙升。如果线程数翻倍缓存未命中数也成倍增长那不是数据量变大而是缓存行在核心间频繁同步。还有一个反向验证法临时给共享数据加填充如果加上填充后性能明显回升那基本可以确定是伪共享了。伪共享最容易出现在这几种结构里多个线程各自维护的计数器数组、并行任务队列里的任务状态、每个线程持有的事件标记。排查思路就是找出所有线程都在写的地址区域检查这些地址是否都落在同一个64字节区间内。可以用地址打印的方式把各线程变量的地址打出来做一次地址对齐计算看看是否落在同一缓存行上。处理手段除了填充还有改变同步机制用原子操作和thread_local变量的组合减少公共数据的写次数。如果是计数器累加还可以用每个线程本地计数最后汇总这也是从源头上规避伪共享。4.2 缓存抖动和亲和性调度器盲目搬家的代价另一种常见的性能劣化是缓存抖动Cache Thrashing和CPU迁移。多线程程序里操作系统调度器可能把一个线程从一个核心迁到另一个核心。核心一换它之前在L1和L2缓存里的热数据全部失效需要重新加载。频繁迁移缓存反复被清空性能一下就掉下来了。这种情况在高性能计算里特别常见。一个并行任务每个线程干的事情差不多但互相之间的数据有交换迁移越频繁数据交换越慢。解决办法是绑核把线程固定到指定CPU核心上Linux下用taskset命令或者在代码里调用sched_setaffinity。我在一个并行排序任务里做过对比不绑核的情况下4个线程并行排序一个大数组耗时135毫秒绑核后耗时降到了97毫秒。原因就是线程不再频繁换核每个线程的局部数据能大概率留在自己的私有缓存里。taskset的用法很简单taskset -c 0,1,2,3 ./your_app或者直接在代码里绑定线程cpu_set_t set; CPU_ZERO(set); CPU_SET(core_id, set); pthread_setaffinity_np(thread, sizeof(set), set);绑核也有一个需要注意的点不是绑了核就万事大吉。超线程技术下同一个物理核心的两个逻辑核心共享L1和L2缓存如果两个高负载线程被绑定到同一物理核心的两个逻辑核上它们会互相争抢缓存和ALU资源。排核时最好用lscpu看下逻辑核心的编号分布让高性能线程分布在不同的物理核心上。4.3 缓存优化常见问题速查表我把这几年实际踩过的坑整理成一个速查表分享你们按图索骥省得走弯路现象可能原因排查方向解决手段L1未命中率高但L3命中率正常局部性差数据访问跳跃检查循环内层遍历方向调整循环嵌套顺序让内层遍历连续内存多线程并行加速比远低于核数伪共享、线程迁移检查线程共享写数据地址结构体填充、对齐、绑核数据集增大后性能突然崩溃数据超过L2/L3缓存容量用perf stat看L3未命中率分块处理让热数据块适配缓存容量所有指标正常但速度依然慢内存带宽饱和或TLB未命中高检查dTLB-load-misses使用大页内存或者改进访存连续性一次修改后运行时间波动大系统噪声、CPU频率调整对照多轮测试取中位数绑核、禁用动态调频用perf计数器做参考三倍循环性能不稳定编译器向量化失效查看汇编是否生成SIMD指令简化循环体使用#pragma unroll辅助展开速查表里的每一项都是真实排查过的场景。尤其想说下大页内存HugePages这个选项很多做数值计算的人都忽略了TLB未命中。默认内存页大小4KB如果一个程序访问的数据分散在大量内存页上TLB条目会被迅速占满每次访存都要查更慢的页表。把内存页改成2MB的大页TLB覆盖率能提升512倍对大规模矩阵、图计算这类随机访存密集的任务提升非常明显。4.4 没有性能分析工具的嵌入式场景怎么办高性能计算不只在服务器上很多嵌入式场景也有缓存但没有perf这类工具。这时候怎么办我的经验是用计时打点和控制变量法。计时打点就是在高频循环的入口和出口记录时间戳隔离出数据访问阶段看每个阶段占总耗时的比例。如果读数据阶段占大头基本就是缓存命中率低的锅。然后做控制变量对比把数据复制到连续的内存里跑一遍如果耗时骤降说明原访存模式对缓存不友好。虽然没有硬件计数器但通过行为对比也能定位问题。另一个土办法是观察访存模式本身。凡是数组下标出现大跨度跳跃的地方比如array[col * ROW row]里的row变化导致跳变先假设这个访存是坏的。把这种访存改成连续步长遍历往往立竿见影。嵌入式芯片通常缓存容量比较小L2缓存可能只有64KB到256KB。这种环境下的优化策略要更激进数据结构尽可能紧凑处理器每次内存读操作尽量把用到的数据一次性搬完。比如你有一个4字节的索引频繁访问一个动辄几个GB的大结构体数组那缓存的压力会用来加载没用的成员数据可以考虑用“结构体拆分”来把热数据分离出来单独存储。5. 工具选型与优化路径再思考5.1 缓存优化工具的适用边界每次讲缓存优化都要重申一遍工具的分工。perf是主力适用范围广能拿到硬件计数器的真实数据valgrind/cachegrind适合开发阶段做细粒度定位但模拟缓存行为的速度极慢跑大输入不现实。还有一类是编译器辅助工具比如GCC的-fopt-info-vec可以输出向量化日志帮你确认循环有没有被优化。如果你的项目比较复杂有大量第三方依赖perf的效果会打折扣因为热点可能分散在多个库里。我有一次排查一个跨平台系统的性能问题仪表数据始终显示缓存未命中特别高但热点分析定位到的是第三方数学库的内部函数。这时只能通过替换库的访存模式或者给库函数换成缓存友好的变体来解决。这种情况没有万能工具只能一个库一个库测试。选择优化路径时我建议按这个优先级排先做能明确改进局部性的改动改循环顺序、改数据布局这类改动收益最大、风险最小再做和并行相关的调整绑核、填充数组因为这类改动涉及线程交互容易出现新问题手动预取、内联汇编等底层优化放最后只在前面几种手段都试过且提升仍然不够时才考虑。5.2 从项目全局看缓存优化的投资回报最后说说投入产出。缓存优化有时候给人感觉特别理论不像写新功能一样有看得见的产出。但用数据说话一次有效的缓存优化往往能把核心模块的性能提升50%到300%这比换更好的CPU划算得多。做缓存优化时还容易陷入一个误区只看单点优化没有考虑整体数据流。我见过有人把矩阵乘法优化得很漂亮但每次调用前后都有大量不必要的数据拷贝缓存优化带来的收益又被拷贝消耗掉了。全局视角特别重要。在做任何局部优化之前先画清楚数据流数据从哪里产生经过哪些缓冲最后在哪里被消费。凡是能减少数据拷贝的改动优先级永远高于在计算热区里的微观优化。另外一个经验是缓存优化不是一锤子买卖。换一个编译器版本升级一个基础库都可能改变访存行为原来精心调优的效果可能被削弱。所以优化完后最好把关键性能指标和测试用例保留下来做成回归测试。每次升级之后跑一遍一旦发现缓存命中率明显下降马上就知道是哪里出了问题。我自己的习惯是在项目里建一个benchmark目录存放主要的性能测试用例和优化的记录文档这样不管过了多久任何新人都能顺着文档复现当时的优化思路。总的来说缓存优化这项技术门槛不在理论理解而在能否读懂你的程序在硬件上的实际行为。量化、定位、修改、验证这四个步骤循环执行逐步逼近理想状态。这也是高性能计算里最值得投入的一项基本功。文章写到这里许多细节都是我平时调试时才想起来的。如果你手头正好有一个跑得慢的程序别急着改算法先把perf stat拉起来看看缓存未命中率大概率会打开一个新世界。