As many of you know, I’m an active member of the MPI Forum. We have recently completed MPI-2.2 and have shifted our sights to focus on MPI-3.
For some inexplicable reason, I’ve become heavily involved in the MPI-3 Fortran working group. There are some well-known problems with the MPI-2 Fortran 90 interfaces; the short version of the MPI-3 Fortran WG’s mission is to “fix those problems.”
A great summary of what the Fortran WG is planning for MPI-3 is available on the Forum wiki page; we’d really appreciate feedback from the Fortran MPI developer community on these ideas.
There is definitely one significant issue that we need feedback from the community before making a decision. Craig Rasmussen from Los Alamos National Laboratory asked me to post the following “request for information” to the greater Fortran MPI developer community. Please send feedback either via comments on this blog entry, email to me directly, or to the MPI-3 Fortran working group mailing list.
The Fortran working group has made substantial progress in completing its goal of creating new Fortran bindings for MPI-3 that fix major problems in calling MPI from Fortran. However, there is still an issue that needs to be resolved — we need community feedback before making a decision.
Currently, MPI-2 integer arguments like source, destination, and tag are default Fortran integers. Perhaps it is time to revisit the size of integer arguments in light of two issues:
- Interoperability with the underlying MPI implementation in C. While integers are likely to be the same size between Fortran and C, they are not required to be, and therefore it might be wise to provide a finer level of control by specifying the precise size (Fortran kind parameter) in MPI-3 Fortran interfaces.
- 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.
Because this decision could potentially have a large impact on the MPI Fortran community, we would like to get as much feedback from the community as possible. We have outlined three options below:
1. Retain the status quo and use default integers, e.g.,
integer :: src, dest, tag
- Pros: No integer kind changes need be made to existing codes to migrate to using the MPI-3 interfaces. Minimal implementation problems for MPI vendors.
- Cons: The issue with using nonstandard compiler options that promote integers to long integers remains a problem.
2. Specify a named kind such as “MPI_INT_KIND”, e.g.,
integer(MPI_INT_KIND) :: src, dest, tag
- Pros: This provides the most specificity and users will have a known way to code that will work under all circumstances, including the use of compiler flags that promote integers. Vendors can easily provide interfaces that interoperate with C.
- Cons: MPI_INT_KIND will likely specify default integers and so existing codes will work in most circumstances. However, to conform to the MPI-3 standard, users would have to modify their code to specifically declare the kind parameter for MPI integers as shown above.
3. Rather than a specific interface, MPI-3 could provide a generic interface so that calls to MPI will take any integer kind.
- Pros: This option works when integers are promoted and doesn’t break existing codes.
- Cons: In practice a truly generic interface for all possibly combinations of integer kinds couldn’t be provided. Likely the best vendors could do would be to provide two generic interfaces, one that uses default integers and one that uses long integers (users can mix integer sizes in one MPI call).
Note: While option 1 doesn’t directly address the integer promotion problem, there is no reason the vendor couldn’t provide option 3 as part of a “quality of implementation” or deal with integer promotion in some other way. Since integer promotion is not part of the Fortran standard (there are now better and standard ways in Fortran to accomplish the same thing), should the MPI-3 Fortran standard try to work around something that is non-standard Fortran?