C++中无原生prefetch语法，需用__builtin_prefetch（便携）或_mm_prefetch（x86专用）等编译器内置函数；适用缓存未命中率高、访存密集场景，预取距离宜为8–64元素。
prefetch 指令在 C++ 中没有直接语法，必须靠编译器内置函数或内联汇编
标准 C++ 不提供 prefetch 语句，它属于底层 CPU 指令（如 x86 的 _mm_prefetch、ARM 的 prfm），需通过编译器提供的内置函数调用。主流编译器（GCC/Clang/MSVC）都支持 __builtin_prefetch（GCC/Clang）或 _mm_prefetch（Intel Intrinsics）。直接写内联汇编不仅可移植性差，还容易破坏编译器优化。
使用时注意：
-
__builtin_prefetch是最便携的选择，但只接受地址、读写意图（0读 /1写）、局部性提示（0–3，数值越大表示越可能被重复使用）三个参数 -
_mm_prefetch需要包含_MM_HINT_NTA（non-temporal）或_MM_HINT_T0 - 传入的地址必须是有效指针，空指针或非法地址会触发未定义行为（即使只是预取）
什么时候加 prefetch 才真能提速？看访存模式和延迟是否匹配
预取只有在「CPU 等待数据从内存到达」成为瓶颈时才有效。典型适用场景是：遍历大数组、处理链表（尤其非连续结构）、多级间接访问（如树节点跳转）、或计算密集但内存带宽受限的循环。如果数据已在 L1/L2 缓存中，或访存本身不密集（比如每百次计算才读一次），加 __builtin_prefetch 反而增加指令开销、干扰分支预测。
关键判断点：
立即学习“C++免费学习笔记（深入）”；
- 用
perf stat -e cache-misses,cache-references（Linux）观察缓存未命中率是否 >10%；高则值得尝试 - 预取距离（offset）要足够：太近（如只提前 1 步）没意义；太远（如提前 1024 步）可能导致预取数据被中途挤出缓存；常见经验值是提前 8–64 个元素（取决于缓存行大小和步长）
- 避免对同一地址重复预取——浪费指令周期，且无额外收益
一个安全有效的 prefetch 循环模板（GCC/Clang）
以下是在遍历 std::vector 时，为下一批数据提前加载的典型写法。它把预取放在循环体靠前位置，并控制偏移量在合理范围：
for (size_t i = 0; i < vec.size(); ++i) {
// 提前预取 i + 16 处的数据（假设 int 为 4 字节，16×4=64 字节 → 1 个 cache line）
if (i + 16 < vec.size()) {
__builtin_prefetch(&vec[i + 16], 0, 3);
}
// 实际计算
sum += vec[i] * vec[i];
}
说明：
-
0表示「只读」，3表示最高局部性（T0类似语义），适合顺序遍历 - 用
i + 16是因为现代 CPU 缓存行通常是 64 字节，int占 4 字节 → 每行 16 个元素；这样每次预取恰好覆盖下一行 - 必须加边界检查，否则
&vec[i + 16]可能越界，导致段错误或静默 UB（尤其vec小于 16 时）
容易被忽略的陷阱：prefetch 不保证数据就绪，也不同步执行
__builtin_prefetch 和 _mm_prefetch 都是「提示型」指令，CPU 可以忽略、延迟、甚至乱序执行它。它不阻塞后续指令，也不提供内存屏障语义。这意味着：
- 不能依赖预取后立刻读取 —— 仍需正常访存，预取只是提高「大概率命中」的概率
- 不能用它替代
std::atomic_thread_fence或__memory_barrier来保证可见性或顺序 - 在 NUMA 系统上，预取不会自动跨节点迁移数据；若线程迁移到远端 socket，预取可能加载到错误的本地缓存
- 开启
-O3后，编译器可能自动插入软件预取（如 GCC 的-fprefetch-loop-arrays），此时手动加可能冗余甚至冲突
真正起作用的永远是访存模式 + 数据局部性 + 缓存层级理解，而不是多加几条 __builtin_prefetch。
