Jeff - The statement in the standard should allow an MPI implementation the option of leaving out checking for MPI functions with single or double CHOICE buffers but should not say they "are explicitly not included in the F90 bindings.". It is possible that even 5,250 functions would be a problem on some Fortran compilers and an implementation that has to deal with such a compiler may wish to provide checking for the MPI subroutines that do not have any CHOICE arguments but skip even the 5250 functions for single CHOICE. Some Fortran compilers have non-standard features that allow a formal parameter to be declared as what amounts to void* and with that compile feature, CHOICE becomes easy. An MPI implementation that is based on a Fortran compiler with this feature could check even double CHOICE easily. Dick Dick Treumann - MPI Team/TCEM IBM Systems & Technology Group Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 mpi-21-bounces_at_[hidden] wrote on 03/05/2008 09:15:35 PM:

The current MPI-2 F90 bindings are un-implementable because they require almost 7 *million* interface functions: with 15 intrinsic Fortran types, each with 7 possible dimensions, the current F90 interface *requires*:

- 50 MPI functions with one choice buffer: 15 * 7 * 50 = 5,250 functions - 25 MPI functions with two choice buffers: (15 * 7 * 25)^2 = 6.8M functions - ...and a few hundred more MPI functions with no choice buffers

This is clearly broken.

An MPI-2.1-worthy solution could be to add a global statement saying that MPI functions with two choice buffers are explicitly not included in the F90 bindings. F90 MPI applications can transparently fall back to the F77 bindings (although they won't get the strong type checking, etc.). This idea therefore fits the requirement of not breaking any existing MPI codes.

Specifically: if we remove the requirement to provide all MPI functions with two choice buffers, 5,000+ F90 interface functions is [a pain but] implementable. I doubt that any current MPI implementation provides more than the no-choice-buffers plus one- choice-buffer functions anyway...

If this seems like a good idea, I can write a proper proposal for it. Comments?

-- Jeff Squyres Cisco Systems

_______________________________________________ mpi-21 mailing list mpi-21_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-21

*