[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Similar systems, different performance of fortran code



On Thu, 2005-04-21 at 12:53 +0100, michael wrote:
> On Thu, 2005-04-21 at 20:35 +0900, Victor Munoz wrote:
> > To add more information about this:
> > 
> > I did a time profiling with gprof. The most important changes:
> > 
> > woody:
> >    time   seconds   seconds    calls   s/call   s/call  name    
> >     96.79     13.88    13.88      482     0.03     0.03  move_
> >      0.28     14.16     0.04      482     0.00     0.00  cpft_
> >      0.21     14.23     0.03      241     0.00     0.00  fields_    
> > 
> > sid:
> > 
> >  time   seconds   seconds    calls   s/call   s/call  name    
> >   99.25    107.86   107.86      482     0.22     0.22  move_
> >    0.58    108.49     0.63      241     0.00     0.00  fields_
> >    0.06    108.56     0.07      482     0.00     0.00  cpft_
> > 
> > So there is a huge difference in the subroutines move and fields. But move, 
> > for instance, is not very involved. It's a subroutine which calls no other
> > functions, just defines some variables, "common" lines, and such, 
> > and then iterates on the particles to move them. A series of matrices 
> > containing data for the particles are accessed element by element, 
> > divided by scalars, summed, etc. Nothing exotic. But these lines are the most 
> > often executed lines in the code, and are probably causing this huge 
> > difference in performance. But it's not obvious (to me at least) why...
> > 
> > Regards,
> > 
> > 					Victor
> > 		
> 
> I've deleted your original email with info on the diff systems, but it
> sounds like 'move' may have to allocate/access substantial amounts of
> memory. Do you have the same amount of cache on each processor? Do you
> notice increase in diff in times as you increase size of matrices in
> 'move'? Do you have the same amount (and speed of) available mem on both
> machines? And, if they are reading are the HDs the same speed/cache size
> etc? You may want to delve into 'move' line by line to see which takes
> the longest...
> 


of course, a better place to start would be to use same compilers on
each machine and then, maybe, you can rule out the compiler version as a
cause... 



Reply to: