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

[Dan Nagle]

Hello,

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

Uniprocessors are a set of zero (or, at least, less than epsilon)  
measure.
One wonders when Lawrie last purchased a workstation.

> 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.

Perhaps Lawrie could provide a link to a seller of uniprocessors,
together with an estimate of the seller's current market share.

> Co-arrays are a "go-faster stripe" that may improve the speed of  
> programs on particular multiprocessor architectures. I can believe  
> that on multiprocessor shared memory machines this could be true. I  
> am prepared to accept that on homogeneous clusters of distributed  
> memory systems they might be effective. I find it hard to see how  
> they can guarantee improved performance on heterogeneous distributed  
> memory clusters, and I strongly suspect that there would be a  
> significant likelihood of degraded efficiency.

Perhaps Lawrie can provide a link to software,
or to a programming paradigm, that is guaranteed to work well
on heterogeneous parallel processors.  And just how would coarrays
degrade performance?  "Degraded", compared to what other software
that is _guaranteed_ to work efficiently?  What software is that?

> 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, such as I recall being constructed using  
> transputer chips in the 1990s; useless as general purpose machines  
> but for specific problems where the problem and the interconnection  
> matched, the solution performance improvement was considerable.

Perhaps Lawrie can provide a link to a credible vendor where such
an architecture is available for sale today for general purpose use,
or to a credible vendor who promises to have such computers available
for sale in the not-too-distant future for general purpose use,
where coarrays will not work well.

What portion of Fortran's market should we estimate will be consumed
by these heterogeneous systems with irregular networks?
And in the meantime, what excuse have we got for not supporting
the vast majority of Fortran programmers who need to program
today's commodity computers?

> 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.

OK, by some ranting definition, 99.44% isn't "universal", but so what?
Coarrays are, however, of interest to anyone with a recently purchased
commercially-available, commodity computer.

> 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.

Absolutely nothing ever has been, is now, or ever will be, applicable
to "any and all" architectures.  This kind of argument is so utterly  
fantastic
as to be of no use whatever.  Shall we forget the multitude who must use
commercially available hardware today just because some special  
purpose hardware
is used ... um, well, for special purposes?  You don't suppose, dare I  
write it,
that special purpose software is used on this special purpose hardware
for this special purpose computation?

> If this is a rant, then I will continue implacably to rant. And for  
> this I will not apologise, I RANT.

And by all means continue implacably to rant.  If this is the best
the anti-coarrays side can conjure after all their brooding, then
coarrays are without any serious defect whatsoever.

-- 
Cheers!

Dan Nagle