On Sun, Apr 20, 2003 at 06:00:25PM +1000, Simon Burge wrote:
> David Maxwell wrote:
> 
> > 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.
> 
> You can also add user events to a ktrace with utrace(2) (which obviously
> requires recompiling).  This may or may not be helpful...

  That sounds like it would be very useful for localizing a computational
bottleneck.  But there appears to be a general slowdown, throughout the entire
calculation.  Of course, there are well-defined places where the program spends
most of its time, and speeding those up (if it were possible) would speed
up the program, but it doesn't look like that would reduce the large
disparity between the slow and fast execution times seen under what should
be identical conditions.

  I mentioned a couple of items in my response to Ben Elliston that seem
to suggest that the alignment hypothesis may be right.  If you have any
ideas for schemes to directly test that, let me know.

  Thanks for the suggestion.

--Jim