From owner-sc22wg5@open-std.org Thu Jun 25 19:31:59 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 4BDE3C76BC8; Thu, 25 Jun 2009 19:31:59 +0200 (CET DST) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from ppsw-7.csi.cam.ac.uk (ppsw-7.csi.cam.ac.uk [131.111.8.137]) by www2.open-std.org (Postfix) with ESMTP id 6C6B3C76BBF for ; Thu, 25 Jun 2009 19:31:33 +0200 (CET DST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:58390) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:nmm1) id 1MJsnN-0001cD-Mt (Exim 4.70) for sc22wg5@open-std.org (return-path ); Thu, 25 Jun 2009 18:31:33 +0100 Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1MJsnN-0003Vi-2Z (Exim 4.67) for sc22wg5@open-std.org (return-path ); Thu, 25 Jun 2009 18:31:33 +0100 Received: from [83.67.89.123] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.1); 25 Jun 2009 18:31:33 +0100 Date: 25 Jun 2009 18:31:33 +0100 From: "N.M. Maclaren" To: sc22wg5 Subject: Re: [ukfortran] (SC22WG5.4043) (j3.2006) LOCK/UNLOCK question Message-ID: In-Reply-To: <20090625153554.533C4C76BBF@www2.open-std.org> 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> <20090625153554.533C4C76BBF@www2.open-std.org> X-Mailer: Prayer v1.3.1 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: owner-sc22wg5@open-std.org Precedence: bulk On Jun 25 2009, Bill Long wrote: >> >> 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. Yes, I know that. The only relevant wording for VOLATILE in the Fortran 2003 standard is in 5.1.2.16: The VOLATILE attribute specifies that an object may be referenced, defined, or become undefined, by means not specified by the program. NOTE 5.21 The Fortran processor should use the most recent definition of a volatile object when a value is required. Likewise, it should make the most recent Fortran definition available. It is the programmer's responsibility to manage the interactions with the non-Fortran processes. It requires a leap of faith to assume that it will have inter-image atomicicity (let alone synchronicity) properties. And, anyway, the WHOLE support for multiple images was a Cray extension, and so was necessarily outside the standard! Any experienced programmer will look in the processor-dependent section for what semantics can be assumed for VOLATILE coarrays - and there wasn't any - so almost all experienced programmers would avoid them like the plague. Sorry, no, that does NOT count as providing enough documentation to claim that there is significant experience by ordinary users. >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. You might. It's not my experience. >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. That is not my experience, either. >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. When I first came to specify it in a procurement, I had to write my own benchmarks because there were NO open source OpenMP programs around. There are now a few, but its acceptance is still very poor. It is still very much second to MPI, even on shared-memory systems. >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. (a) That doesn't apply to MPI non-blocking transfers and (b) several of the people I know of converted from their SHMEM code to MPI blocking calls precisely because they couldn't debug their program when they needed to move to a new system. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: nmm1@cam.ac.uk Tel.: +44 1223 334761 Fax: +44 1223 334679