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

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

17 Mar '08

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. If the type has the BIND(C) attribute, which it should, then it has exactly the same layout as a C struct would with the same members in the same order. So whatever C99 guarantees or does not guarantee applies (check the C standard :-). If it is not a BIND(C) datatype then there are no guarantees of any sort. In C, would you make the C Interface: void MPI_Send(..., struct MPI_Comm comm,...) or do you want void MPI_Send(..., struct MPI_Comm *comm,...) ? Either one of these could be translated into an *equivalent* Fortran interface, where by equivalence I mean full binary compatibility. Aleks

1 0

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

17 Mar '08

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. Hence, if we have MPI implementation X that uses pointers for MPI handles in C, if MPI X's Fortran MPI_COMM type has a single member that is a C_PTR, I was under the impression that we could still have a translation-less implementation (i.e., the Fortran compiler would do all the translation -- no work on the MPI side would be needed). Is that correct? On Mar 17, 2008, at 5:29 PM, Aleksandar Donev wrote: > On Monday 17 March 2008 14:21, Jeff Squyres wrote: >> For >> ABI reasons, you are likely correct that we *will* need to mandate >> what is in the Fortran MPI_COMM. > Well, the first step is to mandate what MPI_COMM is, and then talk > about what > it contains. You cannot leave it undefined as it is in the C > bindings (I am > only familiar with MPI-2 bindings) and let the C headers actually > say what it > is. In Fortran, you must say if it is a scalar or array, what type > it is, > etc. Saying it is a derived type with private components is fine > with me. But > that decision may impose massaging in a wrapper to get the guts of > that > derived type container out of the container, on most implementations. > Thanks, > Aleks > > _______________________________________________ > 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

1 0

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

17 Mar '08

Hi, Thanks. You probably meant TYPEALIAS :: MPI_COMM=>INTEGER(KIND=INT32) ! Handles are integers Because this is what they are in those implementations. By the way, MPI_FILE there is a pointer. I'm talking about MPICH2 and friends here (including MS MPI and Intel MPI). 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 10:24 PM To: MPI-3 Fortran working group Subject: Re: [MPI3 Fortran] What if Fortran is the primary interface? On Monday 17 March 2008 13:39, Supalov, Alexander wrote: > Careful: quite a few implementations use INTEGER to represent a handle > as a bit mask, rather than a pointer. The best way to handle this kind of argument, IMO, is a type alias (typedef). In C that is handled by the preprocessor and so it is essentially a macro, but in Fortran it would have to be built-in. It was part of Fortran 2003 until the very last minute, when it was pulled out due to alleged "technical problems" (as you can tell I did not buy that---this was from language purists that simply did not want a typedef-like facility in the language). The MPI Forum could request this be added in Fortran 2008 for the purposes of interop. I could help you write the technical specification: TYPEALIAS :: MPI_COMM=>TYPE(C_PTR) ! Handles are pointers, or TYPEALIAS :: MPI_COMM=>INTEGER(KIND=INT64) ! Handles are integers Best, Aleks -- Aleksandar Donev, Ph.D. Lawrence Postdoctoral Fellow @ Lawrence Livermore National Laboratory 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 _______________________________________________ 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.

1 0

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

17 Mar '08

On Monday 17 March 2008 14:21, Jeff Squyres wrote: > For ï¿½ > ABI reasons, you are likely correct that we *will* need to mandate ï¿½ > what is in the Fortran MPI_COMM. Well, the first step is to mandate what MPI_COMM is, and then talk about what it contains. You cannot leave it undefined as it is in the C bindings (I am only familiar with MPI-2 bindings) and let the C headers actually say what it is. In Fortran, you must say if it is a scalar or array, what type it is, etc. Saying it is a derived type with private components is fine with me. But that decision may impose massaging in a wrapper to get the guts of that derived type container out of the container, on most implementations. Thanks, Aleks

1 0

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

17 Mar '08

On Monday 17 March 2008 13:39, Supalov, Alexander wrote: > Careful: quite a few implementations use INTEGER to represent a handle > as a bit mask, rather than a pointer. The best way to handle this kind of argument, IMO, is a type alias (typedef). In C that is handled by the preprocessor and so it is essentially a macro, but in Fortran it would have to be built-in. It was part of Fortran 2003 until the very last minute, when it was pulled out due to alleged "technical problems" (as you can tell I did not buy that---this was from language purists that simply did not want a typedef-like facility in the language). The MPI Forum could request this be added in Fortran 2008 for the purposes of interop. I could help you write the technical specification: TYPEALIAS :: MPI_COMM=>TYPE(C_PTR) ! Handles are pointers, or TYPEALIAS :: MPI_COMM=>INTEGER(KIND=INT64) ! Handles are integers Best, Aleks -- Aleksandar Donev, Ph.D. Lawrence Postdoctoral Fellow @ Lawrence Livermore National Laboratory 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

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

17 Mar '08

On Mar 17, 2008, at 4:03 PM, Aleksandar Donev 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. My point (poorly stated) was that the MPI standard only needs to mandate that the type MPI_COMM needs to exist (for example). It doesn't need to standardize what it is in it, nor whether a 2nd level of indirection is necessary. Some MPI's may want/need that 2nd level, others may not -- that should be an implementation-level decision. That being said, ABI adds a whole new level of complexity here. For ABI reasons, you are likely correct that we *will* need to mandate what is in the Fortran MPI_COMM. But the ABI committee has purposefully excluded the Fortran bindings in its first round of discussions (which I personally think is a mistake ;-) ). So unless something changes there, it's probably not worthwhile to discuss ABI ramifications on the Fortran bindings. Indeed, the semantics of which approach are going to be used for the ABI have not yet been decided, so what we decide today (for Fortran ABI) may be irrelevant tomorrow. Just my $0.02... -- Jeff Squyres Cisco Systems

1 0

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

17 Mar '08

Hi, Careful: quite a few implementations use INTEGER to represent a handle as a bit mask, rather than a pointer. 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.

1 0

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

17 Mar '08

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

1 0

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

17 Mar '08

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. 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

1 0

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

17 Mar '08

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. > > >

1 0