[MPI3 Fortran] Straw vote on integers kinds

Craig Rasmussen crasmussen at newmexicoconsortium.org
Mon Sep 14 12:05:26 CDT 2009


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.

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

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-fortran/attachments/20090914/69c1a7de/attachment-0001.html>


More information about the mpiwg-fortran mailing list