[MPI3 Fortran] Proposing changes to Fortran 2008
crasmussen at lanl.gov
Tue Apr 22 06:44:18 CDT 2008
I'm heading back to sleep. Wake me up when you get a chance. I'm at
On Apr 17, 2008, at 11:18 AM, Jeff Squyres wrote:
> I have an 11-noon US Eastern time call scheduled on Tue, Apr 22, but
> am otherwise free.
> On Apr 17, 2008, at 12:07 PM, Craig Rasmussen wrote:
>> 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 compiler implementations.
>> 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
>> 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
>> 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 pending.
>> On Apr 16, 2008, at 10:33 AM, Hubert Ritzdorf wrote:
>>>>> I am probably looking for an extension of the ASYNCHRONOUS (not
>>>> 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 explicit).
>>> 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
>>> memory location
>>> directly from memory if the application program accesses a variable.
>>> This kills any type of optimization and significantly increases the
>>> memory traffic.
>>> MPI nonblocking communication is quite similar to asynchronous read/
>>> Therefore, an extension of ASYNCHRONOUS attribute for MPI or other
>>> communication libraries would be most appropriate and should cause
>>> conflicts with the actual Fortran standard. You can take most of
>>> the description
>>> of the ASYNCHRONOUS attribute and replace input/output by
>>> (only the WAIT doesn't fit, since MPI_Wait is not know by the
>>> Fortran standard).
>>> For example:
>>> The ASYNCHRONOUS_EXT is an extension of the ASYNCHRONOUS attribute.
>>> NOTE 12.26:
>>> The ASYNCHRONOUS_EXT attribute species the variables that might be
>>> 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 be
>>> by the compiler to disable certain code motion optimizations.
>>> Note 5.8:
>>> 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 mechanism.
>>> Making a copy of actual arguments whose values are likely to change
>>> to a (non-blocking, asynchronous) communication operation
>>> completing or
>>> in some unpredictable manner will cause those new values to be lost
>>> 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.
>> mpi3-fortran mailing list
>> mpi3-fortran at lists.mpi-forum.org
> Jeff Squyres
> Cisco Systems
> mpi3-fortran mailing list
> mpi3-fortran at lists.mpi-forum.org
More information about the mpiwg-fortran