問題タブ [gprof]

profプログラムが行うことと同等の方法でLinuxを実行する方法はあり-gprofますか? 正確ではないことはわかっていますが、統計的に正しいだけです。

私は基本的に、gprofデバッグ シンボルを含む C/C++ プログラムのような分析を行う方法を探していますが、再コンパイルする必要はありません。

レンダリングCコードをC++で書き直しています。古いCコードは基本的に必要なものをすべて計算し、各フレームでレンダリングします。新しいC++コードは、代わりに必要なものを事前に計算し、それをリンクリストとして格納します。

現在、実際のレンダリング操作は、変換、色の変更、およびGLリストの呼び出しです。

リンクリストで操作を実行するのは非常に簡単ですが、結果のメソッド呼び出しは古いバージョンよりも時間がかかるように見えます（毎回すべてを計算します-もちろん、新しいバージョンが再計算されないことを確認しました）。

変なこと？古いバージョンよりも少ないOpenGL操作を実行します。しかし、それはさらに奇妙になります。操作の種類ごとにカウンターを追加し、メソッドの最後に古き良きprintfを追加すると、高速になりました。gprofと手動測定の両方でこれが確認されています。

また、両方の場合（トレースありとなし）でG ++によって生成されたアセンブリコードを確認するのも面倒でしたが、大きな変更はありません（これは私の最初の疑いでした）-唯一の違いは、カウンターに割り当てられたスタックワードがいくつかあることです、上記のカウンターを増やし、printfの準備をしてからジャンプします。

また、これは-O2と-O3の両方に当てはまります。UbuntuMaverickでgcc4.4.5とgprof2.20.51を使用しています。

私の質問は、何が起こっているのかということだと思います。私は何が間違っているのですか？私の測定値とgprofの両方から何かが外れていますか？

私は通常、gprof+gprof2dot.pyを使用してC++コードのプロファイルを作成します。私が使用している新しいコードは非常に長い関数名を使用しているため、gprof2dot.pyを使用したグラフィカルな結果は混乱します。小さなボックスに収まるように関数名を短くするにはどうすればよいのでしょうか。

kcachegrdindコードを最適化しようとしている間、とによって生成されたプロファイルの違いに少し戸惑っていますgprof。具体的には、gprof（-pgスイッチとのコンパイルなど）を使用する場合、次のようになります。

これは、私がどこかを探す必要がないことを示唆しているようですが、::R_impl(...)

同時に、-pgスイッチなしでコンパイルしてvalgrind --tool=callgrind ./a.out代わりに実行すると、かなり異なるものがあります。これがkcachegrind出力のスクリーンショットです。

これを正しく解釈すると、::R_impl(...)時間の約50％しかかからないのに対し、残りの半分は、プロファイルのはるか下にある線形代数（ Wrat(...)、および基礎となるlapack呼び出し）に費やされていることを示唆しているようです。eigenvaluesgprof

私はそれを理解し、さまざまな手法gprofをcachegrind使用しています。結果が多少異なっていてもかまいません。しかし、ここでは、それは非常に異なって見えます、そして私はそれらをどのように解釈するかについて途方に暮れています。何かアイデアや提案はありますか？

gprof両方でいくつかの C++ 数値計算コードをプロファイリングするkcachegrindと、実行時間 (入力に応じて 50 ～ 80%) に最も寄与する関数については同様の結果が得られますが、10 ～ 30% の間の関数については、これらのツールの両方で異なる結果が得られます。それらの1つが信頼できないということですか？ここで何をしますか？

gprof を使用してコードをプロファイリングし、レポートから、トップ 20 程度のすべてではないにしても、ほとんどがベクトルに関するものでした

私の関数の残りの部分がかなり効率的であること、または vector< bool > からの値へのアクセスが本当に遅いことを意味するので、それは良い兆候ですか?

gcc -std=c++0x でコンパイルしています

_Unwind_SjLj_Unregister と _Unwind_SjLj_Register とは何ですか? 私の gprof レポートでは、プロセッサ時間のトップ ユーザーとしてそれらを取得しています。google は、これら 2 つのエラーについて不平を言う人々へのリンクのみを返します。

レポートの唯一の部分である != 0:

Windows 7 x64を実行し、コードブロック10.05 gccでコンパイルしています

編集：

プログラムを強制的に 64 秒間実行する関数を有効にすると、次のようになります。

この質問のフォローアップとして、上位 2 つのものが依然として例外ハンドラであることは良いことですか? 一方では、多くの例外を実行しています。一方、これは sdl にあり、おそらく可能な限り最適化されていることを意味します。これは、私の他の関数が本当に高速であることを意味します。それで...

これは、最適化を行った後、約64秒間実行した後のプログラムのプロファイルの上部です

cast128 は 100000 回実行されており、これが一番上にある理由を説明しています

データのロードと保存にかなりの時間が費やされるプログラムがあります。ここで、合計実行時間のパーセンテージで各関数にかかる時間を知りたいと思います。ただし、プロファイラーが考慮する合計時間から、関数のロードと保存にかかる時間を除外したいと考えています。gprof やその他の一般的なプロファイラーを使用してこれを行う方法はありますか?

gprofによって生成される出力からいくつかの関数を除外したいと思います。つまり、実行中に各関数が費やした時間の割合を計算するときに、それらを含めたくありません。一箇所で読んだ-Eオプションが使えます。

ただし、 gprof -E function_to_be_exluded my_program_nameを使用していますが、何も起こりません。マニュアルには減価償却が記載されているため、代わりにsymspecsを使用する必要があります。しかし、私はsymspecsでそれを達成する方法を見つけようとして、30分も無駄にしましたが、運がありませんでした。誰でも親切にこれで私を助けることができます。