On Mon, Mar 17, 2014 at 1:52 PM, Bill Long <[email protected]> wrote:
On Mar 17, 2014, at 1:39 PM, Junchao Zhang <[email protected]> wrote:
On Mon, Mar 17, 2014 at 11:52 AM, Craig Rasmussen <
[email protected]> wrote:
Jeff and I had a similar conversation last week. It is my viewpoint that the MPI-3 interfaces are formal interfaces that can be adapted by an implementation in a way that formally meets the specification.
+1 for this view.
For Open MPI I believe that Jeff will add configuration magic to check is INTEGER(C_INT) and default INTEGER have the same KIND value. This should be true for 100% of the compilers. If not, then that compiler will not be able to build Open MPI.
Supporting different INTEGER and c_int 1) is useless; 2) adds code complexity; 3) adds extra runtime overhead (in MPICH implementation) even when INTEGER and c_int are the same. I prefer stopping the support and doing configuration time check.
There is a problem with this approach. If the normal INTEGER and c_int are the same, then INTEGER compiled with a switch like -i8 is almost assured to be different from c_int. It is not that hard to write the module such that a single source can be used to compile both -i4 and -i8 versions. There should not be measurable overhead with this, since the checks are all on compile-time constants, so the checks and the "unused" branch of the test will be eliminated by the compiler.
The compiler eliminates the unused branch in an MPI implementation at the library build time. But later, you use a different sized INTEGER at user code compilation time (through mpif90 options?). That is erroneous. Why there is runtime overhead when INTEGER = c_int, see my previous reply to Rolf on comparison of designs with INTEGER MPI_Status or with INTEGER(c_int) MPI_Status.
Note that the -i4/-i8 problem is one of the arguments why using default INTEGER in the Fortran interfaces should have been prohibited by the MPI spec.
Cheers, Bill