[MPI3 Fortran] Straw vote on integers kinds

[Bill Long]

Craig Rasmussen wrote:
> I've fixed the wiki to better represent current thinking and cleaned up 
> and added example code.   I think we are pretty close to having most of 
> the issues resolved.  We still must come to terms with what to do with 
> integer kinds.  In the wiki, I've listed four possibilities; three of 
> them have come up in recent discussions.  I've listed them below, also 
> see https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/FtnWikiPage
> 
> Please vote for one of the options.  My personal view is that we need to 
> open up the question to the entire MPI Forum to get reaction from a 
> larger community (not just Fortran geeks).  I'll do this at the next 
> meeting in Portland.


I'm not convinced there is much real difference among these options.


> 
>    1. Use the default integer kind. This has the least impact on
>       existing codes. This causes problems when the size of default
>       integers are promoted for user code and not also in the MPI library.

This is what we have today. If the vendor compiler allows two different 
sizes of "default integer" (via a switch like -i8), then they need to 
supply two different modules/interfaces, one for each default.  The 
correct one is referenced based on the command line switch in effect. If 
  the underlying MPI implementation requires the corresponding arguments 
be of the C type int, then wrappers for Fortran will be needed and the 
integer arguments cast to integer(c_int) before calling the underlying C 
routine.



>    2. Specify a named kind, e.g., MPI_INT_KIND. This provides the most
>       specificity and the user will have a known way to code that will
>       work under all circumstances. But this will cause problems for
>       existing codes when compiler options are used that change the size
>       of default integers.

Option 1 is recovered with the definition MPI_INT_KIND = KIND(0). Option 
2 requires a name for an integer kind, but does not specify the value 
(such as "same as c_int"), nor does is specify that there is only one 
such value. In practice, you are likely back to two modules, with 
different values of MPI_INT_KIND.  If this option explicitly required 
that MPI_INT_KIND be the value of the kind for integers that 
interoperate with the corresponding C dummy arguments [eliminating the 
casts in the wrappers], and hence that there be only one such value, 
then this option would have some teeth.  It could even promote good 
programming. Except that vendors will probably ignore the restriction 
and continue to provide two modules because users do not want to fix 
codes that work.


>    3. Require the vendor to provide two interfaces, one for standard
>       integers and one for long integers. This option works when
>       integers are promoted and doesn't break existing codes.

This option omits the possibility that the vendor supports only one 
integer kind, for a 18-digit (usually 64-bit) integer.  That is all that 
is actually required in the Fortran standard. But assuming there are two 
kinds supported, and they correspond to the two options for the kind of 
"default" integer, then this is the same as Option 1 again.


>    4. Specify a named kind in the Fortran interface (MPI_INT_KIND) but
>       allow the vendor a choice as to how to address integer promotion
>       (it would become a quality of implementation issue) if users use
>       default integers in their codes. The vendor could provide an
>       additional interface for promoted integers (not part of the MPI
>       standard) or could provide a separate library to link against.
> 

Again, I'm not really seeing the practical difference here.


I see that the wiki page proposes MPI_DOUBLE_KIND.  Is this intended to 
be the same as C_DOUBLE?  Why is there no corresponding MPI_FLOAT_KIND? 
Both might be affected (in much the same way) by a switch like -r8.

Of course, the ideal situation would be to outlaw completely the use of 
the -i8 and -r8  (and even worse, one and not the other) options. 
Perhaps this could be an MPI requirement - no program that uses MPI is 
allowed to use these switches.  That would be an enormous step in the 
right direction.


Cheers,
Bill


> -----------
> 
> I vote for number 4.  I believe that a standard should provide 
> specificity to the programmer.  If the programmer uses MPI_INT_KIND, 
> his/her program will always work even if integers are promoted or C_INT 
> doesn't match up with default integers.  Since users will have to change 
> existing codes anyway (to use the new derived types, e.g., MPI_Comm) 
> users can make the transition to specific kinds at this time.  However, 
> I also think the standard should also leave room for vendors to provide 
> additional integer kinds via generics or separate compilation libraries.
> 
> -craig
> 
> On Sep 2, 2009, at 11:30 AM, Lionel, Steve wrote:
> 
>> Craig wrote:
>>
>>> I've been back and forth on this (as well as a few others I think).   
>>> I'm currently leaning toward using default integers.  Primarily  
>>> because to do otherwise could potentially break countless lines of  
>>> users code.  
>>
>> No, it won't, as long as the choice for the MPI integer kind matches 
>> C_INT, which is pretty much universal for default integer in Fortran 
>> implementations.  
>>
>> Let me try an example.
>>
>> module MPI
>> use, intrinsic :: ISO_C_BINDING
>> integer, parameter :: MPI_INT_KIND = C_INT
>>
>> interface
>> subroutine MPI_SUB (INTARG)
>> import ! Makes the definition of MPI_INT_KIND visible here
>> integer(MPI_INT_KIND), intent(IN) :: INTARG
>> end subroutine MPI_SUB
>> end module MPI
>>
>>
>> User code:
>>
>> program test1
>> use MPI
>> integer SOMEVAR1
>> call MPI_SUB (SOMEVAR1)
>> end
>>
>> This is the "existing code" case.  The compiler will have a kind for 
>> "default integer" - the number chosen for this kind value varies by 
>> implementation (usually 4 but not always) - let's say it's 4 here. 
>>  For this combination of Fortran and a "companion C processor", C_INT 
>> is also 4, and thus so is MPI_INT_KIND.  The declaration of SOMEVAR1 
>> does not specify a kind, so it gets "default integer" or 4.  No 
>> problem yet.
>>
>> Now let's say that this user has decided to compile her Fortran code 
>> with an option that changes the default integer kind to 8 (-i8 or 
>> similar).  Now if the above code is compiled, there will be an error 
>> because the module, assuming it wasn't also compiled -i8, defines the 
>> argument as INTEGER(4) but SOMEVAR1 is now INTEGER(8).  The user may 
>> have had a reason to use -i8 for other variables and now needs to 
>> figure out what to do.  She reads the source of the MPI module, but if 
>> it just says INTEGER with no KIND value, she may be at a loss to 
>> figure out what to change.
>>
>> If it had been written like this:
>>
>> program test2
>> use MPI
>> integer(MPI_INT_KIND) SOMEVAR2
>> call MPI_SUB (SOMEVAR2)
>> end
>>
>> The call with SOMEVAR2 is ok in either case, because the explicit kind 
>> overrides the default integer kind in effect.
>>
>> Explicitly specifying the KIND value in the module helps documentation 
>> and encourages, but does not require, the programmer to specify the 
>> KIND value in their own code.  It does no harm and does not force 
>> coding changes that wouldn't be needed otherwise.  Using explicit 
>> kinds also helps make the code understandable.
>>
>> Regarding functions and subroutines, I think I would need a bit more 
>> background on the earlier discussion. I'll be glad to help on this and 
>> perhaps a phone call with you and Jeff would be in order when convenient.
>>
>>
>> Steve Lionel
>> Intel Developer Support
>> Nashua, NH
>>
>>
>>
>>
>> _______________________________________________
>> mpi3-fortran mailing list
>> mpi3-fortran at lists.mpi-forum.org <mailto:mpi3-fortran at lists.mpi-forum.org>
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> mpi3-fortran mailing list
> mpi3-fortran at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran

-- 
Bill Long                                   longb at cray.com
Fortran Technical Support    &              voice: 651-605-9024
Bioinformatics Software Development         fax:   651-605-9142
Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120