From owner-sc22wg5@open-std.org Thu Jun 25 17:35:54 2009 Return-Path: X-Original-To: sc22wg5-dom7 Delivered-To: sc22wg5-dom7@www2.open-std.org Received: by www2.open-std.org (Postfix, from userid 521) id 2E9C9C76BC8; Thu, 25 Jun 2009 17:35:54 +0200 (CET DST) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from mail1.cray.com (mail1.cray.com [136.162.0.111]) by www2.open-std.org (Postfix) with ESMTP id 32ED9C76BBF for ; Thu, 25 Jun 2009 17:35:28 +0200 (CET DST) Received: from beaver.us.cray.com (beaver.us.cray.com [172.30.74.51]) by mail1.cray.com (8.13.6/8.13.3/gw-5323) with ESMTP id n5PFZPNn019185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 25 Jun 2009 10:35:26 -0500 (CDT) Received: from CFEXFE01.us.cray.com (CFEXFE01.americas.cray.com [172.30.74.93]) by beaver.us.cray.com (8.13.8/8.13.3/hub-5273) with ESMTP id n5PFZOHp028328; Thu, 25 Jun 2009 10:35:24 -0500 Received: from bill-longs-macbook-pro.local ([192.168.239.19]) by CFEXFE01.us.cray.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Jun 2009 10:35:23 -0500 Message-ID: <4A4399C6.5020805@cray.com> Date: Thu, 25 Jun 2009 10:37:42 -0500 From: Bill Long Reply-To: longb@cray.com Organization: Cray Inc. User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: fortran standards email list for J3 Cc: sc22wg5 Subject: Re: (j3.2006) (SC22WG5.4042) [ukfortran] LOCK/UNLOCK question References: <4A38A3BB.9090208@nag-j.co.jp><4A38B917.8080202@llnl.gov> <4A391682.8060208@cray.com> <061720091627.18164.4A39196C000C05A4000046F422230703729B0A02D29B9B0EBF02019C050C079D0B020A08D2050C070B@att.net> <4A3930E3.8070505@cray.com> <061720091851.25112.4A393B4100015BA20000621822228869349B0A02D29B9B0EBF02019C050C079D0B020A08D2050C070B@att.net> <4A397E50.9010406@nag-j.co.jp> <4A3F9897.8010103@llnl.gov> <4A3FA25D.1050507@cray.com> <4A3FF921.9070703@llnl.gov> <20090622221248.1FEF4C178E5@www2.open-std.org> <20090623084602.88A3EC178E5@www2.open-std.org> <20090624020300.8EE77C178E5@www2.open-std.org> <20090625033421.31AAEC3BB09@www2.open-std.org> <20090625051920.8B235C3BB09@www2.open-std.org> <20090625094501.CB3A0C4596C@www2.open-std.org> <20090625131644.E257CC4596C@www2.open-std.org> <20090625142825.739B8C76BBF@www2.open-std.org> In-Reply-To: <20090625142825.739B8C76BBF@www2.open-std.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jun 2009 15:35:23.0866 (UTC) FILETIME=[8E5FD3A0:01C9F5AA] X-Cray-VirusStatus: clean Sender: owner-sc22wg5@open-std.org Precedence: bulk N.M. Maclaren wrote: > > S-3901-60 makes no reference to the use of VOLATILE for atomicity, which > is precisely why I included it there. Furthermore, I specifically > looked for VOLATILE coarray support on your Web pages when writing N1754 > (in October 2008), and the latest language reference manual that I could > find did not mention it. > > What version of the manual WAS it first documented in? Our current documentation policy is that the manuals mention only differences between our implementation and the standard. Since 6.0 in 2007, we've used Fortran 2003 as the base standard for the document. Since VOLATILE is part of the standard, it is not mentioned in the documentation. Ironically, when Fortran 2008 is published and we switch to that as the base, we will need to start documenting that off-image references to VOLATILE coarrays are exempted from the segment ordering rules as an extension. > > A more directly relevant issue is the number of parallel programming > paradigms that have failed to take off because users couldn't debug > their code (especially up to the level of portability). To a great > extent, that applies to all of ScaLAPACK, HPF, OpenMP and POSIX threads, > plus a multitude of less widespread paradigms; HPF had performance > problems as well, of course. I'd argue that in the case of ScaLAPACK and HPF, the difficulty of understanding how to write the program in the first place was a bigger cause of failure than debugging. By comparison, I think OpenMP has been widely successful for local (i.e. within image) shared-memory parallelism. The advent of multi-core chips has increased its usage. While there are some performance issues, and serious scaling limitations, I think the OpenMP crowd can feel pretty good about its acceptance. It's in enough benchmarks that vendors are essentially forced to support it. It has even affected MPI non-blocking > transfers; I have no feel for what has prevented MPI one-sided transfers > from taking off. > I suspect it is partly inertia. Some who need one-sided transfers already have access to coarrays or UPC which are a lot easier to code than MPI. Others have been using Shmem for years, and see no point in converting. Cheers, Bill -- Bill Long longb@cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120