我正在使用 Intel Xeon 2660 v3 并发布大量软件预取以利用MLP以及减少停顿时间。现在我想分析应用程序以获得由于软件预取而获得的总体增益。
在论文＆＃34; 提高自适应执行软件预取的有效性＆＃34;中，作者讨论了与软件预取相关的硬件中的性能计数器支持。
我正在撰写论文中的文字，作者在那里讨论了绩效计数器。
此外，唯一需要的硬件支持 最好的自适应方案是一对计数器：一个测量 晚期预取的数量（在处理器之后到达的预取数量） 已请求数据）和另一个测量数量 由于缓存冲突而导致的预取被杀死。
我想描述 Haswell微体系结构的应用程序，但无法在 Perf 或 PAPI 中找到任何此类性能计数器。那么，是否有任何其他性能计数器来获取此类事件以及为代码的一小部分执行此操作的最佳方法是什么？而不是为完整应用程序执行此操作？
答案 0 :(得分：3)
ocperf.py是perf的包装器，具有特定于uarch的事件的符号名称，如load_hit_pre.sw_pf（当分派到装载端口的需求负载到达L1D填充缓冲区时计数（FB ）分配给软件预取）。 ocperf.py list有描述和名称。
这可能是一个很有用的东西，但我自己并没有使用它，所以IDK如果它确实正是你所需要的。绝对查看事件列表（ocperf.py list | less）。
你还应该看看L1D未命中率;如果成功预取能够保持领先于需求负载，则实际负载指令应该在L1D中。 （简单perf可以使用L1-dcache-load-misses跟踪此内容。）
对于预测但在使用前被逐出的测量线，有l2_lines_out.useless_hwpf。 “计算已经硬件预取但未使用的行数，现在由二级缓存逐出。” l2_lines_out.useless_pref是别名;它看起来不像包含SW预取的类似事件。
您可能只需要查看L1D未命中率;应该告诉你预取距离的最佳位置范围。如果load_hit_pre.sw_pf按预期工作，则L1D错过load_hit_pre.sw_pf的低计数意味着您的预取距离太高。 （或者由于某些其他原因导致SW预取请求被丢弃，但我认为只有在需求负载大量使用时才会丢弃硬件预取请求。）
商店的perf-counter硬件事件比加载更加有限，所以如果你试图预取只写流，那么它将更难衡量。 L1D中的HW预取器甚至可能根本不预取存储，因此different access patterns for write-only streams can suffer a lot。另请参阅@ BeeonRope对此答案的评论：商店的SW预取可以帮助它们在L2中而不是在L1D中。 prefetchw是理想的，但普通prefetcht0仍然有用。 （prefetchw在Haswell和ealier上作为NOP运行。）
另请参阅x86代码wiki
中的其他链接