[MPI3 Fortran] Proposing changes to Fortran 2008
alexander.supalov at intel.com
Sat Apr 19 07:02:04 CDT 2008
Thanks for the summary. Could you please propose a couple of definite
time slots, to allow everybody select/deselect those he/she can make? At
the moment, having gone thru a couple of replies, I still cannot figure
out when exactly the meeting is going to be held.
From: mpi3-fortran-bounces at lists.mpi-forum.org
[mailto:mpi3-fortran-bounces at lists.mpi-forum.org] On Behalf Of Craig
Sent: Thursday, April 17, 2008 6:08 PM
To: MPI-3 Fortran working group
Subject: Re: [MPI3 Fortran] Proposing changes to Fortran 2008
>From my point of view the discussions so far have been exceptional.
They are bringing out the precise problems we have in calling MPI from
Fortran. I would like to have a conference call next week to discuss
these issues further. Could we have a call early Tuesday morning so
that both European and American continents can participate? What would
be the latest time for a call from a European perspective?
A couple of general comments on the discussions so far:
1. Regarding copyin/copyout. The difficulty here arises from the fact
that Fortran has richer array semantics than does C; in this instance it
is a much higher-level language than C. Therefore one SHOULD expect
problems in calling C from Fortran if one steps outside of the bounds of
the Fortran C interop standard. It is not the fault of Fortran nor
2. However, given the performance penalty of the target attribute, it
would be appropriate for the MPI Forum to request that the Fortran
committee try to fix this performance problem by changing the standard.
I'll draft a letter that Rich Graham could send to the J3 commitee. We
can discuss the letter at the next MPI Forum meeting.
3. Regarding the ASYNCHRONOUS extension Hubert suggests. Bill Long
(Cray) on the J3 committee has already mentioned something like this as
a possibility. Since Bill is head of the HPC subcommittee on J3, I'm
sure we will discuss this at the next J3 committee meeting in May.
4. It may be that the two committees (J3 and MPI Forum) can arrive at a
solution that maintains performance AND clearly spells out what won't
work and the Fortran MPI programmer should not attempt to do, even if it
happens to work for one compiler or particular section of code. The
Fortran standard has lots of "thou shalt nots" and the MPI Fortran
standard should specify constraints as well, where appropriate. One of
these constraints was already pointed out by Aleks that one is not
allowed to read or modify variables while asynchronous input I/O is
On Apr 16, 2008, at 10:33 AM, Hubert Ritzdorf wrote:
I am probably looking for an extension of the
ASYNCHRONOUS (not VOLATILE)
Why not VOLATILE---is there a difference? The only
difference, as far as I know, is that ASYNC is restricted to Fortran
async I/O, and volatile for everyting "outside of the Fortran standard".
Sounds to me like VOLATILE is exactly what you want. Unless you want
somewhat different semantics/constraints (which is not presently the
case---the only difference I know is that ASYNC attribute is implicitly
given to variables involved in async I/O, while VOLATILE must be
VOLATILE is different. Volatile means that other
processes/threads may change the
data. The effect is, that the run-time system has to reload each
directly from memory if the application program accesses a
This kills any type of optimization and significantly increases
the memory traffic.
MPI nonblocking communication is quite similar to asynchronous
Therefore, an extension of ASYNCHRONOUS attribute for MPI or
communication libraries would be most appropriate and should
conflicts with the actual Fortran standard. You can take most of
of the ASYNCHRONOUS attribute and replace input/output by
(only the WAIT doesn't fit, since MPI_Wait is not know by the
The ASYNCHRONOUS_EXT is an extension of the ASYNCHRONOUS
The ASYNCHRONOUS_EXT attribute species the variables that might
with a pending sequence (the actual memory locations
on which (asynchronous, non-blocking) communication is being
while the scoping unit is in execution. This information could
by the compiler to disable certain code motion optimizations.
The constraints on actual arguments that correspond to a dummy
with ASYNCHRONOUS_EXT attribute are designed to avoid forcing a
to use the so-called copy-in/copy-out argument passing
Making a copy of actual arguments whose values are likely to
to a (non-blocking, asynchronous) communication operation
in some unpredictable manner will cause those new values to be
when a called procedure returns and the copy-out overwrites the
actual argument or the application program aborts.
The ASYNCHRONOUS_EXT attribute is similar to the VOLATILE and
attribute. It is intended to facilitate traditional code motion
optimizations in the presence
of (asynchronous, non-blocking) communication.
Dornacher Strasse 1
85622 Feldkirchen/Muenchen Germany
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456 Ust.-IdNr.
VAT Registration No.: DE129385895
Citibank Frankfurt (BLZ 502 109 00) 600119052
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mpiwg-fortran