performance - 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

(缓存未命中数)/(指令数)很低，约为 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 更受 CPU 限制)内存限制是一种图像过滤算法)。

我正在运行的机器是 Xeon E5-2680(20M 智能缓存，其中每核 256KB L2 缓存，8 核)。

Answer 1

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

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

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

Perf 从来都不太擅长解释这些指标。从数量级来看，缓存引用是命中 LLC 的 L2 未命中。如果 LLC 引用/#Instructions 的数量很少，那么与 LLC 引用相比，高 LLC 未命中数并不总是一件坏事。在您的情况下，您有 0.018，这意味着您的大部分数据都来自 L2。高 LLC 未命中率意味着您仍然需要从 RAM 中获取数据并将其写回。

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

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

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

最后的建议:您可能有兴趣试用 Intel 的 vTune Amplifier。它对指标提供了更好的解释，并为您指出代码中的最终问题。