如何测量Haswell微架构的后期预取和杀死预取？

Posted 2021-04-21

我正在使用Intel Xeon 2660 v3并发布大量软件预取来利用MLP以及减少停顿时间。现在，我想分析应用程序以获得由于软件预取而获得的总体增益。

在“利用自适应执行提高软件预取的有效性”一文中，作者讨论了与软件预取相关的硬件中的性能计数器支持。

我正在写论文中的文字，作者在那里谈到了性能指标。

此外，最佳自适应方案所需的唯一硬件支持是一对计数器：一个计算延迟预取的数量（在处理器请求数据之后到达的预取数量），另一个计量结果，用于测量由于以下原因而被杀死的预取数量。缓存冲突。

我想描述Haswell微体系结构的应用程序，但在Perf或PAPI中找不到任何这样的性能计数器。那么，是否有任何其他性能计数器来获取此类事件，以及为代码的一小部分执行此操作的最佳方法是什么，而不是为完整应用程序执行此操作？

Paper Link

答案

ocperf.py是perf的包装器，带有象load_hit_pre.sw_pf等特定于uarch的事件的符号名称（当调度到加载端口的需求加载命中为分配给软件预取的L1D填充缓冲区（FB）时计数）。 ocperf.py list有描述和名称。

这可能是一个很有用的东西，但是我自己并没有使用它，所以IDK如果它确实是你所需要的。绝对查看事件列表（ocperf.py list | less）。

你还应该看看L1D未命中率;如果成功预取能够保持领先于需求负载，则实际负载指令应该在L1D中。 （简单的perf可以用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预取请求被丢弃，但我认为只有当需求负载大量使用时才会丢弃硬件预取请求）。

---

商店的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标签维基中的其他链接