From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Sat Mar 30 10:55:53 2013 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id 6846F356DC5; Sat, 30 Mar 2013 10:55:53 +0100 (CET) Delivered-To: sc22wg5@open-std.org Received: from postout.lrz.de (postout.lrz.de [129.187.254.115]) by www.open-std.org (Postfix) with ESMTP id 07321356600 for ; Sat, 30 Mar 2013 10:55:52 +0100 (CET) Received: from lxmhs51.srv.lrz.de (localhost [127.0.0.1]) by postout3.mail.lrz.de (Postfix) with ESMTP id 9210E2020D; Sat, 30 Mar 2013 10:55:52 +0100 (CET) X-Virus-Scanned: by amavisd-new at lrz.de in lxmhs51.srv.lrz.de Received: from postout3.mail.lrz.de ([127.0.0.1]) by lxmhs51.srv.lrz.de (lxmhs51.srv.lrz.de [127.0.0.1]) (amavisd-new, port 20024) with LMTP id WGI8xaMffk46; Sat, 30 Mar 2013 10:55:52 +0100 (CET) Received: from BADWLRZ-SWHBT1.ads.mwn.de (BADWLRZ-SWHBT1.ads.mwn.de [IPv6:2001:4ca0:0:108::125]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "BADWLRZ-SWHBT1", Issuer "BADWLRZ-SWHBT1" (not verified)) by postout3.mail.lrz.de (Postfix) with ESMTPS id E12B8201FD; Sat, 30 Mar 2013 10:55:51 +0100 (CET) Received: from BADWLRZ-SWMBX11.ads.mwn.de ([fe80::6de5:ff8b:1900:b1a1]) by BADWLRZ-SWHBT1.ads.mwn.de ([fe80::e42f:e9f5:bde9:f99b%16]) with mapi id 14.01.0438.000; Sat, 30 Mar 2013 10:55:51 +0100 From: "Bader, Reinhold" To: "N.M. Maclaren" CC: "Van.Snyder@jpl.nasa.gov" , fortran standards email list for J3 , sc22wg5 Subject: AW: [ukfortran] (SC22WG5.4944) AW: (j3.2006) Thoughts on Reinhold's thoughts Thread-Topic: [ukfortran] (SC22WG5.4944) AW: (j3.2006) Thoughts on Reinhold's thoughts Thread-Index: AQHOLMPeEB4ouhqMbE29NbX+tIft5pi96zoAgAAS74A= Date: Sat, 30 Mar 2013 09:55:50 +0000 Message-ID: <166ED263DF83324D9A3BA67FB6772B2B59F2B4E6@BADWLRZ-SWMBX11.ads.mwn.de> References: <20130329203623.0D66F356D96@www.open-std.org> <20130329212446.AD585356D97@www.open-std.org> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.187.48.197] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-sc22wg5@open-std.org Precedence: bulk Hello Nick,=20 > -----Urspr=FCngliche Nachricht----- > Von: N.M. Maclaren [mailto:nmm1@hermes.cam.ac.uk] Im Auftrag von N.M. > Maclaren > Gesendet: Samstag, 30. M=E4rz 2013 10:42 > An: Bader, Reinhold > Cc: Van.Snyder@jpl.nasa.gov; fortran standards email list for J3; sc22wg5 > Betreff: Re: [ukfortran] (SC22WG5.4944) AW: (j3.2006) Thoughts on Reinhol= d's > thoughts >=20 > On Mar 29 2013, Bader, Reinhold wrote: > >> > >> (B.1, B.4) CHANGE TEAM synchronization and ancestor-team addressing > >> > >> Reinhold gave an example where image 1 cannot do things asynchronously > >> while the remaining images, decomposed into two teams, do something > >> else, because of the synchronization requirements of CHANGE TEAM. If = it > >> were possible to use ancestor-team coindexing (I haven't given much > >> thought to the syntax) one could decompose first into two teams, image= 1 > >> and the rest of them, then decompose the remaining teams: > > > > Unfortunately, item T2 of N1930 prohibits going outside the current tea= m > > via coindexing, and I think with good reason: It would violate > > composability of the programming model. Of course, there still should b= e > > some way of efficiently exchanging data between subteams, motivating my > > desire to remove the big barrier around CHANGE TEAM (effectively saying= : > > If we can't pull data into a team from its inside, lets push them in fr= om > > the outside). >=20 > Slightly more on this. My suggestion in my response addresses this in > several ways: >=20 > FORM TEAMS would be a mere collective that returns a handle but does > no synchronisation > CHANGE TEAMS would synchronise only the subteam, but would do so at > beginning and end > There would be no problem about uninvolved subteams continuing with > other computation or in other subteams From the "usability" point of view this already would be a big improvement.= =20 >=20 > 'Outside' images could push data into the subteam, but it could not use > it, because there is no way to synchronise. =20 My data_feeder example effectively uses double buffering and separates=20 buffer exchange (a pure memory operation) via a partial synchronization ope= ration in the ancestor team.=20 > Well, actually, there is, > but I am in two minds about whether it is a facility or a loophole that > needs closing. >=20 > If 'outside' synchronises with 'inside' using consistent atomics and > SYNC MEMORY, should that be legal? =20 If coindexing ancestor-inherited coarrays is possible. I believe it shouldn= 't be. > While I can't think of a solid > reason why not, I can think of a lot of consequences, and it won't just > happen in implementations (i.e. they will have to take steps to ensure > that it works). >=20 >=20 > Regards, > Nick.