loop and jam patch?

[Janne Blomqvist]

On Thu, Nov 17, 2005 at 08:35:26PM +0100, Thomas Koenig wrote:
> We currently have a few patches for optimizing matmul and
> dot_product.  If we are indeed optimizing for speed, I think we
> should choose the best available solution, and I think that this
> includes taking advantage of loop and jam.

One thing that definitively would help would be to use blas for bigger
vectors/arrays. BLAS however seems to have quite high overhead for
small arrays, where OTOH inlining is a big benefit. Here is an example
(from my recent matmul vectorizing patch) that shows the difference
between matmul and sgemm (atlas using sse2) in trunk
i686-pc-linux-gnu:

 Matrix side size    Matmul (Gflops/s)    sgemm (Gflops/s)
 ========================================================
    2                0.084                0.022
    4                0.346                0.157
    8                0.794                0.455
   16                0.714                0.741
   32                0.901                1.250
   64                0.989                1.332
  128                1.022                2.827
  256                0.848                4.466
  512                0.773                4.790
 1024                0.769                4.969
 2048                0.778                4.972

Similarly for dot-product, using your dot_demo2.f90 benchmark:

DOT_PRODUCT test
  array length      time(ns)

       4               74.50
       8               81.40
      16              114.60
      32              104.60
      64              179.00
     128              327.50
     256              629.50
     512             1204.00
    1024             2362.50

Changing to use ddot from blas (again using the same atlas w/ sse2)
produces:

DOT_PRODUCT test
  array length      time(ns)

       4              153.90
       8               97.00
      16               88.30
      32              105.80
      64              139.90
     128              214.10
     256              343.70
     512              599.80
    1024             1120.50

There was some discussion a while ago about enabling libgfortran to be
compiled with blas or with the current implementation depending on
some appropriate configure switch. However, I think that is a bit
inflexible, considering that the usual usage scenario will at least
for Linux be that gfortran is provided with the system, and the user
wants to use some cpu-specific optimized blas library (atlas, acml,
mkl, whatever).

So, why not have the frontend call blas directly, leaving it to the
user to specify appropriate flags to link in the correct blas
library? We could even have separate flags allowing the user to change
the array size for which we change from inlining to blas. E.g.

% gfortran -O2 -fblas -fblas-dot-product=64 -fblas-matmul=32 foo.f90 -latlas -lf77blas


-- 
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/20051117/434f78f2/attachment.sig>