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.