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

[Lawrie Schonfelder]

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/377f609f/attachment.html