[Patch, libgfortran] PR21468 Vectorizing matmul, other perf improvements

Dorit Naishlos DORIT@il.ibm.com
Thu Nov 24 10:18:00 GMT 2005





I used your benchmark from
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00929.html to measure the
vectorization impact on matmul on powerpc970 2GHz, 256KB cache.
Here are the results (speedup factor = the ratio between the Gflops/s of
the vectorized and scalar versions):

 Matrix side size   Loop count      speedup factor    speedup factor
                                    no unroll         with unroll

===========================================================================
    2               33333333        0.88x             0.89x
    4               3571428         0.30x             0.76x
    8               416666          0.65x             0.71x
   16               50403           1.78x             1.18x
   32               6200            1.70x             1.58x
   64               768             2.28x             2.38x
  128               95              2.63x             2.52x
  256               11              2.32x             2.62x
  512               1               1.17x             1.13x
 1024               1               1.22x             1.14x

Vectorization degrades performance on the very small data sizes (2,4,8); on
data sizes 16 to 1024 the vectorized version is between 1.13 to 2.62 times
better than the scalar version (without unrolling),
and between 1.22 to 2.78 times better than the scalar version when
unrolled. (This includes alignment handling overhead).

(By the way, on ppc enabling unrolling for matmul improved the performance
by 14%/19% on average for the different datasets, for the scalar/vectorized
versions respectively.)

dorit

> On Sun, Nov 13, 2005 at 08:48:55PM +0100, Thomas Koenig wrote:
> > On Sun, Nov 13, 2005 at 05:52:37PM +0200, Janne Blomqvist wrote:
> >
> > > I have looked at PR21468, "Vectorizing libgfortran". The attached
> > > patch enables vectorizing the main loop for matmul in case of unit
> > > stride. It doesn't change the code much, only adds const and restrict
> > > appropriately to the type declarations, so that the vectorizer can
> > > safely vectorize the main loop.
> >
> > This is OK.  You can commit this part.
>
> Committed. Matmul is now vectorized by default on those targets where
> SIMD instructions are availabe.
>
> > Maybe this needs to become platform-dependent.  I think we need
> > some more benchmarks here.
>
> I updated the benchmark I posted yesterday slightly and did some
> measurements on an 1.8 GHz A64 (i686-pc-linux-gnu, sorry no 64-bit
> results). It seems that while -funroll-loops improves performance
> compared to the baseline, it doesn't really improve when combined with
> vectorizing. Perhaps it's different on x86-64, where there is twice
> the number of SSE2 registers. If that's the case, I propose that we
> enable -funroll-loops, as it increases performance for "bare" x86
> (which doesn't vectorize as sse2 isn't used by default). As for
> -frename-registers mentioned by Tim Prince, it is enabled by default
> if -funroll-loops is used.
>
> trunk:
>
>  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
>
> With -funroll-loops:
>
>  Matrix side size    Matmul (Gflops/s)    sgemm (Gflops/s)
>  ========================================================
>     2                0.056                0.020
>     4                0.388                0.149
>     8                0.794                0.459
>    16                1.042                0.719
>    32                1.205                1.282
>    64                1.264                1.407
>   128                1.172                2.827
>   256                1.000                4.187
>   512                0.912                4.877
>  1024                0.906                4.946
>  2048                0.918                5.047
>
>
> With -ftree-vectorize and -msse2 (sse2 is default on x86-64, needed for
> vectorization):
>
>  Matrix side size    Matmul (Gflops/s)    sgemm (Gflops/s)
>  ========================================================
>     2                0.059                0.021
>     4                0.274                0.159
>     8                0.467                0.467
>    16                0.807                0.730
>    32                1.316                1.235
>    64                1.491                1.350
>   128                1.922                2.746
>   256                1.675                4.785
>   512                1.060                4.877
>  1024                1.060                4.901
>  2048                1.065                5.029
>
>
> Both -ftree-vectorize and -funroll-loops (and -msse2 as well):
>
>  Matrix side size    Matmul (Gflops/s)    sgemm (Gflops/s)
>  ========================================================
>     2                0.047                0.022
>     4                0.261                0.163
>     8                0.380                0.459
>    16                0.645                0.741
>    32                1.000                1.282
>    64                1.469                1.427
>   128                1.884                2.827
>   256                1.675                4.785
>   512                1.052                4.877
>  1024                1.058                4.946
>  2048                1.059                5.042
>
>
> --
> Janne Blomqvist
> [attachment "matmul-bench3.f90" deleted by Dorit Naishlos/Haifa/IBM]
> [attachment "attdz4kg.dat" deleted by Dorit Naishlos/Haifa/IBM]



More information about the Fortran mailing list