Performance 性能统计输出的解释

我开发了一个代码，可以获取一个大的二维图像（高达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%。有人提到，在检查内存效率时，记住这个数字是一件好事

另一方面，缓存引用的缓存未命中率非常高（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限制）

---

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

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

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

我建议在优化阶段禁用超线程，因为这可能会在解释评测指标时导致混淆。（例如，在后端花费的周期增加）。另外，如果您将工作分配给3个线程，那么2个线程很有可能共享一个核心的资源，而第3个线程将拥有整个核心—而且速度会更快

Perf从来没有很好地解释过这些指标。根据数量级判断，缓存引用是命中LLC的二级未命中。如果LLC引用/#指令的数量较低，则与LLC引用相比，较高的LLC未命中数并不总是一件坏事。在您的例子中，您有0.018，这意味着您的大部分数据都是从L2使用的。高LLC未命中率意味着您仍然需要从RAM获取数据并将其写回

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

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

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

---

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

koukouviou，

perf stat-d

可能不准确，可以使用每次运行4-5个事件来多次重新运行它，

perf stat-e L1 dcache加载、L1 dcache加载未命中、LLC加载、LLC加载未命中

。如果你的阶段可以分开，你可以测量每一个阶段，找出哪一个阶段会产生失误。或者，您可以运行

perf record-e cache misses

，以获取未命中率最高的代码配置文件（正如您链接中所建议的）。@osgx我已经完成了您提到的测试，但帖子已经很长了，所以我尽可能简短。虽然统计数据有点变化，但在统计上保持相似，缓存未命中率较高。我已经运行了perf record/report/annotate，未命中主要归因于内核kallsyms，但我不知道该怎么做……koukouviou，您可以在所有事件限制在用户空间的情况下重新运行stat:

perf stat-e event1:u，event2:u，

并与发布的结果进行比较（默认情况下，用户和内核都是测量的）。内核kallsyms意味着内核空间中的某个函数有这个事件。。。此处列出了未知/未解决符号的一些可能问题：。我不能给你关于指标的建议……VAndrei、BE和FE暂停永远不会与100%周期的指令相加，因为大多数Intel CPU都是超级流水线的。许多指令可能正在管道中运行，有些指令会产生停顿；但有些人将被处决。71%的FE暂停是高的（你有很多代码，这是复杂的解码？），51%的BE暂停也是相当高的-所以有几个问题。。。koukouviou，您也可以尝试将

toplev.py

作为Vtune的免费缓和剂。@osgx。我不太确定。FE bound表示预订单元没有收到指令，因此没有