[MPI3 Fortran] Straw vote on integers kinds

Tue Sep 15 10:05:30 CDT 2009

On Sep 14, 2009, at 12:50 PM, Lionel, Steve wrote:

> I vote for #4.  This encourages good programming practice but allows  
> programmers the option of omitting the kind in most circumstances.   
> The wording of choice 2 is unreasonably restrictive, I believe,  
> unless it is suggesting that vendors may not provide generics or  
> promotion features.

Yes, two is meant to be restrictive (thus choice 4, which is an  
unrestricted 2).

-craig

>
>
> Steve Lionel
> Intel Developer Support
> Nashua, NH
>
>
>
> From: mpi3-fortran-bounces at lists.mpi-forum.org [mailto:mpi3-fortran-bounces at lists.mpi-forum.org 
> ] On Behalf Of Craig Rasmussen
> Sent: Monday, September 14, 2009 1:05 PM
> To: MPI-3 Fortran working group
> Subject: [MPI3 Fortran] Straw vote on integers kinds
> Importance: Low
>
> 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
>
> _______________________________________________
> 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/20090915/eee145f6/attachment-0001.html>