[MPI3 Fortran] Proposing changes to Fortran 2008

[Craig Rasmussen]

 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.
>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-fortran/attachments/20080417/956a5f69/attachment-0001.html>