From owner-sc22wg5@open-std.org Thu Aug 2 13:50:15 2007 Return-Path: X-Original-To: sc22wg5-dom6 Delivered-To: sc22wg5-dom6@open-std.org Received: by open-std.org (Postfix, from userid 521) id 57165D7D9B; Thu, 2 Aug 2007 13:50:15 +0200 (CET DST) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from balin.rl.ac.uk (balin.rl.ac.uk [130.246.135.155]) by open-std.org (Postfix) with ESMTP id 8837455CE for ; Thu, 2 Aug 2007 13:49:44 +0200 (CET DST) X-RAL-MFrom: X-RAL-Connect: Received: from jkr.cse.rl.ac.uk (jkr.cse.rl.ac.uk [130.246.9.202]) by balin.rl.ac.uk (8.12.8/8.12.8) with ESMTP id l72BnaTT010644; Thu, 2 Aug 2007 12:49:36 +0100 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by jkr.cse.rl.ac.uk (8.12.10/8.12.8) with ESMTP id l72BnawF031837; Thu, 2 Aug 2007 12:49:36 +0100 Message-ID: <46B1C4CF.3000709@rl.ac.uk> Date: Thu, 02 Aug 2007 12:49:35 +0100 From: John Reid Reply-To: j.k.reid@rl.ac.uk Organization: Rutherford Appleton Laboratory User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060209 Fedora/1.7.12-1.1.2.legacy X-Accept-Language: en-us, en MIME-Version: 1.0 To: WG5 Subject: WG5 Documents for London meeting References: <46A8B935.9050104@rl.ac.uk> In-Reply-To: <46A8B935.9050104@rl.ac.uk> Content-Type: multipart/mixed; boundary="------------060307030106060401080706" X-Scanned-By: MIMEDefang 2.39 Sender: owner-sc22wg5@open-std.org Precedence: bulk This is a multi-part message in MIME format. --------------060307030106060401080706 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Dear WG5, I have just put these new papers on the server: N1684 US National Activity Report (Snyder) N1686 SC22 Other Working Group - Vulnerabilities - Liaison Report (Nagle) N1687 ISO 31-11 special functions (Nagle) N1688 Special mathematical functions in Fortran (Snyder) N1689 Letter to the Convener re co-arrays (Wallin) All are visible using hot links on the WG5 home page. You have already seen N1684 as an email message. The three new text files are attached. N1687 and N1688 concern a new topic and have come very late. I will not rule it out from the chair, but it definitely has low priority. We have significant differences on the content and timing of the main standard to resolve. We should be working on F2003 interpretations. N1689 was sent to me yesterday as a private email. It has been written with care by a newcomer to the Fortran standardization process who cannot get to London. I thought it deserved to be read by you all. Best wishes, John. --------------060307030106060401080706 Content-Type: text/plain; name="N1689.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="N1689.txt" ISO/IEC JTC1/SC22/WG5-N1689 Letter to the Convener from John Wallin Hi John, I just got a read of the British Standards Institution response to the Fortran 08 draft. I am probably preaching to the choir, but here are a few comments. I am very disturbed to see the suggestions about slipping the schedule two years and/or dropping major features in the language. In particular, I am concerned about dropping co-arrays. (I am not doing to talk about the macros or BITS features.) Although this is a new feature, it is coming at a critical time for the language. With Intel creating 80-core chips scheduled for release in the next five years, we need a way to take advantage of this new computing power. Adding on to this, the speed of network connections between boxes is making the walls between CPUs less problematic. In five years, it would be surprising if many machines don't have two to four CPU chips, each with a few dozen (or more cores). The target for our audience will probably be higher end versions of the machines for scientific use - with perhaps several boxes tied together as well. The machines will probably be non-homogeneous and hierarchical, particularly in terms of memory access times. As a data point, it is useful to note that my mid-end current home machine has 96 floating point pipelines in its graphics card and a dual core CPU. I believe it is critical to realize that parallel computing is here now for commodity PCs, and this isn't some concept that is going to happen in the distant future. These hardware changes are going to affect users at the desktop level tremendously, as programmers struggle to optimize their codes for this new hardware. I think the biggest mistake in the document is that "co-arrays would be relevant to only a minority of users." I don't believe this will be true in five or ten years for anyone who wants to get the performance out of their machine they need to solve scientific problems, especially given the current trends in hardware evolution. Right now, as you know, the options for doing parallel computing are fairly limited. You can use HPF extensions, but it limits the types of codes that you can program. The same is true with OpenMP. For many complex problems, MPI is the only workable option especially if you are crossing over a network to access remote data. MPI is a very flexible, general, and yet horrific way to do work on complex parallel code. It is very difficult to write and debug code using MPI, and the book keeping aspects tend to dominate the code. I teach a course in high performance/parallel computing. Seeing how students respond to MPI and the other paradigms out there (threads, sockets, openMP, etc), I believe there is a huge need to have a language that can express parallel concepts easily. Co-arrays fit very nicely into what people need to do. It isn't perfectly intuitive, but it is infinitely better than most of the other options around AND it fits the array model of Fortran perfectly. It is also clear that the demand for this type of paradigm is going to grow greatly over the next few years as hardware changes. We haven't barely begun to address these issues in the Computational/Computer Science curriculum, but I suspect industry is going to start demanding our students know how to take advantage of the hardware that is coming. Having something we can teach them that is straightforward would greatly help make this possible. I also should note that the argument that we need more experience with Fortran 03 doesn't quite make sense to me. Co-arrays really only address issues that were in the 95 draft and are largely independent of the revisions to 03. Yes - the feature does add complexity to the language, but it doesn't interfere or interact with 03 in a deep way. In summary, I think the hardware on commodity PCs is going to force us to use parallel programming constructs on any code we want to run efficiently. The current paradigms are not well suited for the task in many types of complex codes. If we don't have constructs available to make this work, the language will be in serious trouble. Fortran 08's co-arrays are critical to taking advantage of the new hardware that is on the way. Well, that's my two cents. I hope all is going well for you and hope to see you at the November meeting. -John Wallin --------------060307030106060401080706 Content-Type: text/plain; name="N1687.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="N1687.txt" ISO/IEC JTC1/SC22/WG5-N1687 ISO 31-11 special functions Dan Nagle, 2007 July 31 The C and C++ committees are in the process of defining an optional binding for many of the special functions defined in ISO 31-11 Part 14. I believe Fortran should similarly have optional bindings defined for them. These bindings are being done via the vehicle of a Type 2 TR, to appear as an optional annex of the respective standards. Very little effort is needed for Fortran to duplicate the C effort, as the C document WG14 N1243 and N1244 provide a complete technical specification (in C of course) and rationale for decisions made. It is only necessary to translate the work into the required Fortran format. As an optional part of the standard, or as an optional clause of the standard, or as an optional annex, the binding may be used by vendors anywhere the C/C++ compilers of the same vendor support the functions. If defined as a module, very little additional effort is required by the vendor. A substantial increase in the portability of Fortran programs may be had with very little additional effort either in the standards definition process or in the implementation. --------------060307030106060401080706 Content-Type: text/plain; name="N1686.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="N1686.txt" ISO/IEC JTC1/SC22/WG5-N1686 SC22 Other Working Group - Vulnerabilities - Liaison Report Dan Nagle, 2007 July 31 OWG-V continues to meet four times per year, and is steadily writing its Type 2 TR. The web site is http://www.aitcnet.org/isai/ OWG-V is charged with writing a document which will provide guidance for those who want to write their own coding standards. The most recent draft is OWG-V N0079. The document is organized with a language-independent portion discussing vulnerabilities in general (for example, array index out-of-bounds) to be followed by language specific portions (for example, in Fortran, use whole array operations) for each (C/C#/Ada/Fortran) language. The next meeting is during September/October of this year. I expect that after the next meeting, the Vulnerabilities list will be well enough developed to start work on the Fortran-specific list. OWG-V was pleased to hear that J3 had added a portability annex to our committee draft. While substantial parts of OWG-V's work are devoted to safety and security issues, reliability issues from the perspective of programmers coding applications with very long execution times are also being considered. OWG-V intends to establish its own method of operation regarding issues involving sequential execution and integer data only prior to tackling floating point issues and parallel execution issues. The work of OWG-V has benefitted Fortran by focusing attention on issues of confidence in a program's correctness, and the addition of the above-mentioned annex. At some point in the future, perhaps some years from now, it may be worthwhile to visit the issue of whether there are features which might be added to Fortran to good benefit in light of the OWG-V document. --------------060307030106060401080706--