John Reid wrote:

>Co-array Fortran, formerly known as F--,  is a simple parallel
>extension to Fortran 90/95, based using on a second set of subscripts
>to address arrays that are spread over several processes. A full
>description, with examples, ... may be accessed through
>  http://www.co-array.org/

>If compared with HPF, the most significant difference is that HPF
>is a single-threaded language that relies on the compiler providing
>efficient procedures to operate on distributed arrays. Thus the
>user does not have to worry about synchronization, but there may
>be performance penalties.

Others wrote:

> > HPF- Great for some problems, OK for some, but it's impossible
> > to manage the communications overhead
>
> Add to that, HPF is not very good for irregular problems, for example adaptively
> refined or unstructured grids

Hi all,

I quickly read over Numrtich's and Reid's report on Co-array Fortran and here is a
few of my comments to it, especially in regards to its position to HPF (I use HPF to
do my distributed memory programming and are relatively happy with it, though always
open for suggestions). I may be wrong on some of my comments, so please forgive me.

First of all, about the problems/shortcommings of HPF. It is clear that the original
decision to make HPF programs be compatible with Fortran 90 by hiding the HPF
commands into directives was not the best choice. Also the decision to completely
avoid reference to communication and not allow the programmer to specify when
communication should be generated / extracted out of loops etc. has some drawbacks.
The above are more of syntactic, rather than inherent, problematic nature. I mean,
one can always add communication routines/directives to HPF for a particular
implementation. Most important though the performance of HPF is *very* compiler /
platform / problem dependent. I guess this is what "manage the communications
overhead" means? For example, I can tell you with great accuracy / certainty when
and how my HPF compiler is going to translate a statement that I know will require
communication and can usually rewrite it in a form that will best suit the compiler
(Adaptor) rather easily. The same program might run badly on other compilers though.

But HPF has some great advantages. First, it is a *very* well defined, tested, and
widely implemented language. I mean, a 33 page paper on Co-Array Fortran can not
even begin to compare to all the work done on HPF.  Yes, I am aware that Co-array
Fortran is meant to be the "smallest possible extension to Fortran", but if you
think that it will solve the problems inherent in making a unified approach to
distributed memory computing, I think life may disappoint you (HPF was originally
met with the same enthusiasm, so was / is OpenMP).

Second, and more important, HPF is a very extensible language in two major ways.
First, the boring one, is via the very well defined EXTRINSIC models. Second, it is
very extensible at the compiler level. I use the compiler Adaptor
(http://www.gmd.de/SCAI/lab/adaptor/adaptor_home.html), which has made a lot of
additions / changes to the HPF standard to fit the compiler and the problems its
user work on.
For example, the above statement "HPF is not very good for irregular problems, for
example adaptively refined or unstructured grids" is only partially true in Adaptor
(and HPF 2, HPF+, JAHPF). For example, Adaptor defines a new extension to the HPF
library, the HPF_HALO_LIBRARY, which can be used to solve problems on unstructured
grids (like finite-element methods) very easily and rather efficiently. This library
may as well become a part of HPF in the somewhat distant future. I will post
detailed documentation on how one can use Adaptor to find the connected components
of a randomly diluted 2D and 3D grid on a  Beowulf cluster on my web-page
(http://computation.pa.msu.edu/hpf/) very soon.
Also, people are really working hard on making extensions to HPF to make it suitable
for irregular applications. This process takes a lot of time though and so it's not
really HPF's fault that a decade or so of existence are not enough to make a perfect
language. Extensions to HPF, like the more conservative ones in Adaptor, or more
radical ones in HPF+ and JAHPF, make HPF look more and more complete and versatile
day after day. It really has become a big undertaking!

For example, Adaptor provides a library called the HPF task library which can be
used together with the EXTRINSIC(HPF_LOCAL) or HPH TASKing model to emulate co-array
statements like x(:)=y(:)[q]. Namely, there are communication routines there that
can operate on whole arrays/array section, so that the above statement would be
something like (approximately):
HPF_SEND_RECV(send_data=y,source=q,recv_data=x,dest=HPF_ALL_RECV,...)
I agree that x(:)=y(:)[q] is much nicer and Fortran-spirited though. But look, the
important thing to recognize is that the run-time / library support needed for
actually translating x(:)=y(:)[q] is already implemented in most HPF runtime
libraries (actually, in HPF_TASK_LIBRARY the arrays x and y may reside on several
processors, so the run time support in Adaptor is more sophisticated than that).
It's just the front-end language that becomes more elegant and easier for the
compiler to translate efficiently. In that sense, co-array syntax can be
incoorporated into HPF compilers (though not the standard itself) fairly easily (I
think).

So, although I find the basic ideas behind Co-array syntax very nice and versatile,
I don't think they are sophisticated enough to provide a parallel language of wide
applicability. Can somebody tell me how a general parallel scatter/gather operation
(A(L)=B in HPF, where A and L and B are all distributed on different processors, in
this case Co-arrays) would be implemented in Co-array Fortran? Would this require
that the user writes inspector/executor routines himself (what a job!)?

Anyway, I think some vendor should at least implement an initial Linux F95 (Beowulf
cluster) version of this relatively new invention. I think the research group I work
with would be interested in buying / testing it, so long as licencing is not as
complicated as paying per node / processor and machine (so we can expand / port our
applications).

All the best,
Aleksandar

--
_____________________________________________
Aleksandar Donev
Physics Department
Michigan State University
East Lansing, MI 48824-1116
E-mail: [log in to unmask]
Work phone: (517) 432-6770
_____________________________________________




%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%