From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Fri Mar 29 22:24:46 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 07444356DA6; Fri, 29 Mar 2013 22:24:45 +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 BDA73356BB3 for ; Fri, 29 Mar 2013 22:24:42 +0100 (CET) Received: from lxmhs52.srv.lrz.de (localhost [127.0.0.1]) by postout4.mail.lrz.de (Postfix) with ESMTP id 9CBE3200BA; Fri, 29 Mar 2013 22:24:42 +0100 (CET) X-Virus-Scanned: by amavisd-new at lrz.de in lxmhs52.srv.lrz.de Received: from postout4.mail.lrz.de ([127.0.0.1]) by lxmhs52.srv.lrz.de (lxmhs52.srv.lrz.de [127.0.0.1]) (amavisd-new, port 20024) with LMTP id 4qCQeOhRuQLH; Fri, 29 Mar 2013 22:24:37 +0100 (CET) Received: from BADWLRZ-SWHBT2.ads.mwn.de (BADWLRZ-SWHBT2.ads.mwn.de [IPv6:2001:4ca0:0:108::126]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "BADWLRZ-SWHBT2", Issuer "BADWLRZ-SWHBT2" (not verified)) by postout4.mail.lrz.de (Postfix) with ESMTPS id CB3E3200B7; Fri, 29 Mar 2013 22:24:37 +0100 (CET) Received: from BADWLRZ-SWMBX11.ads.mwn.de ([fe80::6de5:ff8b:1900:b1a1]) by BADWLRZ-SWHBT2.ads.mwn.de ([fe80::5951:9dc3:7b2b:14ba%13]) with mapi id 14.01.0438.000; Fri, 29 Mar 2013 22:24:30 +0100 From: "Bader, Reinhold" To: "Van.Snyder@jpl.nasa.gov" , fortran standards email list for J3 , sc22wg5 Subject: AW: (j3.2006) (SC22WG5.4943) Thoughts on Reinhold's thoughts Thread-Topic: (j3.2006) (SC22WG5.4943) Thoughts on Reinhold's thoughts Thread-Index: AQHOLL0emfmHxPMlx02pxdzh21ion5i9JFhA Date: Fri, 29 Mar 2013 21:24:29 +0000 Message-ID: <166ED263DF83324D9A3BA67FB6772B2B59F2B417@BADWLRZ-SWMBX11.ads.mwn.de> References: <20130329203623.0D66F356D96@www.open-std.org> In-Reply-To: <20130329203623.0D66F356D96@www.open-std.org> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.187.48.231] 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 Van,=20 > -----Urspr=FCngliche Nachricht----- > Von: j3-bounces@mailman.j3-fortran.org [mailto:j3-bounces@mailman.j3- > fortran.org] Im Auftrag von Van Snyder > Gesendet: Freitag, 29. M=E4rz 2013 21:37 > An: sc22wg5 > Betreff: (j3.2006) (SC22WG5.4943) Thoughts on Reinhold's thoughts >=20 > (B.1, B.4) CHANGE TEAM synchronization and ancestor-team addressing >=20 > 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 team vi= a coindexing,=20 and I think with good reason: It would violate composability of the program= ming model.=20 Of course, there still should be some way of efficiently exchanging data be= tween subteams,=20 motivating my desire to remove the big barrier around CHANGE TEAM (effectiv= ely saying:=20 If we can't pull data into a team from its inside, lets push them in from t= he outside).=20 >=20 > type(team_type) top > integer :: id_1, id_2 > id_1 =3D min(2,this_image()) > form subteam ( id_1, top ) > 1 change team ( top ) > select case ( id_1 ) > case ( 1 ) > ! work asynchronously from the remaining teams, accessing > ! their data using ancestor-team indexing > case ( 2 ) > block > type(team_type) bottom > id_2 =3D 2+mod(this_image,2) > form subteam ( id_2, bottom ) > 2 change team ( bottom ) > select case ( id_2 ) > case ( 2 ) > ... > case ( 3 ) > end select > end block > end select > end team >=20 > The first change team synchornizes all images (maybe this is the problem > Reinhold wanted to avoid), while the second one only synchronizes images > other than image 1. >=20 > (D.1) CO_MULT: for distributed linear algebra, it is likely that a > collective multiply-add would be more useful. I'd go along with this idea. >=20 > (D.2) Asynchronous execution: I previously argued that EVENT WAIT ought > to be WAIT, that the WAIT statement ought to be moved to somewhere in > Clause 8, and that the I/O and WAIT statements ought to admit a variable > of LOCAL_EVENT_TYPE for synchronization. The objection appeared to be > to the concept of conflating I/O with anything else. If we use the > ASYNCHRONOUS attribute for the purpose Reinhold suggests, perhaps we can > re-visit the question of WAIT. >=20 > Reinhold's and Nick's concerns tell me that we must tread very > carefully, lest we make an irrevocable mistake. We risk things that > even interps cannot repair. Getting it right must take a much higher > priority than getting it out on schedule. Agreed. With respect to the big barrier in CHANGE TEAM let me note that the= re are risks to any path we take: =20 * if it is retained and no other way is found to *efficiently* exchange dat= a between teams, the teams feature will be regarded as a half-baked solution by pr= ogrammers * if it is removed and we fail to nail down the possible inconsistencies th= at might result, implementors will start a head-hunt ... For this reason I'd like to see *concrete examples* that show how things ca= n go badly=20 wrong if the synchronization requirements are relaxed. Regards Reinhold >=20 >=20 > _______________________________________________ > J3 mailing list > J3@mailman.j3-fortran.org > http://mailman.j3-fortran.org/mailman/listinfo/j3