From owner-sc22wg5@open-std.org Thu Jan 22 08:59:15 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 736B3CA3439; Thu, 22 Jan 2009 08:59:15 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from ns.nag-j.co.jp (218-42-159-107.cust.bit-drive.ne.jp [218.42.159.107]) by www2.open-std.org (Postfix) with ESMTP id 3BDC1CA3430 for ; Thu, 22 Jan 2009 08:59:13 +0100 (CET) Received: from 218-42-159-108.cust.bit-drive.ne.jp ([218.42.159.108] helo=[127.0.0.1]) by ns.nag-j.co.jp with esmtp (Exim 4.50) id 1LPuSB-0004QM-VB for sc22wg5@open-std.org; Thu, 22 Jan 2009 16:58:20 +0900 Message-ID: <4978280D.2030408@nag-j.co.jp> Date: Thu, 22 Jan 2009 17:02:21 +0900 From: Malcolm Cohen User-Agent: Thunderbird 3.0a1pre (Windows/2008022014) MIME-Version: 1.0 To: WG5 Subject: [Fwd: Re: (j3.2006) (SC22WG5.3880) [ukfortran] [MPI3 Fortran] MPI non-blocking transfers] Content-Type: multipart/mixed; boundary="------------000907070600060705070708" Sender: owner-sc22wg5@open-std.org Precedence: bulk This is a multi-part message in MIME format. --------------000907070600060705070708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Forwarded message from Van. **********NOTE*********** PLEASE ENSURE THE WG5 DISCUSSION REMAINS ON THE WG5 LIST. ======================= Thank you. --------------000907070600060705070708 Content-Type: message/rfc822; name="Re: (j3.2006) (SC22WG5.3880) [ukfortran] [MPI3 Fortran] MPI non-blocking transfers.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="Re: (j3.2006) (SC22WG5.3880) [ukfortran] [MPI3 Fortran] MPI "; filename*1="non-blocking transfers.eml" X-Account-Key: account2 X-Mozilla-Keys: Return-path: Envelope-to: malcolm@nag-j.co.jp Delivery-date: Thu, 22 Jan 2009 11:46:19 +0900 Received: from mail35.messagelabs.com ([62.231.131.195]) by ns.nag-j.co.jp with smtp (Exim 4.50) id 1LPpaE-00033U-A3 for malcolm@nag-j.co.jp; Thu, 22 Jan 2009 11:46:19 +0900 X-VirusChecked: Checked X-Env-Sender: j3-bounces@j3-fortran.org X-Msg-Ref: server-9.tower-35.messagelabs.com!1232592425!23635688!1 X-StarScan-Version: 6.0.0; banners=.,-,- X-Originating-IP: [62.231.145.242] Received: (qmail 27848 invoked from network); 22 Jan 2009 02:47:05 -0000 Received: from nagmx1.nag.co.uk (HELO nagmx1.nag.co.uk) (62.231.145.242) by server-9.tower-35.messagelabs.com with SMTP; 22 Jan 2009 02:47:05 -0000 Received: by nagmx1.nag.co.uk (Postfix) id 4C2F1120160; Thu, 22 Jan 2009 02:47:12 +0000 (GMT) Delivered-To: malcolm@nag.co.uk Received: from mail194.messagelabs.com (mail194.messagelabs.com [85.158.140.211]) by nagmx1.nag.co.uk (Postfix) with ESMTP id 41D5B12015F for ; Thu, 22 Jan 2009 02:47:12 +0000 (GMT) X-VirusChecked: Checked X-Env-Sender: j3-bounces@j3-fortran.org X-Msg-Ref: server-13.tower-194.messagelabs.com!1232592424!14545067!1 X-StarScan-Version: 6.0.0; banners=-,-,nag.co.uk X-Originating-IP: [129.174.65.102] X-SpamReason: No, hits=0.0 required=7.0 tests= Received: (qmail 32256 invoked from network); 22 Jan 2009 02:47:04 -0000 Received: from j3.cos.gmu.edu (HELO j3.cos.gmu.edu) (129.174.65.102) by server-13.tower-194.messagelabs.com with AES256-SHA encrypted SMTP; 22 Jan 2009 02:47:04 -0000 Received: from j3-fortran.org (j3 [127.0.0.1]) by j3.cos.gmu.edu (8.13.1/8.13.1) with ESMTP id n0M2Hc5o029333; Wed, 21 Jan 2009 21:17:42 -0500 Received: from mail.jpl.nasa.gov (sentrion2.jpl.nasa.gov [128.149.139.106]) by j3.cos.gmu.edu (8.13.1/8.13.1) with ESMTP id n0M2HbPf029330 for ; Wed, 21 Jan 2009 21:17:37 -0500 Received: from mprox2.jpl.nasa.gov (mprox2.jpl.nasa.gov [137.78.160.141]) by mail.jpl.nasa.gov (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id n0M2kcsA010867 for ; Thu, 22 Jan 2009 02:46:39 GMT Received: from [137.79.7.57] (math.jpl.nasa.gov [137.79.7.57]) (authenticated bits=0) by mprox2.jpl.nasa.gov (Switch-3.2.6/Switch-3.2.6) with ESMTP id n0M2kbnA009311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 21 Jan 2009 18:46:37 -0800 From: Van Snyder To: fortran standards email list for J3 In-Reply-To: <200901211617.53468.donev1@llnl.gov> References: <20090121234200.4F3BDCA3434@www2.open-std.org> <20090122000407.D5A8ECA3434@www2.open-std.org> <200901211617.53468.donev1@llnl.gov> Organization: Yes Date: Wed, 21 Jan 2009 18:46:36 -0800 Message-Id: <1232592397.15119.747.camel@math.jpl.nasa.gov> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-8.el5_2.3) X-Source-IP: math.jpl.nasa.gov [137.79.7.57] X-Source-Sender: Van.Snyder@jpl.nasa.gov X-AUTH: Authorized Subject: Re: (j3.2006) (SC22WG5.3880) [ukfortran] [MPI3 Fortran] MPI non-blocking transfers X-BeenThere: j3@j3-fortran.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Van.Snyder@jpl.nasa.gov, fortran standards email list for J3 List-Id: fortran standards email list for J3 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: j3-bounces@j3-fortran.org Errors-To: j3-bounces@j3-fortran.org On Wed, 2009-01-21 at 16:17 -0800, Aleksandar Donev wrote: > On Wednesday 21 January 2009 16:04, Van Snyder wrote: > > > or is there another cause for it? > YES!!! Why do we have the ASYNCHRONOUS attribute instead of just having > WAIT?!? The compiler must know that a variable can change behind its > back, must now not to perform copy in/out and "optimizations", and the > standard has several restrictions on ASYNCHRONOUS dummies (see chapter > 12). These are all "other causes" and have no connection to WAIT what > so ever. The restrictions on ASYNCHRONOUS dummies are frequently to protect the associated actual argument, but in any case can't apply to dummies that aren't there. Isn't that the problem with MPI wait? > And no, this is not a defect with MPI's interface. It is simply another > way to do interfaces. Plenty of libraries save pointers and do not ask > you to pass the same 100 arguments both for the "start" and the "end" > of an operation. It is perfectly sensible design, especially in the C > world. It's sensible in the C world because C's pointer semantics paralyze the optimizer. Code motion is very limited compared to the possibilities in Fortran. It would be sensible in the Fortran world, too, because of the rule that says the base object of an asynchronously referenced component either gets the ASYNCHRONOUS attribute by magic or has to have it explicitly declared (ASYNCHRONOUS is not in ). But the Fortran compiler doesn't understand the guts of the opaque C struct that MPI uses for its handle, so it can't know enough not to do code motions involving stuff that might be referenced by the handle. Fortran knows enough not to move accesses to variables with the ASYNCHRONOUS attribute across a WAIT statement because it understands the semantics of the WAIT statement. It also knows enough not to move such accesses across a reference to a procedure where they appear as actual arguments and the associated dummy argument has the ASYNCHRONOUS attribute, because the called procedure might execute a WAIT statement. When Fortran calls C and a variable isn't mentioned, the compiler can't know enough not to move accesses to the unmentioned variable across the procedure reference. If the variable were to have the ASYNCHRONOUS attribute, and were to appear as an actual argument associated with a dummy argument having the ASYNCHRONOUS attribute in a reference to a procedure, the compiler wouldn't need to understand the semantics of the procedure, and wouldn't need any extra magic to avoid moving accesses to the variable across the reference. I don't think Fortran needs a new/different attribute, or to understand the semantics of the MPI wait procedure, or an annotation for the MPI wait procedure to tell the compiler its semantics. Just write an interface layer that includes a buffer dummy argument with the ASYNCHRONOUS attribute, and within that interface layer call the MPI wait routine and ignore the buffer. The interface layer probably has to be written in C to avoid the possibility that a clever compiler would inline it, optimize away the do-nothing layer, and then notice that the buffer isn't passed to the MPI wait routine -- so it can move code across the reference! Maybe add text (maybe in a note) that explains when asynchronous objects have to appear as actual arguments associated with asynchronous dummy arguments -- some blah blah blah about appearing anywhere as an actual argument to a procedure with BIND(C) if the procedure or one of its lackeys might take a pointer to it, or in C_LOC or..., because once C gets the address of it, Fortran can't otherwise know when to suppress code motion. The alternative is that the optimizer NEVER moves access to ANY interoperable variable with the ASYNCHRONOUS attribute across ANY procedure reference. If the handle in the MPI wait reference were not opaque, and it had a pointer TKR-compatible with the buffer, and the buffer were either a target or pointer and had the ASYNCHRONOUS attribute, and the handle had the ASYNCHRONOUS attribute, the compiler might know enough not to move references to the buffer across the reference. But the handle is opaque, and a C struct to boot, right? Which raises a Fortran-only question, having nothing to do with MPI: If a variable X has a pointer ultimate component Y, and the ASYNCHRONOUS attribute, and appears as an actual argument in a procedure reference in which the corresponding dummy argument has the ASYNCHRONOUS attribute, would an optimizer refrain from moving accesses to ANY variable that has the ASYNCHRONOUS attribute, and either the POINTER or TARGET attribute, and is either TKR-compatible with X%...Y or has an ultimate component that is TKR-compatible with X%...Y, across the reference? It probably should, but also probably need not worry about other variables. _______________________________________________ J3 mailing list J3@j3-fortran.org http://j3-fortran.org/mailman/listinfo/j3 ________________________________________________________________________ This e-mail has been scanned for all viruses by Star. ________________________________________________________________________ ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ --------------000907070600060705070708--