顺序扫描大数组用prefetcht0，单次读大块数据用prefetchnta；预取需边界检查、合理调度时机，并禁用编译器自动预取以确保生效。
prefetcht0 和 prefetchnta 在什么场景下该选哪个
预取指令本身不改变程序逻辑，只影响缓存行为；选错类型反而会污染缓存或拖慢主线程。对顺序扫描的大数组（如 std::vector<int></int>），prefetcht0 更合适——它把数据拉进 L1/L2 缓存，后续访存命中率高；而 prefetchnta 走的是非临时路径，绕过 L2，适合只读一次的大块数据（比如解码一帧视频后就丢弃的 buffer），否则容易挤走真正需要复用的数据。
常见错误是不管访问模式统一用 prefetchnta，结果发现热点数据反复被踢出缓存，性能反而下降 10%～20%。
- 顺序遍历、局部性好 → 用
prefetcht0 - 单次遍历、数据远大于 L3 → 可试
prefetchnta，但要实测带宽收益 - 多线程各自扫独立内存块 → 每个线程仍可用
prefetcht0，无需同步
如何用指针安全地触发预取，避免越界崩溃
直接对 ptr + offset 调用 _mm_prefetch 很危险：若 ptr 接近页尾，加偏移后地址可能未映射，触发 SEGFAULT（尤其在 ASLR 开启时）。不能依赖“反正只读不写”——预取指令仍会触发行级页表查询。
实操建议始终做边界检查，且预留安全距离：
- 预取距离设为 64–256 个元素（取决于元素大小和缓存行长度），而非固定字节数
- 检查
ptr + distance ，其中 <code>end_ptr是合法内存末地址（不是vec.data() + vec.size()，而是vec.data() + vec.capacity()或明确分配的上限） - 用
__builtin_assume（GCC/Clang）或[[assume]]（C++23）向编译器声明“此处不会越界”，避免优化干扰预取位置
为什么在循环里放预取却没效果
预取失效最常见的原因是调度时机不对：太早（数据还没到 DRAM controller 队列）或太晚（CPU 已经开始等这个地址了）。典型表现是 perf stat 显示 L1-dcache-load-misses 没降，甚至 cycles 反升。
关键调整点：
- 预取点放在当前处理索引的前 8～16 次迭代处（例如处理
i时预取i+12），不是固定提前 1KB - 避免在分支多的循环体里预取——分支预测失败会导致预取指令被丢弃
- 确认编译器没把预取指令优化掉：
objdump -d查看汇编中是否存在prefetcht0指令；加volatile参数或用内联汇编强制保留（仅调试用）
gcc/clang 下启用预取需注意的编译选项
默认情况下，即使写了 _mm_prefetch，编译器也可能因 -O2 优化策略跳过生成对应指令，尤其是自动向量化开启时（-ftree-vectorize）会接管访存调度。
必须显式控制：
- 确保定义了
#include <xmmintrin.h></xmmintrin.h>，且目标架构支持（-march=native或至少-march=haswell） - 禁用自动预取：
-fno-prefetch-loop-arrays（否则编译器可能插自己的预取，和你的冲突） - 若用
__builtin_prefetch，注意 GCC 默认只生成prefetcht0，且不校验地址合法性——得自己兜底
最易被忽略的一点：预取效果高度依赖内存带宽饱和度。如果扫描时 CPU 大部分时间在等 store buffer 刷回，或者 NUMA 节点间跨通道访问频繁，预取带来的延迟掩盖会被掩盖。上线前务必在真实数据集 + 生产机器上跑 perf mem record 看 cache-miss 分布。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
