問題タブ [callgrind]

複数のプロセスを生成し、それぞれでインストルメンテーションを開始しています。プロセスが終了する直前にインストルメンテーションを停止しようとすると、インストルメンテーション プログラムが、プロセスが既に終了しているかのようにシェルでハングしているように見え、インストルメンテーションを停止するプロセスがありません。コードは次のとおりです。

ハングアップの問題を解決するにはどうすればよいですか? 本当にインストルメンテーションを停止する必要がありますか?

ターミナルからプログラムのcallgrindの詳細を分析することができました...

ただし、「KcacheGrind」を使用してグラフィカルツールで結果を表示したい場合...[Source_Code]タブでデフォルトで使用できるはずのmysourceコードにアクセスできません。

誰かが何をする必要があるかを指摘できますか？

Callgrind プロファイル形式を理解しようとしています。オンラインの説明を見つけました

「拡張された例」に遭遇するまで、私はそれをかなりよく理解していると思っていました:

説明は次のとおりです。「メイン」では、16行目からのコードのみが実行され、他の関数も呼び出されることがわかります。「メイン」の包括的コストは 420 です。これは、自己コスト 20 と呼び出しで費やされたコストの合計です。

func2 のみの自己コストが既に 700 である場合、「main」の包括的コストはどのようにして 420 になりますか?

-g -O2" " でプログラムをビルドし、 valgrind+cachegrind を実行しました。出力の解釈方法がわかりません。出力は次のとおりです。

http://daviddoria.com/Uploads/callgrind.CacheMisses

私の「プログラム全体」は、InpaintingAlgorithm「メイン」の 98.4% の関数です。ここまでは順調ですね。の呼び出し先を見るとInpaintingAlgorithm、92.9% がInpaintingAlgorithmですLinearSearchKNNProperty::operator()。これは私の「内部ループ」であり、ここでも膨大な時間が費やされると予想しています。

ここで私は混乱します。の呼び出し先を見ると、LinearSearchKNNProperty::operator()本当に何もない?? 最大の関数はわずか 7.64% で、残りは < 0.25% です。すべての呼び出し先の合計が約 8% しか追加されない理由がわかりません。残りの92%はどこ?? （おそらく、それをより速くするために私が探しているものです！）

誰かがこれらの結果を読む際の私の誤りを指摘してくれたら、私はそれを感謝します!

私は自分のコードをプロファイリングしていますが、すでにその中で最も高価な部分を見つけました。ただし、インライン関数で発生します。影響を測定するために、関数をインライン化しないように強制しました。

次に、正確なプロファイリングデータを報告したいと思います。インラインがないと、大きなオーバーヘッドが発生します（関数は基本的に単一のループですが、非常に頻繁に呼び出されます）。

関数を強制的にインライン化せずに、コードの特定のセクションをそれ自体が関数（makros CALLGRIND_START_INSTRUMENTATION、CALLGRIND_STOP_INSTRUMENTATIONなど）として処理するようにvalgrindに指示できるかどうか疑問に思います。

私はc++cmd行プログラムでいくつかのコードの書き直しに取り組んでいます。

使用する低レベルのデータ構造を変更し、新しいバージョンはすべてのテストに問題なく合格し（かなり多く）、新しいバージョンと古いバージョンの両方から正しい出力を取得します...それでも、特定の入力を与えると、それらは異なる振る舞いをします。

要点：やや大きなプロジェクトであるため、実行フローが分岐したときに追跡する方法がわからないため、関数呼び出しツリー（おそらくstd呼び出しを除く）を追跡する方法があります。 、わからない、ソースファイルの行番号とソース名？多分いくつかのgccまたはマクロカンフー？

プログラムが実行される場所なので、Linuxソリューションが必要になります。

callgrindを使用するために、apacheをシグナルプロセス/デバッグモードで実行しようとしてきましたが、デバッグのために使用する単純な単一のプロセスがあります。

シングルプロセスモードでapacheを実行した経験のある人はいますか？

実行してみましたhttpd -X。これは単一のプロセスでapacheを開始できますが（良い）、このように実行しているときに、それらを再びシャットダウンするクリーンな方法が見つかりませんでした。動作する唯一の方法はkill -9です。これはデバッグ出力も吹き飛ばすので、callgrindを使用しているときはそれ以上先に進むことはありません。興味のある人のために、私が実行している完全なコマンドは次のとおりです。

どんなアイデアでもありがたいです。
ありがとう

気にしないノイズと計算を削除して、コードの特定の部分を (Callgrind で) プロファイルしようとしています。これが私がやりたいことの例です：

私のユースケースは回帰テストです。問題のメソッドがまだ十分に高速であることを確認したいと思います (最後の実装以降の追加命令が 10% 未満など)。これが、Callgrind からのよりクリーンな出力が欲しい理由です。(プロファイリングするメソッドの動作を適切に推定するために、大量のデータを処理するために for ループが必要です)

私の最初の試みは、コードを次のように変更することでした。

インストルメンテーションを制御する Callgrind マクロを追加します。また、 --instr-atstart=no オプションを追加して、必要なコードの部分のみをプロファイルするようにしました...

残念ながら、この構成では、callgrind で実行可能ファイルを起動し始めると、決して終了しません... 完全なインストルメンテーションの実行は 1 分未満であるため、遅さの問題ではありません。

私も試しました

(または --toggle-collect="myMethod" オプション) しかし、Callgrind は呼び出しなしでログを返しました (KCachegrind は雪のように白です :( そしてゼロ命令を言います...)

マクロ/オプションを正しく使用しましたか? 期待される結果を得るために何を変更する必要があるかについて何か考えはありますか?

現在、valgrind/callgrind を使用して、さまざまなアルゴリズムの実装を測定および比較しています。アルゴリズムに 2 つの実装があり、処理チェーンが次のようになっているとします。

これら 2 つの実装の違いは、2 つの異なるアルゴリズムの実装が実行される 3 番目の手順にあります。どちらの実装が優れているかを確認するために、現在、kachegrind の助けを借りて valgrind/callgrind を使用しています。

私がイメージできる限り、Algorithm_imp_1()が よりも効率的である場合Algorithm_imp_2()、その 2 つの指標: 1 つはプログラムの実行に使用された絶対時間であり、もう 1 つは 3 番目の手順にかかる時間の割合であり、小さいはずです。ただし、valgrind で得たものは非常に紛らわしいです。

両方の方法の全体の手順は、3 番目の部分を除いて同じであるため、3 番目の部分の消費時間の割合が小さければ、プログラムの実行にかかる全体の時間も短くなるはずです。しかし、上記で観察したことは矛盾しています。私の分析の何が問題なのか疑問に思っていました。ありがとう！

gprof、またはなどのプロファイリング機能を備えた C/C++ ライブラリを探していcallgrindます。

callgrindより正確には、KCacheGrind などのサードパーティ ツールに渡すために、その出力が発行されるものと同等であることを望みます。

アイデアは、このライブラリに基づいてアスペクトを設計し、それを私のチームで開発しているいくつかのアプリケーションにプラグインできるようにすることです.