__builtin_prefetch 应在存在明确可预测内存访问模式（如顺序遍历大数组、ring buffer）且 profiler 显示缓存缺失率高时使用；误用于随机访问或小数据集反而降低性能。
什么时候该用 __builtin_prefetch？
它不是“让程序变快”的银弹，而是针对明确的、可预测的内存访问模式做微优化——比如遍历大数组、处理链表节点、或实现 ring buffer 的消费者/生产者循环。如果你的热点代码里有规律性的远距离访存（比如提前 1–2 个 cache line 读取下一批数据），且 profiler 显示 L1/L2 缺失率高，这时才值得试。
常见误用：在随机访问、小数据集、或编译器 already 能 auto-vectorize 的循环里硬加 prefetch，反而增加指令开销，甚至干扰硬件预取器。
__builtin_prefetch 的三个参数怎么填？
函数原型是 void __builtin_prefetch(const void *addr, int rw = 0, int locality = 3)，三个参数必须按顺序理解：
-
addr：要预取的地址，必须是有效指针（不能为nullptr，也不能是未映射页）。常用写法如&arr[i + 4]或ptr + stride * 8 -
rw：0 表示只读（默认），1 表示即将写入。填错会导致 CPU 预取到 wrong cache state（比如对只读地址设rw=1，可能触发不必要的 write-allocate） -
locality：0~3，表示数据被重用的“亲密度”。3（默认）表示强局部性（预取进 L1/L2）；0 表示只进 L3 或不缓存（适合只用一次的大块数据）。多数场景保持 3 即可，除非你明确知道数据只会用一次
为什么预取后性能没提升，甚至变慢？
典型原因不是语法错，而是节奏没踩准：
立即学习“C++免费学习笔记（深入）”；
- 预取太早：CPU 还没执行到对应 load 指令前几十 cycle 就 prefetch，数据可能被挤出 cache；太晚则起不到作用。经验上，对 3GHz CPU，提前 50–200 条指令较稳妥（对应约 16–66ns）
- 预取地址越界：比如
i+8超出数组边界，虽不 crash（prefetch 是 hint），但浪费带宽，还可能触发 page fault 前置开销 - 编译器优化干扰：
-O2以上可能把 prefetch 挪到循环外，或与其它指令乱序。加volatile强制保留位置不现实，更可靠的是用#pragma GCC unroll N控制展开，并手动把 prefetch 放在循环体靠前位置 - 硬件不支持：某些老 ARM 或低功耗 CPU 忽略该 builtin；x86-64 一般支持，但需确认 microarch（如 Intel Atom 可能效果弱）
一个安全可用的 vector 遍历预取模板
假设你遍历 std::vector<int></int> 并做简单计算，目标是预取后续 4 个元素（约 64 字节，一个 cache line）：
for (size_t i = 0; i < vec.size(); ++i) {
// 提前预取 i+4 位置（确保不越界）
if (i + 4 < vec.size()) {
__builtin_prefetch(&vec[i + 4], 0, 3);
}
result += vec[i] * 2;
}
注意点：
- 必须带边界检查，否则
vec[i+4]在末尾会越界 - 不要预取
&vec[i+1]—— 太近，L1 硬件预取器已覆盖；也不要预取&vec[i+16]—— 太远，大概率被换出 - 如果 vector 数据量极大（>1GB），且你确定访问是顺序的，可考虑每 8 个元素 prefetch 一次，减少指令数
真正难的从来不是写这行 builtin，而是确认你的访存 pattern 是否稳定、是否已被硬件预取器覆盖、以及是否值得用额外的调试成本去压那零点几个百分点的延迟。
