Re: Profiller for Linux



On 24 Mar, 12:34, Noob <r...@xxxxxxxxxxxxxxxxxxxxxx> wrote:
gpderetta wrote:
Noob wrote:

LinuxAsm wrote:

Does anyone know of a good code profiler for Linux?

I recommend oprofile over gprof.
http://oprofile.sourceforge.net/about/

Valgrind is extremely good for doing both source level
and assembler level profiling (you get execution count
for every single instruction!).

It also does cache (both data and instruction) and memory
allocation profiling.

Kcachegrind is the perfect companion for examining and
navigating valgrind output.

The downside of valgrind is that your program will run very
slowly (even 30x) when profiling. But I have found it incomparably
more useful than gprof. I have no experience with oprofile.

If a profiler is too intrusive (high overhead) then it is not profiling
the application, but the combination of the application AND the profiler
itself. The impact of cache misses will be incorrectly reported because
the timing is different, and the profiler itself will induce extraneous
data and cache misses.

cf.http://en.wikipedia.org/wiki/Observer_effect


Well, valgrind doesn't compute profiling information by timing each
instruction as executed by the actual cpu, but it fully emulates a
virtual cpu, cache included. This cpu is completely dedicated to the
execution of the profiled program, the profiler doesn't run inside it,
so it can't influence the results: for example, cache misses are
computed as seen from the virtual cache, not the real cache. This is
where the 30x cost comes from.

Of course what you get is not the profile of the program running on
the real cpu, but rather on the virtual cpu. There are differences in
fact: in the assence of cache misses, the cost of every instruction
is, IIRC, always a single clock cycle: a simple sum will be shown to
cost as much as a long latency division. Also there is no branch
prediciton emulation. Differences in instruction cost are only due to
cache miss extimation. Still what you get is a very precise idea of
what are the most executed modules, functions and even instrucitons in
your program.

Also you can play with the cache settings and even profile your
program as if it where running on a different cpu than your actual
machine.

--
gpd

.



Relevant Pages

  • Task profiling in Linux
    ... I need some help to make profiling of an application on Linux. ... considering only the CPU time that the task has actually executed (i.e. ... - it can't be invoked by a generic task to know the execution time of another ... If somebody has suggestions about how doing this profiling, ...
    (Linux-Kernel)
  • Re: profiling kernel modules.
    ... especially compared with other profiling techniques. ... Run pmcstat to begin taking samples(make sure that whatever you are ... pmc will take a sample every 64K non-idle CPU ... if you suspect that data cache misses are ...
    (freebsd-current)
  • Re: [RFC PATCH 00/19] Cleanup and optimise the page allocator V2
    ... thanks a lot for profiling this. ... The OLTP results had the following things to say about the page allocator. ... there doesn't appear to be in time spent in the allocator but due to ... Something like cache misses or ...
    (Linux-Kernel)
  • Re: [RFC PATCH 00/19] Cleanup and optimise the page allocator V2
    ... thanks a lot for profiling this. ... The OLTP results had the following things to say about the page allocator. ... there doesn't appear to be in time spent in the allocator but due to ... Something like cache misses or ...
    (Linux-Kernel)
  • Re: Memory allocation performance
    ... Are you effectively "cycling through" objects rather than using a smaller set that fits better in the cache? ... To check UMA dependency I have made a trivial one-element cache which in my test case allows to avoid two for four allocations per packet. ... They are quite a bit more expensive on several hardwawre platforms, and any environment it's safe to call uma_zallocfrom will be equally safe to use regular mutexes from. ... Profiling results I have sent promised close results. ...
    (freebsd-hackers)