[MPI3 Fortran] Request for a straw vote.

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  
>> 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.

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  
>> 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.

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
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran