From owner-sc22wg5@open-std.org Thu Jan 22 20:11:05 2009 Return-Path: X-Original-To: sc22wg5-dom7 Delivered-To: sc22wg5-dom7@www2.open-std.org Received: by www2.open-std.org (Postfix, from userid 521) id 427C0CA5FED; Thu, 22 Jan 2009 20:11:05 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from smtp.llnl.gov (nspiron-3.llnl.gov [128.115.41.83]) by www2.open-std.org (Postfix) with ESMTP id 4BB87CA5FE6 for ; Thu, 22 Jan 2009 20:11:03 +0100 (CET) X-Attachments: None Received: from cyrus2.llnl.gov ([128.15.97.105]) by smtp.llnl.gov with ESMTP; 22 Jan 2009 11:11:02 -0800 From: Aleksandar Donev Organization: LLNL To: mpi3-fortran@lists.mpi-forum.org Subject: Re: [MPI3 Fortran] (j3.2006) (SC22WG5.3891) [ukfortran] MPI non-blocking transfers Date: Thu, 22 Jan 2009 11:11:01 -0800 User-Agent: KMail/1.9.4 Cc: fortran standards email list for J3 , WG5 References: <20090122175730.8BA1BCA3439@www2.open-std.org> <4978C20F.2070207@cray.com> In-Reply-To: <4978C20F.2070207@cray.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200901221111.01710.donev1@llnl.gov> Sender: owner-sc22wg5@open-std.org Precedence: bulk On Thursday 22 January 2009 10:59, Bill Long wrote: > Only for statements that might involve references or definitions of a > volatile variable. =A0The rest of the code can be optimized normally. =A0 > Which is exactly what we need here. No. Take: ! complex calculations using array to calculate values: call mpi_isend(array,...) =2E.. ! array not modified here call mpi_wait(...) ! more calculations involving array reading the values Surely it is ok, desirable, or even necessary to optimize the=20 calculations??? > > ASYNCHRONOUS only disables > > code motion accross waits and certain argument associations (such > > as more care with copy in/out). The rest of the code can be > > optimized as usual. > > If that's the case, then there is a serious problem with ASYNCHRONOUS But these are covered by the "disables...certain argument associations"=20 part of my sentence. In particular, depending on whether the=20 actual/dummy are (both) asynchronous, some transformations (e.g., copy=20 in/out for the hell of it, copy in/out of more than the piece of the=20 actual, code motion accross the argument call, etc.) should be=20 disabled. I understand no compiler actually implements asynchronous so=20 no implementor has actually pinned down the list of what optimizations=20 are "not allowed", but I can assure you, the list is much smaller than=20 for volatile, which, disables even the most basic optimization, such as=20 using registers during a calculation loop. Best, Aleks =2D-=20 Aleksandar Donev, Ph.D. Lawrence Postdoctoral Fellow @ Lawrence Livermore National Laboratory High Performance Computational Materials Science and Chemistry E-mail: donev1@llnl.gov Phone: (925) 424-6816 Fax: (925) 423-0785 Address: P.O.Box 808, L-367, Livermore, CA 94551-9900 Web: http://cherrypit.princeton.edu/donev