From owner-sc22wg5@open-std.org Thu Jan 22 20:37:21 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 A273CCA5FED; Thu, 22 Jan 2009 20:37:21 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from mail1.cray.com (mail1.cray.com [136.162.0.111]) by www2.open-std.org (Postfix) with ESMTP id 4EBEDCA5FE6 for ; Thu, 22 Jan 2009 20:37:19 +0100 (CET) Received: from beaver.us.cray.com (beaver.us.cray.com [172.30.74.51]) by mail1.cray.com (8.13.6/8.13.3/gw-5323) with ESMTP id n0MJb9np010739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Jan 2009 13:37:09 -0600 (CST) Received: from CFEXFE01.us.cray.com (cfexfe01.us.cray.com [172.30.74.93]) by beaver.us.cray.com (8.13.8/8.13.3/hub-5273) with ESMTP id n0MJb8lx025704; Thu, 22 Jan 2009 13:37:08 -0600 Received: from mh-dhcp-172-31-16-180.us.cray.com ([172.31.16.180]) by CFEXFE01.us.cray.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Jan 2009 13:37:08 -0600 Message-ID: <4978CB93.2050609@cray.com> Date: Thu, 22 Jan 2009 13:40:03 -0600 From: Bill Long Reply-To: longb@cray.com Organization: Cray Inc. User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: MPI-3 Fortran working group Cc: WG5 , fortran standards email list for J3 Subject: Re: [MPI3 Fortran] (j3.2006) (SC22WG5.3891) [ukfortran] MPI non-blocking transfers References: <20090122175730.8BA1BCA3439@www2.open-std.org> <4978C20F.2070207@cray.com> <200901221111.01710.donev1@llnl.gov> In-Reply-To: <200901221111.01710.donev1@llnl.gov> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jan 2009 19:37:08.0278 (UTC) FILETIME=[D00FF560:01C97CC8] X-Cray-VirusStatus: clean Sender: owner-sc22wg5@open-std.org Precedence: bulk Aleksandar Donev wrote: > On Thursday 22 January 2009 10:59, Bill Long wrote: > > >> Only for statements that might involve references or definitions of a >> volatile variable. The rest of the code can be optimized normally. >> Which is exactly what we need here. >> > No. Take: > > ! complex calculations using array to calculate values: > call mpi_isend(array,...) > ... ! 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 > calculations??? > This example shows the problem well. There is no way for the compiler to tell that the mpi_wait call is related to the isend that is using array as its buffer. It might be for a different isend (and hence different buffer) started somewhere else. The only safe thing for the compiler to do is treat array as volatile throughout the subprogram containing these two calls. Which is just what happens if array is declared volatile. It's irrelevant whether you spell the attribute asynchronous or volatile. The effect is the same. > >>> 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" > part of my sentence. In particular, depending on whether the > actual/dummy are (both) asynchronous, some transformations (e.g., copy > in/out for the hell of it, copy in/out of more than the piece of the > actual, code motion accross the argument call, etc.) should be > disabled. Reread Nick's earlier message. The optimization pitfalls extend past just argument passing. > I understand no compiler actually implements asynchronous so > no implementor has actually pinned down the list of what optimizations > are "not allowed", I'm sure at least some compilers do implement asynchronous. > but I can assure you, the list is much smaller than > for volatile, which, disables even the most basic optimization, such as > using registers during a calculation loop. > Again, I think Nick's examples suggest that the compiler needs to be more careful with asynchronous than you might think. Cheers, Bill -- Bill Long longb@cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120