Home > Archive > Fortran > February 2008 > Re: Will Co-Array Fortran be considered a valuable tool for next-generation programmi
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: Will Co-Array Fortran be considered a valuable tool for next-generation programmi
|
|
| Ron Shepard 2008-02-22, 10:27 pm |
| In article
<bd6a7a89-53c0-4c57-8344-887336b12b4b@o77g2000hsf.googlegroups.com>,
Tim Stitt <Timothy.Stitt@gmail.com> wrote:
> I was just wondering if anyone had any thoughts on the impact
> Partitioned Global Array Space languages (PGAS) such as Co-Array
> Fortran will have for programming productivity on next-generation
> petascale architectures.
The co-array fortran syntax does simplify many of the
message-passing operations required in parallel codes, but it seems
to be missing much of both the low- and high-level functionality
that is known to be important in writing efficient and general codes.
For example, one problem with co-array fortran is that it does not
allow the programmer to specify nonblocking transfer operations. In
MPI (or other explicit message passing environments), the programer
can initiate a transfer of data between processors, and then go off
and do some useful work while the data is being transferred, query
the transfer operation to determine when it is complete, and then
begin operating on that data when it is available. This
functionality is missing in co-array fortran. Also, in MPI it is
possible to assign subgroups of processors to a particular task.
This is useful when writing library routines meant to be used by a
wide range of application programs. This high-level functionality
also is not included in co-array fortran. It can be added by the
programmer at the application level, but this complicates the
process of writing general library routines intended to be used by
multiple applications.
$.02 -Ron Shepard
| |
| Dan Nagle 2008-02-22, 10:27 pm |
| Hello,
On 2008-02-22 11:58:48 -0500, Ron Shepard
<ron-shepard@NOSPAM.comcast.net> said:
>
> For example, one problem with co-array fortran is that it does not
> allow the programmer to specify nonblocking transfer operations. In
> MPI (or other explicit message passing environments), the programer
> can initiate a transfer of data between processors, and then go off
> and do some useful work while the data is being transferred, query
> the transfer operation to determine when it is complete, and then
> begin operating on that data when it is available. This
> functionality is missing in co-array fortran.
A coarray program certainly can start a transfer long before
the data is needed and go do some other unrelated work.
The images synchronize _only_ at a sync statement.
Depending upon your specific application, various combinations
of sync statements, volatile attributes and flush statements
might be best.
For example,
local_b(:) = remote_b(:)[over_there]
call big_honking_calculation_involving_a( a)
sync memory
! now work with b
> Also, in MPI it is
> possible to assign subgroups of processors to a particular task.
> This is useful when writing library routines meant to be used by a
> wide range of application programs. This high-level functionality
> also is not included in co-array fortran. It can be added by the
> programmer at the application level, but this complicates the
> process of writing general library routines intended to be used by
> multiple applications.
Coarrays were split into core coarrays features in the draft standard,
and a TR consisting of further coarrays features. It was a compromise
between those who wanted coarrays now, and those who wanted
to go slow standardizing parallelization.
All the TEAM= stuff was put into the TR for further work.
I agree that TEAMs are useful, but the final decision was a compromise.
It will take some paper shuffling to get the TR formally started,
so I can't point you to a document right now.
--
Cheers!
Dan Nagle
| |
| Ron Shepard 2008-02-23, 4:31 am |
| In article <2008022213413875249-dannagle@verizonnet>,
Dan Nagle <dannagle@verizon.net> wrote:
> Hello,
>
> On 2008-02-22 11:58:48 -0500, Ron Shepard
> <ron-shepard@NOSPAM.comcast.net> said:
>
>
> A coarray program certainly can start a transfer long before
> the data is needed and go do some other unrelated work.
Yes, just like a compiler could initiate I/O operations ahead of
time in anticipation of some future request. But in practice, it is
good just to give the programmer direct control of this. That does
not prevent the compiler from looking ahead, but it gives the
programmer the ability to get the job done correctly even if the
compiler cannot do a good job by itself of recognizing such
opportunities. As I say above, it is already well established (for
about 20 years now) that this functionality is useful in explicit
message passing programing environments.
$.02 -Ron Shepard
| |
| Janne Blomqvist 2008-02-23, 4:31 am |
| On 2008-02-23, Ron Shepard <ron-shepard@NOSPAM.comcast.net> wrote:
> In article <2008022213413875249-dannagle@verizonnet>,
> Dan Nagle <dannagle@verizon.net> wrote:
>
>
> Yes, just like a compiler could initiate I/O operations ahead of
> time in anticipation of some future request. But in practice, it is
> good just to give the programmer direct control of this. That does
> not prevent the compiler from looking ahead, but it gives the
> programmer the ability to get the job done correctly even if the
> compiler cannot do a good job by itself of recognizing such
> opportunities. As I say above, it is already well established (for
> about 20 years now) that this functionality is useful in explicit
> message passing programing environments.
I think you misunderstood the 'long before' thing. Yes, the compiler
can reorder statements as long as it retains the semantics of the
program, but the point here AFAICT was that coarray statements are
more like the nonblocking MPI procedures. I.e. the data is not
guaranteed to be available on the recieving side before the sync
statement has finished (just like MPI_Wait). So if anything, coarrays
lack the traditional blocking MPI operations.
--
Janne Blomqvist
| |
| Dan Nagle 2008-02-23, 7:13 pm |
| Hello,
On 2008-02-23 05:01:07 -0500, Janne Blomqvist <foo@bar.invalid> said:
>
> I think you misunderstood the 'long before' thing. Yes, the compiler
> can reorder statements as long as it retains the semantics of the
> program, but the point here AFAICT was that coarray statements are
> more like the nonblocking MPI procedures. I.e. the data is not
> guaranteed to be available on the recieving side before the sync
> statement has finished (just like MPI_Wait). So if anything, coarrays
> lack the traditional blocking MPI operations.
This is the point I was trying to make.
Programmers can roll-their-own blocking transfers
by surrounding the transfers with sync statements.
(Just like in MPI a non-blocking transfer could be surrounded
by wait calls.)
The sync statements are the only place where the program
synchronizes (there are also critical blocks), they are present
explicitly in the code. So they are clearly visible.
--
Cheers!
Dan Nagle
|
|
|
|
|