On Monday 25 May 2009, Raphael Clifford wrote:
> >> for (i=0;i<length;i++) {
> >> val = rand() % length;
> >> temp += p[val];
> >> p[val] = i;
> >> }
> >
>
> Thanks. As you point out I didn't really understand the output from
> valgrind. The line that was confusing me was the percentage one but
> I should have realised that most of this is not from the array access
> at all but from everything else associated with running the code.
If you do not trust the results of the simulator, you should look at
the most fine-grained level where it is much easier to check any
expectations.
Callgrind has more or less the same simulator built in as Cachegrind,
but is slower because of call graph tracing. You can run with
valgrind --tool=callgrind --simulate-cache=yes --dump-instr=yes <yourcode>
to get all the cache simulation results related both to source (as Cachegrind)
and assembly level. For the latter, you have to run KCachegrind (or compile
the qt-only qcachegrind from KDE SVN).
To even see executed (conditional) jumps in the annotated assembly (e.g. how
often a loop body was actually executed), you can add --collect-jumps=yes to
the command line. However, this gives confusing results for source annotation.
Josef
>
> Raphael
>
------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
