(j3.2006) Liaison to IFIP WG 2.5

[Aleksandar Donev]

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