1

私のプログラムの短期間の結果は次のとおりです。

 67.93      3.24     3.24                             grid::rKfour(int, int)
  9.43      3.69     0.45                             alloc_mmap
  5.03      3.93     0.24    30001     0.01     0.01  grid::timeStep()
  3.04      4.08     0.15 42007105     0.00     0.00  linkers::linkers(linkers const&)
  2.94      4.22     0.14  6360900     0.00     0.00  particle::fulldistance(particle&)
  2.73      4.35     0.13                             blas_thread_server
...

lddからの出力は

linux-vdso.so.1 =>  (0x00007fffe2bea000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007eff34595000)
    libboost_filesystem.so.1.46.1 => /usr/lib/libboost_filesystem.so.1.46.1 (0x00007eff34377000)
    libboost_system.so.1.46.1 => /usr/lib/libboost_system.so.1.46.1 (0x00007eff34172000)
    libGL.so.1 => /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1 (0x00007eff33f16000)
    libglut.so.3 => /usr/lib/libglut.so.3 (0x00007eff33cd0000)
    libGLU.so.1 => /usr/lib/x86_64-linux-gnu/libGLU.so.1 (0x00007eff33a62000)
    libGLEW.so.1.5 => /usr/lib/libGLEW.so.1.5 (0x00007eff3380c000)
    libboost_thread.so.1.46.1 => /usr/lib/libboost_thread.so.1.46.1 (0x00007eff335f3000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007eff332eb000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007eff33067000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007eff32e51000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007eff32ab1000)
    /lib64/ld-linux-x86-64.so.2 (0x00007eff347c4000)
    libglapi.so.0 => /usr/lib/x86_64-linux-gnu/libglapi.so.0 (0x00007eff3288d000)
    libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007eff32555000)
    libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007eff32341000)
    libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1 (0x00007eff3213e000)
    libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007eff31f38000)
    libXxf86vm.so.1 => /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1 (0x00007eff31d31000)
    libdrm.so.2 => /usr/lib/x86_64-linux-gnu/libdrm.so.2 (0x00007eff31b26000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007eff31922000)
    libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007eff31705000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007eff314fd000)
    libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007eff312f9000)
    libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007eff310f3000)

誰かが「alloc_mmap」を識別できますか？

4

2 に答える 2

2

プログラムの速度を向上させるために何ができるかを知りたいので、あなたが質問していると思います。
そうでない場合は、これを忘れてください。

gprofの出力では、重要な数値は2番目の列である累積秒数です。これは、そのルーチンに時間がかからない場合、合計時間が短縮される量であるためです。

gprofの問題の1つは、I/Oのようにブロックされた時間を無視することです。プログラムはalloc_mmap（直接的または間接的に）ファイルをメモリにマッピングしているため、I / Oを実行しますが、これは多くの場合、少額のコストではありません。gprofはそれを見ていません。

gprofにはさらに多くの問題があります。Linuxを使用している場合は、Zoomなどのプロファイラーを試すことができます。実時間でサンプリングするため、I/Oを認識できません。また、関数だけでなく、行/命令ごとの使用時間の割合も示されるため、コード内の行を正確に特定し、それらを改善/削除できれば、最も高速化できます。（通常、これらは関数呼び出しです。「セルフタイム」は、重い計算やタイトなCPUループを除いて、ほとんど関係ありません。とにかく問題ではありません。ズームで検出されます。）

私が頼りにしている方法はこれです。

于 2011-10-24T13:39:18.533 に答える
0

おそらく、メモリアロケータは大規模な割り当てにmmapを使用しています。最初にこれを確認し（alloc_mmapのgdbブレークポイントが機能するはずです）、malloptを使用してしきい値を増やす必要があります。

于 2011-10-24T14:51:23.660 に答える