(j3.2006) Liaison to IFIP WG 2.5

Wed Aug 22 09:10:59 EDT 2007

> -----Original Message-----
> From: j3-bounces at j3-fortran.org [mailto:j3-bounces at j3-fortran.org]On
> Behalf Of Dan Nagle
> Sent: 22 August 2007 10:30
> To: Fortran standards email list for J3
> Subject: Re: (j3.2006) Liaison to IFIP WG 2.5
>
>
> Hello,
>
> Lawrie Schonfelder wrote:
>
> <snip>
>
> > Later in the same meeting it became clear that co-arrays were specifically aimed at systems that
> > were based on homogeneous parallelism. (To Alex, this is what I mean by architecturally
> specific.)
> > Looking at co-arrays from my al beit, limited understanding, they would be entirely
> superfluous to
> > anyone wishing to express an application in a
> > serial manner and most likely positively harmful in attempting to exploit heterogeneous
> parallelism.
>
> Wrong.  Language was removed (from a Note!) that hinted that
> one might be expected by the standard to do so.  It is certainly
> possible to do so.  The alternative is MPI or PVM (which might
> become the underpinning of an implementation).

I was not referring to the precise changes to the book that were made as a result of the discussion
but what the discussion indicated about the computing architecture model that was behind the design
of co-arrays. This is became clear was an architecture of a number of entirely homogeneous
processors and a homogeneous interconnect. This happens to be the model applicable to a number of
popular current processors but I would claim is not universal even at present and I will lay odds
will not be universal in the future. So when an alternative, heterogeneous architecture comes along
for which CAF is not the best thing since sliced bread, we will have to add another language feature
to allow it to be exploited effectively. Nevertheless, CAF will still have to be implemented because
it is a non-optional part of the core-language standard.
>
> > Nevertheless, by including CAF in the core language standard every implementer must
> include them and
> > every user must be aware of them. Processors must implement them even if they are superfluous or
> > harmful.
>
> Processors must implement sqrt() even if it is superfluous
> or harmful.  :-)  Seriously, what's the point?

That, if you don't mind me saying so an irrelevant facile point. SQRT is a specific member of a set
of entities. A nearer analogue might be the whole concept of function subprogram/ intrinsic
function. Adding functions to the language was a serious addition and it was done because they were
seen to have general utility. Specific functions might have less general utility but in the case of
SQRT this is one that has a very wide domain of application. There is no architecture that I know of
on which SQRT would be harmful, its implementation is trivial, and if it is not used has next to no
effect on the user or his program. I do not believe the same can be said for co-arrays. If they are
in the core-language everyone must implement them and because they have syntax and semantics that
impact virtually every where in the language virtually every user will have to learn about them even
if they are of no interest or could be positively harmful.

>
> Commodity hardware is parallel.
> Commodity software is parallel.
> Languages which can't easily express parallelism
> will no longer be used and will die a commercial death,
> probably rather quickly.

I could not agree more! It just does not follow that the specific form of parallelism represented by
co-arrays has to be a non-optional feature of every Fortran processor or program. Where the
architecture of the processor is appropriate and the application suitable standardised co-arrays
would be useful. An optional standard should exist. BUT <big but> where they are superfluous or
positively inappropriate they should not be mandated.

If you could convince me, and others, that co-arrays will always be useful in expressing parallelism
regardless of machine architecture then I might be convinced that they should be non-optional and in
the core part-1 standard. Following the last meeting I am even more convinced that they are not
architecture neutral and hence I believe should be standardised by an optional part-n standard.
>
> > No application that can be written to exploit parallelism via co-arrays could not be
> written more
> > simply without co-arrays.
>
> But co-arrays are so simple, it wouldn't be _much_ simpler.
>
> > (This is what I mean about not having general problem solving support.) On
> > appropriate hardware the use of CAF might make the solution run faster. On different
> hardware CAF
> > may well make it run slower.
>
> Slower than what?  Slower than MPI or PVM?
Are you confident that an implementation on a uni-processor or even a dual that is forced to
implement co-arrays will be better optimised than one that decided not to add this complication. I
have no such faith. On the contrary, I think it likely that an implementation that sees little
benefit in Co-arrays in its context would be more like to put resources saved by not having to do
them into improved optimisation, including some implicit parallisation on a dual core. My contention
is that where Co-arrays are superfluous or where they do not map comfortably onto the architecture,
their implementation will result in code that uses them being likely less efficient than code that
does not.
>
> > For all these reasons I believe CAF should be standardised via an optional part-n standard.
> > The other thing that concerned me before and during the meeting is the continuing level
> of technical
> > dispute that exists over co-arrays. CAF generates the largest number of unresolved
> technical issues
> > and most of these result in multiple attempts at resolution, being sent back to
> subgroup repeatedly.
> > This does not suggest to an interested observer that a technically robust consensus has been
> > reached.
> > Standardise Co-arrays please but as a part-n standard and do not inflict it on core
> Fortran for ever
> > or the next 50 years.
>
> 50 years *after* commodity hardware is parallel?
> Fortran will either be a full-blown parallel language,
> or Fortran will have been dead for 50 years.
>
> I'd like to thank Lawrie for his support of co-arrays
> as an integral part of the standard.  If the best
> the critics can do is based on misunderstanding ...

Why do you constantly misunderstand my position. Standardise co-arrays now as an optional part. If
it is subsequently demonstrated that on all parallel architectures the option is adopted and is seen
as useful then by all means mandate it for all implementations. But the history of parallel
computing is now littered with the debris of language proposals that were going to solve the
programming problem. In a part standard co-arrays could be quietly lost if it proved to be yet
another. As a part of core part-1 Fortran it will take 50 years to eternity to get it out, look how
long it is taking to get rid of bad ideas from F66.
>
> <snip>
>
> --
>
> Dan Nagle
> Purple Sage Computing Solutions, Inc.
> _______________________________________________
> J3 mailing list
> J3 at j3-fortran.org
> http://j3-fortran.org/mailman/listinfo/j3
>