(j3.2006) Liaison to IFIP WG 2.5

Wed Aug 22 14:54:43 EDT 2007

You appear to be angry about parameterised data types and yes I will accept significant
responsibility for their original design. However, I consider them of an entirely different
character to co-arrays. PDTs provide a consistency between derived and intrinsic types that was
lacking. Without PDT there are a whole class of applications that simply cannot be programmed. I
would claim that there is no, absolutely null, nil, applications that can be programmed with
co-arrays that cannot be programmed more succinctly without them. That makes co-arrays very
different conceptually and practically.

I am NOT attacking co-arrays as such. On the contrary I think they are probably the best way I have
yet seen of expressing explicit parallelism. That is just the point! They are merely the best yet
devised for a particular architecture and are explicit parallelism. Much of the thrust of F90 was to
distance the language from a detailed specification of how a problem was to be mapped onto a
particular computer model towards a language which would tightly specify the problem to be solved
and to leave the efficient mapping of this onto the machine in the hands of the implementer. WE were
constrained in this by having to carry about with us all of the baggage of F66/77 where a single
processor, linear memory model of a computer was heavily embedded (not as heavily fortunately as it
is in C and this is to some extent why Fortran is still a much better language for parallel
processor optimisation). Co-arrays are a step back in the other direction. They appear to be
embedding a different albeit particular parallel architecture into language constructs that in any
other context merely complicate the expression of problem solution; co-arrays are a "go-faster
stripe". In the future stripes might be found to be no help. I do not want to be stuck with them if
that happens.

Alex is correct, I am not deeply involved any more with the technical details so my objections are
mainly procedural and philosophical. They are not therefore, any less valid or real. I restate for
the umpteenth time, I support co-arrays as a standard that is optional in that any vendor based on a
processor that can benefit from co-arrays should implement them as per the standard but a vendor who
is not likely to benefit from them should not have to add them to his implementation of Fortran.
To the user they are a significant complication. If they are in the core language they will have to
be taught and will make the language more difficult. As an option they need only be a user burden on
processors  and for applications that can benefit.

I remain opposed to co-arrays in the core and in favour of them as a part-n standard.

--
Lawrie Schonfelder
Wirral, UK

> -----Original Message-----
> From: j3-bounces at j3-fortran.org [mailto:j3-bounces at j3-fortran.org]On
> Behalf Of Aleksandar Donev
> Sent: 22 August 2007 18:13
> To: j3 at j3-fortran.org
> Subject: Re: (j3.2006) Liaison to IFIP WG 2.5
>
>
> On Wednesday 22 August 2007 02:30, David Muxworthy wrote:
>
> > I support Lawrie's viewpoint of half an hour ago - vendors and users
> > for whom parallelism is irrelevant should not be forced to accommodate
> > it, whatever the hardware they are using.
> It is a complete and utter fallacy that we are forcing anyone to be aware of
> co-arrays or parallelism. Processors have complete freedom to set the number
> of images to one once and for all and simply parse co-arrays but not do
> anything special about them. This was BY DESIGN---we tried hard to leave
> serial Fortran unchanged.
>
> If in fact you and Lawrie can come up with a *technical* argument showing that
> we have inflicted something other than mere parsing of square brackets to
> anyone, or even worse, changed the meaning or implementation of Fortran not
> using co-arrays, then yes, bring it along. It might have been an oversight.
> If it really is some fundamental flaw in the design of CAF, we will
> reconsider it and maybe even not add co-arrays. Stop waving your hands, it
> does no one any good.
>
> I get Lawrie's point that CAF might not be the best option for some code on a
> dual processor. The answer is very simple. If the code was written such that
> it runs with NUM_IMAGES=1, and all existing codes are, simply compile it with
> a switch that says: compile serially please and do your implicit paralellism
> optimizations. CAF will do nothing to harm or hurt your code. If you can
> demonstrate otherwise, please do with a technical argument.
>
> We have NOT forced explicit parallelism on anyone. We have *offered* it as an
> option to those that need it, in a syntactically and semantically tight form
> that can be compiled efficiently. It is our offer to programmers, a service!
>
> On Wednesday 22 August 2007 01:54, Lawrie Schonfelder wrote:
> > 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.)
> Correct. But exisiting Fortran, with implicit or any other parallelism, is
> also only suitable for homogeneous machines. If you think otherwise, find me
> a portable Fortran code (using MPI, threads, OpenMP, whatever) that runs on a
> truly heterogeneous machine. I don't give a damn about 50 years from now...by
> then hopefully computers will program themselves!
>
> > most likely positively harmful in attempting to exploit
> > heterogeneous parallelism.
> Wrong. They are neither harmful nor helpful in dealing with heterogeneity. A
> compiler may be able to mask the heterogeneity successfully. Once we actually
> have some experience with such machines we will add features to deal with
> them.
>
> Again, be specific. Give an example of a heterogeneous machine. Show me how
> adding co-arrays to the language *hurts* the programmer. Note that "hurt" is
> not the same as "not help".
>
> > Nevertheless, by including CAF in the core
> > language standard every implementor must include them and every user must
> > be aware of them.
> Wrong, wrong, wrong. You don't have to learn CAF at all and can still program
> in Fortran, just like you did not have to learn parameterized derived types
> to write Fortran 2003 programs.
>
> > Processors must implement them even if they are
> > superfluous or harmful.
> And the implementation may consist of mere parsing front-end massaging.
> Trivial to do. Much less than your parameterized derived types, thank you
> very much. Or maybe you don't count delaying F2003 implementations by couple
> of years and putting some vendors out of the business as harm...
>
> > No application that can be written to exploit parallelism via co-arrays
> > could not be written more simply without co-arrays.
> Ugh?!? How? Please be specific. This claim is absurd.
>
> > On appropriate hardware
> > the use of CAF might make the solution run faster.
> Yes, but by faster do you mean N times faster, where N is the number of
> processors/cores/whatever, or do you mean 50% faster. This is the essential
> point. Explicit parallelism gets you the factor of N (or N/logN or whatever
> it is for the algorithm in question)...which is not something you can shrug
> off as a mere optimization. It is fundamental.
>
> > For all these reasons I believe CAF should be standardised via an optional
> > part-n standard.
> Sure, the optional one should be a separate US standard that everyone follows
> and the rest a UK standard that no-one follows. If we could impose
> parameterized types on every vendor, we can impose parsing CAF syntax too. It
> really is not the end of the world, no matter what some vendor may claim.
>
> > The other thing that concerned me before and during the
> > meeting is the continuing level of technical dispute that exists over
> > co-arrays.
> Was any other major feature different. Did people unanimously agree to all the
> stuff added in Fortran 90 and 2003???
>
> > CAF generates the largest number of unresolved technical issues
> Yes, it is the major feature of the revision. There is nothing suprising about
> this fact. If it were trivial to add to Fortran we wouldn't have a whole
> committee working on it!
>
> Best,
> Aleks
>
> --
> Aleksandar Donev, Ph.D.
> Lawrence Postdoctoral Fellow @ LLNL
> High Performance Computational Materials Science and Chemistry
> E-mail: donev1 at llnl.gov
> Phone: (925) 424-6816  Fax: (925) 423-0785
> Address: P.O.Box 808, L-367, Livermore, CA 94551-9900
> Web: http://cherrypit.princeton.edu/donev
> _______________________________________________
> J3 mailing list
> J3 at j3-fortran.org
> http://j3-fortran.org/mailman/listinfo/j3
>