计算与访存平衡：Roofline模型

做算子优化这么久，我越来越觉得一个道理：不懂Roofline模型，就别谈什么性能优化。说白了，这玩意儿就是帮你一眼看穿算子的瓶颈到底在哪——是卡在计算上，还是卡在访存上。

我记得刚入行那会儿，有个同事花了两周优化一个卷积算子，各种汇编指令都用上了，结果性能只提升了5%。后来我用Roofline一分析，发现这算子根本就是访存瓶颈，计算再快也没用。嗯，那哥们儿当场就沉默了。

什么是Roofline模型？

Roofline模型，你可以把它想象成一座房子的屋顶。这个屋顶由两根斜线组成：

• 左边斜线：代表访存带宽限制区
• 右边斜线：代表计算能力限制区
• 屋顶交点：就是计算与访存达到平衡的点

横轴是计算密度（Ops/Byte），纵轴是性能（FLOPS）。你想想看，一个算子落在哪个区域，就说明它被什么因素限制着。

计算密集型 vs 访存密集型

这两个概念，我习惯用一个比喻来解释：

• 计算密集型：就像你在厨房里炒菜，锅铲翻飞，CPU忙得冒烟。典型代表：大矩阵乘法、FFT、大卷积核。
• 访存密集型：就像你在图书馆找书，大部分时间花在走路和翻目录上。典型代表：Element-wise操作、Reduce操作、小卷积核。

特性	计算密集型	访存密集型
计算密度	高（> 10 Ops/Byte）	低（< 1 Ops/Byte）
瓶颈	算力（FLOPS）	带宽（GB/s）
优化方向	向量化、并行化、指令优化	数据复用、缓存优化、访存合并
典型算子	MatMul (M,N,K大)、Conv (大核)	Add、Relu、Softmax、Gather

如何识别瓶颈？

识别瓶颈这事儿，说白了就三步：

1. 算计算密度：总计算量 ÷ 总访存量
2. 画Roofline图：把算子的计算密度标在横轴上
3. 看落在哪：落在左边斜线上就是访存瓶颈，落在右边水平线上就是计算瓶颈

我举个例子，你感受一下：

// 假设一个简单的向量加法
// 计算量：N 次加法 = N FLOPS
// 访存量：2N 次读 + N 次写 = 3N * 4 Bytes (float)

计算密度 = N / (3N * 4) = 0.083 Ops/Byte

// 假设硬件算力 10 TFLOPS，带宽 800 GB/s
// 理论性能 = min(10T, 800G * 0.083) = min(10T, 66.4G)
// 实际性能 ≈ 66.4 GFLOPS —— 访存瓶颈！

实战：用Roofline分析一个真实算子

咱们拿一个实际项目中的例子来说。之前我在优化一个3x3卷积算子，输入是256x256x64，输出是256x256x128。我算了一下：

• 计算量：3×3×64×128×256×256 × 2 ≈ 9.6 GFLOPS
• 访存量：输入64通道 + 输出128通道 + 权重3×3×64×128 ≈ 约 2.5 MB
• 计算密度：9.6G / (2.5M × 4) ≈ 960 Ops/Byte

嗯，这个计算密度非常高，按理说应该是计算瓶颈。但实际跑下来，性能只有理论峰值的40%。

我仔细一查，发现问题出在数据复用上。虽然计算密度高，但每次卷积窗口滑动时，相邻窗口有大量重复数据加载。说白了，就是缓存没用好，导致实际访存带宽远低于理论值。

后来我做了两件事：

1. 输入数据重排：把输入特征图按tile组织，提高空间局部性
2. 权重预取：用软件流水提前加载下一组权重

优化后，性能直接翻倍。你看，Roofline模型不仅告诉你瓶颈在哪，还能指导你往哪个方向优化。

最后说一句：Roofline模型不是万能的，但它能帮你快速定位问题方向。我每次接手一个新算子，第一件事就是画Roofline图。这习惯，帮我省了不知道多少冤枉时间。

想要更多资料，联系可可