linux中的运行时和报告周期计数

Question

我在英特尔的4核CPU上运行了一个单线程矩阵乘法(每个内核一个线程)，但是来自perf的数字没有意义。

 Performance counter stats for 'system wide':

    31,728,397,287      cpu-cycles                #    0.462 GHz                    
   131,661,730,104      ref-cycles                # 1916.425 M/sec                  
         68,701.58 msec cpu-clock                 #    4.000 CPUs utilized          
         68,701.90 msec task-clock                #    4.000 CPUs utilized          
    31,728,553,882      cpu/cpu-cycles/           #  461.830 M/sec                  

      17.176244725 seconds time elapsed

我已将cpu频率设置为最小，并观看了它，因此，所有的核心运行在800兆赫。这意味着一个周期是1.25ns。在cpu周期为31,728,397,287的情况下，执行时间应为39.66秒，但运行时间为17.1秒。

我也不知道为什么0.462 GHz写在cpu周期前面.

有关处理器的更多信息：

Thread(s) per core:              1
Core(s) per socket:              4
Socket(s):                       1
NUMA node(s):                    1
Vendor ID:                       GenuineIntel
CPU family:                      6
Model:                           94
Model name:                      Intel(R) Core(TM) i5-6600 CPU @ 3.30GHz
Stepping:                        3
CPU MHz:                         800.022
CPU max MHz:                     3900,0000
CPU min MHz:                     800,0000

对此有什么想法吗？

更新：

我用root访问重新运行实验，并指定用户代码。

# perf stat -a -e cycles:u,cycles,cpu-clock  ./mm_double_omp 1
Using 1 threads
Total execution Time in seconds: 15.4839418610
MM execution Time in seconds: 15.3758427450

 Performance counter stats for 'system wide':

    14,237,521,876      cycles:u                  #    0.230 GHz                    
    17,470,220,108      cycles                    #    0.282 GHz                    
         61,974.41 msec cpu-clock                 #    4.000 CPUs utilized          

      15.494002570 seconds time elapsed

正如你所看到的，频率仍然不是800兆赫。但是，如果我不指定-a，则结果是有意义的，因为周期:U*(1/800 the )几乎与经过的时间相同。

# perf stat -e cycles:u,cycles,cpu-clock  ./mm_double_omp 1
Using 1 threads
Total execution Time in seconds: 16.5347361100
MM execution Time in seconds: 16.4267430900
 Performance counter stats for './mm_double_omp 1':

    13.135.516.694      cycles:u                  #    0,794 GHz                    
    13.201.778.987      cycles                    #    0,798 GHz                    
         16.541,22 msec cpu-clock                 #    1,000 CPUs utilized          

      16,544487905 seconds time elapsed

      16,522146000 seconds user
       0,019997000 seconds sys

Answer 1

i运行了一个单线程矩阵乘法

，但是当它运行的时候，你把系统范围内的计算在所有4个核心上。是perf -a所做的，也是为什么在你的输出中有Performance counter stats for 'system wide':的原因。

因此，每当您的进程处于活动状态时，内核的task-clock“事件”就会计算所有4个内核的时间：

68,701.90毫秒任务-时钟# 4.000 CPU使用

这是68.7cpu秒，几乎正好4x17.17秒，这是合理的.

我也不知道为什么0.462 GHz写在cpu周期前面.

这是代码活动期间所有4个核心的平均周期/时间。对于处于休眠状态的CPU，时钟不会滴答作响，因此，在您的代码保持一个核心繁忙的时候，负载平均值似乎是4 * 462/800 = 2.31 CPU没有休眠。

因此，当您的系统平均运行另外1.3个线程时，您正在进行基准测试。(包括因中断而醒来的CPU时间)

我假设您的度量不局限于用户空间(不包括内核模式下的滴答)；这是另一种可能的效果。

如果您没有使用-a，如果只计算用户空间周期，而不是在内核中花费的周期，则仍然会出现比HW运行频率更低的情况。(例如，perf stat --all-user，或者您的kernel.perf_event_paranoid设置得足够高，不允许您在内核中分析HW事件，这有效地将:u应用于HW事件，但不将它们打印为cycles:u。)

如果将kernel.perf_event_paranoid sysctl设置更改为0，或以根用户身份运行perf，则应该将800 MHz作为循环/任务时钟，因为这是线程运行时的运行速度。

花费大量的周期(而不是在用户空间)将意味着您的代码在内核上花费了大量时间，如果您使用一个大数组，可能会处理页面错误。