prentice@triton.unm.edu (John Prentice) (04/29/91)
In article <1266@argosy.UUCP> ian@bear.UUCP (Ian L. Kaplan) writes: > > Fortran 90 is indeed a complex language whose implementation is not >entirely understood. As with any compromise, it can be criticized >from a number of perspectives. However, I do not believe that it is >reasonable to criticize Fortran 90 because it does not support MIMD >parallelism. > My concerns have nothing whatsoever to do with Fortran Extended. I am not criticizing Fortran Extended nor am I advocating any particular language or approach in place of Fortran. In fact, on balance, I think Fortran Extended is a vast improvement over Fortran 77. What I am criticizing is a standards process so slow that it is twenty years between implementations of modernized versions of the language. In an era when hardware developments are producing an order of magnitude increase in performance every few years, my point is that the current process of producing a standard is an anarchism. If Fortran fails to rapidly evolve features which support things like parallelism, it will be rapidly replaced by languages that do, at least amongst scientific users who are pushing the frontiers of computing. The same is true of C or any other language subject to standarization. But C is a language that has a following across a broad segment of the computing community and in particular to segments of the community that are not that heavily involved with or in need of extraordinary floating point performance. There the basic paradigm of computing is not changing rapidly, it is still overwhelmingly based on serial computers. On the other hand, Fortran has a rather narrow following limited mostly to those people who are doing very high performance floating point computing where the paradigm of computing is rapidly evolving from serial to parallel computing. If Fortran fails to provide the software tools needed by that switch, then it will get abondoned by the high performance scientific computing community simply out of necessity. And that will leave the language in a backwater. It will continue to be used by scientists less concerned about state of the art performance for awhile. But eventually even these people will move on to parallel systems as they become more commonplace and hence away from Fortran. The real lifeblood of the Fortran community has been and is today the high performance scientific community. Failure to address the needs of that community will doom this language. The typical response to this question seems to be either to challenge me to suggest an alternative or to criticism my alternatives. That seems to me to be missing the forest for the trees. The point is that lots of very clever people are working very hard to develop language alternatives that do address issues like parallelism (and parallelism is only one of several issues of importance in high performance computing right now. There are needs for language features to implement domain decomposition boundary passing for example in a cleaner and less programmer intensive fashion, etc...). The literature is full of attempts in this direction and progress is being made. Even if there are no clear winners yet, I am quite confident that some of these ideas are going to eventually pay off, and probably sooner rather than later. If Fortran can't rapidly incorporate such ideas, it will become a dinosaur. The current standards process is a recipe for exactly that outcome. One suggestion I would make is to echo something Jim Giles has often said, for perhaps somewhat different but no less valid reasons. We should regularly be issuing new standards which standardize existing or common extensions in vendor implementations. That could easily include extensions to support parallelism as they are developed. To do anything other than this will make the language too slow to react to the rapidly evolving needs of user community. We just plain have to have a language that evolves in at least some systematic way faster than once every couple decades. Besides, right now the whole idea of standards is a bit of a charade. Most vendors have extensions which they have added to address shortcomings in the language. The purpose of standards is supposedly to make it possible to have highly transportable code. But in fact the only machines on which Fortran is highly transportable today are machines which are of little interest to the high performance community. Every supercomputer I know of requires some system specific massaging to get decent performance. I would feel far better served by the regular incorporation of the best of these features into a standard than I do by sitting down and redesigning the language every decade or two. But if, as many will counter, the community can't agree on how to do something like this, then I again will assert that the result will be that users will just bypass the language. The bottom line is that the Fortran community is a great deal more dynamic in its needs right now than other computing communities and much more intimately linked to hardware advances that are necessitating new ways of programming. I would like to see Fortran be able to keep up with it. John -- John K. Prentice john@unmfys.unm.edu (Internet) Dept. of Physics and Astronomy, University of New Mexico, Albuquerque, NM, USA Computational Physics Group, Amparo Corporation, Albuquerque, NM, USA
Patrick F. McGehearty <patrick@convex.COM> (04/29/91)
In article <1991Apr29.034625.25562@ariel.unm.edu> prentice@triton.unm.edu (John Prentice) writes: ... What I am >criticizing is a standards process so slow that it is twenty years >between implementations of modernized versions of the language. In an era >when hardware developments are producing an order of magnitude increase >in performance every few years, my point is that the current >process of producing a standard is an anarchism. If Fortran fails to rapidly >evolve features which support things like parallelism, it will be >rapidly replaced by languages that do, at least amongst scientific >users who are pushing the frontiers of computing. The same is true >of C or any other language subject to standarization. But C is a >language that has a following across a broad segment of the computing >community and in particular to segments of the community that are not >that heavily involved with or in need of extraordinary floating point >performance. There the basic paradigm of computing is not changing >rapidly, it is still overwhelmingly based on serial computers. >On the other hand, Fortran has a rather narrow following limited mostly >to those people who are doing very high performance floating point computing >where the paradigm of computing is rapidly evolving from serial to >parallel computing. If Fortran fails to provide the software tools needed by >that switch, then it will get abondoned by the high performance scientific >computing community simply out of necessity. And that will leave the language >in a backwater. It will continue to be used by scientists less concerned >about state of the art performance for awhile. But eventually even these >people will move on to parallel systems as they become more commonplace and >hence away from Fortran. The real lifeblood of the Fortran community has been >and is today the high performance scientific community. Failure to address >the needs of that community will doom this language. > I agree in general with the ideas expressed above. I am somewhat more optimistic about the prognosis. I make a distinction between formal standardization and usable common practice. Various extensions are common to Fortran, and most serious vendors support them, even though they are not part of the FORTRAN77 standard (DO ... ENDDO is an example). In a similar way, various parallel constructs have been added to different vendors Fortran implementations. For example, Convex uses a "C$DIR ..." syntax for Convex specific extensions. Other vendors use other syntaxes. While these divergent practices inhibit portability in the short term, they allow a body of experience to be developed. Those features which are found to be useful are likely to be included in interim standards, such as that due from the Parallel Computing Forum (PCF). Since these changes are much less extensive than FORTRAN 90, they are likely to be widely available within a couple of years of a standard, instead of decades. Of course, each vendor will have their own timetable, which will be driven in part by their customer requirements. I encourage all those reading this who are interested in high performance computing to get a copy of the PCF interim/draft/(whatever it to be called) standard when it emerges and read it carefully. Please evaluate the standard for your needs. I know that I will. Only ask for features that are meaningful and consistent, otherwise standardization and implementation times will be extended.