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

[Timothy C Prince]

-----Original Message-----
From: "Timothy C Prince" <tprince@myrealbox.com>
To: paulthomas2@wanadoo.fr
Date: Sun, 13 Nov 2005 20:25:40 +0000
Subject: Re: Re: [Patch, fortran] PR24518 and PR24520 - Improvements to MOD and



-----Original Message-----
From: Paul Thomas <paulthomas2@wanadoo.fr>
To: tprince@computer.org
Date: Sun, 13 Nov 2005 10:13:16 +0100
Subject: Re: [Patch, fortran] PR24518 and PR24520 - Improvements to MOD and

Tim,

>>
> On the first platform I tried (Cygwin on Centrino laptop), this 
> version of
> inline dot product gave me full performance at all lengths. For the
> non-vectorizable case (different strides on the 2 arrays), with 
> -funroll-loops,
> it performed significantly better than ifort.
>
It's a real tribute to Paul Brooks' work, isn't it?

Does your library improvement do better for any condition?

Did anybody try real(16)???  Whilst I believe that it will work but 
verification of this is the only thing that stands in the way of 
resubmitting the dot_product patch.

Best regards

Paul

__________________________________
I just tested the Levin-Callahan-Dongarra "vector" benchmark in dot_product() and sum(a*b) versions.  In the "sparse dot product" cases, where the library call requires copying the data to a temporary array, in-lining still improves performance by 90%, even at length 1000.
I'll try to access my Itanium and Pentium D linux machines now.
___________________________________________________
Pentium D 64-bit linux results were not much different from 32-bit Cygwin Centrino:  An advantage for in-lining in nearly all cases at loop lengths 10 and 100, no significant difference at length 1000 except for a large gain in "sparse dot product."

Itanium linux results showed no significant difference between in-lined and library results, except for a  large gain at all loop lengths for in-lining the sparse dot product.


Tim Prince