To Bill Long

Sorry, I am nearly unexperienced in programming with CAF...

I never programmed using CoArray Fortran !

Nevertheless I dare to make the following remarks
and considerations:

1) From a "philosophic" point of view I am for CAF
because I think that the parallel calculation is the
future of the scientific calculation and that the
parallel calculation must can be managed by Fortran
instructions and not by directives.
Now the little multiprocessor systems are spreading
and a big code intended for big computers can begin its
development life in a little parallel computer.
So, the CoArray had to be available in Windows too. It is true ?

2) The CoArray are a development of the vectorial notation. Then they
are based on Fortran tradition and on scientific calculation
where Cray computers  played ... and play a leading role.
If I have rightly understood, with easy words and strongly simplifying,
one has to add one dimension more, turning the scalars in vectors, the
vectors in matrices etc.
Then, for example:

a,bbb,cc  ==> a[nt],bbb[nt],cc[nt]
vx(j)     ==> vx(j)[nt]
ar(j,k)   ==> ar(j,k)[nt]

A special symbology is used to mean the parallel indices but, substantially,
it is almost to write: a(nt),bbb(nt),cc(nt),vx(j,nt),
ar(j,k,nt).

In these expressions the variable nt can be simply interpreted,
from threads point of view, as the threads identifying number.

3) Roughly speaking, the operative and conceptual differences
between CoArray and threads programming based on a
utility_object is the following.
In the CoArrays the OOP concepts are ignored and the belonging
to the same domain (that is the computer memory
that the thread can freely modify without syncronization)
of all the variables to be used in the same thread
is not pointed out.
Using the example variables, the OOP (that is thread )
programming involves the following transformation:

a,bbb,cc  ==> obj(nt)%a,obj(nt)%bbb,obj(nt)%cc
vx(j)     ==> obj(nt)%vx(j)
ar(j,k)   ==> obj(nt)%ar(j,k)

This transformation is possible because I defined


type :: utility_obj
   real:: a,bbb,cc
   real,dimension(1000)::vx
   real,dimension(200,200)::ar
end type utility_obj

type(utility_obj),dimension(maxthr):: obj

Than, between Co_Array and thread programming there are many analogies
but the Co_Arrays follow the vector programming tradition whereas
the threads follow the object programming tradition and are more
homogeneous with the not_scientific programmers programming style.

My insisting on asking an ASSOCIATE(* =>obj%*) instruction arise from the
uselessness of remembering in each instruction that the variables used
belong to a particular type of data used from a particular thread.

Each formula becomes uselessly complicate...

By the way, even the vector notation is criticizable (in my opinion)
because, when dimension and strides of each vector used must be specified,
the programmer is stimulate to write formulas more
complicated than it is necessary.
Than, long life to CoArray but I would like don't emphazise too much the
differences between Fortran and the other languages and I would like to get
an instruction like ASSOCIATE(*=obj%*) allowing to write
clear formulas even when more than only one CPU is used.

Anyway, I remark that the readibility of formulas
even written with CoArray could be enhanced from the ASSOCIATE instruction
and so I hope to find allies in my request for the
ASSOCIATE(*=>...%*) instruction availability
Regards
             G.B.


In 10.49 11/12/00 -0600, hai scritto:
>Giampaolo Bottoni wrote:
>>
>
>>
>> The parallel calculation can be carried out using
>> [a] parallelization directives (and I hope that
>> the new OpenMP specifications coherent with fortran 90 become
>> really standard),
>
>[a] As far as I can tell, OMP is already universal.
>
>> [b] directives for data driving parallelism (HPF),
>
>[b] On the other hand, HPF seems to have died.
>
>[c]
>> libraries for messages exchange (PVM and MPI) and, at the end,
>
>On smaller systems, the use of MPI is almost universal.
>
>> [d] the seldom used, threads.
>
>But you omit two other options that are perhaps better than threads:
>
>[e] SHMEM, the shared memory libraries, which provide much faster
communications
>than MPI.
>
>and
>
>[f] CAF - Co-Array Fortran. This provides the speed of SHMEM, but with
>communications using direct language syntax rather than external calls.  See
>www.co-array.org.
>
>
>If one is to advocate a new direction for Fortran programmers, I would
suggest
>that CAF is a far better scheme than threads. It is much easier for the
>programmer, faster, and integrates well into Fortran as a language.
>
>
>>
>> The scientific programmers very seldom or never
>> use threads but, in my opinion, many advantages can be
>> obtained using threads.
>>
>
>I believe there is one clear advantage of MPI over threads - the interface is
>standardized and portable. The minor performance difference between
threads and
>MPI cannot overcome this huge advantage. This, no doubt, accounts for the
reason
>scientific codes are not written using threads.  If ultra-fast communications
>are needed, you would skip over threads/MPI and use something like the SHMEM
>libraries, or CAF.
>
>Cheers,
>Bill
>
>
>--
>Bill Long                            [log in to unmask]
>Fortran Technical Support            voice: 651-605-9024
>Cray Inc.                            fax:   651-605-9142
>1340 Mendota Heights Rd., Mendota Heights, MN, 55120
>