From owner-sc22wg5@open-std.org Thu Jan 22 20:19:00 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 5B318CA5FED; Thu, 22 Jan 2009 20:19:00 +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 836EDCA5FE6 for ; Thu, 22 Jan 2009 20:18:59 +0100 (CET) Received: from mh1750-1.us.cray.com (mh1750-1.us.cray.com [172.31.74.55]) by mail1.cray.com (8.13.6/8.13.3/gw-5323) with ESMTP id n0MJIr5T010028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Jan 2009 13:18:53 -0600 (CST) Received: from mh2650-1.us.cray.com (mh2650-1.us.cray.com [172.31.74.50]) by mh1750-1.us.cray.com (8.13.8/8.13.3/hub-5273) with ESMTP id n0MJIqM4021710; Thu, 22 Jan 2009 13:18:52 -0600 Received: from mh-dhcp-172-31-16-180.us.cray.com (mh-dhcp-172-31-16-180.us.cray.com [172.31.16.180]) by mh2650-1.us.cray.com (8.13.8/8.13.3/spool-5907) with ESMTP id n0MJIpdr014333; Thu, 22 Jan 2009 13:18:51 -0600 Message-ID: <4978C74B.70605@cray.com> Date: Thu, 22 Jan 2009 13:21:47 -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: fortran standards email list for J3 Cc: WG5 , MPI-3 Fortran working group Subject: Re: (j3.2006) (SC22WG5.3892) [ukfortran] [MPI3 Fortran] MPI non-blocking transfers References: <49776DF7.1040900@cray.com> <20090121211748.130A5C178D9@www2.open-std.org> <20090121224014.6CB63C178D9@www2.open-std.org> <20090121234200.4F3BDCA3434@www2.open-std.org> <20090122000407.D5A8ECA3434@www2.open-std.org> <20090122100652.C31E9CA3434@www2.open-std.org> <4978A8A0.8090407@cray.com> <20090122184931.B5D95CA3439@www2.open-std.org> In-Reply-To: <20090122184931.B5D95CA3439@www2.open-std.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Cray-VirusStatus: clean Sender: owner-sc22wg5@open-std.org Precedence: bulk Jim Xia wrote: > > > Except that the WAIT statement does have at least some semantics that > > the compiler understands. Which raises an interesting point. Nick has > > pointed out several places where it is theoretically possible for the > > compiler optimizer to cause problems because the "invisible hand" of > the > > MPI runtime currently "owns" part of the program's memory space and > > either expects it to remain static (sends) or modifies it (receives). > > > The "invisible hand" can be expressed by a visible hint if the > association between the two entities are explicitly established in > language. For example something like ALIAS_ASSOCIATED(buffer, > MPI_WAIT) hints an aliasing (or asynchronous) relationship between > buffer and MPI_WAIT, then the compiler (more precisely the optimizer) > may have enough information not to perform the code motion. I think > it is also more direct and obvious than asynchronous/wait. This suffers from the same problem as Van's extra argument proposal. The buffer may not be visible in the scoping unit of the call to MPI_wait. In addition, it may not be clear which buffer is relevant to a particular call. Nice idea, but I don't think it is practical. > > > > Fortran already has an attribute designed exactly for this situation - > > VOLATILE. VOLATILE and ASYNCHRONOUS normally appear together in the > > standard since they are so similar in effect. > > > I disagree here. VOLATILE and ASYNCHRONOUS has near zero similarity > in semantics. Volatile tells compilers the variable may be accessed > by another processor so don't trust register/cache, and always goes to > memory for any reference. I can't imagine any relation to > asynchronous except that both may disable optimization one way or > another. In the second sentence above, replace "Volatile" -> "Asynchronous" and "another process" -> "a concurrently executing thread in the I/O library", and it still makes sense. As your last sentence says, the similarity is in disabling optimizations, and that is the topic here. > > > The one difference (from > > the compiler's point of view) is that the volatility of a variable with > > the asynchronous attribute can be "turned off" when the compiler sees a > > global WAIT. > > > What is the volatility of an asynchronous variable? That its value can get changed by an invisible process. > > > If we modify the ASYNCHRONOUS attribute to be used to > > solve the issues with MPI calls, then WAIT is no longer special, and > > VOLATILE and ASYNCHRONOUS become functionally identical. > > I don't think they will. They have different semantics. > > > That's one of > > the undesirable side effect that makes me dislike the idea of modifying > > ASYNCHRONOUS. (The other is that it incorrectly suggests that MPI > calls > > have something to do with I/O which is not the case (except for the > > actual MPI I/O calls).) If we use a different name, like > > ASYNC_EXTERNAL, is there any difference between that and VOLATILE? I > > suspect not. In which case, the obvious solution is to just use > > VOLATILE. (Which was the conclusion of the previous round of > > discussions on this topic.) VOLATILE had a couple of very attractive > > features. It requires zero changes in either the Fortran standard > or in > > any compiler implementations. Thus, it is an immediately available > > solution for the MPI group. VOLATILE might be strong enough to solve > > the code-motion problem as well. > > I doubt volatile can effectively "turns off" code motion since it does > not have that semantics. You might be right about that, since the buffer is not part of the MPI_wait call. The subroutine prefix option should work, though. 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