🚀 go-pugleaf

In article <l9p02vINNorv@almaak.usc.edu> ajayshah@almaak.usc.edu (Ajay Shah) writes:
>In the Great Lwars, one point which commonly comes up is that fortran
>is conceptually lowbrow and hence well-suited for the generation of
>good code, esp. to exploit various parallel architectures.
>
>  [some stuff deleted]
>
>Parallel hardware is obviously a way to get revolutionary gains in
>compute power, but Bill Joy's law suggests that single CPUs will give
>tremendous gains without paying any software irritations (they
>certainly have done great in the last five years).
>
>If this is indeed the case; that most people use workstation-type
>computers, then the argument changes quite a bit.  There may be room
>for a language with simple semantics like fortran, but only for those
>5% of users who want to use parallel hardware.  I suspect most
>scientific computation out there does not know or care about parallel
>hardware.
>

Let me make two comments.  One is overall agreement with your statement
as regards the likely users of massively parallel supercomputers.
The general comment about supercomputing is that 10% of the computing
community uses 90% of the supercomputing power.  I think that is probably
a correct statement, it certainly is within the DoD and DoE laboratories
I have been affiliated with over the years.  The projections for the use
of high performance massively parallel supercomputers preserve that 
user mixture, meaning that only a small minority of people doing
scientific computing will use highly parallel computers.  The outlook
for small parallelism is quite different however.  Consider the
Sparc 10, a workstation by any measure.  It has 4 CPU's in it and is
meant to exploit parallelism on a small scale.  Just as there has not
been a single CPU supercomputer built in years, I stronly suspect that
there will be fewer and fewer single processor workstations in the future.
It is less clear whether the multiprocessors in your workstation will be
something only the operating system will know about or whether they will
be available to the user.  An side comment is that most workstations sit
idle most of the time, which has generated considerable interest in
distributing parallel computing where you use network linked workstations
as the computing nodes.  

My second comment takes issue with your characterization of Fortran as
the language of choice for parallel computing.  Let us assume you meant
Fortran 90, since there is nothing about Fortran 77 that would make it
particularly good for this purpose (the same being true of C and other
procedural languages out there).  Fortran 90 does have array syntax,
which makes data parallelism easier to perform.  However, the trend is
away from data parallelism and toward control parallelism (though many
would argue this.  However, even the guru's of data parallelism, 
Thinking Machines Corporation, are now producing a system which is
at least partly MIMD).  I guess I don't see anything about Fortran 90
which makes control parallelism any easier.  I would argue in fact
that none of the current generation of procedural languages address
parallelism at all well.  Some of the OOPS concepts make it easier,
but only in allowing one to hide the machine architecture from the user.
Certainly they do little to enhance efficiency and the usual reason you
run on a supercomputer is because you are sweating bricks about
speed (otherwise, why not use a workstation).  Functional languages
actually strike me as the ones currently best suited to expressing
parallelism (data or control).  

Having said all that, there is hardly a bit of difference in the
functionality of Fortran 90 and any of the other procedural languages.
Fortran 90 has structures, pointers, recursion, all the things that
people have been trashing on it for not having all these years.  So
I am not sure I see where you are going with your comment, since there
is little about it that I would call "conceptually lowbrow".  That
it is not an OOPS language or a functional language hardly makes it
conceptually lowbrow.  In addition, each of these concepts, OOPS,
procedural, and functional, have their pros and cons.  If you want
to compete in the 90's world of computing, you are going to have to
use a variety of languages, exploting the strength of each when the
problem demands it.

I would make a final comment about Fortran also.  There are now at
least two variants of Fortran 90 being developed which are attempting
to address the issue of parallelism.  One is Fortran D by Ken Kennedy
and company, the other is High Performance Fortran.  I don't think I
would call either of these "lowbrow" languages.

John
-- 
Dr. John K. Prentice                      
Partner, Quetzal Computational Associates    
3200 Carlisle N.E., Albuquerque, NM   87110-1664; 505-889-4543
john@aquarius.unm.edu -or- jkprent@cs.sandia.gov -or- prentice@rufous.cs.unm.edu