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

Re: [MPI3 Fortran] What if Fortran is the primary interface?
by Craig Rasmussen 18 Mar '08

18 Mar '08

On Mar 17, 2008, at 4:05 PM, Aleksandar Donev wrote: > On Monday 17 March 2008 14:40, Jeff Squyres wrote: > >> Craig mentioned last week that if we have these opaque Fortran types >> (with their contents unspecified), that we could be guaranteed that >> their first member would be at the first byte of the instance. Sorry, I don't recall saying that. It's as Aleks says below, the guarantee is that it will conform to the equivalent C struct for the companion C compiler. Is struct foo { int i; } always equivalent to an int in C? I think the C calling convention treats them differently enough so that defining an MPI_HANDLE as a user defined type (essentially a C struct) with one integer component won't be guaranteed to work. In that case, we need the typealias Aleks so dearly wants :-) That was before my time on the committee so I don't have a horse in that race. Cheers, Craig

1 0

Re: [MPI3 Fortran] What if Fortran is the primary interface?
by Craig Rasmussen 18 Mar '08

18 Mar '08

On Mar 17, 2008, at 2:39 PM, Supalov, Alexander wrote: > Hi, > > Careful: quite a few implementations use INTEGER to represent a handle > as a bit mask, rather than a pointer. My test so far indicate that this works fine too. As I recall, type MPI_HANDLE private type(C_INT) :: handle end type MPI_HANDLE worked for those implementations. Since MPI_HANDLE is an opaque type, the implementer has freedom to define it as she wishes. Cheers, Craig > > Best regards. > > Alexander > > -----Original Message----- > From: mpi3-fortran-bounces(a)lists.mpi-forum.org > [mailto:[email protected]] On Behalf Of > Aleksandar Donev > Sent: Monday, March 17, 2008 9:04 PM > To: MPI-3 Fortran working group > Subject: Re: [MPI3 Fortran] What if Fortran is the primary interface? > > On Monday 17 March 2008 11:54, Hubert Ritzdorf wrote: > >> I have an additional question. Is this really guaranteed by the >> Fortran 2003 standard that >> type(MPI_COMM), bind(C), protected :: MPI_COMM_WORLD >> err = MPI_Recv (..., ..., MPI_COMM_WORLD, ...) >> in the same C Pointer such as the MPI_Comm MPI_COMM_WORLD ? > No, it is not. > >> My feeling is that it points to a structure containing the C pointer >> MPI_COMM_WORLD. > Exactly. One can put the VALUE attribute on the communicator dummy > argument, > which means that the communicator will be passed in whatever way > structs > are > passed by value (presumably put on the stack). Whether that is the > same > as > passing the actual pointer (without the enclosing struct) depends > on the > ABI, > I believe. > > On Monday 17 March 2008 12:53, Jeff Squyres wrote: >> FWIW, I don't think the 2-level indirection is necessary. > Depends on the details of the MPI implementation, and the ABI for > passing > arguments. > >> I think >> that Craig was trying to unify everything, but I would agree with >> Hubert: it would be better if MPI_COMM directly referred to whatever >> the Right stuff is in C. > What is the *set of Right things* accross implementations. Is a > plain C > pointer (void*) always good enough---then just make the argument > TYPE(C_PTR) > and pass a pointer instead of a struct containing a pointer. Do some > implementations use non-pointers, say a simple integer, for that > argument? > > Craig's scheme has two advantages: > 1) Uniform interface to MPI accross implementations---put inside the > struct > whatever you need (pointers, integers, etc.). > 2) Strong type-checking > BUT, it has the disadvantage that I don't think it is possible to > avoid > a > wrapper level of indirection to massage the arguments. Personally, I > don't > see that as a design goal: MPI internally surely will call dozens of > wrappers > until the actual work gets done? > > Best, > Aleks > _______________________________________________ > mpi3-fortran mailing list > mpi3-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran > --------------------------------------------------------------------- > 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. > > > _______________________________________________ > mpi3-fortran mailing list > mpi3-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran

1 0

Re: [MPI3 Fortran] What if Fortran is the primary interface?
by Craig Rasmussen 18 Mar '08

18 Mar '08

On Mar 17, 2008, at 1:53 PM, Jeff Squyres wrote: > FWIW, I don't think the 2-level indirection is necessary. I think > that Craig was trying to unify everything, but I would agree with > Hubert: it would be better if MPI_COMM directly referred to whatever > the Right stuff is in C. > Right. I don't have the two levels of indirection. I defined it as: type(MPI_HANDLE), protected, bind(C, name="ompi_mpi_comm_world_f") :: MPI_COMM_WORLD This seems to work in OpenMPI. Though perhaps not as I currently have to call mpi_init_f_c() after each MPI_Recv call. Somewhere the pointers are getting tromped on. Craig > In Open MPI's case, for example, the private member would be a pointer > to an ompi_communicator_t struct instance. > > > On Mar 17, 2008, at 2:54 PM, Hubert Ritzdorf wrote: > >> Hi Alexander, >> >> Jeff and Torsten are right. We have special implementations >> for frequently used Fortran functions. But this Fortran MPI >> functions are implemented in C. >> >> I think, that it will be difficult to convince real Fortran >> programmers >> by this C interface. They have to re-write main parts of the code. >> change it from Fortran Style into C Style and what is the benefit ? >> >> I have an additional question. Is this really guaranteed by the >> Fortran 2003 standard that >> >> type, bind(C) :: MPI_HANDLE >> private ! Components not visible >> type(C_PTR) :: HANDLE >> end type MPI_HANDLE >> >> type, bind(C) :: MPI_COMM >> private >> type(MPI_HANDLE) :: handle >> end type MPI_COMM >> >> type(MPI_COMM), bind(C), protected :: MPI_COMM_WORLD >> >> err = MPI_Recv (..., ..., MPI_COMM_WORLD, ...) >> in the same C Pointer such as the MPI_Comm MPI_COMM_WORLD ? >> My feeling is that it points to a structure containing the C pointer >> MPI_COMM_WORLD. >> >> Hubert >> >> Supalov, Alexander wrote: >>> 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. >>> >>> >>> >> _______________________________________________ >> mpi3-fortran mailing list >> mpi3-fortran(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran > > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > mpi3-fortran mailing list > mpi3-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran

1 0

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

18 Mar '08

On Mar 18, 2008, at 10:08 AM, Craig Rasmussen 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. > > I'm not sure I understand MPI datatypes to respond coherently, but > that's never stopped me before :-) > > I think you really want contiguous"ness", otherwise you wouldn't know > how to stride through the data with constant offsets. Right? No. MPI datatypes are a rich abstraction that allow the description of a variety of different layouts in memory (such as constant strides, etc.). Specifically: in C, there is no requirement for a contiguous buffer. As long as the accompanying MPI datatype accurately describes the buffer, you're good to go. This is one of the reasons that MPI requires a datatype argument -- because even though modern languages such as C++ and Fortran can derive a type from the buffer argument, what if the actual memory layout differs from that of the buffer argument type? For example: struct foo { char c; double d; } struct foo instance; MPI_Send(&instance->c, ...); What is passed is a pointer to a character. But what you really want to send is the whole struct (which likely has a big hole in its memory map). Likewise, the type in the following call doesn't tell anything to MPI, and an explicit datatype is required: MPI_Send(&instance, ...) And note that &instance == &instance->c. -- Jeff Squyres Cisco Systems

1 0

Re: [MPI3 Fortran] Proposing changes to Fortran 2008
by Craig Rasmussen 18 Mar '08

18 Mar '08

On Mar 14, 2008, at 6:29 PM, Jeff Squyres wrote: > 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. I'm not sure I understand MPI datatypes to respond coherently, but that's never stopped me before :-) I think you really want contiguous"ness", otherwise you wouldn't know how to stride through the data with constant offsets. Right? Cheers, Craig

1 0

Re: [MPI3 Fortran] Proposing changes to Fortran 2008
by Craig Rasmussen 18 Mar '08

18 Mar '08

On Mar 14, 2008, at 2:47 PM, Lionel, Steve wrote: > 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 >> >> > 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. > I note my suggestion earlier that in Aleks' proposal that c_void be treated much like c_ptr is now to allow the interface to be implementable in Fortran. > 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. > Unfortunately the integer declaration is just for show also. What is really meant in void :: buffer and everything else is just to get around the fact we can't have a void type in Fortran. This is why I like type(c_void) better as it explicitly refers to a C type unavailable without the iso_c_binding module. Cheers, Craig

1 0

Re: [MPI3 Fortran] Proposing changes to Fortran 2008
by Craig Rasmussen 18 Mar '08

18 Mar '08

On Mar 12, 2008, at 3:24 PM, Aleksandar Donev wrote: > Hello, > > I am just joining this group Welcome Aleks. > > 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 We discussed this at the MPI Forum meeting last week. In my opinion, unless we can get this fixed, users will revolt and not use the new interfaces as it may decrease performance. > 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. > I like this suggestion as it kill two birds with one stone: 1. It removes the need for explicit CLOCs at the call site; 2. More importantly, it allows semantic information to be provided in the interface about the usage of the void* pointer in a way that the CLOC indirection doesn't allow. If the target attribute isn't present, the burden is on the C implementor not to keep the pointer squirreled away someplace. However, I'm not sure about the copying if non- contiguous. I think it would be better if the user were forced to provide a contiguous array (same as your Isend example below). > 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. Why can't c_void be used like c_ptr is now so that the interface is bi-directional (implementable in either C or Fortran)? > > 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. > 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. > I've discussed the more natural solution with Jeff Squyres and he agrees that this can be done later. We can provide a "real" Fortran binding much like the C++ one. Cheers, Craig

1 0

Re: [MPI3 Fortran] What if Fortran is the primary interface?
by Hubert Ritzdorf 18 Mar '08

18 Mar '08

Hi, > BUT, it has the disadvantage that I don't think it is possible to avoid a > wrapper level of indirection to massage the arguments. Personally, I don't > see that as a design goal: MPI internally surely will call dozens of wrappers > until the actual work gets done? > > This is not true for our MPI versions; for example the MPI send calls for SX and Earth Simulator don't have any wrapper up to the assembler routine which is putting the data on the interconnect. And this is true also for the Fortran versions of send routines. And I would expect that the number of wrappers could become crucial if the clock frequency is reduced in future systems (in order to save energy). Hubert

1 0

Re: [MPI3 Fortran] What if Fortran is the primary interface?
by Craig Rasmussen 17 Mar '08

17 Mar '08

On Mar 14, 2008, at 6: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? A BIND(C) interface specifies the interface only. The implementation can be either in Fortran or C. Regards, Craig

1 0

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

17 Mar '08

On Mar 17, 2008, at 6:05 PM, Aleksandar Donev wrote: > In C, would you make the C Interface: > > void MPI_Send(..., struct MPI_Comm comm,...) This. > or do you want > > void MPI_Send(..., struct MPI_Comm *comm,...) Not this. In C, the type of MPI_Comm is not defined. For example, Open MPI and HP MPI use pointers (natively), but Intel MPI, MPICH, and others use int's. > Either one of these could be translated into an *equivalent* Fortran > interface, where by equivalence I mean full binary compatibility. Yes, the ABI problem really stems from the C interface. :-\ -- Jeff Squyres Cisco Systems

1 0