From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Sat Mar 30 12:54:01 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 D6AAF356DE6; Sat, 30 Mar 2013 12:54:01 +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 67D01356DD7 for ; Sat, 30 Mar 2013 12:53:59 +0100 (CET) Received: from lxmhs51.srv.lrz.de (localhost [127.0.0.1]) by postout3.mail.lrz.de (Postfix) with ESMTP id 2A70F20206; Sat, 30 Mar 2013 12:53:59 +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 FapB7TTXQxdC; Sat, 30 Mar 2013 12:53:58 +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 E5A90201FD; Sat, 30 Mar 2013 12:53:57 +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 12:53:57 +0100 From: "Bader, Reinhold" To: fortran standards email list for J3 CC: sc22wg5 , "Van.Snyder@jpl.nasa.gov" Subject: AW: (j3.2006) (SC22WG5.4954) AW: AW: [ukfortran] AW: Thoughts on Reinhold's thoughts Thread-Topic: (j3.2006) (SC22WG5.4954) AW: AW: [ukfortran] AW: Thoughts on Reinhold's thoughts Thread-Index: AQHOLTuF3T79fT2wrEaS5Fy5tkMge5i+HRTg Date: Sat, 30 Mar 2013 11:53:56 +0000 Message-ID: <166ED263DF83324D9A3BA67FB6772B2B59F2B577@BADWLRZ-SWMBX11.ads.mwn.de> References: <20130329203623.0D66F356D96@www.open-std.org> <20130329212446.AD585356D97@www.open-std.org> <20130329231248.0A33D356DA7@www.open-std.org> <166ED263DF83324D9A3BA67FB6772B2B59F2B4D0@BADWLRZ-SWMBX11.ads.mwn.de> <166ED263DF83324D9A3BA67FB6772B2B59F2B546@BADWLRZ-SWMBX11.ads.mwn.de> <20130330114121.E5517356DD8@www.open-std.org> In-Reply-To: <20130330114121.E5517356DD8@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.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 > -----Urspr=FCngliche Nachricht----- > Von: j3-bounces@mailman.j3-fortran.org [mailto:j3-bounces@mailman.j3- > fortran.org] Im Auftrag von N.M. Maclaren > Gesendet: Samstag, 30. M=E4rz 2013 12:41 > An: Bader, Reinhold > Cc: sc22wg5; Van.Snyder@jpl.nasa.gov; fortran standards email list for J3 > Betreff: (j3.2006) (SC22WG5.4954) AW: AW: [ukfortran] AW: Thoughts on > Reinhold's thoughts >=20 > On Mar 30 2013, Bader, Reinhold wrote: > > > > Note that since your suggestion also involves relaxation of the CHANGE > > TEAM synchronization semantics, you're under obligation of providing > > proof of correctness as well ... >=20 > Accepted :-) >=20 > That suggestion (and it's most definitely inchoate) was because of all > of the fundamental objections I had to the facility proposed in the > draft TS. That definitely won't work. >=20 > I can see three approaches, in various levels of severity: >=20 > 1) To forbid ALL communication from inside or outside a team to the > other, even for coarrays that are used only in one place >=20 > 2) To forbid any synchronisation between inside and outside, though > to permit the outside to access inside coarrays not used inside This is what my suggestions would imply (and may also answer your issues wi= th my version of the=20 data feeder). The example does not completely get rid of overhead, but cons= iderably reduces it.=20 To reiterate:=20 * computation and coindexed data transfers are overlapped with team executi= on (and this activity will usually involve=20 orders of magnitude more cycles than the one in the next bullet).=20 * local memory operations and partial synchronization are not overlapped; f= urther optimization potential compared to my example might be to use a local pointer assignment instea= d of a local memory copy, and to use events for synchronization instead of SYNC IMAGES. >=20 > 3) To allow limited synchronisation between inside and outside, > whether by using atomics and SYNC MEMORY or otherwise >=20 > (1) is easy to validate, (2) doesn't introduce any consistency problems > though it might introduce deadlock, and (3) is the one I get twitchy > about. I would also be in favor of disallowing (3). In fact, usage of atomics (as = well as events) should also not be=20 allowed across team boundaries if they are to be generally efficient, for j= ust the reasons you give.=20 >=20 >=20 >=20 > Regards, > Nick Maclaren. >=20 > _______________________________________________ > J3 mailing list > J3@mailman.j3-fortran.org > http://mailman.j3-fortran.org/mailman/listinfo/j3