我正在使用 Intel Xeon 2660 v3 并发出大量软件预取来利用 MLP 并减少停顿时间。现在我想分析应用程序以获得由于软件预取而产生的总体增益。
在论文“通过自适应执行提高软件预取的有效性”中，作者讨论了与软件预取相关的硬件中的性能计数器支持。
我放的是论文中的文本，作者在其中讨论了性能计数器。
Furthermore, the only hardware support required by the best adaptive scheme is a pair of counters: one measuring the number of late prefetches (the ones arriving after the processor has requested the data) and another one measuring the number of prefetches killed as a result of cache conflicts.
我想针对 Haswell 微架构分析应用程序，但在 Perf 或 PAPI 中找不到任何此类性能计数器。那么，是否有其他性能计数器可以获取此类事件，以及对一小部分代码而不是对整个应用程序执行此操作的最佳方法是什么？
最佳答案
ocperf.py是 perf 的包装器，具有 uarch 特定事件的符号名称，例如 load_hit_pre.sw_pf (当分派(dispatch)到加载端口的需求加载命中 L1D 填充缓冲区时进行计数(FB )分配给软件预取)。 ocperf.py list 包含描述和名称。
这可能是一个有用的东西，但我自己还没有使用过它，所以我不知道它是否真的符合你的需要。一定要查看事件列表(ocperf.py list | less)。
您还应该查看 L1D 未命中率；通过成功预取并设法保持领先于需求加载，实际加载指令应该在 L1D 中命中。 (普通的 perf 可以使用 L1-dcache-load-misses 来跟踪这一点。)
为了测量预取但在使用前被逐出的行，有l2_lines_out.useless_hwpf。 “计算已硬件预取但未使用且现在被二级缓存逐出的行数”。 l2_lines_out.useless_pref 是那;看起来没有包含软件预取的类似事件。
您可能只需要查看 L1D 未命中率即可；这应该告诉您预取距离的最佳范围在哪里。如果 load_hit_pre.sw_pf 按我希望的方式工作，那么 L1D 未命中且 load_hit_pre.sw_pf 计数较低意味着您的预取距离太高。 (或者由于某些其他原因，软件预取请求被删除，但我认为只有当需求负载利用率很高时，才会删除硬件预取请求)。
存储的性能计数器硬件事件比加载的性能计数器硬件事件受到更多限制，因此如果您尝试预取只写流，则将更难以测量。 L1D 中的硬件预取器甚至可能根本不预取存储，因此 different access patterns for write-only streams can suffer a lot 。另请参阅@BeeonRope对此答案的评论:如果商店在 L2 中命中，但在 L1D 中命中，则 SW 预取可以提供帮助。 prefetchw 是理想的选择，但普通的 prefetcht0 仍然有用。 (prefetchw 在 Haswell 及更早版本上作为 NOP 运行。)
另请参阅 x86 中的其他链接标签维基
关于x86 - 如何测量 Haswell 微架构上的延迟预取和终止预取？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/48008741/