2016-05-17 3 views
6

Inspired by SQLite、私は、再現性、パフォーマンスのベンチマークを行うにはvalgrindのの「cachegrind」ツールを使用してで探しています。出力する数値は、他のどのタイミング方法よりもはるかに安定していますが、依然として確定的ではありません。例として、ここでは簡単なCプログラムです:なぜキャッシュグリッドは完全に決定論的ではないのですか?

int main() { 
    volatile int x; 
    while (x < 1000000) { 
    x++; 
    } 
} 

私はそれをコンパイルし、cachegrindの下でそれを実行すると、私は次のような結果を得る:この場合

$ gcc -O2 x.c -o x 
$ valgrind --tool=cachegrind ./x 
==11949== Cachegrind, a cache and branch-prediction profiler 
==11949== Copyright (C) 2002-2015, and GNU GPL'd, by Nicholas Nethercote et al. 
==11949== Using Valgrind-3.11.0.SVN and LibVEX; rerun with -h for copyright info 
==11949== Command: ./x 
==11949== 
--11949-- warning: L3 cache found, using its data for the LL simulation. 
==11949== 
==11949== I refs:  11,158,333 
==11949== I1 misses:   3,565 
==11949== LLi misses:   2,611 
==11949== I1 miss rate:  0.03% 
==11949== LLi miss rate:  0.02% 
==11949== 
==11949== D refs:  4,116,700 (3,552,970 rd + 563,730 wr) 
==11949== D1 misses:  21,119 ( 19,041 rd + 2,078 wr) 
==11949== LLd misses:   7,487 ( 6,148 rd + 1,339 wr) 
==11949== D1 miss rate:  0.5% (  0.5%  +  0.4% ) 
==11949== LLd miss rate:  0.2% (  0.2%  +  0.2% ) 
==11949== 
==11949== LL refs:   24,684 ( 22,606 rd + 2,078 wr) 
==11949== LL misses:   10,098 ( 8,759 rd + 1,339 wr) 
==11949== LL miss rate:   0.1% (  0.1%  +  0.2% ) 
$ valgrind --tool=cachegrind ./x 
==11982== Cachegrind, a cache and branch-prediction profiler 
==11982== Copyright (C) 2002-2015, and GNU GPL'd, by Nicholas Nethercote et al. 
==11982== Using Valgrind-3.11.0.SVN and LibVEX; rerun with -h for copyright info 
==11982== Command: ./x 
==11982== 
--11982-- warning: L3 cache found, using its data for the LL simulation. 
==11982== 
==11982== I refs:  11,159,225 
==11982== I1 misses:   3,611 
==11982== LLi misses:   2,611 
==11982== I1 miss rate:  0.03% 
==11982== LLi miss rate:  0.02% 
==11982== 
==11982== D refs:  4,117,029 (3,553,176 rd + 563,853 wr) 
==11982== D1 misses:  21,174 ( 19,090 rd + 2,084 wr) 
==11982== LLd misses:   7,496 ( 6,154 rd + 1,342 wr) 
==11982== D1 miss rate:  0.5% (  0.5%  +  0.4% ) 
==11982== LLd miss rate:  0.2% (  0.2%  +  0.2% ) 
==11982== 
==11982== LL refs:   24,785 ( 22,701 rd + 2,084 wr) 
==11982== LL misses:   10,107 ( 8,765 rd + 1,342 wr) 
==11982== LL miss rate:   0.1% (  0.1%  +  0.2% ) 
$ 

を、によって異なり、「私は、引用文献」 2回の走行の間にわずか0.008%であったが、なぜこれらが異なるのか不思議である。より複雑なプログラムでは(数十ミリ秒)、それらはさらに変化する可能性があります。ランを完全に再現可能にする方法はありますか? a topic in gmane.comp.debugging.valgrind、 ニコラスNethercote(Valgrindの開発チームで働くMozillaの開発者に対し)の終わりに

+0

は、例えば、分岐予測を行いません少ない洗練されたCPUを使用してください。 –

+1

私が正しく理解するならば、valgrindは自身のCPUをシミュレートし、--branch-sim = yesを渡さない限り分岐予測を行いません。それでも、CPUをシミュレートするときに分岐予測を決定論的にすることができないのはなぜですか? –

答えて

5

は小さな変化がCachegrindを使用して共通している(と私は、彼らが大きな問題にはつながらないだろうことを推測することができます)と言います。

Cachegrind’s manualは、プログラムは非常に敏感であることを言及しています。たとえば、Linuxでは、(セキュリティを向上させるために使用される)アドレス空間のランダム化が非決定論の原因となります。

注目に値するもう一つは、結果は非常に敏感であるということです。 は、プロファイルされる実行可能ファイルのサイズ、または の大きさが使用する共有ライブラリのいずれか、またはそのファイル 名の偶数の長さを変更し、結果を混乱させることができます。変化は小さいですが、 は、プログラムがまったく変化しても完全に反復可能な結果を​​期待しません。

さらに最近のGNU/Linuxディストリビューションでは、同じプログラムの同一実行にセキュリティ対策として異なる場所にロードされた共有ライブラリ がある のアドレス空間のランダム化が行われています。これも の結果を乱す。

これらの要因は、あなたが 超正確であるとの結果を信用してはならない意味が、それらは有用であるために十分に接近しているべきです。

関連する問題