X86 如何在Haswell micro architecture上测量延迟预取和终止预取？

我正在使用英特尔至强2660 v3，并发布大量软件预取来利用MLP并减少暂停时间。现在我想分析应用程序，以获得由于软件预取而带来的总体收益

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

我把论文中的文字放在这里，作者在那里谈到了性能计数器

此外，所需的唯一硬件支持 最佳自适应方案是一对计数器：一个测量 延迟预取的数量（在处理器之后到达的预取 已请求数据）和另一个测量 缓存冲突导致预取被终止

我想分析Haswell微体系结构的应用程序，但在性能或PAPI中找不到任何此类性能计数器。那么，是否还有其他性能计数器可以获取此类事件？对于代码的一小部分，而不是整个应用程序，最好的方法是什么

是

perf

的包装器，具有uarch特定事件的符号名称，如

load\u hit\u pre.sw\u pf

（当发送到加载端口的请求加载命中分配给软件预取的L1D填充缓冲区（FB）时计数）

ocperf.py列表

包含说明和名称

这可能是一个有用的方法，但我自己还没有用过，所以我想知道它是否真的能满足你的需要。一定要查看事件列表（

ocperf.py list | less

）

您还应该查看L1D未命中率；成功的预取能够保持在需求加载之前，实际加载指令应该在L1D中命中。（普通

perf

可以通过

L1数据缓存加载未命中

跟踪此情况）

---

对于预取但在使用前收回的测量线，有

l2\u行。无用的\u hwpf

。“统计已硬件预取但未使用且现在已被二级缓存逐出的行数”

l2\u line\u out。无用的\u pref

是它的别名；看起来没有类似的事件包括软件预取

您可能只需要查看L1D未命中率；这应该告诉您预取距离的最佳点范围在哪里。如果

load\u hit\u pre.sw\u pf

如我所希望的那样工作，则L1D未命中，且

load\u hit\u pre.sw\u pf

的计数较低。这意味着您的预取距离太长。（或者软件预取请求由于其他原因被丢弃，但我认为只有在需求负载利用率较高的情况下才会丢弃硬件预取请求）

---

存储的性能计数器硬件事件比加载的要有限得多，因此，如果您试图预取一个只写的流，它将很难测量。L1D中的硬件预取器甚至可能根本不会预取存储，因此。另请参见@BeeonRope对这个答案的评论：如果商店的软件预取在L2中，而不是L1D中，那么它们会有所帮助

prefetchw

是理想的，但是普通的

prefetcht0

仍然有用。（

prefetchw

作为NOP在Haswell和ealier上运行。）

---

---

另请参见tag wiki中的其他链接

l2_行_out _无用_hwpf

和

l2_行_out _无用_pref

是同一事件的两个不同名称。还请注意，最近的

perf

版本也具有特定于arch的事件。自从我更新到4.10.x内核后，

perf

的事件与

ocperf

（即所有Skylake事件）几乎相同，包括您提到的两个事件。关于商店和L1预取器，我的印象是，L1硬件预取器从不由商店触发。但是，即使没有

prefetchw

，您也可以有效地为门店进行软件预取。嗨，彼得，如果这不是一个太大的负担，您介意澄清一下

prefetchw

是NOP的部分吗？谢谢大家!@MargaretBloom：在Core2之前，英特尔CPU在

prefetchw

3dNOW指令上使用UD。从Core2到Haswell，这是不可能的。（适用于x86-64的Windows 8.1要求

prefetchw

没有故障；可能是Microsoft要求Intel至少以NOP的形式运行它。）从Broadwell开始，Intel CPU设置

prefetchw

CPUID功能位，并将其作为实际的预取运行到独占状态。