该在缓存未命中成为性能瓶颈且访问模式可预测时使用__builtin_prefetch，适用于顺序扫描、固定步长跳读或结构体数组字段访问等场景，不适用于随机访问或小数据量。
什么时候该用 __builtin_prefetch？
它不是“写得快就加一个”的优化手段，而是当你明确观察到缓存未命中（cache miss）成为瓶颈，且数据访问模式可预测时才值得介入。常见于遍历大数组、处理连续内存块、或实现自定义容器的迭代器时——比如你用 perf 看到 LLC-load-misses 高，又确认访存是热路径，这时预取才有意义。
- 适用场景：顺序扫描、固定步长跳读（如 stride=64）、结构体数组中只读某字段
- 不适用场景：随机地址访问、小数据量（
- 副作用：增加前端指令带宽压力；若预取地址非法（如空指针），不会 crash，但可能触发页错误延迟
__builtin_prefetch 的参数怎么选？
它有三个参数：__builtin_prefetch(addr, rw, locality)，其中后两个是编译期常量，直接影响硬件行为，不能随便填。
-
rw：0 表示只读（默认），1 表示预期写入。多数情况用 0；若你紧接着要写某个地址，且 CPU 支持写预取（如 x86 的PREFETCHW），才设为 1 —— 但 GCC 对此支持有限，实际效果不稳定，慎用 -
locality：0（无局部性）、1（低局部性）、2（中）、3（高）。它控制预取进哪级缓存。顺序遍历时通常用 3；若预取的是后续几轮才用的数据（比如提前 4096 字节），用 2 更稳妥，避免挤占 L1 缓存 - 最常用组合：
__builtin_prefetch(p + 128, 0, 3)—— 提前预取 128 字节后的一个 cache line（x86 下典型 cache line 是 64 字节，128 足够错开当前访问）
为什么加了预取反而变慢？
预取本身不耗时，但会抢占内存带宽和 TLB 条目。常见翻车点：
- 预取太近：比如
__builtin_prefetch(p + 64, 0, 3)，和当前访问几乎重叠，浪费带宽，还可能触发额外的 cache line 搬运 - 预取太远或太多：一次循环里调用多次，或提前几百个元素，导致 prefetch 指令在流水线里堆积，甚至引发 memory order 乱序问题
- 没对齐地址：预取未对齐的地址（如
p + 1）会让 CPU 多 fetch 一个 cache line，尤其在 ARM 上更敏感 - 忘了检查指针有效性：对
nullptr或已释放内存调用，虽不崩溃，但会引发不必要的 page fault，实测延迟飙升数微秒
实际代码里怎么安全插入？
别裸写在循环头部，先做两件事：确定 offset，再加边界防护。下面是一个典型安全模板：
立即学习“C++免费学习笔记（深入）”；
for (size_t i = 0; i < n; ++i) {
// 安全预取：确保 p + offset 不越界，且至少提前 1 个 cache line
const size_t prefetch_dist = 256; // 根据数据大小和步长调整
if (i + prefetch_dist < n) {
__builtin_prefetch(&arr[i + prefetch_dist], 0, 3);
}
process(arr[i]);
}
- offset 值建议从 128 开始试，用
perf stat -e cache-misses,instructions对比变化 - 如果
arr是std::vector，直接用&arr[0]起始地址，别对迭代器解引用后再取址（避免 operator[] 以外的开销） - 在 release 构建中开启
-O2或更高，否则 GCC 可能忽略该内建函数
真正起效的预取，往往藏在 profiler 数据和反复验证之间，而不是靠直觉加一行代码。注意，ARM 和 RISC-V 的预取语义与 x86 不完全一致，跨平台时需单独验证。
