From owner-sc22wg5@open-std.org Thu Jun 25 15:16:44 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 23134C76BBF; Thu, 25 Jun 2009 15:16:44 +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 A4DF5C4596C for ; Thu, 25 Jun 2009 15:16:14 +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 n5PDG9PM010920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 25 Jun 2009 08:16:10 -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 n5PDG8EI021500; Thu, 25 Jun 2009 08:16:08 -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 08:16:07 -0500 Message-ID: <4A437921.9040005@cray.com> Date: Thu, 25 Jun 2009 08:18:25 -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.4039) [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> In-Reply-To: <20090625094501.CB3A0C4596C@www2.open-std.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jun 2009 13:16:07.0859 (UTC) FILETIME=[19CE5830:01C9F597] X-Cray-VirusStatus: clean Sender: owner-sc22wg5@open-std.org Precedence: bulk N.M. Maclaren wrote: > > It is the problem of putting SYNC MEMORY there that makes me feel that > this can't be done - as I have said many times, users WILL use C code, > POSIX and I/O for synchronisation, in conjunction with that. And those > bring in all of the problems being referred to. We have provided enough capabilities that the use of C code, POSIX, and I/O synchronization should no longer be necessary. This seems like an excellent topic for a section of a textbook on Fortran 2008. Also, I'm convinced that users who can get by with just >> SYNC ALL and SYNC IMAGES will never venture into the low-level stuff. >> Why would they? > > With all respect, Bill, I have some doubts that your experience is > representative. I searched Cray's documentation, and that use of > VOLATILE was not documented until December 2008! See, for example: > > http://docs.cray.com/books/S-3901-60 > http://docs.cray.com/books/S-3901-70 > > Any experience before 2009 must necessarily have been in-house and > selected users of pre-release software only - and I would expect the > vast majority of those people to be classifiable as 'experts'. We completely revamped our documentation with the 6.0 release (the S-3901-60 manual) which we release in September, 2007. The older manuals might be no longer online. However, I can assure you that we (like many other vendors) have supported VOLATILE for a very long time, and coarrays in compilers released to customers since 1998. What you claim "must necessarily have been" is not correct. > > Secondly, there is essentially no experience with coarrays outside Cray, > so you can have little to no experience with code written for Cray > coarrays being ported to other implementations. This is valid observation. It is often the case that new features in the language have limited prior implementation experience. So far we've implemented coarrays on four different network interconnects (excluding the never-released SGI Origin version), are mostly done with a fifth due for release next year, and I'm mostly focused on a 6th that's in design stage. No disasters so far. And, as I said above, > THAT is when most experts will realise that there 'working' code was > actually buggy, but the bug had not previously shown up. Or that the new implementation is buggy, which is not that uncommon with new implementations of any non-trivial feature. The initial f90 implementations were not optimal either. But vendors eventually got the kinks out and I think the overall result has been success. I expect a similar trajectory for coarrays. Andy seems to be off to a good start with g95, which is very encouraging. >> But their work was outside Fortran - before coarrays there were no >> Fortran facilities at all. LOCK was added precisely because there were >> situations where the previous set of tools was inadequate. > > That attitude is appallingly reminiscent of the way that the 1970s and > 1980s 'computer scientists' said that none of the previous mainframe, > Fortran, Algol, Cobol and other experience was relevant. And so we > ended up with C-like languages, Unix and Windows 3. Thanks for the warning about "computer scientists". :) We still have Fortran and Cobol. I think C was a big improvement over assembly language, which it was intended to replace. It also had a brilliant marketing strategy - provide free compilers to students. (The Java crowd was smart enough to realize this, with similar results.) So far, I've been mostly successful in avoiding Windows. I started on mainframes and later migrated to Unix. I would never want to go back. The same era also gave rise to VMS, which was (in my opinion) even better. Some of the VMS ideas are still being migrated into Unix-based systems. Unfortunately, DEC management thought that the elegance of their software was so compelling that the relatively weak performance of the VAX processors did not matter. That turned out to be commercially fatal, and a lesson imprinted on other vendors since. > > Fortran, of all languages, should not make that mistake, especially > not through intellectual arrogance. > Agreed. Especially the lesson that performance is what sells. If Fortran did not offer better performance compared to more fashionable languages, its survival would be seriously endangered. Fortran 2003 has been roundly criticized for a swing too far in the direction of abstraction and theory. We need to keep up with "modern practices" to some extent, but cannot ignore the basis for continued acceptance. 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