爲什麼在Linux性能計數器中指令的數量不確定

Question

爲了能夠分析其二進制文件實際上將在模擬器（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的指令數量（與示例輸出中的指令數量相反），以便確定執行代碼的數量辦法？

Answer 1

摘要：

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實際經過的時間略有不同。這是非確定性的來源。但是，用戶模式指令的數量與內核模式指令相比變化較小。