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

Re: [MPI3 Fortran] Proposing changes to Fortran 2008
by Lionel, Steve 16 Mar '08

16 Mar '08

Jeff Squyres wrote: > I admit that I know so little about Fortran that much of your mail > went over my head. :-( But a question about the above: is it > possible to allow non-contiguous datatypes to be passed through > without having the compiler copy them into contiguous areas? It may > be possible, for example, for the MPI datatype to accurately describe > the non-contiguousness of the data, and MPI is well-equipped to handle > such situations. It is possible - but to do so in a standard-conforming way requires that the called routine be coded in Fortran. There is a proposal in front of the Fortran standards committee to enhance C interop to provide some standard way for C code to obtain the stride information. At present, there's not even a way for a Fortran routine to get this (the compiled code knows but there's no intrinsic to get that information.) The way this is done is for the explicit interface to declare the array as "assumed shape", for example A(:). The colon, in the absence of lower and upper bounds, tells the compiler to pass information regarding rank, size and stride. If the called routine has an assumed-shape dummy argument, the language requires that an explicit interface be visible to the caller. Amusingly, the called routine does NOT know the lower bound - if you pass an array declared as 2:5 it is received as 1:4 - a fact that trips up Fortran programmers all too frequently. Steve Lionel Intel

1 0

Re: [MPI3 Fortran] What if Fortran is the primary interface?
by Torsten Hoefler 14 Mar '08

14 Mar '08

Hi, > > It appears to me that the current proposal basically intends to pass > > data thru to the presumably existing C implementation layer. How will > > this work for an implementation where the Fortran binding is a primary > > one? > > > > I believe that at least NEC has followed this route. I'm adding Hubert > > Ritzdorf, in case he's accidentally not involved into this discussion > > yet, to verify NEC's position. > > I thought that NEC provided functions written in C that are callable > directly via Fortran. The code in the C MPI_Send and the "Fortran" > MPI_SEND was essentially the same C code -- the point of the design > was the avoid a second function call from the Fortran API functions. It seemed so to me too. > Do we really need to worry about [real] native Fortran MPI > implementations? I do not think that it would be useful to write a whole MPI library (or even big parts of it) in Fortran because it seems pretty hard to interface C-functions. And pretty much all system libraries are written in C (e.g., sockets). It would probably be possible to provide glue code (assembler/C) to use those functions from Fortran but certainly not easy. My personal opinion is that we should not worry/care about such an implementation. Best, Torsten -- bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ ----- Indiana University | http://www.indiana.edu Open Systems Lab | http://osl.iu.edu/ 150 S. Woodlawn Ave. | Bloomington, IN, 474045-7104 | USA Lindley Hall Room 135 | +01 (812) 855-3608

1 0

Re: [MPI3 Fortran] What if Fortran is the primary interface?
by Jeff Squyres 14 Mar '08

14 Mar '08

On Mar 14, 2008, at 8:24 PM, Supalov, Alexander wrote: > It appears to me that the current proposal basically intends to pass > data thru to the presumably existing C implementation layer. How will > this work for an implementation where the Fortran binding is a primary > one? > > I believe that at least NEC has followed this route. I'm adding Hubert > Ritzdorf, in case he's accidentally not involved into this discussion > yet, to verify NEC's position. I thought that NEC provided functions written in C that are callable directly via Fortran. The code in the C MPI_Send and the "Fortran" MPI_SEND was essentially the same C code -- the point of the design was the avoid a second function call from the Fortran API functions. Do we really need to worry about [real] native Fortran MPI implementations? -- Jeff Squyres Cisco Systems

1 0

Re: [MPI3 Fortran] Proposing changes to Fortran 2008
by Jeff Squyres 14 Mar '08

14 Mar '08

On Mar 12, 2008, at 5:24 PM, Aleksandar Donev wrote: > 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. I admit that I know so little about Fortran that much of your mail went over my head. :-( But a question about the above: is it possible to allow non-contiguous datatypes to be passed through without having the compiler copy them into contiguous areas? It may be possible, for example, for the MPI datatype to accurately describe the non-contiguousness of the data, and MPI is well-equipped to handle such situations. -- Jeff Squyres Cisco Systems

1 0

[MPI3 Fortran] What if Fortran is the primary interface?
by Supalov, Alexander 14 Mar '08

14 Mar '08

Hi everybody, It appears to me that the current proposal basically intends to pass data thru to the presumably existing C implementation layer. How will this work for an implementation where the Fortran binding is a primary one? I believe that at least NEC has followed this route. I'm adding Hubert Ritzdorf, in case he's accidentally not involved into this discussion yet, to verify NEC's position. Best regards. Alexander -- Dr Alexander Supalov Intel GmbH Hermuelheimer Strasse 8a 50321 Bruehl, Germany Phone: +49 2232 209034 Mobile: +49 173 511 8735 Fax: +49 2232 209029 --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

1 0

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

14 Mar '08

On Mar 10, 2008, at 1:26 PM, Harald Klimach wrote: >>>> Not really. You could send N COMPLEX items and receive N*2 REAL >> items. You can get more creative with C structs and Fortran derived >> types, with the already-mentioned restriction that you might (* see >> below) have to fall back to the F77 bindings for Fortran derived >> types. > > I thought we were talking about basic datatypes only. You obviously > can't provide explicit interfaces with type checking for all possible > Fortran derived types. We might be running into terminology issues here: MPI has COMPLEX as an intrinsic datatype (meaning that it's natively supported by MPI). That's what I meant. Regardless: the rule is that what you send in MPI must have an equivalent type map on the receiver, but the specific datatypes do not have to be the same. I agree that without user-defined MPI datatypes (since at least OMPI's current F90 implementation doesn't allow arbitrary derived types in the choice buffer arguments without falling back to the F77 bindings), this severely restricts the cases where datatypes do not match (more importantly, where the types of the choice buffer do not match) but type maps do. If derived types are allowed in the choice buffers, it gets more complicated (see below), and it's impossible to make a finite listing of overloaded functions. In Chicago this week, we pretty much decided that for the F90 bindings, almost every F90 compiler (if not all of them?) has a "void*"-like extension to ignore the type of a given parameter, and that might be good enough for current MPI implementations. It's bad for the MPI standard to rely on compiler extensions, but it does at least make the current F90 bindings salvageable. > I thought compatible type maps require you to have the same basic > types, and if it is allowed to change basic types from sender to > receiver I'm wondering what MPI1 3.3.1 is talking about, when it says: > Communication of typed values (e.g., with datatype different from > MPI_BYTE), where the datatypes of the corresponding entries in the > sender program, in the send call, in the receive call and in the > receiver program must all match. There are two main cases where this can occur: 1. C structs / F90 derived types where you could conceivably have two different datatypes with the same type map (or some combination of datatypes -- possibly even with N instances of datatype A and M instances of different datatype B, where N != M). 2. Using the various datatype pattern constructors to build datatypes with "holes" in them, but have the same number of data items. E.g., one datatype with 100 doubles, skipping every other one, and a 2nd datatype with 100 doubles, but skipping every two. Here's a wonky example: you could use MPI_SENDRECV to effect a memcpy in a single process from one memory pattern (datatype) to a different memory pattern (datatype). -- Jeff Squyres Cisco Systems

1 0

Re: [MPI3 Fortran] Proposing changes to Fortran 2008
by Lionel, Steve 14 Mar '08

14 Mar '08

Aleksandar Donev wrote: > 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 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. My opinion on this is that "type(c_void)" is not consistent with the Fortran language. I'd propose instead that a new VOID attribute be allowed in declarations of dummy arguments. The argument could be declared as having any type (INTEGER would do) - but a dummy with the VOID attribute would match any actual argument TKR (Type, Kind, Rank). Indeed, many commercial compilers already implement this concept, though each spells it differently (with some sort of comment-looking directive, such as Intel's !DEC$ ATTRIBUTES NO_ARG_CHECK). I feel that a VOID attribute is more natural to Fortran in that it does not require a special case for a specially named derived type (note that one ought to be able to write the module ISO_C_BINDING in Fortran (perhaps with some extensions), and we in fact do so.) I think this would also be easy for programmers to understand the correspondence with C's void (un)type. So with my proposal, the interface above would be written: interface subroutine mpi_send(buffer...) bind(c) integer, dimension(*), void :: buffer end subroutine end interface In this case, the dimension(*) is really there for the reader - the compiler ignores it. When used in a generic procedure declaration, VOID arguments match any TKR. Steve Lionel Developer Products Division Intel Corporation Nashua, NH

1 0

[MPI3 Fortran] Proposing changes to Fortran 2008
by Aleksandar Donev 12 Mar '08

12 Mar '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

1 0

[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

Re: [MPI3 Fortran] MPI-2.1: Fortran 90 bindings
by Harald Klimach 10 Mar '08

10 Mar '08

> >> It is required that the send and receive buffers have > >> compatible type > >> maps. See MPI-1:4.1: > > Note that this is the only requirement -- compatible type *maps*. Not > compatible *types*. > > > ... > > Not really. You could send N COMPLEX items and receive N*2 REAL > items. You can get more creative with C structs and Fortran derived > types, with the already-mentioned restriction that you might (* see > below) have to fall back to the F77 bindings for Fortran derived types. I thought we were talking about basic datatypes only. You obviously can't provide explicit interfaces with type checking for all possible Fortran derived types. I thought compatible type maps require you to have the same basic types, and if it is allowed to change basic types from sender to receiver I'm wondering what MPI1 3.3.1 is talking about, when it says: Communication of typed values (e.g., with datatype different from MPI_BYTE), where the datatypes of the corresponding entries in the sender program, in the send call, in the receive call and in the receiver program must all match. Most propably I'm understanding something wrong, but to my reading this should really disallow different basic types for sender and receiver. Best regards, Harald

1 0