(j3.2006) MPI usage problems in Fortran

[Bill Long]

A couple of comments on the ideas below.

1) The ASYNCHRONOUS FUNCTION scheme is basically what some people call 
'futures'.  If we (WG5) want to go that direction, we should consider 
how to do it in general.

2) Either the async functions, or the proposal to change the rules for 
C_LOC() take the proposal out of conformance with f03.  If the idea is 
to provide a facility that is usable with f03, then those options are 
out.  If the idea is to make an interface for f08, for which we (barely) 
have time for changes, or for a future f1x standard, then it would be 
better, in my opinion, to directly address the root problem rather than 
trying to twist existing syntax.  For example, we could add a type 
C_VOID to the ISO_C_BINDING module, say that any data type can match 
this in an interface, and that variables declared that way shall not 
appear in a definition context, shall not be referenced, and shall not 
be allocatable, pointer, or assumed-shape.  In other words, can't be 
used outside an interface, and are pass by address, and not dope 
vector.  Alternatives, like type(*), have been proposed in the past to 
serve a similar function, though experience suggests that messing with 
the basic typing syntax is unpopular. 

Another variation that has been discussed (and I would prefer) is to add 
a LANG= spec to the BIND( ) syntax, which would enable you to specify 
that an interface was for a function written in C and that type(C_VOID) 
would be allowed only in such an interface, and disallow allocatable, 
pointer, and assumed-shape for type(C_VOID) dummies.  You enforce the C 
nature (or , at least non-Fortran nature) of the function by requiring 
that the LANG= spec on the interface and the actual function definition 
has to match , and that LANG="C"  is allowed only in an interface body.  
Some of these ideas COULD be added into the C interop TR, which would be 
better than messing with the base f08 document.  And it would allow the 
MPI crowd to require f03 + TR rather than all of f08. 

Cheers,
Bill




Craig Rasmussen wrote:
> On Mar 20, 2008, at 11:10 AM, Aleksandar Donev wrote:
>
>   
>>> As Bill says, this is very much like asynchronous I/O in
>>> Fortran and should be treated similarly.
>>>       
>> Yes, but if only ASYNCHRONOUS were itself treated consistently, we  
>> could have
>> something to work from...
>>
>>     
>>> Perhaps it would be helpful
>>> to have the ASYNCHRONOUS attribute apply to procedures, i.e.,
>>>       ASYNCHRONOUS FUNCTION MPI_Isend(...)
>>>       
>> And what exactly does this mean?
>>     
>
> A description of one problem (text partially borrowed from MPI  
> documentation at Argonne):
>
> -----------------------------
>
> To prevent instruction reordering or the allocation of a buffer in a  
> register there are two possibilities in portable Fortran code:
>
> The compiler may be prevented from moving a reference to a buffer  
> across a call to an MPI subroutine by surrounding the call by calls  
> to an external subroutine with the buffer as an actual argument.
>
>          call MPI_IRECV(buf,...,req)
>
>          ....
>
>          call MPI_WAIT(rec,...)
>
>          call DD(buf)
>
> with the separately compiled
>
>          subroutine DD(buf)
>
>            integer buf
>
>          end
>
> ------------------------------
>
> So with appropriate wording in the standard, could something like the  
> following be made to work?
>
> interface
>
>      ASYNCHRONOUS function MPI_Irecv(...)     ! similar effect as  
> asynchronous specifier (9.6.2.5) and
>
>      ASYNCHRONOUS function MPI_Wait(...)      ! any statement to  
> these functions involve asynchronous operations
>
> end interface
>
>
>
> integer, ASYNCHRONOUS :: buf(*)     ! ASYNCHRONOUS rather than TARGET  
> to limit the effect to local scoping unit
>
> call MPI_Irecv(C_LOC(buf),...,req)        ! C_LOC modified to include  
> ASYNCHRONOUS variables
>
> ....
>
> call MPI_Iwait(req,...)            ! last asynchronous function seen  
> in this scoping unit so optimizations can be turned back on?
>
>
>
> Regards,
>
> Craig
> _______________________________________________
> J3 mailing list
> J3 at j3-fortran.org
> http://j3-fortran.org/mailman/listinfo/j3
>   

-- 
Bill Long                                   longb at cray.com
Fortran Technical Support    &              voice: 651-605-9024
Bioinformatics Software Development         fax:   651-605-9142
Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120