[MPI3 Fortran] Proposing changes to Fortran 2008

[Hubert Ritzdorf]

Hi,

Aleksandar Donev wrote:
> Hi,
>
> Not to be argumentative, take this as IMO please.
>
> On Friday 21 March 2008 05:13, Hubert Ritzdorf wrote:
>   
>> MPI and Fortran 77 have worked without any problems
>>     
> Except for the problem that the MPI Forum chose to completely ignore and 
> violate ALL existing Fortran standards. This *includes* Fortran 77. All 
> Fortran versions are strictly typed and passing a REAL array to an INTEGER 
> argument has never been, nor will it ever be legal.
>
>   
>> Thus, an attribute for an argument "Behave such as without interface
>> description
>>     
> Then don't supply an interface? Or simply say
>
> VOID :: buffer 
>
> for the actual just to give it a name. I already commented on this earlier.
>   
This is what some vendors already implemented (using different names). 
When I remember (and understood)
it correctly, you mentioned that they didn't it right. Since the 
behaviour should be well-defined if an
interface description is not available and the vendors have to implement 
it, and it should be possible
to specify it for a single argument. It's fine for me to have such a 
VOID attribute.
>   
>> and don't perform copy-in/copy-out" 
>>     
> What if the actual argument is a strided (non-contiguous) array or, say, an 
> array constructor? The Fortran committee did not invent copy-in/copy-out 
> because compilers wanted to do copy frivolously. It is a necessary 
> implementation method to pass certain types of actuals to certain types of 
> dummies. You have to explicitly address this and cannot just say "go back to 
> Fortran 77". New Fortran has strided arrays, array constructors, array 
> pointers, etc., etc., like it or not.
>   
There are 2 general problems for MPI with these copy-in/copy-out behaviour:
   (*) In non-blocking MPI communication routines, the buffers may be 
received
        or sent after the MPI routine which specifies the buffer has 
already finished.
        If the compiler issues a copy-in/copy out of that buffer 
before/after that
        MPI routine, this causes incorrect results. I.e. the data is 
read from or written
        to memory which is already used by other tasks. Even if the 
application
        programmer is aware of this and has ensured that the data is 
stored in
        consecutive/contiguous memory addresses, it happens that the 
compiler
       performs a copy-in/copy-out before/after these MPI routines.
       Thus, a major problem for the application programmer is that there is
       no possibility to specify this to the interface description so 
that the
       compiler doesn't perform copy-in/copy out.
       A second major problem is that the application program may work
       for a long time with this copy-in/copy-out behaviour for 
non-blocking MPI routines.
       But small changes in the  run-time behaviour of the application 
program may cause
       errors (incorrect results/segmentation violations) in other (far 
away) parts of the application
       programs which are very very hard to find/debug.
   (*) Derived MPI datatypes are defined as sequence of primitive types 
and byte displacements.
         The byte displacements (which might be negative) are relative to
         the buffer specified in the MPI function call. (If the 
MPI_BOTTOM is specified as MPI buffer,
         you can see the byte displacements as memory addresses).
        In order to compute these displacements for general derived 
datatypes, function MPI_Get_address
        should be called. Again copy-in before MPI_Get_address or 
copy-in/copy-out before/after a
        MPI communication subroutine call might cause incorrect results 
because the memory layout of
        the generated MPI derived datatype and the memory layout which 
was  generated by the
        compiler before/after the MPI communication call might be 
totally different.
        Even if the application programmer defines MPI derived datatype 
correctly, he cannot control
        the behaviour of the application program since he doesn't know 
at which places the
        compiler creates temporary memory in order to perform 
copy-in/copy-out.
   
Best regards

Hubert   
        

>   
-------------- 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/20080327/e80643c0/attachment-0001.bin>