多次运行后令人困惑的性能统计结果答案

【问题标题】：Confusing perf stat results after multiple runs多次运行后令人困惑的性能统计结果
【发布时间】：2014-09-13 07:33:59
【问题描述】：

我用 perf stat -e cache-misses 命令连续执行了 6 次 1000x1000 矩阵乘法代码，得到以下结果

Observation Cache-Misses Time elapsed(sec)
   1          48822173    7.697147087
   2          48663517    7.710045908
   3          48667119    7.701690126
   4          48867057    7.766267284
   5          48610651    7.701600681
   6          49203583    7.719180737

正如我们在此处看到的，观察 1 的缓存未命中率大于观察 2、3 和 5 中的缓存未命中。但观察 1 的经过时间小于观察 2、3 和 5。另一方面在所有这些观察中，观察 4 的经过时间最长，但观察 4 的缓存未命中少于观察 3 和观察 6。根据教科书，增加缓存未命中会延长程序的执行时间。那么我们如何解释这种行为呢？谢谢

这是我的系统详细信息：

Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                4
On-line CPU(s) list:   0-3
Thread(s) per core:    2
Core(s) per socket:    2
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 42
Stepping:              7
CPU MHz:               2300.000
BogoMIPS:              4589.89
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              3072K
NUMA node0 CPU(s):     0-3

【问题讨论】：

标签： linux performance caching profiling computer-architecture

【解决方案1】：

有多种工具可用于查找缓存未命中的根本原因。但是很多未命中并不总是意味着更长的执行时间。它还取决于缓存未命中级别。

此外，建议进行一到两次观察运行，而不收集统计信息来预热缓存（即，用数据填充它们）：后续运行将受益于第一次使用必要数据预热缓存的运行。

dprof 之类的工具可以帮助您查找由于缓存未命中导致的原因和性能问题。试试看。

【讨论】：

@.GHugo 感谢您的回复和工具链接！我相信 perf 工具中的缓存未命中事件会计算由于所有级别的缓存（在本例中为 3）中的未命中而导致的内存访问次数。那么这些额外的未命中如何不影响执行时间呢？以及为什么第 3、4 和 6 次观察没有利用已经预热的缓存？
如果没有有关您的工作负载的更多信息，您无法解释行为：它是多线程/进程吗？矩阵存储在哪里？（例如，内存、文件）等。我的意思是缓存未命中并不是一切，您的应用程序中可能有很多其他性能热点。 perf 测量的缓存未命中也可以附加到内核中，其中会发生许多不同的机制并可能影响缓存内容。试试 dprof，它应该可以帮助您了解缓存未命中的原因。
perf 具有仅捕获用户级缓存未命中的选项：perf stat -e cache-misses:u。看看缓存未命中的差异是在内核还是用户级代码上会很有趣。
@.GHugo，感谢您的解释。我会用 :u 试试 dprof 和 perf 看看发生了什么。