From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Thu Jan 26 23:56:51 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 B1D4F356929; Thu, 26 Jan 2012 23:56:51 +0100 (CET) Delivered-To: sc22wg5@open-std.org Received: from mk-filter-2-a-1.mail.uk.tiscali.com (mk-filter-2-a-1.mail.tiscali.co.uk [212.74.100.53]) by www.open-std.org (Postfix) with ESMTP id EEB86356638 for ; Thu, 26 Jan 2012 23:56:47 +0100 (CET) X-Trace: 722927082/mk-filter-2.mail.uk.tiscali.com/B2C/$b2c-THROTTLED/TalkTalk_Customer/92.21.150.178/None/John.Reid@stfc.ac.uk X-SBRS: None X-RemoteIP: 92.21.150.178 X-IP-MAIL-FROM: John.Reid@stfc.ac.uk X-SMTP-AUTH: X-Originating-Country: GB/UNITED KINGDOM X-MUA: Mozilla/5.0 (Windows NT 5.1; rv:9.0.1) Gecko/20111221 Firefox/9.0.1 SeaMonkey/2.6.1 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIBAPDZIU9cFZay/2dsb2JhbAAMN7IiJT0WGAMCAQIBSw0IAr9xiT8GAQEYByuCaAIJAgECAQEGBQIGBAoCAhJmHAEBAQEBAQECAQEBAQEBAQEBAYNABI48gRmFSoVEjQ0 X-IronPort-AV: E=Sophos;i="4.71,576,1320624000"; d="txt'?scan'208";a="722927082" Received: from host-92-21-150-178.as13285.net (HELO [127.0.0.1]) ([92.21.150.178]) by smtp.tiscali.co.uk with ESMTP; 26 Jan 2012 22:56:44 +0000 Message-ID: <4F21DA2A.9050909@stfc.ac.uk> Date: Thu, 26 Jan 2012 22:56:42 +0000 From: John Reid User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0.1) Gecko/20111221 Firefox/9.0.1 SeaMonkey/2.6.1 MIME-Version: 1.0 To: WG5 Subject: Second invitation to comment on coarray features Content-Type: multipart/mixed; boundary="------------090709060608060006080104" Sender: owner-sc22wg5@open-std.org Precedence: bulk This is a multi-part message in MIME format. --------------090709060608060006080104 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. The deadline was noon UK time today. This has passed and I have received only one response. This is from Reinhold and is attached. I am remiss in not reminding you of the deadline. It was set so that the comments would be available for the J3 meeting. A paper written on Monday will meet the pre-meeting deadline, so I am open to additional comments until 9 a.m. UK time on Monday. Cheers, John. --------------090709060608060006080104 Content-Type: text/plain; name="comments_N1888.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="comments_N1888.txt" 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. --------------090709060608060006080104--