Re: [Valgrind-users] Pre-instrumented vs JIT instrumentation

[Nicholas N. <nj...@ca...>]

On Fri, 6 Jun 2003, Mike Bresnahan wrote:

> > But the dynamic compilation + instrumentation phase typically only
> > takes up about 10% of the execution time for Valgrind (the Memcheck
> > skin, at least) so doing this wouldn't help performance much, but it
> > would make the implementation more complicated, and possibly make life
> > more difficult for users.
>
> I don't understand why it must be more difficult for the user.

If the instrumented version replaces the original version, they don't have
their uninstrumented version anymore.  If the instrumented version is
saved in a second file, they have extra files to deal with.  It's not
necessarily much more difficult for the user.

> Do you know what percentage of time when using the cache profiling skin?

It's hard to give an answer because it can vary quite a bit.  But, as an
example, I just tried bunzip2'ing a 600kb file.  40% of the time was spent
running the instrumented code.  57.5% of the time was spent in the cache
simulation functions.  The time spent compiling and instrumenting was less
than 0.1%.

If you want to know more, you can enable Valgrind's internal profiling by
including the line:

  #include "vg_profile.c"

in a skin (they all have it in there, just commented out).  Recompile, and
use --profile=yes and you get a breakdown of where the time was spent.

> BTW, why are they called "skins"?  It makes it sound like something
> graphical.

Because it's a short name (I didn't want to call them "instrumentation
plug-ins" or somesuch) and I couldn't think of anything better and now it
has stuck :)


> > Actually, thinking more, Valgrind's just-in-time approach could has
> > another efficiency advantage -- it only instruments the code that gets
> > executed.  This is good (especially space-wise) if you only use a small
> > fraction of a great big library.
>
> I agree this is an efficiency gain if you profile the executable only once
> or perhaps a handfull of times.  However the efficiency gain is whiped away
> if you execute the same executable enough times.

Assuming you aren't changing and recompiling the program frequently...

N