perf stat 输出解读

Question

我开发了一个代码，该代码将大型二维图像（高达 64MPixels）作为输入，并且：

• 对每一行应用过滤器
• 转置图像（使用阻塞来避免大量缓存未命中）
• 对图像的列（现在的行）应用过滤器
• 将过滤后的图像转回以进行其他计算

虽然它没有改变什么，但为了我的问题的完整性，过滤是应用离散小波变换，代码是用 C 编写的。

我的最终目标是让它尽可能快地运行。通过使用阻塞矩阵转置、向量化、多线程、编译器友好的代码等，我迄今为止的加速超过了 10 倍。

提出我的问题：我拥有的代码（使用perf stat -e）的最新分析统计数据困扰了我。

        76,321,873 cache-references                                            
     8,647,026,694 cycles                    #    0.000 GHz                    
     7,050,257,995 instructions              #    0.82  insns per cycle        
        49,739,417 cache-misses              #   65.171 % of all cache refs    

       0.910437338 seconds time elapsed

(# of cache-misses)/(# instructions) 很低，约为 0.7%。 Here 有人提到这个数字是检查内存效率的好东西。

另一方面，缓存引用的缓存未命中百分比非常高（65%！），正如我所见，这可能表明缓存效率方面的执行出了问题。

来自perf stat -d的详细统计数据是：

   2711.191150 task-clock                #    2.978 CPUs utilized          
         1,421 context-switches          #    0.524 K/sec                  
            50 cpu-migrations            #    0.018 K/sec                  
       362,533 page-faults               #    0.134 M/sec                  
 8,518,897,738 cycles                    #    3.142 GHz                     [40.13%]
 6,089,067,266 stalled-cycles-frontend   #   71.48% frontend cycles idle    [39.76%]
 4,419,565,197 stalled-cycles-backend    #   51.88% backend  cycles idle    [39.37%]
 7,095,514,317 instructions              #    0.83  insns per cycle        
                                         #    0.86  stalled cycles per insn [49.66%]
   858,812,708 branches                  #  316.766 M/sec                   [49.77%]
     3,282,725 branch-misses             #    0.38% of all branches         [50.19%]
 1,899,797,603 L1-dcache-loads           #  700.724 M/sec                   [50.66%]
   153,927,756 L1-dcache-load-misses     #    8.10% of all L1-dcache hits   [50.94%]
    45,287,408 LLC-loads                 #   16.704 M/sec                   [40.70%]
    26,011,069 LLC-load-misses           #   57.44% of all LL-cache hits    [40.45%]

   0.910380914 seconds time elapsed

这里的前端和后端停滞周期也很高，并且较低级别的缓存似乎遭受了 57.5% 的高未命中率。

哪个指标最适合这种情况？我在想的一个想法是，工作负载可能不再需要在初始图像加载后进一步“接触”LL缓存（加载一次值，然后完成 - 工作负载比 CPU 更受限制） memory-bound 是一种图像过滤算法）。

我运行它的机器是 Xeon E5-2680（20M 智能缓存，其中每个核心 256KB 二级缓存，8 个核心）。

Answer 1

您要确保的第一件事是没有其他计算密集型进程在您的计算机上运行。那是一个服务器 CPU，所以我认为这可能是个问题。

如果您在程序中使用多线程，并且在线程之间分配相同数量的工作，您可能会对仅在一个 CPU 上收集指标感兴趣。

我建议在优化阶段禁用超线程，因为它会在解释分析指标时导致混淆。 （例如，增加后端花费的#cycles）。此外，如果您将工作分配给 3 个线程，则很有可能 2 个线程将共享一个内核的资源，而第 3 个线程将拥有整个内核 - 而且速度会更快。

Perf 从来都不善于解释指标。从数量级来看，缓存引用是命中 LLC 的 L2 未命中。如果 LLC 引用/#Instructions 的数量较低，则与 LLC 引用相比，较高的 LLC 未命中数并不总是坏事。在您的情况下，您有 0.018，这意味着您的大部分数据都是从 L2 使用的。高 LLC 未命中率意味着您仍然需要从 RAM 中获取数据并将其写回。

关于#Cycles BE 和 FE bound，我有点担心这些值，因为它们的总和不是 100% 和循环总数。您有 8G，但在 FE 中保持 6G 周期，在 BE 中保持 4G 周期。这似乎不太正确。

如果 FE 周期很高，则意味着指令缓存中存在未命中或分支推测错误。如果 BE 周期很高，则意味着您在等待数据。

无论如何，关于你的问题。评估代码性能最相关的指标是指令/周期 (IPC)。您的 CPU 最多可以执行 4 条指令/周期。你只执行 0.8。这意味着资源未被充分利用，除非您有许多向量指令。在 IPC 之后，您需要检查分支未命中和 L1 未命中（数据和代码），因为它们会产生最多的惩罚。

最后一个建议：您可能有兴趣尝试英特尔的 vTune 放大器。它可以更好地解释指标，并指出代码中的最终问题。