(j3.2006) (SC22WG5.3611) Preparing for the Tokyo meeting

[Van Snyder]

On Mon, 2008-11-03 at 19:24 +0000, Lawrie Schonfelder wrote:

> On a uni-processor vonNeuman machine they are manifestly useless.

They are also manifestly useless on an IBM 407, or even 704.

>  They merely make it more difficult to comprehend the linguistic
> facilities available for the expression of the algorithm that could
> solve the problem in question. There is NO PROBLEM that is more easily
> expressed because of the availability of co-arrays.

One might have been tempted to make the same argument concerning COMPLEX
in 1958, or modules or pointers or structures or arrays in 1988.

> Co-arrays are a "go-faster stripe" that may improve the speed of
> programs on particular multiprocessor architectures....

For me, coarrays are not a "go-faster stripe," if by that you mean that
I should expect my program to go faster with coarrays than with PVM or
MPI.  Coarrays are a programming abstraction that is far clearer than
PVM or MPI or anything else I've used.

Parallel programming is a necessary abomination -- at least it is for
us: we use over 5000 3.6 GHz Pentium hours per day for analysis of data
from our instrument, and the next one will return 400 times as much
data.

The more we relieve the intellectual load of it, the more likely we are
to have reliable programs at reasonable cost.  Computers keep going
faster and faster, but I am starting to go slower and slower.  I need
the help; my computer doesn't.  Coarrays will help me.  Even if they
hurt my computer a little bit, I'll get a shiny new one next year that
will make up for it.

Coarrays are almost certainly not the end point of this evolution, but
they are a giant step forward compared to what we have today.

> I will accept a lack of detailed direct experience but I would be very
> surprised if co-arrays were anything but useless on an architecture
> that was a tree-structure of multi-level separate memory
> processors,...
>  
> Co-arrays are an interesting and probably effective way of supporting
> "go-faster" programming on a popular but by no means universal set of
> system architectures. 

I would expect a program that uses coarrays to work across a broad
spectrum of different interconnection architectures.  I might have to
tune it to get improved performance for the particular machine I have at
hand at some particular time, but it ought to work.

> Fortran at its base core level is a language to provide the conceptual
> framework for the convenient expression of algorithms applicable to
> any and all architectures. An addition that is useful in an
> architecture restricted sub environment is possibly important but as
> an additional optional element not as a part of the core language
> definition.

One might have been tempted to make the same argument concerning COMPLEX
in 1958, or modules or pointers or structures or arrays in 1988.

Backus was right to recognize the importance of the potential of Fortran
to reduce labor costs, even at a time when labor was far cheaper than
machine cycles.  What appears not to have occurred to him until much
later was portability.  Portability requires a standard.  If one uses
optional things, one should anticipate that portability is compromised.
The way to get around this is to use procedure libraries, which brings
us back to PVM and MPI.  "Using MPI" by Gropp et al is 306 pages, or
roughly half the size of the Fortran standard.  "Using MPI-2" is 406
pages.  I doubt that even the most verbose textbook on "Using coarrays"
will need that many words.  I think it was Churchill who observed that
somebody had the remarkable ability to fit the largest number of words
into the smallest number of ideas.  Let's not require Fortran
programmers to develop the same skill.


-- 
Van Snyder                    |  What fraction of Americans believe 
Van.Snyder at jpl.nasa.gov       |  Wrestling is real and NASA is fake?
Any alleged opinions are my own and have not been approved or
disapproved by JPL, CalTech, NASA, the President, or anybody else.