From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Tue Feb 7 15:58:28 2012 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 22A72356990; Tue, 7 Feb 2012 15:58:27 +0100 (CET) Delivered-To: sc22wg5@open-std.org Received: from mk-filter-4-a-1.mail.uk.tiscali.com (mk-filter-4-a-1.mail.tiscali.co.uk [212.74.100.55]) by www.open-std.org (Postfix) with ESMTP id CEEA135692D for ; Tue, 7 Feb 2012 15:58:25 +0100 (CET) X-Trace: 720457383/mk-filter-4.mail.uk.tiscali.com/B2C/$b2c-THROTTLED/TalkTalk_Customer/2.101.17.7/None/John.Reid@stfc.ac.uk X-SBRS: None X-RemoteIP: 2.101.17.7 X-IP-MAIL-FROM: John.Reid@stfc.ac.uk X-SMTP-AUTH: X-Originating-Country: XX/UNKNOWN X-MUA: Mozilla/5.0 (Windows NT 5.1; rv:10.0) Gecko/20120129 Firefox/10.0 SeaMonkey/2.7 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIBAG07MU8CZREH/2dsb2JhbAAMN7MkJT0MChgDAgECAUsNCALCNYthBgEBAYM6AQIJAgIBAwEDBAQCBgcEAgEBCgFfGwEBAQEBAQIBAQEBAQEBAQEBE4MpBI5FgRuFTIVFjRg X-IronPort-AV: E=Sophos;i="4.73,377,1325462400"; d="txt'?scan'208";a="720457383" Received: from host-2-101-17-7.as13285.net (HELO [127.0.0.1]) ([2.101.17.7]) by smtp.tiscali.co.uk with ESMTP; 07 Feb 2012 14:58:24 +0000 Message-ID: <4F313C10.3030606@stfc.ac.uk> Date: Tue, 07 Feb 2012 14:58:24 +0000 From: John Reid User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0) Gecko/20120129 Firefox/10.0 SeaMonkey/2.7 MIME-Version: 1.0 To: WG5 Subject: Second invitation to comment on coarray features Content-Type: multipart/mixed; boundary="------------030103050603080108050307" Sender: owner-sc22wg5@open-std.org Precedence: bulk This is a multi-part message in MIME format. --------------030103050603080108050307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit WG5, In N1888, I invited comments on the proposals there or new suggestions. I have received only one response. This is from Reinhold and is in the attached paper. Dan, please will you arrange for J3 to take this into account during the forthcoming J3 meeting. Cheers, John. --------------030103050603080108050307 Content-Type: text/plain; name="N1906.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="N1906.txt" ISO/IEC JTC1/SC22/WG5 N1906 Response to the second invitation to comment on the contents of the TS on further coarray features John Reid 7 February 2012 In N1888, I invited comments on the proposals there or new suggestions. I have received only one response. This was from Reinhold Bader. Here it is. Comments on WG5/N1888: ~~~~~~~~~~~~~~~~~~~~~~ Comment on Proposal 2 (teams): Perhaps it should also be mentioned that teams, if properly designed, would provide Fortran with a uniformly usable hybrid programming model, well-mapped to nowadays' deeply hierarchical HPC architectures; synchronization statements would not only not impede uninvolved images, but might also execute much faster within a team (e.g., executing an OpenMP lock across a large-scale shared memory system typically needs the top-level latency of the system, multiplied with the logarithm of the number of units on that level). Adding a WITH TEAM construct therefore may turn out to be more than only syntactic sugar. Comment on Proposal 5 (global pointers): The discussion section mentions that "[t]he Bader proposal is significantly more complicated since it also contains the idea of any image being able to access a local object that resides on one image". This appears to be a misunderstanding - coscalar pointers were certainly not meant to be able to point at local entities on other images. Although I may not have explicitly said this, I did mention that the intent was to mirror the functionality of UPC shared pointers to shared entities. (Note that I am not arguing against the conclusion in the proposal, although I suspect it increases the size of the feature). Comment on Proposal 11: For a decision on the size of the TS, priorization may be helpful. My preference for priorization would be as follows, in descending order of importance: (1) Collective procedures (2) Notify/Query one-sided synchronization (3) Teams (4) Additional atomic operations (5) Remove restrictions on coarray components (6) Global pointers (7) Parallel I/O extensions (8) Predicated copy_async intrinsic The order of importance was chosen mainly according to my expectation on the combined impact on performance scalability and ease of use for the programmer. Even if a 30% size increase in the time budget is conceded, I suspect that not all the suggested features still open for investigation can be realized. --------------030103050603080108050307--