当perf stat没有提供线索时,我怎样才能解释一个较慢的执行?

我的程序测量执行500次函数所需的时间(这个时间约为14秒),并报告每次执行的平均时间。 由于精确的时间测量很重要,所以我非常小心地去除时间测量中所有可能的噪音源。

  1. 该程序在Ubuntu 14.04下运行,具有root权限, nice -n -20 ,在屏蔽的CPU上(使用-k on选项来cset shield )。

  2. 超线程被禁用。

  3. 内存只被分配一次,以避免由于malloc导致的上下文切换。

  4. 在计时开始之前执行一个大的memset500预热function执行,试图在定时器启动之前获得类似的数据高速caching状态。 该程序是相当小的,所以我不担心指令caching。

  5. 时间是以clock_gettime(CLOCK_MONOTONIC)返回的两个值的差值来clock_gettime(CLOCK_MONOTONIC)

下面是从连续5次运行的报告时间(以毫秒为单位,但是测量的时间是这次的500次,所以它是大约14秒): 28.77 。 请注意,这里有三个非常一致的时序结果(#1,#3和#4)。 我正在寻求帮助来理解和消除exception值的来源。 以下是第一次和最后一次运行的性能perf stat报告:

第一次运行:

  29176.113027 task-clock (msec) # 0.999 CPUs utilized 596 context-switches # 0.020 K/sec 0 cpu-migrations # 0.000 K/sec 5,061 page-faults # 0.173 K/sec 104,825,303,791 cycles # 3.593 GHz <not supported> stalled-cycles-frontend <not supported> stalled-cycles-backend 104,316,069,689 instructions # 1.00 insns per cycle 19,672,922,035 branches # 674.282 M/sec 346,005,888 branch-misses # 1.76% of all branches 

上次运行:

  30003.678991 task-clock (msec) # 0.999 CPUs utilized 417 context-switches # 0.014 K/sec 0 cpu-migrations # 0.000 K/sec 4,945 page-faults # 0.165 K/sec 107,799,951,303 cycles # 3.593 GHz <not supported> stalled-cycles-frontend <not supported> stalled-cycles-backend 104,310,601,483 instructions # 0.97 insns per cycle 19,671,642,624 branches # 655.641 M/sec 345,885,486 branch-misses # 1.76% of all branches 30.023661486 seconds time elapsed 

我没有注意到这些统计数据中的任何内容,这些数据都会提供一个线索,说明为什么最后一次运行比第一次慢。 我非常感谢这方面的帮助。

编辑:有人注意到,每个循环的说明数是不同的。 find这个差异的根本原因是很好的。

Solutions Collecting From Web of "当perf stat没有提供线索时,我怎样才能解释一个较慢的执行?"