[MPI3 Fortran] Request for a straw vote.

[Hubert Ritzdorf]

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.
>
> -craig
>
> ---------------
>
> 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 
> C_F_POINTER.
>    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 
> 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 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 
> copyin/copyout?
>
> 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 
> standard?
>     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.
> .
>
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-fortran/attachments/20090610/d29ca60a/attachment-0001.bin>