C ++プロファイリング技術の調査
この回答では、いくつかの異なるツールを使用して、いくつかの非常に単純なテストプログラムを分析し、それらのツールの動作を具体的に比較します。
次のテストプログラムは非常に単純で、次のことを行います。
main呼び出しfastとmaybe_slow3回、maybe_slow呼び出しの1つが遅い
の遅い呼び出しmaybe_slowは10倍長く、子関数の呼び出しを考慮するとランタイムを支配しますcommon。理想的には、プロファイリングツールが特定の遅い呼び出しを示すことができるようになります。
プログラム実行の大部分を占めるfastとmaybe_slow呼び出しの両方common
プログラムインターフェイスは次のとおりです。
./main.out [n [seed]]
そしてプログラムはO(n^2)合計でループします。seedランタイムに影響を与えずに異なる出力を取得するだけです。
main.c
#include <inttypes.h>
#include <stdio.h>
#include <stdlib.h>
uint64_t __attribute__ ((noinline)) common(uint64_t n, uint64_t seed) {
for (uint64_t i = 0; i < n; ++i) {
seed = (seed * seed) - (3 * seed) + 1;
}
return seed;
}
uint64_t __attribute__ ((noinline)) fast(uint64_t n, uint64_t seed) {
uint64_t max = (n / 10) + 1;
for (uint64_t i = 0; i < max; ++i) {
seed = common(n, (seed * seed) - (3 * seed) + 1);
}
return seed;
}
uint64_t __attribute__ ((noinline)) maybe_slow(uint64_t n, uint64_t seed, int is_slow) {
uint64_t max = n;
if (is_slow) {
max *= 10;
}
for (uint64_t i = 0; i < max; ++i) {
seed = common(n, (seed * seed) - (3 * seed) + 1);
}
return seed;
}
int main(int argc, char **argv) {
uint64_t n, seed;
if (argc > 1) {
n = strtoll(argv[1], NULL, 0);
} else {
n = 1;
}
if (argc > 2) {
seed = strtoll(argv[2], NULL, 0);
} else {
seed = 0;
}
seed += maybe_slow(n, seed, 0);
seed += fast(n, seed);
seed += maybe_slow(n, seed, 1);
seed += fast(n, seed);
seed += maybe_slow(n, seed, 0);
seed += fast(n, seed);
printf("%" PRIX64 "\n", seed);
return EXIT_SUCCESS;
}
gprof
gprofは、ソフトウェアを計装で再コンパイルする必要があり、また、その計装とともにサンプリングアプローチを使用します。したがって、精度（サンプリングは常に完全に正確であるとは限らず、関数をスキップできる）と実行速度の低下（計装とサンプリングは実行速度をあまり低下させない比較的高速な手法）の間でバランスを取ります。
gprofはGCC / binutilsに組み込まれ-pgているため、gprofを有効にするオプションを指定してコンパイルするだけで済みます。次に、通常は数秒（10000）の妥当な期間の実行を生成するサイズCLIパラメーターを使用してプログラムを実行します。
gcc -pg -ggdb3 -O3 -std=c99 -Wall -Wextra -pedantic -o main.out main.c
time ./main.out 10000
教育上の理由から、最適化を有効にせずに実行も行います。通常、最適化されたプログラムのパフォーマンスの最適化のみに関心があるため、これは実際には役に立たないことに注意してください。
gcc -pg -ggdb3 -O0 -std=c99 -Wall -Wextra -pedantic -o main.out main.c
./main.out 10000
最初に、time実行時間と実行時間-pgは同じだったと言っています。ただし、たとえばこのチケットに示されているように、複雑なソフトウェアの2倍から3倍の速度低下の説明を見たことがある。
でコンパイルしたため-pg、プログラムを実行すると、gmon.outプロファイリングデータを含むファイルファイルが生成されます。
次のgprof2dot質問で、そのファイルをグラフィカルに観察できます。gprofの結果をグラフィカルに表示することはできますか？
sudo apt install graphviz
python3 -m pip install --user gprof2dot
gprof main.out > main.gprof
gprof2dot < main.gprof | dot -Tsvg -o output.svg
ここで、gprofツールはgmon.outトレース情報を読み取り、人間が読めるレポートをで生成します。レポートはmain.gprof、gprof2dotグラフを生成するために読み取られます。
gprof2dotのソース：https : //github.com/jrfonseca/gprof2dot
-O0実行時に次のことが観察されます。
そして-O3実行のために：
-O0出力はかなり自明です。たとえば、3つのmaybe_slow呼び出しとその子呼び出しが合計実行時間の97.56％を占めることを示していますが、子maybe_slowなしでそれ自体を実行すると、合計実行時間の0.00％を占めます。つまり、その関数で費やされた時間のほとんどすべてが子が呼び出します。
TODO：GDBで見ることができるのにmain、なぜ-O3出力から欠落しているのbtですか？GProfの出力から関数が欠落しているのは、gprofがコンパイルされたインストルメンテーションに加えてサンプリングベースであるためだと思い-O3 mainます。高速すぎてサンプルがありません。
PNGではなくSVG出力を選択します。SVGはCtrl + Fで検索可能であり、ファイルサイズは約10倍小さくできるためです。また、生成された画像の幅と高さは、複雑なソフトウェアでは数万ピクセルeogと非常に不自然で、PNGの場合はGNOME 3.28.1でバグが発生しますが、SVGはブラウザーによって自動的に開かれます。ただし、gimp 2.8はうまく機能しました。以下も参照してください。
しかし、それでも、画像をたくさんドラッグして必要なものを見つけます。たとえば、このチケットから取得した「実際の」ソフトウェアの例からこの画像を参照してください。
並べ替えられていない小さなすべてのスパゲッティラインが互いに重なり合うことで、最も重要なコールスタックを簡単に見つけることができますか？dot確かにもっと良いオプションがあるかもしれませんが、今はそこに行きたくありません。私たちが本当に必要としているのは、そのための適切な専用ビューアですが、まだ見つかりません。
ただし、カラーマップを使用して、これらの問題を少し軽減することができます。たとえば、前の巨大な画像で、緑が赤の後に続き、最後に濃い青が続くという見事な演繹を行ったとき、私はようやく左側のクリティカルパスを見つけることができました。
または、gprof以前に保存した組み込みのbinutilsツールのテキスト出力を確認することもできます。
cat main.gprof
デフォルトでは、これにより、出力データの意味を説明する非常に詳細な出力が生成されます。それ以上は説明できないので、自分で読んでもらいましょう。
データ出力形式を理解したら、冗長性を減らして、-bオプションなしのチュートリアルなしでデータのみを表示できます。
gprof -b main.out
この例では、出力は次のものでした-O0。
Flat profile:
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds seconds calls s/call s/call name
100.35 3.67 3.67 123003 0.00 0.00 common
0.00 3.67 0.00 3 0.00 0.03 fast
0.00 3.67 0.00 3 0.00 1.19 maybe_slow
Call graph
granularity: each sample hit covers 2 byte(s) for 0.27% of 3.67 seconds
index % time self children called name
0.09 0.00 3003/123003 fast [4]
3.58 0.00 120000/123003 maybe_slow [3]
[1] 100.0 3.67 0.00 123003 common [1]
-----------------------------------------------
<spontaneous>
[2] 100.0 0.00 3.67 main [2]
0.00 3.58 3/3 maybe_slow [3]
0.00 0.09 3/3 fast [4]
-----------------------------------------------
0.00 3.58 3/3 main [2]
[3] 97.6 0.00 3.58 3 maybe_slow [3]
3.58 0.00 120000/123003 common [1]
-----------------------------------------------
0.00 0.09 3/3 main [2]
[4] 2.4 0.00 0.09 3 fast [4]
0.09 0.00 3003/123003 common [1]
-----------------------------------------------
Index by function name
[1] common [4] fast [3] maybe_slow
そしてのために-O3：
Flat profile:
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds seconds calls us/call us/call name
100.52 1.84 1.84 123003 14.96 14.96 common
Call graph
granularity: each sample hit covers 2 byte(s) for 0.54% of 1.84 seconds
index % time self children called name
0.04 0.00 3003/123003 fast [3]
1.79 0.00 120000/123003 maybe_slow [2]
[1] 100.0 1.84 0.00 123003 common [1]
-----------------------------------------------
<spontaneous>
[2] 97.6 0.00 1.79 maybe_slow [2]
1.79 0.00 120000/123003 common [1]
-----------------------------------------------
<spontaneous>
[3] 2.4 0.00 0.04 fast [3]
0.04 0.00 3003/123003 common [1]
-----------------------------------------------
Index by function name
[1] common
各セクションの非常に簡単な要約として：
0.00 3.58 3/3 main [2]
[3] 97.6 0.00 3.58 3 maybe_slow [3]
3.58 0.00 120000/123003 common [1]
インデントされたままの関数を中心に配置します（maybe_flow）。[3]その関数のIDです。関数の上に呼び出し元があり、その下に呼び出し先があります。
については-O3、ここではグラフィカル出力のように、既知の親がないことmaybe_slowを参照してくださいfast。これは、ドキュメントに書かれているとおりです<spontaneous>。
gprofで行ごとのプロファイリングを行う良い方法があるかどうかはわかりません：特定のコード行で費やされた `gprof`時間
valgrind callgrind
valgrindは、valgrind仮想マシンを介してプログラムを実行します。これにより、プロファイリングは非常に正確になりますが、プログラムの速度が非常に遅くなります。また、以前にkcachegrindについて言及しました：コードの絵の関数呼び出しグラフを取得するツール
callgrindは、コードをプロファイルするvalgrindのツールであり、kcachegrindは、cachegrind出力を視覚化できるKDEプログラムです。
最初に-pg、通常のコンパイルに戻るにはフラグを削除する必要がProfiling timer expiredあります。そうしないと、実行は実際にで失敗します。そうです、これは非常に一般的であり、スタックオーバーフローの質問がありました。
したがって、次のようにコンパイルして実行します。
sudo apt install kcachegrind valgrind
gcc -ggdb3 -O3 -std=c99 -Wall -Wextra -pedantic -o main.out main.c
time valgrind --tool=callgrind valgrind --dump-instr=yes \
--collect-jumps=yes ./main.out 10000
--dump-instr=yes --collect-jumps=yesこれは、比較的小さな追加のオーバーヘッドコストで、アセンブリラインごとのパフォーマンスの内訳を表示できる情報もダンプするので、有効にします。
バット、timeプログラムを実行するために29.5秒かかったので、私たちは、この例の15倍程度の減速を持っていたことを教えてくれる。明らかに、このスローダウンは、より大きなワークロードにとって深刻な制限となるでしょう。ここで言及した「実際のソフトウェアの例」では、80倍の速度低下が見られました。
実行すると、callgrind.out.<pid>たとえばcallgrind.out.8554私の場合はという名前のプロファイルデータファイルが生成されます。そのファイルは次のように表示されます。
kcachegrind callgrind.out.8554
これは、テキストのgprof出力に類似したデータを含むGUIを示しています。
また、右下の「コールグラフ」タブに移動すると、右クリックしてエクスポートできるコールグラフが表示され、次の画像に無理な量の白い境界線が表示されます:-)
fastkcachegrindは視覚化を単純化する必要があるため、そのグラフに表示されていないと思います。これは、呼び出しにかかる時間が少なすぎるためです。これは、実際のプログラムで必要な動作になる可能性があります。右クリックメニューには、そのようなノードをカリングするタイミングを制御するためのいくつかの設定がありますが、すばやく試行した後、そのような短い呼び出しを表示することができませんでした。fast左側のウィンドウをクリックすると、で呼び出しグラフが表示されるfastため、スタックが実際にキャプチャされました。完全なグラフ呼び出しグラフを表示する方法はまだ誰も見つけていませんでした：callgrindにすべての関数呼び出しをkcachegrind呼び出しグラフに表示させる
複雑なC ++ソフトウェアでTODOを実行すると、typeのエントリがいくつか表示されます<cycle N>。たとえば<cycle 11>、関数名を予期している場合、それはどういう意味ですか？オンとオフを切り替える「サイクル検出」ボタンがあることに気づきましたが、どういう意味ですか？
perf から linux-tools
perfLinuxカーネルサンプリングメカニズムのみを使用しているようです。これにより、セットアップが非常に簡単になりますが、完全に正確ではありません。
sudo apt install linux-tools
time perf record -g ./main.out 10000
これにより、実行に0.2秒が追加されたので、時間的には問題ありませんcommonが、キーボードの右矢印でノードを展開した後は、あまり関心がありません。
Samples: 7K of event 'cycles:uppp', Event count (approx.): 6228527608
Children Self Command Shared Object Symbol
- 99.98% 99.88% main.out main.out [.] common
common
0.11% 0.11% main.out [kernel] [k] 0xffffffff8a6009e7
0.01% 0.01% main.out [kernel] [k] 0xffffffff8a600158
0.01% 0.00% main.out [unknown] [k] 0x0000000000000040
0.01% 0.00% main.out ld-2.27.so [.] _dl_sysdep_start
0.01% 0.00% main.out ld-2.27.so [.] dl_main
0.01% 0.00% main.out ld-2.27.so [.] mprotect
0.01% 0.00% main.out ld-2.27.so [.] _dl_map_object
0.01% 0.00% main.out ld-2.27.so [.] _xstat
0.00% 0.00% main.out ld-2.27.so [.] __GI___tunables_init
0.00% 0.00% main.out [unknown] [.] 0x2f3d4f4944555453
0.00% 0.00% main.out [unknown] [.] 0x00007fff3cfc57ac
0.00% 0.00% main.out ld-2.27.so [.] _start
それで、-O0プログラムをベンチマークして、それが何かを示しているかどうかを確認しようとしましたが、ついに、ようやくコールグラフが表示されるようになりました。
Samples: 15K of event 'cycles:uppp', Event count (approx.): 12438962281
Children Self Command Shared Object Symbol
+ 99.99% 0.00% main.out [unknown] [.] 0x04be258d4c544155
+ 99.99% 0.00% main.out libc-2.27.so [.] __libc_start_main
- 99.99% 0.00% main.out main.out [.] main
- main
- 97.54% maybe_slow
common
- 2.45% fast
common
+ 99.96% 99.85% main.out main.out [.] common
+ 97.54% 0.03% main.out main.out [.] maybe_slow
+ 2.45% 0.00% main.out main.out [.] fast
0.11% 0.11% main.out [kernel] [k] 0xffffffff8a6009e7
0.00% 0.00% main.out [unknown] [k] 0x0000000000000040
0.00% 0.00% main.out ld-2.27.so [.] _dl_sysdep_start
0.00% 0.00% main.out ld-2.27.so [.] dl_main
0.00% 0.00% main.out ld-2.27.so [.] _dl_lookup_symbol_x
0.00% 0.00% main.out [kernel] [k] 0xffffffff8a600158
0.00% 0.00% main.out ld-2.27.so [.] mmap64
0.00% 0.00% main.out ld-2.27.so [.] _dl_map_object
0.00% 0.00% main.out ld-2.27.so [.] __GI___tunables_init
0.00% 0.00% main.out [unknown] [.] 0x552e53555f6e653d
0.00% 0.00% main.out [unknown] [.] 0x00007ffe1cf20fdb
0.00% 0.00% main.out ld-2.27.so [.] _start
TODO：-O3実行時に何が起こりましたか？それは単にそれでmaybe_slowあり、fast速すぎてサンプルを取得しませんでしたか？-O3実行に時間がかかる大きなプログラムでもうまく機能しますか？一部のCLIオプションを見逃しましたか？-Fヘルツでサンプル周波数を制御しようとしましたが、デフォルトで許可されている最大値-F 39500（で増加可能sudo）まで上げましたが、明確な呼び出しが表示されません。
perfすばらしい点の1つは、Brendan GreggのFlameGraphツールです。これにより、コールスタックのタイミングが非常にきちんと表示され、大きなコールをすばやく確認できます。このツールは、https：//github.com/brendangregg/FlameGraphで入手できます。また、彼のperfチュートリアルでも言及されています。http：//www.brendangregg.com/perf.html#FlameGraphs perfなしで実行するsudoとERROR: No stack counts found、今私はそれでやりますsudo：
git clone https://github.com/brendangregg/FlameGraph
sudo perf record -F 99 -g -o perf_with_stack.data ./main.out 10000
sudo perf script -i perf_with_stack.data | FlameGraph/stackcollapse-perf.pl | FlameGraph/flamegraph.pl > flamegraph.svg
しかし、このような単純なプログラムでは、グラフmaybe_slowもfastグラフも簡単に確認できないため、出力を理解するのは簡単ではありません。
より複雑な例では、グラフの意味が明らかになります。
TODO [unknown]その例には関数のログがありますが、それはなぜですか？
価値があると思われる別のパフォーマンスGUIインターフェイスには、次のものがあります。
gperftools
以前は「Google Performance Tools」と呼ばれていました。ソース：https : //github.com/gperftools/gperftoolsサンプルベース。
最初にgperftoolsをインストールします：
sudo apt install google-perftools
次に、実行時とビルド時の2つの方法でgperftools CPUプロファイラーを有効にできます。
実行時に、をLD_PRELOAD指すようにsetを渡すlibprofiler.so必要があります。これはlocate libprofiler.so、たとえば、私のシステムで、で見つけることができます。
gcc -ggdb3 -O3 -std=c99 -Wall -Wextra -pedantic -o main.out main.c
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libprofiler.so \
CPUPROFILE=prof.out ./main.out 10000
または、リンク時にライブラリをビルドして、LD_PRELOAD実行時にパスをディスペンスすることもできます。
gcc -Wl,--no-as-needed,-lprofiler,--as-needed -ggdb3 -O3 -std=c99 -Wall -Wextra -pedantic -o main.out main.c
CPUPROFILE=prof.out ./main.out 10000
参照：gperftools-ダンプされないプロファイルファイル
これまでに見つけたこのデータを表示する最も良い方法は、pprofの出力をkcachegrindが入力として取るのと同じ形式（そう、Valgrind-project-viewer-tool）にし、kcachegrindを使用してそれを表示することです。
google-pprof --callgrind main.out prof.out > callgrind.out
kcachegrind callgrind.out
これらの方法のいずれかで実行した後prof.out、出力としてプロファイルデータファイルを取得します。以下のようにして、そのファイルをSVGとしてグラフィカルに表示できます。
google-pprof --web main.out prof.out
これは、他のツールと同じように、おなじみのコールグラフとして提供されますが、秒数ではなくサンプル数の不格好な単位を使用しています。
あるいは、次のようにしてテキストデータを取得することもできます。
google-pprof --text main.out prof.out
それは与える：
Using local file main.out.
Using local file prof.out.
Total: 187 samples
187 100.0% 100.0% 187 100.0% common
0 0.0% 100.0% 187 100.0% __libc_start_main
0 0.0% 100.0% 187 100.0% _start
0 0.0% 100.0% 4 2.1% fast
0 0.0% 100.0% 187 100.0% main
0 0.0% 100.0% 183 97.9% maybe_slow
参照：Google Perfツールの使用方法
Ubuntu 18.04、gprof2dot 2019.11.30、valgrind 3.13.0、perf 4.15.18、Linuxカーネル4.15.0、FLameGraph 1a0dc6985aad06e76857cf2a354bd5ba0c9ce96b、gperftools 2.5-2でテスト済み。
