[MPI3 Fortran] Proposing changes to Fortran 2008

Tue Apr 22 06:42:31 CDT 2008

Jeff, my email has been cranky while in Washington but VPN seems to  
cleared up in Eugene.  Would it be possible to have a telecon at  
10:00 AM EST ?  Could we use your number?

Craig

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
>> 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 pending.
>>
>> Regards,
>> Craig
>>
>>
>> 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 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/
>>> write.
>>> Therefore, an extension of ASYNCHRONOUS  attribute for MPI or other
>>> communication libraries would be most appropriate and should cause
>>> minimal
>>> conflicts with the actual Fortran standard. You can take most of
>>> the description
>>> of the ASYNCHRONOUS attribute and replace input/output by
>>> communication
>>> (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
>>> associated
>>> with a pending sequence (the actual memory locations
>>> on which (asynchronous, non-blocking) communication is being
>>> performed)
>>> while the scoping unit is in execution. This information could be
>>> used
>>> by the compiler to disable certain code motion optimizations.
>>>
>>> Note 5.8:
>>> The constraints on actual arguments that correspond to a dummy
>>> argument
>>> with ASYNCHRONOUS_EXT attribute are designed to avoid forcing a
>>> processor
>>> to use the so-called copy-in/copy-out argument passing mechanism.
>>> Making a copy of actual arguments whose values are likely to change
>>> due
>>> 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
>>> ASYNCHRONOUS
>>> 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
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran
>
>
> -- 
> Jeff Squyres
> Cisco Systems
>
> _______________________________________________
> mpi3-fortran mailing list
> mpi3-fortran at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran