(j3.2006) Liaison to IFIP WG 2.5
Wed Aug 22 13:13:01 EDT 2007
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
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
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!
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
More information about the J3