From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <sgk@troutmask.apl.washington.edu>
Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu
 [128.95.76.21])
 by sourceware.org (Postfix) with ESMTPS id 0B7B8386F00D
 for <fortran@gcc.gnu.org>; Fri, 19 Mar 2021 07:04:00 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 0B7B8386F00D
Received: from troutmask.apl.washington.edu (localhost [127.0.0.1])
 by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 12J73vEk035914
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
 Fri, 19 Mar 2021 00:03:57 -0700 (PDT)
 (envelope-from sgk@troutmask.apl.washington.edu)
Received: (from sgk@localhost)
 by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 12J73vbw035913;
 Fri, 19 Mar 2021 00:03:57 -0700 (PDT) (envelope-from sgk)
Date: Fri, 19 Mar 2021 00:03:57 -0700
From: Steve Kargl <sgk@troutmask.apl.washington.edu>
To: Thomas Koenig <tkoenig@netcologne.de>
Cc: Richard Biener <richard.guenther@gmail.com>,
 Tobias Burnus <tobias@codesourcery.com>,
 "fortran@gcc.gnu.org" <fortran@gcc.gnu.org>
Subject: Re: MATMUL broken with frontend optimization.
Message-ID: <20210319070357.GA35874@troutmask.apl.washington.edu>
References: <CAFiYyc3kfoKsqhn2zJWsMzqOZ3-Z3OYoORcJC9mJtpt=Ogm3Vg@mail.gmail.com>
 <563cee48-fbcc-09bc-0cd1-f05082e4feb3@codesourcery.com>
 <CAFiYyc3GzyKqRNLEvf-KA+cgpzXXmYGTwWWVCXWeK50hNFzZkA@mail.gmail.com>
 <20210318161347.GA24201@troutmask.apl.washington.edu>
 <1780c473-3523-316f-c372-52824d062a01@netcologne.de>
 <f549cd59-0e4f-bf3e-91f8-26c12816ce63@netcologne.de>
 <20210318202239.GA25584@troutmask.apl.washington.edu>
 <367461e9-72b4-0f8d-d04e-878789595942@netcologne.de>
 <20210318220758.GA26001@troutmask.apl.washington.edu>
 <34f8dfc0-c752-c8fb-8f6b-6880b984e69c@netcologne.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <34f8dfc0-c752-c8fb-8f6b-6880b984e69c@netcologne.de>
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS,
 KAM_LAZY_DOMAIN_SECURITY, SPF_HELO_NONE, SPF_NONE,
 TXREP autolearn=no autolearn_force=no version=3.4.2
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
 server2.sourceware.org
X-BeenThere: fortran@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Fortran mailing list <fortran.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/fortran>,
 <mailto:fortran-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/fortran/>
List-Help: <mailto:fortran-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/fortran>,
 <mailto:fortran-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Mar 2021 07:04:02 -0000

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 data with AVX (which I think we can mostly count
> on now),
> 
> - The library is always faster for matmul(vector,matrix) for any n >=100
> - For matmul(matrix,vector) there is no appreciable difference
> 
> So, putting in the same inline limits for matmul(vector,matrix)
> that we have for matmul(matrix,matrix), and leaving
> mamul(matrix,vector) alone, seems like a reasonable thing to do.
> 
> I'll work on a patch.
> 

Thanks for working on this in such short notice.  I agree the core2
is old, and gfortran should look toward the future so using the same
inline threshold seems right.

I saw your other email with the concept patch.  I'll look through
it tomorrow when I'm a little more cogent (it's after midnight here).

-- 
Steve