Question

我出于某些目的使用perf stat并且为了更好地理解该工具的工作，我编写了一个程序，将文件的内容复制到另一个文件中。我在一个750MB的文件上运行该程序，统计数据低于

   31691336329 L1-dcache-loads                                             
      44227451 L1-dcache-load-misses       
   15596746809 L1-dcache-stores                                            
      20575093 L1-dcache-store-misses                                      
      26542169 cache-references                                            
      13410669 cache-misses                 
   36859313200 cycles                            
   75952288765 instructions                      
      26542163 cache-references

每个号码的单位是多少。我的意思是。是比特/字节/或其他东西。提前致谢。

Answer 1

该单元是“单一缓存访问”，用于加载，存储，引用和未命中。负载对应于由处理器执行的加载指令的数量;同样适用于商店。遗漏是计数，有多少负载和存储无法从此级别的缓存中加载数据：L1-dcache-事件的L1数据缓存; cache-事件的最后一级缓存（通常为L2或L3，具体取决于您的平台）。

31 691 336 329 L1-dcache-loads                                             
    44 227 451 L1-dcache-load-misses       
15 596 746 809 L1-dcache-stores                                            
    20 575 093 L1-dcache-store-misses                                      


    26 542 169 cache-references                                            
    13 410 669 cache-misses

Cycles是CPU执行程序的CPU计时器的总计数。如果你有3 GHz CPU，最多每秒约有3 000 000 000个周期。如果机器繁忙，则程序可用的循环次数会减少

36 859 313 200 cycles

这是从您的程序执行的指令总数：

75 952 288 765 instructions

（我将使用G后缀作为十亿的缩写）

从数字我们可以得出结论：76G指令在37G周期内执行（每个cpu tick约2个指令，而IPC的高级别）。您没有提供CPU及其频率的信息，但假设3 GHz CPU，则运行时间接近12秒。

在76G指令中，您有31G加载指令（42％）和15G存储指令（21％）;所以只有37％的指令没有内存指令。我不知道，内存引用的大小是多少（是字节加载和存储，2字节还是宽SSE movs），但31G加载指令对于750 MB文件来说看起来太高（平均值是0.02字节;但是最短的负载）并且存储是单字节）。所以我认为你的程序做了几个数据副本;或者文件更大。在12秒内750 MB看起来相当慢（60 MBytes / s），但如果第一个文件被读取并且第二个文件被写入磁盘而没有Linux内核缓存，那么这可能是真的（你有fsync()在您的程序中调用？您是否对CPU或硬盘进行了分析？）。使用缓存文件和/或RAMdrive（tmpfs - 文件系统，存储在RAM内存中），速度应该更高。

现代版本的perf在perf stat中进行了一些简单的计算，也可以打印单位，如下所示：http://www.bnikolic.co.uk/blog/hpc-prof-events.html

perf stat -d  md5sum *

    578.920753 task-clock                #    0.995 CPUs utilized
           211 context-switches          #    0.000 M/sec
             4 CPU-migrations            #    0.000 M/sec
           212 page-faults               #    0.000 M/sec
 1,744,441,333 cycles                    #    3.013 GHz                     [20.22%]
 1,064,408,505 stalled-cycles-frontend   #   61.02% frontend cycles idle    [30.68%]
   104,014,063 stalled-cycles-backend    #    5.96% backend  cycles idle    [41.00%]
 2,401,954,846 instructions              #    1.38  insns per cycle
                                         #    0.44  stalled cycles per insn [51.18%]
    14,519,547 branches                  #   25.080 M/sec                   [61.21%]
       109,768 branch-misses             #    0.76% of all branches         [61.48%]
   266,601,318 L1-dcache-loads           #  460.514 M/sec                   [50.90%]
    13,539,746 L1-dcache-load-misses     #    5.08% of all L1-dcache hits   [50.21%]
             0 LLC-loads                 #    0.000 M/sec                   [39.19%]
(wrongevent?)0 LLC-load-misses           #    0.00% of all LL-cache hits    [ 9.63%]

   0.581869522 seconds time elapsed

更新2014年4月18日

请解释为什么缓存引用与L1-dcache数字无关

缓存引用与L1-dcache数相关联。 cache-references接近L1-dcache-store-misses或L1-dcache-load-misses。为什么数字不相等？因为在您的CPU（Core i5-2320）中有3级缓存：L1，L2，L3;和LLC（最后一级缓存）是L3。因此，在第一次尝试时加载或存储指令以从L1缓存中获取/保存数据（L1-dcache-loads，L1-dcache-stores）。如果地址未在L1中缓存，则请求将转到L2（L1-dcache-load-misses，L1-dcache-store-misses）。在此次运行中，我们没有确切的数据表明L2提供了多少请求（计数器未包含在perf stat中的默认设置中）。但是我们可以假设有些货物/商店已经送达，而有些则没有。然后，L2请求不会发送给L3（LLC），我们看到有L3M（cache-references）有26M个引用，其中一半（13M）是L3未命中（cache-misses;由主RAM内存服务）。另外一半是L3命中。

44M + 20M =来自L1的64M未命中传递给L2。 26M请求从L2传递到L3 - 它们是L2未命中。所以64M-26M = 3800万请求由L2服务（12次点击）。

perf stat统计的单位

1 个答案: