我正在使用Intel Xeon 2660 v3并发布大量软件预取来利用 MLP 并减少停顿时间。现在我想分析应用程序以获得由于软件预取而获得的整体收益。
在“通过自适应执行提高软件预取的有效性”一文中，作者讨论了与软件预取相关的硬件中的性能计数器支持。
我把论文中的文字放在了作者谈论性能计数器的地方。
此外，最佳自适应方案所需的唯一硬件支持是一对计数器：一个测量延迟预取的数量（在处理器请求数据之后到达的那些），另一个测量因缓存冲突。
我想分析Haswell 微架构的应用程序，但在Perf或PAPI中找不到任何此类性能计数器。那么，是否有任何其他性能计数器来获取此类事件？对于一小部分代码而不是为整个应用程序执行此操作的最佳方法是什么？
ocperf.py是perfuarch 特定事件的符号名称的包装器，例如load_hit_pre.sw_pf（当调度到加载端口的需求加载到达为软件预取分配的 L1D 填充缓冲区 (FB) 时计数）。 ocperf.py list有描述和名称。
这可能是一个有用的东西，但我自己并没有使用它，所以 IDK 如果它真的完全符合你的需要。一定要查看事件列表 ( ocperf.py list | less)。
您还应该查看 L1D 未命中率；通过成功预取并设法保持领先于需求加载，实际加载指令应该在 L1D 中命中。（plainperf可以用 . 来跟踪它L1-dcache-load-misses。）
对于预取但在使用前被驱逐的测量线，有l2_lines_out.useless_hwpf. “计算已被硬件预取但未使用且现在被 L2 缓存逐出的行数”。 l2_lines_out.useless_pref是那个的别名；看起来没有包含 SW 预取的类似事件。
您可能只需要查看 L1D 未命中率；这应该告诉你预取距离的最佳范围在哪里。如果load_hit_pre.sw_pf按我希望的那样工作，那么 L1D 未命中数低load_hit_pre.sw_pf意味着您的预取距离太高。（或者由于其他原因，SW预取请求被丢弃，但我认为只有在需求负载利用率很高时才会丢弃硬件预取请求）。
存储的性能计数器硬件事件比加载更有限，因此如果您尝试为只写流预取，它将更难测量。L1D 中的硬件预取器甚至可能根本不预取存储，因此只写流的不同访问模式可能会受到很大影响。另请参阅@BeeonRope 对此答案的评论：如果商店在 L2 而不是 L1D 中命中，则商店的 SW 预取会有所帮助。 prefetchw是理想的，但平原prefetcht0仍然有用。（prefetchw在 Haswell 和之前作为 NOP 运行。）
另请参阅x86标签 wiki中的其他链接