[MPI3 Fortran] Proposing changes to Fortran 2008

[Jeff Squyres]

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