4

能够分析其二进制文件实际上将在模拟器 (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 的指令量（与示例输出中的指令量相反），以便以确定的方式获得执行代码的数量？

4

1 回答 1

2

摘要：

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

2) 如果您的 CPU 支持，您可以使用硬件偶数计数器找到获取的指令数。但是，这将比退役指令的数量变化更多（这是 perf 通常报告的指令）。

细节：

如果您希望执行确定数量的指令，则该sleep命令不是一个好的测试用例。它将执行不确定数量的指令，因为内核正在执行的操作会有一些细微的变化。

instructions:u您可以使用for user-mode 或instructions:kfor kernel mode指定是收集用户模式还是内核模式指令计数。对于两次运行：

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略有不同。这是非决定论的根源。但是，用户模式指令的数量比内核模式指令的变化要小。

于 2014-12-02T16:33:50.810 回答