[MPI3 Fortran] Request for a straw vote.
jsquyres at cisco.com
Mon Jun 22 10:43:36 CDT 2009
Sorry for being late to the discussion.
On Jun 9, 2009, at 5:41 PM, Craig Rasmussen wrote:
> 1. Q: Should intents be specified in the MPI-3 interfaces?
> A: Yes, specifying intent in the Fortran interfaces helps the user
> to understand the call (it may also help the compiler with
> 2. Q: Should derived types be used in place of some MPI handles that
> are currently integers? For example, TYPE(MPI_Comm).
> A: Yes, the use of specific types enhances type safety.
Yes. Remember that MPI specifies that these are *handles* to back-end
objects. Implementors can put whatever they want in handles; they
just have to observe the defined handle semantics as listed in the MPI
spec (this usually means that the handle is separate from the back-end
object; the handle can be copied without copying the object, etc.)
There's already good precedent for this in the MPI C++ bindings.
> 3. Q: What type should be specified for the extra_state and value
> parameters in MPI_Comm_create_keyval and MPI_Comm_attr_set?
> A: TYPE(C_PTR). Use of C_PTR allows the MPI implementation to
> store the address of the Fortran type and the user to subsequently
> associate a Fortran pointer with the stored C_PTR with a call to
> NOTE: C addresses are to be obtained using C_LOC which requires
> the target attribute on the actual argument. This warns the compiler
> that MPI may store (alias) the extra_state or value parameters.
I thought Hubert was right on this one: we decided to use TYPE(*),
DIMENSION(..) to allow anything to go through (of course, that's a
problem if scalars can't be specified this way). Perhaps the real
Right answer here is to do whatever is done for MPI_SEND choice
buffers (and friends) -- then at least we only continue that debate in
one arena, not two.
> 4. Q: What should the name of the MPI-3 module be?
> A: MPI3 to distinguish it from the current MPI module.
> Unresolved Issue: A consensus was not reached on this question.
> An alternative is to use module names MPI2, MPI3, ..., as well as
> MPI. If "USE MPI" is used, the MPI vendor will allow the module to be
> chosen with a compile time option specifying the location of the MPI
I prefer explicit versioning (e.g., "mpi3") since we *know* that the
MPI-3 Fortran interface will be different and incompatible with the
MPI-1 and MPI-2 Fortran interfaces, then having "use mpi" magically
change to use the new interfaces will break old codes -- they'll
refuse to compile. I think that's extremely undesirable.
As previously mentioned, conversion functions will be provided that
can be used to convert between C and MPI-1/MPI-2 Fortran handles and
this new interface.
> 5. Q: Should default integer kinds be used for most integer
> A: Yes, this has not caused problems in the past and will have the
> least impact on existing code.
> NOTE: A specified kind, MPI_COUNT_KIND will be used for buffer
> count arguments.
I can see Alexander/Intel's position on this one: it has been a long-
standing problem that users may have an MPI implementation that
expects an INTEGER of size 4 bytes, but then the user compiled their
application with "ifort -i8 ...", changing all the INTEGERS in their
app to 8 bytes. Badness ensues when they use an 8 byte INTEGER to
call an MPI function.
But I can also see that it would be a PITA for programmers to have to
specify *every* argument to MPI functions, and potentially have to
translate between their MPI-argument-variables and non-MPI-argument-
I think I fall on the side of "use default INTEGERs", though. The MPI
can provide a "regular" INTEGER library, and a "-i8" INTEGER library.
It's not perfect, but perhaps it's best to continue this uneasy
compromise between programmer convenience / functionality and
What does the Fortran community do for this issue in other software
> 6. Q: How should type and rank be specified for buffer choice
> A: TYPE(*), DIMENSION(..)
> NOTE: This has been vetted by the Fortran J3 standards committee.
> MPI vendors will use the Fortran descriptor interface.
> Unresolved Issue 1: Will this block the compiler from using
I tried to get involved in this debate and Alexander D. jumped all
over my syntax. So I'll stay out.
The intent is that *any* variable -- scalar or otherwise -- can be
passed through this argument in a portable fashion (i.e., compiler-
independent). If that means not specifying the actual language/
compiler mechanism but just specifying the mandated behavior, then so
One point that may have gotten lost in the email chain: Craig is
correct that there is *NO RUSH* on specifying this. We can definitely
wait for J3 to finalize its relevant specification(s) (e.g., TYPE(*),
DIMENSION(..)). The Forum agrees on this point and definitely does
not want to specify something based on a non-official/proposed J3 draft.
> 7. Q: Are vendors allowed to provide a different actual interface in
> the MPI-3 module for TYPE(*), DIMENSION(..) as a workaround until
> compilers catch up.
> A: Yes, if possible.
> Unresolved issue: Can existing IGNORE TKR compiler directives be
> used instead?
Ditto with #6.
> 8. Q: Should the value attribute be given to some parameters?
> A: No, it would be different from current semantics (though more
> true to the C interface) and there is no need to make the change.
> Specify intent instead.
> 9. Q: What syntax should be specified to inhibit aggresive compiler
> optimizations associated with asynchronous MPI calls.
> A: Used the Fortran asynchronous attribute on dummy variables.
> NOTE: The MPI-3 standard will need to make clear that there are
> requirements on the user to get this correct.
Staying out of this one for the same reason as #6.
> 10. Q: Should specific Fortran interfaces be specified in the MPI-3
> A: Yes, this is preferable to use of <type> in the current
> standard. While <type> is shorted, specific Fortran interfaces
> provide greater clarity for users.
Yes, we should specify them because they will be different than the
existing Fortran (77 style) bindings that are listed in the MPI-2.2
spec. Types will be different, etc. Hence, they really are two
difference interfaces and need to be delineated.
A reminder: the F90-style bindings are *not* listed anywhere in the
MPI-2.2 spec. I assume that's because the types are all the same as
the F77-style bindings that are listed throughout MPI-2.2.
> 11. Q: Should the F77 and F90 interfaces be deprecated?
> A: Yes.
> NOTE: Old interface descriptions should be moved to an appendix.
Note: "deprecated" is not "removed". Either moving them to an
appendix or marking them deprecated in the text (like we're about to
do with the C++ bindings) are good solutions; they functions are still
there, but we want everyone to use the new stuff.
I agree that both the MPI spec and MPI implementations won't be
removing them any time soon. Perhaps we can say "deprecated" in the
spec for the old-style interfaces with appropriate language explaining
that it is just our intent that people use the new stuff -- we're not
abandoning the millions of LOC of legacy MPI Fortran apps.
> 12. Q: Is it an error if the user gives a non-contiguous buffer to a
> choice argument as it is for C?
> A: Yes.
> Unresolved issue: Should the vendor be required to catch the
> error as always checking the argument is a performance issue.
I have seen this listed inaccurately in this thread multiple times:
MPI does *NOT* say that it is an error to give a non-contiguous buffer
as a choice buffer (in C or any language). This is *why* MPI has
datatype arguments -- to describe the type map of the buffer.
As Hubert indicated, it *must* be permissible to pass non-contiguous
buffers as choice arguments and [somehow] have the underlying MPI do
the Right Thing.
Staying out of type/syntax discussions on this point for the same
reasons as #6.
> 13. Q: Should mixed MPI-3 and older MPI code be compatible within the
> same application.
> A: Yes, this allows a gentler transition path to MPI-3 if the
> user doesn't have to convert all of this code at once.
> NOTE: This will require conversion routines between, for example,
> integer handles and MPI-3 typed handles. This would allow a
> TYPE(MPI_Comm) to be converted to an integer and passed to code in a
> user's older Fortran library.
I think we will need to outlaw mixing "include 'mpif.h'", "use mpi",
and "use mpi3" (or whatever the new one is called) within the same
block, though. I'm guessing that the types and/or values of MPI
constants (e.g., MPI_COMM_WORLD) will conflict between these 3
More information about the mpiwg-fortran