Re: interesting metric

[Tim Prince <timothyprince at sbcglobal dot net>]

Ron Young wrote:
> Steve Kargl wrote:
> > On Sat, Aug 05, 2006 at 12:04:09AM -0400, Jack Howarth wrote:
> >  
> > >     Interesting, XL Fortran at -O3 produces exactly the same time as
> > > gfortran at -O3 (121.8 seconds). At -O4, XL Fortrans is slightly 
> > > faster (114.8 seconds), but only at -O5 does it break away (52.7 
> > > seconds).
> > > The difference between -O4 and -O5 in XL Fortran is "-qipa=level=2"
> > > which is...
> > >
> > >                        Full interprocedural data flow and  alias
> > >                         analysis.
> > >
> > > Doesn't profiled IPA exist in gcc? I tried the following...
> > >
> > >     
> >
> > There is an ipa branch where changes are merged
> > back into trunk.  I don't know what the status is
> > with respect to performance.
> >   
> Inlining the functions v and dv more than makes up the time difference. 
> For one thing it would save one of sin calls.
>
> ! vr = sin(min(x,PI2))**2
> pot = pot + 0.5_DP*sin(min(d,PI2))**2
> ! dvr = 2.0_DP*sin(min(x,PI2))*cos(min(x,PI2))
> dvr = 2.0_DP*sin(min(d,PI2))*cos(min(d,PI2))
> do k=1,nd
> f(k,i) = f(k,i) - rij(k)*dvr/d
> enddo
Combining the sin() and cos() calls with the same argument into a sincos
could speed this up.
If you are interested in performance here, I would think you would hoist 
the calculation dvr/d out of the loop explicitly, rather than relying on 
a compiler to find it.
I don't see that this supports the assertion that this case is a good 
general guide to where gfortran could be optimized.  In the code I have 
profiled, the big opportunities would lie in vectorization.  gfortran 
does well in vectorization of simple one-liner loops such as this, but 
not where there are multiple results per loop.