为什么在Linux性能计数器中指令的数量是不确定的

为了能够剖析应用程序运行时的二进制文件实际上将在模拟器(NS-3 / DCE)下运行。 我想使用Linux性能计数器,我预计指令计数的应用程序没有非确定性的来源是确定性的。 根据linux性能计数器,我不能再犯错了,我们举一个简单的例子:

$ (perf stat -c -- sleep 1 2>&1 && perf stat -c -- sleep 1 2>&1) |grep instructions 669218 instructions # 0,61 insns per cycle 682286 instructions # 0,58 insns per cycle 

1)这个非确定性的来源是什么? 这是否源于CPU中的低级分支预测和其他引擎?

2)还有一个问题,是否有办法知道提供给CPU的指令数量(与示例输出中的指令数量形成对比),以确定性地获取执行代码的数量?

Solutions Collecting From Web of "为什么在Linux性能计数器中指令的数量是不确定的"

总结

1)非确定性是由sleep 1命令的变化引起的,而不是来自分支预测或其他微体系结构特征。

2)如果您的CPU支持,您可以使用硬件偶数计数器找到取指的数量。 然而,这将会比退休指令的数量(这通常是指令报告的指令)的数量有所不同。

细节:

如果需要确定数量的指令执行, sleep命令不是一个好的测试用例。 它会执行一个非确定的数目的指令,因为内核在做什么会有一些细微的变化。

您可以指定是否收集用户模式或内核模式指令计数instructions:u表示用户模式或instructions:k表示内核模式。 对于两个运行:

 perf stat -e instructions:k,instructions:u,instructions sleep 1 

我得到以下结果:

 Performance counter stats for 'sleep 1': 373,044 instructions:k # 0.00 insns per cycle 199,795 instructions:u # 0.00 insns per cycle 572,839 instructions # 0.00 insns per cycle 1.001018153 seconds time elapsed 

 Performance counter stats for 'sleep 1': 379,722 instructions:k # 0.00 insns per cycle 199,970 instructions:u # 0.00 insns per cycle 579,519 instructions # 0.00 insns per cycle 1.000986201 seconds time elapsed 

正如你所看到的,实际的sleep 1时间sleep 1略有不同。 这是非确定性的来源。 但是,用户模式指令的数量与内核模式指令相比变化较小。