[OT?] Valgrind profiling Was: Re: [fpc-pascal]Performance testing of FPC programs?

[Peter Vreman]

At 18:43 8-2-2003, you wrote:
>Hi,
>
>   well, I read something interesting here so I thought I could write a few
>lines. Since I don't have the previous mails anymore and the maillist
>archives (http://lists.freepascal.org/mailman/listinfo/fpc-pascal ?) don't
>seem to work I hope I'm not missing the discussion point way too much...
>
> > > 2 choices, use profiling (see Marco's response), which is ok but a bit
> > > cumbersome IMHO, or add your own timing (this is what I do). I use clock
> >
> > The easiest will be in the future to use valgrind and kcachegrind. Those
> > programs are linux-x86 only, but you don't need to recompile your program
> > to get the an easy to browse profile.
>
>Valgrind sounds to be an interesting tool for detecting memory debugging.
>Otoh I am not really convinced about its use of a profiler (I've heard about
>it for the first time too). Isn't it the case that val/kcachegrind measures
>cache misses/hits on pre-processed code (e.g. x86 code transformed into an
>intermediate language, optimized and transformed back) according to a
>simulated cache model (which might not represent the actual cache model used
>by the processor properly)? Doesn't it act as a virtual P54C processor to
>the host program which do influence the program flow (e.g. use of
>specialized routines)?
>It doesn't seem to profile the actual instructions as they are issued on the
>processor the way they were omitted by the compiler, so anyone knows how
>close to "real world" are those values really?
>[I do guess it returns lots of nice numbers and with those you can always
>draw really nice looking graphs >:-]

The compiler does not insert very exotic instructions in the code so i 
guess that the results are close to the "real world". Maybe the 
visualization program kcachegrind can also read gprof output files in the 
future and then you can also visualize that output.


>I guess cachegrind does get the "big picture" about memory accesses but
>somehow I've my doubts about this method being really useful as a profiler,
>especially with the JIT compiler/optimization stage involved. I know a
>little (not much though) that other techniques have their drawbacks as well.
>Anyone knows whether somebody else ever had similar thoughts?
>
>Probably my thoughts are completely without reason because as already
>mentioned I've heard about this program for the first time. Additionally my
>only source is the "The design and implementation of Valgrind"-doc, which is
>a little older (according to the 1.0.4 release, 1.9.x is current) so please
>bear with my foolishness.... ;-) Probably everything has been resolved in
>the "bazillions of other minor changes" on the webpage
>(http://developer.kde.org/~sewardj/)
>
>Just interested and probably one of you can point me to resources without a
>close examination of the source...

I also don't know much about the valgrind internals and how close it is to 
the real world. But i know from work were we needed to profile a 
multithreaded program that valgrind was one of the best options to use, 
gprof didn't give a good result.


Peter