March 2008 - mpiwg-fortran - mailman3.cels.anl.gov

[MPI3 Fortran] Proposing changes to Fortran 2008
by Aleksandar Donev 22 Apr '08

22 Apr '08

Hello, I am just joining this group so forgive me for not having the full background. I am a member of the J3 committee and in discussions with Craig we think it would be great if this group comes up with a specific proposal on changes needed to the Fortran standard to construct a nice interface to MPI. Sorry for the long missive. The main issue is the handling of the void* arguments and avoiding the issues with type-kind-rank (TKR) matching between actuals and dummies. The first step in any proposal to J3 is to argue that what was already put in Fortran 2003 with C Interop is insufficient. Here is my argument, but other things can be added. The mechanism for passing void* pointers is scalar arguments of type C_PTR. At the call site, C_LOC is used to get the address: CALL MPI_Send(C_LOC(buffer)...) The issues with this are: 1) buffer must have the TARGET attribute, affecting performance and existing codes 2) one must add C_LOC at every call site, thus affecting existing codes. Number 1 is very serious, IMO. It cannot be relaxed without compromising the standard's internal consistency. So a new mechanism is needed. A possible solution is something like: interface subroutine mpi_send(buffer...) bind(c) type(c_void), dimension(*) :: buffer end subroutine end interface or interface subroutine mpi_send(buffer,N,...) bind(c) integer :: N type(c_void), dimension(N) :: buffer end subroutine end interface The actual must be of interoperable type. The argument association rules are the same as for "normal" arrays (for example, in the first case the association is with all of the elements of the actual, in the second with the first N elements, the actual can be of higher rank, etc.). In particular, if the actual is not contiguous, a contiguous copy will be made at the call site. The corresponding C routine must have a void* argument. The important thing here, which will be objected to in J3, is that such a type(c_void) argument can only appear in bind(c) interfaces for an assumed-size or explicit-shape array (we can discuss extensions to assumed-shape arrays later...we are working on a TR for that). One cannot write an actual Fortran routine that has a dummy with no type since it is ill-defined what that means in Fortran. This is not the case with existing Fortran---interfaces merely repeat what can be written in Fortran and any BIND(C) routine may be written in either C or Fortran. Bill Long has proposed that the syntax BIND(C,LANG="C99") be used for the new type of interface blocks. For non-blocking sends, a pointer to the actual must be retained. This requires matching TARGET attributes on *both* the dummy and actual: interface subroutine mpi_Isend(buffer...) bind(c) type(c_void), dimension(*), target :: buffer end subroutine end interface integer(c_int), target :: x(100) call mpi_Isend(x...) For the call to actually work as expected, the actual must be contiguous (this is a new defined term in Fortran 2008 with some intrinsics to test is an array is contiguous) and have the target attribute, and must be of interoperable type. This approach would allow one to construct a Fortran interface to MPI that emulates the C interface closely. One more useful thing are TYPEALIASes, which were supposed to be in F2003 but were pulled out at the last minute. I think that things like MPI_Datatype should be type aliases instead of opaque derived types. But this is not that serious. An alternative is to construct a Fortran interface to MPI that actually uses the full power of Fortran, rather then using the (IMHO) very low-level and very annoying to use in practice C interface. For example, a call to MPI_Send includes redundant information about the type and size of the buffer. This info is known to the compiler from the actual argument and can be automatically provided by the compiler thus increasing safety and usability greatly. This is done in Fortran using array descriptors, which contain info about the TKR of the array. My dream interface to MPI_Send would be something like: interface subroutine mpi_send(buffer...) class(*), dimension() :: buffer end subroutine end interface This would pass a descriptor to the C routine, which can then get the TKR info from it and call the low-level MPI routine. This is more for the future. I think getting the simple "no TKR matching" is more focused and important for now. Best, Aleks -- Aleksandar Donev, Ph.D. Lawrence Postdoctoral Fellow @ LLNL High Performance Computational Materials Science and Chemistry E-mail: donev1(a)llnl.gov Phone: (925) 424-6816 Fax: (925) 423-0785 Address: P.O.Box 808, L-367, Livermore, CA 94551-9900 Web: http://cherrypit.princeton.edu/donev

6 55

[MPI3 Fortran] MPI-2.1: Fortran 90 bindings
by Jeff Squyres 18 Mar '08

18 Mar '08

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

8 48

[MPI3 Fortran] Notes from Chicago meeting
by Jeff Squyres 11 Mar '08

11 Mar '08

I took a few [sparse] notes from the meeting today and put them on the wiki (I didn't capture the lunch conversation): http://svn.mpi-forum.org/trac/mpi-forum-web/wiki/FtnWikiPage Please feel free to edit with things that I missed. -- Jeff Squyres Cisco Systems

1 0

[MPI3 Fortran] Is the concall number working?
by Terry Dontje 06 Mar '08

06 Mar '08

I just tried the 866-736-2112 number Jeff sent out yesterday and it seems to not work for me. --td

1 1

[MPI3 Fortran] Start discussing new Fortran binding
by Craig E. Rasmussen 05 Mar '08

05 Mar '08

I propose that we have a phone call next week sometime to begin to discuss potential new Fortran bindings. I have put some ideas on the wiki as a starting point for discussion (text copied below). I'll add more in the next couple of days. Cheers, Craig ------------------ ! import C interop and MPI interfaces use, intrinsic :: ISO_C_BINDING use :: MPI_C_BINDING ! this needs to be given a name integer(C_INT) :: rank, size, err ! this module needs to be given a size (C_INT here) ! I think we should provide better interfaces to command line arguments. ! It can be done through GET_COMMAND and GET_COMMAND_ARGUMENT. ! MPI_Init should be able to pass back something like modified C argc and argv arguments. err = MPI_Init() ! We need to figure out the type of MPI handles. ! Currently I'm leaning toward TYPE(C_PTR) rather than ! the INTEGER(MPI_HANDLE_KIND) Jeff and I used in our paper. err = MPI_Comm_rank(MPI_COMM_WORLD, rank) err = MPI_Comm_size(MPI_COMM_WORLD, size) err = MPI_Finalize()

4 15

[MPI3 Fortran] Con call?
by Jeff Squyres 03 Mar '08

03 Mar '08

Craig -- Where are we on having a teleconf? Thanks. -- Jeff Squyres Cisco Systems

4 10