[comp.lang.fortran] Fortran standardization process

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.