私は callgrind を使用して Linux マルチスレッド アプリのプロファイリングを行っていますが、ほとんどの場合うまく機能しています。インストルメンテーションをオフ ( --instr-atstart=no ) で開始し、セットアップが完了したら、 callgrind_control -i on でオンにします。ただし、特定の構成を変更してアプリの別の部分をプロファイリングしようとすると、インストルメンテーションをオンにする前でも実行が非常に遅くなります。基本的に、通常の操作では数秒かかるコードの一部が、callgrind (インスツルメンテーションがオフ) では 1 時間以上かかります。その理由と、遅さのデバッグ/解決方法についてのアイデアはありますか?
1 に答える
Callgrind は valgrind 上に構築されたツールです。Valgrind は基本的に動的バイナリ トランスレータです (libVEX、valgrind の一部)。すべての命令をデコードし、それらを同じ CPU のいくつかの命令のストリームに JIT コンパイルします。
私が知っているように、既に実行中のプロセスに対してこの変換を (valgrind 実装で) 有効にする方法はないため、動的変換はプログラムの開始時から常に有効になっています。これもオフにできません。
ツールは、いくつかのインストルメンテーション コードを追加することにより、valgrind に構築されます。「Nul」ツール (nulgrind) は、インストルメンテーションを追加しないツールです。しかし、すべてのツールは valgrind を使用しており、動的変換は常にアクティブです。callgrind でオンとオフを切り替えることは、追加のインストルメンテーションをオンとオフにするだけです。
Valgrind によって実装される仮想 CPU には制限があり、(不完全な) 制限のリストがありますhttp://valgrind.org/docs/manual/manual-core.html#manual-core.limitsほとんどの制限は浮動小数点演算に関するものです。それらは間違ってエミュレートされる可能性があります。
変更は浮動小数点演算に関連していますか? または、リストされている他の制限がありますか?
また、「 Valgrind は一度に 1 つのスレッドのみが実行されるように実行をシリアル化する」ことも知っておく必要があります。(同ページ manual-core.html より)