[MPI3 Fortran] Request for a straw vote.
ritzdorf at it.neclab.eu
Wed Jun 10 12:08:08 CDT 2009
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 alternative.
> 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 optimization).
> 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 parameters.
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.
> 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 vote for MPI3 so that for the application programmer is clear which
he is using.
> 5. Q: Should default integer kinds be used for most integer parameters?
> 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 arguments?
> 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
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
non-contiguous buffer has to be interpreted.
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3245 bytes
Desc: S/MIME Cryptographic Signature
More information about the mpiwg-fortran