[MPI3 Fortran] Request for a straw vote.
crasmussen at newmexicoconsortium.org
Wed Jun 10 13:28:28 CDT 2009
On Jun 10, 2009, at 11:08 AM, Hubert Ritzdorf wrote:
> Craig Rasmussen wrote:
>> We made a lot of progress today on prospective MPI-3 interfaces for
>> Fortran. Since not everyone was able to attend the MPI Forum
>> meeting, I'd like to open the issues up for a straw vote. Everyone
>> may vote or otherwise express their opinion as this isn't an
>> official Forum vote. I've formed the vote in terms of a question
>> and an answer. If you agree with the answer, vote yes. Otherwise
>> vote no and please give the reason why along with a suggested
>> I should note that I personally haven't participated in the resent
>> discussions because I've been on travel to foreign lands.
>> Issues to straw vote:
>> 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.
>> 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
> I think that we proposed to use type(*), dimension(..) at the
> interface and to pass the
> corresponding Fortran descriptor to the functions which have
> extra_state as input argument.
This is true for the MPI optional arguments like the buf argument in
MPI_Send. In C typically these parameters are void* pointers to a
struct, not an array. There are no real performance implications so I
don't think we don't have to worry about using the target attribute or
Fortran pointers. In addition we can use C_F_POINTER to "cast" the
C_PTR back to a concrete Fortran type. I don't think we have a way to
cast a type(*) to something concrete.
>> 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 module.
> I vote for MPI3 so that for the application programmer is clear
> which interfaces
> he is using.
>> 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.
>> 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
>> 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?
>> 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.
>> 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.
>> 11. Q: Should the F77 and F90 interfaces be deprecated?
>> A: Yes.
>> NOTE: Old interface descriptions should be moved to an appendix.
> I think that deprecated is too strong. I think that we have to
> support them for a long time
> (ever). I personally also think that we have to provide F77 and F90
> interfaces for
> the new MPI3 functions.
>> 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
> No; The MPI library has to support this and the MPI forum has to
> define how the
> non-contiguous buffer has to be interpreted.
A note to everyone not at the MPI Forum meeting. There seems to be a
consensus forming around having the MPI implementors doing the "right"
thing with regards to noncontiguous memory.
>> 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.
> As mentioned above, I think that we have to provide F77/F90
> interfaces also for new MPI functions.
> Hubert Ritzdorf
> NEC Europe
> mpi3-fortran mailing list
> mpi3-fortran at lists.mpi-forum.org
More information about the mpiwg-fortran