From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by sourceware.org (Postfix) with ESMTPS id C052B386F02D for ; Thu, 18 Mar 2021 22:08:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C052B386F02D 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 12IM7xoc026271 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 18 Mar 2021 15:07:59 -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 12IM7wl6026270; Thu, 18 Mar 2021 15:07:58 -0700 (PDT) (envelope-from sgk) Date: Thu, 18 Mar 2021 15:07:58 -0700 From: Steve Kargl To: Thomas Koenig Cc: Richard Biener , Tobias Burnus , "fortran@gcc.gnu.org" Subject: Re: MATMUL broken with frontend optimization. Message-ID: <20210318220758.GA26001@troutmask.apl.washington.edu> References: <20210318074849.GA22541@troutmask.apl.washington.edu> <563cee48-fbcc-09bc-0cd1-f05082e4feb3@codesourcery.com> <20210318161347.GA24201@troutmask.apl.washington.edu> <1780c473-3523-316f-c372-52824d062a01@netcologne.de> <20210318202239.GA25584@troutmask.apl.washington.edu> <367461e9-72b4-0f8d-d04e-878789595942@netcologne.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <367461e9-72b4-0f8d-d04e-878789595942@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 List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 22:08:04 -0000 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 > multiplications. > > What we could do is only to enable the inlining for vector*matrix > at -O2 or higher. Again, this will mean a penalty for smaller loops, > but at less than -O2, people probably don't care too much. > 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 -- Steve program t implicit none character(len=10) str integer i, j integer, parameter :: & & n(10) = [100, 1000, 2000, 3000, 4000, 5000, 6000, 7000, 8000, 10000] real t0, t1, t3, t4 real, allocatable :: a(:), b(:,:), c(:) ! ! Loop over n(j) array. Run each test 5 times and average. ! do j = 1, 10 allocate(a(n(j)), b(n(j),n(j)), c(n(j))) a = 1 b = 1 t3 = 0 do i = 1, 5 call cpu_time(t0) c = matmul(a, b) call cpu_time(t1) t3 = t3 + (t1 - t0) if (c(1) /= n(j)) stop 1 end do t4 = 0 do i = 1, 5 call cpu_time(t0) c = matmul(b, a) call cpu_time(t1) t4 = t4 + (t1 - t0) if (c(1) /= n(j)) stop 2 end do print '(I5,1X,2(F8.4,1X))', n(j), (t3/5) * 1000, (t4/5) * 1000 deallocate(a, b, c) end do end program t