[MPI3 Fortran] Proposing changes to Fortran 2008

[Hubert Ritzdorf]

Hi,

Aleksandar Donev wrote:
> On Tuesday 01 April 2008 15:07, Hubert Ritzdorf wrote:
>
>   
>> The run-time error occurred for the version which performed copy-in/copy
>> out. The usage of the compiler flag which avoids copy-in/copy out for that
>> source file worked.
>>     
> Yes, but you did not answer my question: What would happen with that compiler 
> and that flag when copy in/out were actually required at run-time (i.e., the 
> actual was not contiguous)? What would you want/expect to happen?
>   
If the application program would
   (*) put in a subsection "array (i,:)" and
   (*) sends/receives contiguous data and
   (*) expects that the data is read from/written to this subsection
the application program would not work.

I hate destroying running application programs, but as I already mentioned
such an example would not work for isend/irecv. Therefore, it would be
probably better to have a well defined behaviour. The user has to
guarantee that the buffer is contiguous if the user expects continuous data.
If the user works with derived datatypes (non-contiguous data),
copy-in/copy-out would kill the application program also.

Thus, compile time checking is ok. Default run-time checking is not
ok since the application program might transfer non-contiguous data.

By the way. What does the 2003 compiler/runtime say if the application 
program
(*) tries to perform an asynchronous read/write of an non-contiguous 
array section
     and
(*)  pass this array-section to a subroutine which requires copy-in/copy 
out
before the WAIT statement is executed ?
Switches the runtime system back to synchronous I/O ?
Or is this simply an user error ?

> The point here is that we are talking about standardizing things, and the 
> standard needs to explain exactly what happens for *all* source codes, not 
> just your particular one which "worked".
>
>   
>> 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.

> The best thing would be for you (or whoever has specific ideas) to write a 
> sample code that calls MPI_Isend, including the proposed interface for 
> MPI_Isend, and explain what each of the proposed attributes/keywords means. 
> Maybe that would bring some progress instead of going in circles. If it 
> helps, assume that the buffer is a REAL array for now (i.e., separate the 
> TKR-mismatch issue from the copy in/out issue).
>   
I have attached an exemplary F90 test program which tries to show a simple
copy-in/copy-out problem which I have seen for an application program.
The application program  crashed because the Fortran compiler created a
temporary array for the section recv_vector(ip+1:ip+len_sent(i)).
If recv_vector(ip+1) was passed, the application program worked fine.
The proposed interfaces for MPI_Irecv and MPI_Isend are at the head
of the Fortran 90 file.

Hubert
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: isend.F90
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-fortran/attachments/20080416/ab08ce94/attachment-0001.ksh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-fortran/attachments/20080416/ab08ce94/attachment-0001.bin>