David N. Smithe Oct 23, 2009

Of course 2 is the “correct” answer from a standarization and modern library usage point-of-view.  But this is Fortran, so practicality matters too

Why not a combination of 2&3, where a generic interface is encouraged to work for as many kinds as the vendor is willing to put up with, but is at least, guaranteed to work if integers happen to be of kind MPI_INT_KIND.

Whether one also guarantees that it works for C_INT and C_LONG kinds, or any other kind, including the mythical “default” kind ... that would be up to the vendor.

Stefan Knecht Oct 23, 2009

Hi,
I would prefer option 2. This looks like a “clean” solution.
BTW, we successfully use the integer promotion in our quantum chemistry program package (http://wiki.chem.vu.nl/dirac/index.php/Dirac_Program).
Regards,
stefan

Terry Frankcombe Oct 25, 2009

Let’s not forget that fudging the default types also breaks interactions with any other library that’s linked.

I have a bit of a problem with declaring that if MPI_INT_KIND is defined, then any code that doesn’t explicitly declare the integers as that kind is not compliant.  I can certainly see why one might make that declaration.  But if every implementation happens to set MPI_INT_KIND to the default kind for all the compilers that work on the platforms they’re targeting?  The kind spec becomes something of a no-op, yet all codes that don’t do it are non-conforming?  That seems a bit silly.  (I don’t expect all implementations to match defaults for all compilers, but I do expect that to be the norm rather than the exception.)

It would be nice to see MPI_INT_KIND implemented.  It would also be nice to see it as advisory, and that if the default kind is not MPI_INT_KIND then the code is broken.  I guess that means MPI_INT_KIND could not be part of a sourcecode compliance requirement.  I could see how this could be unacceptable to the Forum.

Jeff Squyres Oct 26, 2009

These are great comments—keep them coming!

Paul Fischer Oct 26, 2009

Regarding the statement:

Some MPI Fortran users change the size of default integers by using nonstandard compiler options that promote all integer declarations to long integers.  Obviously this can cause problems when the MPI library has not been compiled with the same option.

It’s certainly the case that the users can (and likely should) control whether src,  dest, tag variables are promoted or not by explicitly specifying their size, no?  If that’s the case, then it seems like (1) is a valid option, provided we know a priori what size MPI will expect to see.  Else, (2) is ok—- but how does this interact with f77?

Stephen Pickles Oct 26, 2009

I strongly prefer option (1), on the grounds that we’re talking about an API for Fortran, and there’s nothing about Fortran default integers that make them unfit for the purpose of representing a rank, size or tag.

As long as Fortran default integers remain at least 32 bits, there should be no problem in terms of size for src, dest and tag. We’ll still be programming for 1 million core machines in MPI, but I doubt we’ll be progamming machines with a billion cores with one MPI task per core. Although I’ve encountered cases where more tags would be convenient, the limitation wasn’t the size of a default integer, but the MPI implementation’s maximum tag value.

I don’t buy the argument that interoperability with C here should be an issue, at least from the application programmer’s point of view. So what if a particular Fortran has a larger default integer than C? Let any implementation that uses C internally do any required casts.

Nor do I buy the argument about the possibility of a Fortran compiler promoting default integers from 32-bit to 64-bit. Such applications do exist, for sure. But merely adding MPI_INT_KIND won’t fix the problem, unless ALL applications are required to use it, instead of default integers, all the time. If the owners of such applications won’t bite the bullet and fix their integer size problem using standard fortran features, what makes you think they’ll bite a bullet of a different flavour?

The legacy code-base is so important that any MPI implementation would have to support default integers as well as MPI_INT_KIND during the transition; so it would be making the implementors’ job harder, not easier.

Likewise, if MPI3 compliant implementations do not support MPI2 compliant implementations out-of-the-box, we’d be in danger of another round of this sort of abomination:
#ifdef MPI3
    INTEGER(MPI_INT_KIND) :: ...
#else
    INTEGER :: ...
#endif

By the way, the ring example on the Fortran Bindings Working Group Wiki Pages is broken, is it not? It should be using MPI_DOUBLE_PRECISION instead of MPI_DOUBLE (which is a predefined constant matching a C double, and has no place in a Fortran program).

Jeff Squyres Oct 26, 2009

Stephen—you’re correct about the use of MPI_DOUBLE_PRECISION on the ring example on the MPI Forum Fortran wiki page.  I fixed it.  Thanks!

R. Bader Oct 26, 2009

Option 2 seems most preferable. It could be combined with having multiple versions of MPI3 module files and libraries which support different KINDs for MPI_INT_KIND, so even the case of the user wishing to continue using default integers could be covered provided such usage is consistent.

Stephen Pickles Oct 26, 2009

Re-reading my own post above, I realize that I’m not so much arguing for (1) as against (2). However, I do have a residual preference for (1) over (3), as IMHO (3) is a compromise that will entail a good deal of work for little, if any, impact. MPI is already creaking under the weight of compromise.

Also, in my second last paragraph, I should have written “if MPI3 compliant implementations do not support MPI2 compliant _applications_”.

Terry Frankcombe Oct 27, 2009

Thinking some more, I think I’m arguing for (1) plus bits of (2).  Defining MPI_INT_KIND allows one to code in such a way as to be safe from integer badness on “global” integer promotion, if that’s the kind of trick you’re going to pull with you app.  It shouldn’t be *required* if kind(1)==MPI_INT_KIND.

Douglas Guptill Oct 28, 2009

I like #2.

We are in the midst of a change from 32-bit systems to 64-bit systems.  Experience shows that some will continue to run 32-bit systems for some time into the future, while others will go to 64-bit.

Craig Rasmussen Oct 30, 2009

I woke up early one morning this week and while tossing and turning came up with about the same idea as Terry Frankcombe posted above.  Stephen makes a good argument for preference 1.  However preference 1 doesn’t really help with those who change the type system with a compiler option (yuk).

However, if MPI provides MPI_INT_KIND as a convenience constant that just supplies the kind of a default integer as compiled in the MPI library, then I think everyone is happy.

1. Normal users declare MPI tag, src, dst, ... as regular integers requiring no change in coding.

2. Those who want to promote integers to something else will have to declare MPI tag, src, dst, ... as integer(MPI_INT_KIND) and then their codes will work fine as well.

Only those promoting integers are affected and the MPI-3 standard would provide a standard way for them to write standard compliant programs.

Craig Rasmussen Oct 30, 2009

Commenting on Doublas Guptill’s post.  I don’t really think the question at hand really depends on whether you are using a 32-bit or 64-bit system.  Could you be more specific.