Профили gprof и cachegrind - PullRequest
Новая
       29

Профили gprof и cachegrind

11 голосов
/ 11 июня 2011

Пытаясь оптимизировать код, я немного озадачен различиями в профилях, создаваемых kcachegrdind и gprof. В частности, если я использую gprof (компиляция с переключателем -pg и т. Д.), Я получаю следующее: 

Flat profile:

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total           
 time   seconds   seconds    calls  ms/call  ms/call  name    
 89.62      3.71     3.71   204626     0.02     0.02  objR<true>::R_impl(std::vector<coords_t, std::allocator<coords_t> > const&, std::vector<unsigned long, std::allocator<unsigned long> > const&) const
  5.56      3.94     0.23 18018180     0.00     0.00  W2(coords_t const&, coords_t const&)
  3.87      4.10     0.16   200202     0.00     0.00  build_matrix(std::vector<coords_t, std::allocator<coords_t> > const&)
  0.24      4.11     0.01   400406     0.00     0.00  std::vector<double, std::allocator<double> >::vector(std::vector<double, std::allocator<double> > const&)
  0.24      4.12     0.01   100000     0.00     0.00  Wrat(std::vector<coords_t, std::allocator<coords_t> > const&, std::vector<coords_t, std::allocator<coords_t> > const&)
  0.24      4.13     0.01        9     1.11     1.11  std::vector<short, std::allocator<short> >* std::__uninitialized_copy_a<__gnu_cxx::__normal_iterator<std::vector<short, std::alloca

Что говорит о том, что мне не нужно искать где-либо, а ::R_impl(...)

В то же время, если я компилирую без ключа -pg и запускаю valgrind --tool=callgrind ./a.out, я получаю нечто иное: вот скриншот вывода kcachegrind

enter image description here

Если я правильно интерпретирую это, то, по-видимому, можно предположить, что ::R_impl(...) занимает только около 50% времени, в то время как другая половина тратится на линейную алгебру (Wrat(...), eigenvalues и лежащие в основе вызовы Лапака), которая была внизу в профиле gprof.

Я понимаю, что gprof и cachegrind используют разные методы, и я бы не стал беспокоиться, если бы их результаты были несколько иными. Но здесь это выглядит совсем по-другому, и я не знаю, как их интерпретировать. Есть идеи или предложения?

Ответы [ 2 ]

12 голосов
/ 05 августа 2011

Вы смотрите не на тот столбец.Вы должны посмотреть на второй столбец в выводе kcachegrind, который называется «self».Это время, затрачиваемое конкретной подпрограммой только без учета ее детей.Первый столбец имеет кумулятивное время (оно равно 100% машинного времени для основного) и не очень информативно (на мой взгляд).

Обратите внимание, что из вывода kcachegrind вы можете увидетьобщее время процесса составляет 53,64 секунды, в то время как время, проведенное в подпрограмме «R_impl», составляет 46,72 секунды, что составляет 87% от общего времени.Так что gprof и kcachegrind согласны почти идеально.

6 голосов
/ 11 июня 2011

gprof является профилированным профилировщиком , callgrind является профайлером дискретизации .С профилированным профилировщиком вы получаете накладные расходы на каждую функцию входа и выхода, что может исказить профиль, особенно если у вас есть относительно небольшие функции, которые вызываются много раз.Профилировщики выборки имеют тенденцию быть более точными - они слегка замедляют общее выполнение программы, но это имеет тенденцию оказывать одинаковое относительное влияние на все функции.

Попробуйте бесплатную 30-дневную оценку Zoom from RotateRight - Я подозреваю, что это даст вам профиль, который больше согласуется с callgrind, чем с gprof.

...