On Fri, Mar 19, 2021 at 07:36:22AM +0100, Thomas Koenig wrote:
>
> Am 19.03.21 um 07:19 schrieb Thomas Koenig:
>
> > I'll work on a patch.
>
> So, here's a concept patch. It still needs a ChangeLog and testsuite
> adjustment, but this is what I would propose to use.
>
I see that you've submit
On Fri, Mar 19, 2021 at 07:19:16AM +0100, Thomas Koenig wrote:
>
> Hi Steve,
>
> > On my old core2 cpu, a quick test with N=1000 and NxN matrix
> > suggest a cross over near N=1000 for REAL(4). This cpu doesn't
> > have any AVX* instruction, so YMMV. Program follows .sig
>
> Looking at your da
Am 19.03.21 um 07:19 schrieb Thomas Koenig:
I'll work on a patch.
So, here's a concept patch. It still needs a ChangeLog and testsuite
adjustment, but this is what I would propose to use.
Regards
Thomas
diff --git a/gcc/fortran/frontend-passes.c b/gcc/fortran/frontend-passes.c
inde
Hi Steve,
On my old core2 cpu, a quick test with N=1000 and NxN matrix
suggest a cross over near N=1000 for REAL(4). This cpu doesn't
have any AVX* instruction, so YMMV. Program follows .sig
Looking at your data with AVX (which I think we can mostly count
on now),
- The library is always
On Thu, Mar 18, 2021 at 09:55:27PM +0100, Thomas Koenig wrote:
>
> > I haven't checked. If so, how about disabling
> > in-lining MATMUL for 11.1;
>
> Absolutely not for the general case. This would cause a huge regression
> in execution time for 2*2 matrices, and also for small matrix-vector
> m
Am 18.03.21 um 21:22 schrieb Steve Kargl:
On Thu, Mar 18, 2021 at 07:24:21PM +0100, Thomas Koenig wrote:
I didn't finish the previous mail before hitting "send", so here
is the postscript...
OK, so I've had a bit of time to look at the actual test case. I
missed one very important detail be
On Thu, Mar 18, 2021 at 07:24:21PM +0100, Thomas Koenig wrote:
> I didn't finish the previous mail before hitting "send", so here
> is the postscript...
>
> > OK, so I've had a bit of time to look at the actual test case. I
> > missed one very important detail before: This is a vector-matrix
> >
I didn't finish the previous mail before hitting "send", so here
is the postscript...
OK, so I've had a bit of time to look at the actual test case. I
missed one very important detail before: This is a vector-matrix
operation.
For this, we do not have a good library routine (Harald just
remov
OK, so I've had a bit of time to look at the actual test case. I
missed one very important detail before: This is a vector-matrix
operation.
For this, we do not have a good library routine (Harald just
removed it because of a bug in buffering), and -fexternal-blas
does not work because we do no
On Thu, Mar 18, 2021 at 04:05:40PM +0100, Richard Biener wrote:
> On Thu, Mar 18, 2021 at 3:48 PM Tobias Burnus wrote:
> >
> > Richard,
> >
> > On 18.03.21 13:35, Richard Biener via Fortran wrote:
> > > [...]
> > > Since the libgfortran MATMUL should be vectorized
> > > I think it's not reasonable
On Thu, Mar 18, 2021 at 3:48 PM Tobias Burnus wrote:
>
> Richard,
>
> On 18.03.21 13:35, Richard Biener via Fortran wrote:
> > [...]
> > Since the libgfortran MATMUL should be vectorized
> > I think it's not reasonable to inline any but _very_ small
> > MATMUL at optimization levels that do not en
Richard,
On 18.03.21 13:35, Richard Biener via Fortran wrote:
[...]
Since the libgfortran MATMUL should be vectorized
I think it's not reasonable to inline any but _very_ small
MATMUL at optimization levels that do not enable vectorization.
Besides the obvious if (!flag_external_blas) which sh
On Thu, Mar 18, 2021 at 8:49 AM Steve Kargl via Fortran
wrote:
>
> It seems that gfortran will inline MATMUL with optimization.
> This produce very poor performance. In fact, gfortran will
> inline MATMUL even if one specifies -fexternal-blas. This is
> very bad.
>
> % cat a.f90
> program main
13 matches
Mail list logo
