|
From: David T. <dav...@gm...> - 2008-04-08 11:05:48
|
Hi,
I've got a program that I'm attempting to generate cache statistics
for. After a make clean and remaking (so there's no possibility of a
mismatch between source and executable), I'm finding the cg_annotate
(on produced cachegrind.out.8728 files) is repeatedly reporting things
like
------------------------------------------8<-----------------------------------
. . . . . . . . .
deallocate1DArray(sums,2*noObjs);
11 2 2 4 0 0 3 0 0 }
7 1 1 2 0 0 2 0 0
<bogus line 1026>
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@ WARNING @@ WARNING @@ WARNING @@ WARNING @@ WARNING @@ WARNING @@ WARNING @@
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@
@@ Information recorded about lines past the end of
'/home/sis05dst/PRG_DEV/KDEV/TESTING/ARCHITECTURE/benefitCacheCare/simdImageRoutines.cc
'.
@@
@@ Probable cause and solution:
@@ cause: not sure, sorry
@@
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
------------------------------------------8<-----------------------------------
Some of the detailed cache statistics on many of the lines look wrong,
but that may be my misunderstanding of my program's behaviour. One
observation is that I only get these on source files I've written, for
headers like
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/include/emmintrin.h
and
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_pair.h
I don't get these error messages.
This is with the program compiled with g++ ("g++ (GCC) 4.1.2 20070925
(Red Hat 4.1.2-27)") at -g (although I later want to use "-O2 -g" so
that the SIMD intrinsic functions actually get inlined into one
machine instruction rather than a function call and machine
instruction). The valgrind version is SVN from about a month ago,
modified with an analogue of Nick Nethercote's patch for massif for
putting statistics for fork()'d processes in files named with the
correct PID. This is because the program starts, sets up some big data
structures and then fork()'s a couple of times, with each child then
running an intensive computation in the child; it's these child
processes I'm really interested in the cache stats on. (I can dig up
the patch if it's important, but I literally copied the massif patch
operations at the same points in cachegrind.)
Does anyone have any ideas on what could be wrong with my setup? Is it
likely that the cache statistics are generally correct with some
strange bits at the end of files, or is it likely that every line's
cache stats are incorrect?
Many thanks for any insight and assistance,
--
cheers, dave tweed__________________________
dav...@gm...
Rm 124, School of Systems Engineering, University of Reading.
"while having code so boring anyone can maintain it, use Python." --
attempted insult seen on slashdot
|
|
From: Nicholas N. <nj...@cs...> - 2008-04-09 05:06:06
|
On Tue, 8 Apr 2008, David Tweed wrote: > I've got a program that I'm attempting to generate cache statistics > for. After a make clean and remaking (so there's no possibility of a > mismatch between source and executable), I'm finding the cg_annotate > (on produced cachegrind.out.8728 files) is repeatedly reporting things > like > > ------------------------------------------8<----------------------------------- > . . . . . . . . . > deallocate1DArray(sums,2*noObjs); > 11 2 2 4 0 0 3 0 0 } > 7 1 1 2 0 0 2 0 0 > <bogus line 1026> > > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ > @@ WARNING @@ WARNING @@ WARNING @@ WARNING @@ WARNING @@ WARNING @@ WARNING @@ > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ > @@ > @@ Information recorded about lines past the end of > '/home/sis05dst/PRG_DEV/KDEV/TESTING/ARCHITECTURE/benefitCacheCare/simdImageRoutines.cc > '. > @@ > @@ Probable cause and solution: > @@ cause: not sure, sorry > @@ > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Cachegrind produces an output file that indicates how many times each line of code was executed (plus some other stuff). What's happened here is that Cachegrind is generating statistics for one or more lines that appear not to exist in the file. Eg. it's got numbers for line 500 in a file that has only 400 lines in it. It's unclear why this might be happening. Perhaps the debug info generated by the compiler is bogus? That's what Cachegrind uses to identify which lines are executed. Nick |