interesting metric

[Tim Prince]

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.