[Patch, fortran] PR24518 and PR24520 - Improvements to MOD and DOT_PRODUCT

[Janne Blomqvist]

On Thu, Nov 10, 2005 at 09:13:20AM +0100, Paul Thomas wrote:
> It is proposed to retain the library version of the DOT_PRODUCT because 
> the inline version does not work for types longer that 8 bytes and for a 
> future implementation, where the library is used with the option -Os. I 
> just have not had time to get my head around how to pick up that option, 
> yet. Nor have I had the time to check if the inline version ever 
> produces larger executables; the test attached is 300bytes shoreter!

BTW, does BLAS do anything fancy for dot product that might help for
big vectors? I mean, is it worth thinking about inlining only for
small vectors? What happpens when the vectors won't fit into cache?
I'm not saying this as a criticism of your patch, just idle
wondering..

For some further idle speculation, for big vectors would it pay off to
insert prefetch hints for archs that support it?

> The attached program, mod_demo.f90, demonstrates the problem and times 
> the MOD function.  The complexity of the two loops came about because I 
> found that the optimizer would otherwise eliminate the loops!  That is, 
> it looks very carefully for trivial content that makes the loop 
> unnecessary.  gcc is more demanding than Intel in that respect.

Seems like pathscale is even more demanding. I had to go to O1 to get
it to execute the loops. Same for dot_demo.f90.

> New: Sets result to zero if the abs(result) is larger that abs(arg2).

I'm not entirely comfortable with this. This might give the user a
false sense of security. At least a huge value is obviously wrong.

> Version of MOD   ------old-----       ------new------
> Optimization     -O0        -O3       -O0         -O3
> Time in ns       117.6     67.1      85.3        52.0

Nice!

> Note that not only does ifc keep going up to > 10**24 but it is a factor 
> of 2 faster than the best that I could achieve with gfc.  I would 
> suggest that it is time for floating point mod to be implemented as a 
> builtin, at very least using x87 instructions.

IIRC there was some discussion on gcc@ a while ago that x87 ins in
builtins might actually make the code slower when used in conjunction
with -msse2 or was it -mfpmath=sse. To give it some significance, IIRC
both of these options are default on x86-64.

> The attached demo program produces the following for the existing, 
> library version of DOT_PRODUCT using -O3:
> 
> DOT_PRODUCT test
>  array length      time(ns)
> 
>       4             4629.00
>       8             4617.00
>      16             4807.00
>      32             5128.00
>      64             5773.00
>     128             7039.00
>     256             9598.00
> 
> and for the proposed new version:
> 
> DOT_PRODUCT test
>  array length      time(ns)
> 
>       4              128.00
>       8              186.00
>      16              377.00
>      32              704.00
>      64             1367.00
>     128             2692.00
>     256             5323.00

WOW!!! That's great!



-- 
Janne Blomqvist
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 185 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20051110/9d8ec243/attachment.sig>