From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Sat Apr 6 00:07:15 2013 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 2D3FD3569A2; Sat, 6 Apr 2013 00:07:15 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by www.open-std.org (Postfix) with ESMTP id 779A23569A2 for ; Sat, 6 Apr 2013 00:07:10 +0200 (CEST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:46424) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:nmm1) id 1UOEms-0005FU-Q8 (Exim 4.72) for sc22wg5@open-std.org (return-path ); Fri, 05 Apr 2013 23:07:10 +0100 Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1UOEms-0004fd-2b (Exim 4.72) for sc22wg5@open-std.org (return-path ); Fri, 05 Apr 2013 23:07:10 +0100 Received: from [87.112.94.53] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.5); 05 Apr 2013 23:07:10 +0100 Date: 05 Apr 2013 23:07:10 +0100 From: "N.M. Maclaren" To: sc22wg5 Subject: Re: [ukfortran] (SC22WG5.4971) (j3.2006) AW: WG5 ballot on first draft TS 18508, Additional Parallel Features in Fortran (Update) Message-ID: In-Reply-To: <20130405211129.3FA88356D36@www.open-std.org> References: <20130329104945.2C28A356BB3@www.open-std.org> <20130329232930.A368A356DC2@www.open-std.org> <20130330091839.AC044356A50@www.open-std.org> <20130405211129.3FA88356D36@www.open-std.org> X-Mailer: Prayer v1.3.5 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: owner-sc22wg5@open-std.org Precedence: bulk On Apr 5 2013, Bill Long wrote: >> >> There is no support in most hardware for most reductions or, indeed, >> most of modern Fortran. We shouldn't be adopting a C/C++ mindset and >> imagining that the primary purpose of a high-level language is to give >> the programmer access to the hardware facilities. Fortran has lasted > >Well, the purpose of C is exactly to give the programmer access to the >hardware facilities. You need that to write device drivers and OS kernels. Not really. That mindset is relatively new. And there is no reason to use C to access such things - it's generally easier to write small assembler primitives than to worry about what the compiler might do. >> over more variations in those than most people can believe! > >Fortran has lasted because it continues to provide a portable means for >compiling (mainly scientific or mathematical) source code into >executable files that perform well on current hardware. The key is that >Fortran has evolved with the hardware changes to keep relevant. Eh? I can't think of many cases where Fortran evolution has been for the support of new hardware, except for the IEEE 754 stuff. Also, in my view and that of many other people, Fortran has lasted precisely because of the remarkably good machine-independence and optimisability of the language. > When >some hardware-specific operation vanishes (think arithmetic IF) for long >enough, we (at least sometimes) relegate the corresponding Fortran >construct to the deleted heap. That's a bit contorted. There hasn't been hardware support for that since the 1950s, as I understand it. >Users will continue to want the high performance that keeps >Fortran relevant, and if the hardware changes, vendors will be pressed >to add language features that can be translated to use that new >capability. If these are not standardized as language features, we >loose portability, which is one of the main goals. That is making a 1960s-era mistake. The route to performance is NOT via more hardware-specific coding, but by giving compilers more opportunity to optimise. >To some extent, we >need to anticipate future hardware trends (usually not that hard to do), >because the time lag between a feature proposal and widespread >availability in a compiler is years. Well, yes, but low-level features are transient over such a timescale, so there is very little point in trying to track them. On WG5, almost all of us remember vector supercomputers, but probably only you and the people in Japan still have access to them :-) Similarly FPS systems on IBM PCs, which were rather similar to modern GPUs. Or the ICL DAP. The point is that Fortran can be compiled into reasonably good code for all of them. It was the first language for which autoparallelisation was commercially available (IBM and Alliant). And so on. we really don't want to lose that. Regards, Nick Maclaren.