ABSTRACT
The quotation refers to the draft of a new Fortran language standard produced by the X3J3 committee of the American National Standards Institute. Originally the standard was to be released in 1988 and called Fortran-88 (after Fortran-66 and Fortran-77) but factional warfare in the committee repeatedly delayed completion of its work so the language came to be referred to as Fortran-8X, with the X to be filled in when agreement was finally reached. In the end that was 1991, but the language [121] was called Fortran-90 (and no longer spelled like the acronym that it is). Subsequent revisions of the standard have described Fortran-95 and Fortran-2000 (the latter colloquially known as Fortran-03, its standard having been published in November of 2004). Additional “requirements” are being considered for Fortran-08 as I write this, which suggests an ongoing process [164] in which a new version of the language is produced every five years or so. In §0.2 I began referring to Fortran-90 and all of its successors as Modern Fortran, to distinguish them from the Classical Fortran discussed elsewhere in this book. The 8X committee’s modest goals were to introduce array operations, standardize some
common programming practices not anticipated in the Fortran-77 document, and add a few new features such as dynamic memory allocation. The unfortunate product of these good intentions is an enormous hodgepodge in which the charming simplicity of Classical Fortran is hard to recognize. Fortran-90 has 85 statements, compared to 46 in Fortran-77, 32 in the C programming language, and 32 in Classical Fortran (see [76, p7-10] [55, §A] [74, §2.4] and Exercise 0.10.12). Fortran-90 introduces 75 new built-in functions, free-form source code, user-defined data types, operator overloading, pointers, recursion, new ways of specifying subprograms, new ways of declaring the attributes of variables, and numerous smaller features. Fortran has always evolved with the addition of new capabilities, as discussed in §0.2, but never before on such a vast industrial scale! Each subsequent version of Modern Fortran has further enlarged and altered the language. As in the past it will probably turn out that many of the new ideas in Fortran-90 and its successors are bad ideas, that some find only limited application in numerical computing, and that some are easier to use by programming in other languages. To embrace all of the added features it would be prudent to think of Modern Fortran as a completely new (and periodically changing) language that is related to Classical Fortran more and more distantly as time goes by. Just as we considered only a subset of Fortran-77 in earlier chapters, we will here ignore
the most recent developments in Modern Fortran and consider only a small subset of the functionality that was added at the Fortran-90 revision of the standard (for a complete exposition of Fortran-90 see [98] or [76]). Except for a few gotchas, this will allow us to view Fortran-90 as just an extension of Classical Fortran. Several vendors market Modern Fortran compilers, and the free compilers g95 and gfortran also support the features of Fortran-90 discussed here. Although Fortran-90 introduces array operations that cry out for vector or parallel imple-
mentation, the language provides no way for the programmer to specify whether multiple
circuits are to be used or how the calculations are to be assigned to them. To make it possible to request parallel execution, a collaboration of academic, government, and industry researchers wrote a standard [18] in 1994 for High Performance Fortran. HPF consists of Fortran-90 plus compiler directives, a few new statements, and many new built-in functions. HPF directives, like the vectorization directives described in §16.1.5, are special comments added to a serial program. HPF supports data parallel programming, which is a variety of the domain decompo-
sition model described in §16.2.4. Some prominent researchers advocated [136] that the data-parallel approach and HPF be regarded as the standard paradigm and used for all parallel processing, but this view was challenged by others [184] who favored explicit message passing with MPI. Certain problems seem to require functional decomposition and thus apparently do not fit the data parallel model. In a survey [80] of typical applications for which HPF is appropriate, parallelizing with HPF took about half as much development time as parallelizing with MPI but yielded only about half the speedup. In practice implementations of HPF generate calls to message passing routines, so MPI is present even though it is hidden from the programmer. For these reasons and others [75] HPF has not achieved the wide acceptance that its designers expected. However, some parallel programs can be written much more easily with HPF than with MPI, a commercial HPF compiler [30] is available, and the language is used extensively in at least one important research community: the NEC Earth Simulator [113], a large supercomputer used for studying global climate models, is programmed in HPF. The data-parallel programming model on which HPF is based is, like vector processing, a good enough idea that it will probably continue to play a role in high-performance computing even if HPF itself is someday abandoned. To introduce the ideas of data-parallel programming I will give in §17.2 only a brief overview of the version of HPF-1 described in [18].
