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

Mon Nov 3 15:09:54 EST 2008

I thought I would give a quick reply on this.

I think it is certainly true that coarrays are manifestly useless on systems that are uniprocessor vonNeumann machines.   However, you can't buy those any more.   Everything now and in the future is going to be multicore, at least from Intel's point of view.

Second, on systems that have heterogeneous and/or hierarchical, NO language is going to give a magical speedup on all problems.  The issue is going to be writing algorithms in some language that can take advantages of this computing structure that exists.   The problem then becomes how do you express these algorithms, since compilers are not going to make codes run effectively on all machines.  

However, right now, the only option for those types of machines is MPI and message passing.  With coarrays, you will need to define processor teams and set up the algorithm to work on a heterogeneous machine, but the big advantage is that you can do it without all the horrific overhead associated with using MPI.   (I have some good examples of how horrific this can be for the morbidly curious.)   This is a huge advantage as a programmer since it moves this type of algorithm from the ridiculously difficult to the annoyingly difficult.    

The advantage for coarrays on heterogeneous machines is that it makes the complex algorithms easier to express.   I would argue that one of the directions to examine in the future is ways to help programmers decompose problems more easily.   However, this is WAY outside the scope of 08.

The final part of the argument was that Fortran provides a convenient expression of algorithms that are applicable to any architecture.   This is only partially true.   All of us have tuned our codes to run more efficiently on vector machines.   Of course, compilers have gotten better at vectorizing code, but code tuning for specific platforms in parallel computing does go on all the time.  For me, at least, this means we should provide programmers with some tools to make this easier rather than ignoring the problem.

Of course, any Fortran program will certainly run on any platform.   In fact, this is the reason why coarrays need to be included in part 1.  However, it is not true that it will run at the same efficiency on all platforms.   That detail is still left to the programmer since compilers really can't figure this out and architectures are rapidly changing. 
-------------- next part --------------
I will endeavour to refrain from rant!

The principle that motivates my implacable belief that co-arrays (as would
an addition of MPI, or what have you) should not be core language but an
optional additional part, is that they are not architecture neutral.

On a uni-processor vonNeuman machine they are manifestly useless. 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.

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.

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.

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.

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.

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

--
Lawrie Schonfelder
Wirral, UK

  -----Original Message-----
  From: j3-bounces at j3-fortran.org [mailto:j3-bounces at j3-fortran.org]On
Behalf Of Jim Xia
  Sent: 31 October 2008 21:32
  To: fortran standards email list for J3
  Subject: Re: (j3.2006) (SC22WG5.3611) Preparing for the Tokyo meeting

  j3-bounces at j3-fortran.org wrote on 10/31/2008 05:07:28 PM:

  > [image removed]
  >
  > Re: (j3.2006) (SC22WG5.3611) Preparing for the Tokyo meeting
  >
  > Lawrie Schonfelder
  >
  > to:
  >
  > fortran standards email list for J3
  >
  > 10/31/2008 05:09 PM
  >
  > Sent by:
  >
  > j3-bounces at j3-fortran.org
  >
  > Please respond to fortran standards email list for J3
  >
  > I will refrain, I hope from ranting!
  >
  > I will nevertheless continue in the firmly held belief that even if
  > co-arrays are "superbly
  > wonderful" for expressing parallelism on a number of popular
  > architectures, they are not universally
  > "the answer to a maiden's prayer" on all architectures. They quite
  > manifestly do not make a "knats
  > testicles" improvement in the ease of expressing <emf>any</emf>
  > algorithm on a uniprocessor system,
  > and I suspect there are a number of other potential architectures on
  > which co-arrays will be less
  > than helpful.

  Would you please share with us on what architectures the coarray will be
less than helpful.  I thought one strength of coarrays is they're
architecture neutral.  My imagination is limited by whatever machine
architectures we're having today but I'm interested in learning its
potential limitations in future, so I'd like to hear your opinion where you
can foresee the coarray feature will fail.

  Thanks,

  Jim Xia

  RL Fortran Compiler Test
  IBM Toronto Lab at 8200 Warden Ave, Markham, On, L6G 1C7
  Phone (905) 413-3444  Tie-line 313-3444
  email: jimxia at ca.ibm.com
  D2/YF7/8200 /MKM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://j3-fortran.org/pipermail/j3/attachments/20081103/ec1908e9/attachment-0001.html 
-------------- next part --------------
_______________________________________________
J3 mailing list
J3 at j3-fortran.org
http://j3-fortran.org/mailman/listinfo/j3