[MPI3 Fortran] Proposing changes to Fortran 2008

[Jeff Squyres]

I didn't get Craig's e-mails until this morning.  Let's go for 10am US  
Eastern time (about 2 hours from now).

I'll send out a teleconf number shortly.



On Apr 22, 2008, at 7:44 AM, Craig Rasmussen wrote:

> I'm heading back to sleep.  Wake me up when you get a chance.  I'm at
>
> Thanks,
> 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
>
> _______________________________________________
> 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