perf stat统计的单位

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数据缓存; 事件的最后一级缓存(通常是L2或L3,具体取决于您的平台)cache-.

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                 

周期是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的26M引用cache-references,其中一半(13M)是L3未命中(cache-misses由主RAM内存服务).另一半是L3命中.

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