我正在尝试通过大型阵列上的软件预取来进行一些性能改进，大约5000万个条目，显然不适合L3缓存。访问数组是随机的，但我对下一步要访问的位置有一定的可预测性。有趣的是，在实际访问之前，预取指令会导致高速缓存未命中。
findFirst经过大量指令实际取消引用prim_bkt变量
要验证缓存未命中，我实际上注释了解除引用变量const struct _bucket *prim_bkt;
prim_bkt = &(h->buckets[prim_bucket_idx]);
__builtin_prefetch(prim_bkt,0, 3);
，但我看到的缓存未达到相同数量。如果我删除预取部分我没有LLC高速缓存未命中。所以真正的问题是预取导致缓存未命中/我是否在上面的代码中做了一些愚蠢的事情。
我正在使用intel haswell x86-64 bit arch on cent os 7.任何缓存专家都可以提供帮助。
我已经知道的事情： 预取和实际访问之间需要足够的差距。这很好照顾。
尝试使用T0，T1，T3和非时间预取指令，所有这些都导致LLC高速缓存未命中。 Perf工具用于缓存测量。
修改： 我开始使用ocperf.py测量LLC miss。这是我使用的命令。
prim_bkt。
我只对运行这段代码的核心16感兴趣。我看到像perf输出这样的行为。我没有引用实际的指针，所以理论上它应该是零缺失。只是做prefetch和ocperf计数器是3400万（./ocperf.py stat -e offcore_response.demand_data_rd.llc_miss.local_dram -C 16 sleep 10）。如果我删除prefetch line llc miss is~0。
根据ocperf.py帮助定义此计数器： offcore_response.demand_data_rd.llc_miss.local_dram - 计数需求数据读取错过L3并且数据从本地dram返回