From owner-sc22wg5@open-std.org Thu Jan 22 19:49:31 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 892A4CA5FE6; Thu, 22 Jan 2009 19:49:31 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by www2.open-std.org (Postfix) with ESMTP id B168ACA3439 for ; Thu, 22 Jan 2009 19:49:29 +0100 (CET) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n0MIls47032320 for ; Thu, 22 Jan 2009 13:47:54 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n0MInSXv190768 for ; Thu, 22 Jan 2009 13:49:28 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n0MImXAI011926 for ; Thu, 22 Jan 2009 13:48:33 -0500 Received: from d25ml04.torolab.ibm.com (d25ml04.torolab.ibm.com [9.26.6.105]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n0MImXRF011919; Thu, 22 Jan 2009 13:48:33 -0500 In-Reply-To: <4978A8A0.8090407@cray.com> 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> To: longb@cray.com Cc: WG5 MIME-Version: 1.0 Subject: Re: (j3.2006) (SC22WG5.3886) [ukfortran] [MPI3 Fortran] MPI non-blocking transfers X-Mailer: Lotus Notes Release 8.0.1 HF105 April 10, 2008 Message-ID: From: Jim Xia Date: Thu, 22 Jan 2009 13:50:01 -0500 X-MIMETrack: Serialize by Router on D25ML04/25/M/IBM(Release 7.0.3FP1|February 24, 2008) at 01/22/2009 13:50:04, Serialize complete at 01/22/2009 13:50:04 Content-Type: multipart/alternative; boundary="=_alternative 006766AF85257546_=" Sender: owner-sc22wg5@open-std.org Precedence: bulk This is a multipart message in MIME format. --=_alternative 006766AF85257546_= Content-Type: text/plain; charset="US-ASCII" > 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. > 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. 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? 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. Cheers, Jim Xia RL Fortran Compiler Test IBM Toronto Lab at 8200 Warden Ave, Markham, On, L6G 1C7 Phone (905) 413-3444 Tie-line 313-3444 email: jimxia@ca.ibm.com D2/YF7/8200 /MKM --=_alternative 006766AF85257546_= Content-Type: text/html; charset="US-ASCII"
> 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.


> 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.


                                                 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?


                    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.
Cheers,

Jim Xia

RL Fortran Compiler Test
IBM Toronto Lab at 8200 Warden Ave, Markham, On, L6G 1C7
Phone (905) 413-3444  Tie-line 313-3444
email: jimxia@ca.ibm.com
D2/YF7/8200 /MKM
--=_alternative 006766AF85257546_=--