[MPI3 Fortran] MPI draft 2011-04-21

[Malcolm Cohen]

>> Pg 543, line 45: These named "constants" are an implementation detail
>> and I don't understand why this is more than advice to implementors.
>
>It is important, that the user must not copy these constants.
>  buf = MPI_BOTTOM
>  MPI_SEND(buf, ...)
>is invalid. Therefore here the reason and a pointer to Section 2.5.4.

In Fortran 2003 and later this is more-or-less enforceable if you make the type 
of MPI_BOTTOM a private derived type.  That prevents the user from declaring a 
variable of that type.

>Does the Fortran standard guarantee that an array of a derived type
>or a derived type with arrays as structure elements is internally
>always stored as defined:

No.

>  TYPE :: struct
>    REAL :: x, y, z
>    INTEGER :: geo
>    END TYPE struct
>  TYPE(struct) a(1000000)
...
>Is the fortran compiler allowed to store it
>as
>
>  TYPE :: struct_iternal
>    REAL :: x(1000000), y(1000000), z(1000000)
>    INTEGER :: geo(1000000)
>    END TYPE struct
>  TYPE(struct) a

In theory there is no requirement for any kind of uniform address space, 
contiguous storage, or even non-distributed storage.  This has been exploited in 
the past on various massively-parallel machines.  In practice on a conventional 
modern machine with a flat address space there are a lot of things it has to get 
right w.r.t. e.g. argument passing, array sectioning and subscripting which 
would make that infeasible without special hardware (or a lot of slow 
emulation).

Why is this important?

>I was told, that without the SEQUENCE attribute,
>the compiler can do what it expect to be most efficient.
>Is this true?

Yes.

>> Pg 552, two examples: These examples remind me that we need to
>> carefully think where the TARGET attribute should/must be used in a
>> valid MPI program.
>
>The other solutions for examples 16.13 and 16.14
>have been there and were described since July 1997.

That does not mean that they were correct at that time.

>I hope that they are still correct and that there is no case
>where TARGET ***must be used*** instead of the other solutions.

If buf does not have the TARGET attribute, MPI_GET_ADDRESS is not necessarily 
going to get the address of it!  That's the whole point of TARGET... (and not 
having TARGET).

VOLATILE does not solve that.  Making it a module variable does not solve that. 
Playing with helper routines does not solve it as far as I can tell.

These proposed "other solutions" appear to have been invalid since 1991.

BTW, the "can be compiled as" columns seem to show fairly conservative 
optimisations... the compiler is at liberty to do much more to the code than 
these demonstrate.

I'm not sure why the allergy to using TARGET to describe things you take an 
address of, since that is the very purpose of TARGET, and MPI's other target 
language C effectively gives every variable the TARGET attribute.

>> Pg 553, line 6: Insert something like "MPI_F_SYNC_REG and the use of
>> module data" are not guaranteed to work by the Fortran standard,
>> though will likely work on most compilers.
>
>I'll add after "Each of these methods solve ... every application context.":
>
>  These methods may not be guaranteed by the Fortran standard,
>  but they must be guaranteed by a \MPIIIIDOTO/ compliant (and later)
>  \MPI/ library and their compiler according to the requirements
>  listed in Section 16.2.16 on page 566.

Seems to be p565 on my copy, maybe I'm looking at the wrong text or have a 
different version of the document.

Given the decades-old (certainly pre-97) link-time optimisation technologies 
that have been and are being used, this seems to be misguided.

>> Pg 554, first paragraph: MPI_F_SYNC_REG should be made BIND(C) to keep
>> Fortran from very aggressive optimizations.

Doesn't work against link-time optimisations.

Doesn't work against various other compiler technologies in current use either.

...
>The MPI Forum is in the conflict that it should keep the MPI
>standard backward compatible. Thus, the DD must stay a valid
>solution.

It probably wasn't a valid solution then either.

I appreciate that an apparent lack of backwards compatibility would be a 
problem, but remaining incompatible with long-established compiler technologies 
that are in use could also be considered to be a problem, and one that is only 
going to get worse in time.

Cheers,
-- 
................................Malcolm Cohen, Nihon NAG, Tokyo.