On Sun, Apr 20, 2003 at 10:14:30AM +1000, Ben Elliston wrote:
> Jim Bernard <jbernard@mines.edu> writes:
> 
> >   My guess is that the two different execution times represent runs
> > in which the program was loaded with different alignments of
> > double-precision variables, one efficient and the other not.  I
> > tried compiling with -malign-double, but that made no difference.
> > I've tried a large number of variations in compile-time optimization
> > flags, including no optimization, and nothing made much of a
> > difference.
> 
> I doubt that would make any difference; your variables should be bound
> to the same address in every run.  Try compiling your program with -pg
> and see if gprof gives you any insight into where the extra time is
> being spent.  That might be a good starting point.

Ben's suggestion is a good one.

Another thing you can try, which doesn't require recompiling, is to get
a ktrace of the process for each runtime. I know you said it doesn't do
much IO, but the timestamps on the system calls should let you narrow
the extra delay down. At the least, you may be able to determine whether
it's a single large hit, or many small ones.

Depending on the complexity of your program, you could also start
inserting exit()s at various points, and recompiling. A binary search
should narrow down where the extra time comes from, without too much
trouble (as long as the fast/slow runs are fairly evenly distributed).

-- 
David Maxwell, david@vex.net|david@maxwell.net -->
An organization gets what it rewards.
			      - Perry Metzger