October 2008 - Mpi-22 - mailman3.cels.anl.gov

Re: [Mpi-22] Should all constants/types beavailablein all languagebindings?
by unknown＠example.com 24 Oct '08

24 Oct '08

Hi, Yes, it appears that if p483:46-47 are to be interpreted literally, any implementation that does not provide all datatypes in all languages will be non-compliant with MPI-2.1. More on this below. For now, a bit of fun: Re C handle produced out of the Fortran MPI_REAL - imagine it's MPI_FLOAT. Will anything change for the MPI_Send? Probably, no. The datatype signature would be different if the struct was created directly in Fortran, but the MPI_Send would not suffer a jot. Re MPI_Fint, C++ defines to many C++ entities that have C equivalents, like MPI::REAL, MPI::SEEK_SET, etc. Why should the user rely on MPI_Fint then? More generally, where is the boundary between the C++ and C interfaces, or, how much of C++ should really look like C++? So far I was pulling your let a little. Now it's getting serious. There are four things to consider: 1) Language independent datatype definition - say, MPI_INTEGER (see p27:13). 2) Language binding for the datatype handle representing 1) in actual programs - say, C MPI_Datatype MPI_INTEGER, C++ MPI::INTEGER, and Fortran INTEGER MPI_INTEGER. 3) Internal representation of the MPI datatype inside the MPI library referenced by 1) and 2). 4) Actual format of the data in memory defined by the language and platform, and referenced by 1), 2), and 3). Note that distinction between 1) and 2) sort of justifies existence of so specifically C++ binding MPI::INTEGER for otherwise mundane entities in C and Fortran. The argument for MPI::Fint arises from this observation: if we started to do things C++ way, let's stick to this. And what I was talking about re example in p483 was basically a play between 2) and 4): what is different for the user may actually be the same thing for the platform, in this case - typically a machine word interpreted as a real value. See p. 490 for an acknowledgement of this fact (about nonportable possibility to receive MPI_INTEGER as an MPI_INT). Finally, at the moment a part of the standard (see pp. 27-28) does not seem to differentiate clearly between 1) and 2), while another part (see pp. 483-484) talks about making 1) available in all languages thru 2), and Appendix (pp 494-495) serves as the only definition of the datatype equivalence. This, in addition to practical aspects mentioned in earlier messages, is probably why so many implementations are noncompliant with MPI-2.1. Best regards. Alexander -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Friday, October 24, 2008 9:13 PM To: MPI 2.2 Subject: Re: [Mpi-22] Should all constants/types beavailablein all languagebindings? On Oct 24, 2008, at 2:03 PM, Supalov, Alexander wrote: > If this requirement is to be interpreted literally, then yes, the > standard must define all datatypes in all languages. However, the > example following this statement shows how an MPI_REAL is transformed > into an equivalent C data type. Whether or not this is indeed MPI_REAL > is not clear. It may well be an MPI_FLOAT. I'm not sure what you mean -- Example 16.16 shows making a combined datatype with 1 C int and the 5 Fortran REALs. The C code never tries to use the values in the R array; it just MPI_SEND's them. Using the MPI_REAL type passed up from Fortran is the right thing to do here (vs. using MPI_FLOAT). Alternatively, if the C code knew that the buffer was 5 reals, it wouldn't need to have a type passed in from Fortran -- just the buffer. Then it could TYPE_CREATE_STRUCT with MPI_INT and MPI_REAL and send using the resulting datatype. That's exactly why the datatypes are supposed to be defined in all languages, right? Not for dereferencing, but for sending/receiving data that originally came from another language. The way I read Hubert's text (p483:46-47), none of us are 2.1 compliant because we don't offer *all* the datatypes in all languages. Right? > By the way, this example shows that MPI::Fint may be necessary: > MPI_Fint > is used here to pass Fortran datatype thru the C function boundary. > Imagine a C++ function. There was a ticket #4 calling for removal of > the > MPI::Fint until it was redefined. Why not use MPI_Fint? -- Jeff Squyres Cisco Systems _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- 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: [Mpi-22] Should all constants/types be availablein all languagebindings?
by unknown＠example.com 24 Oct '08

24 Oct '08

On Oct 24, 2008, at 2:03 PM, Supalov, Alexander wrote: > If this requirement is to be interpreted literally, then yes, the > standard must define all datatypes in all languages. However, the > example following this statement shows how an MPI_REAL is transformed > into an equivalent C data type. Whether or not this is indeed MPI_REAL > is not clear. It may well be an MPI_FLOAT. I'm not sure what you mean -- Example 16.16 shows making a combined datatype with 1 C int and the 5 Fortran REALs. The C code never tries to use the values in the R array; it just MPI_SEND's them. Using the MPI_REAL type passed up from Fortran is the right thing to do here (vs. using MPI_FLOAT). Alternatively, if the C code knew that the buffer was 5 reals, it wouldn't need to have a type passed in from Fortran -- just the buffer. Then it could TYPE_CREATE_STRUCT with MPI_INT and MPI_REAL and send using the resulting datatype. That's exactly why the datatypes are supposed to be defined in all languages, right? Not for dereferencing, but for sending/receiving data that originally came from another language. The way I read Hubert's text (p483:46-47), none of us are 2.1 compliant because we don't offer *all* the datatypes in all languages. Right? > By the way, this example shows that MPI::Fint may be necessary: > MPI_Fint > is used here to pass Fortran datatype thru the C function boundary. > Imagine a C++ function. There was a ticket #4 calling for removal of > the > MPI::Fint until it was redefined. Why not use MPI_Fint? -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi-22] Should all constants/types be availablein all languagebindings?
by unknown＠example.com 24 Oct '08

24 Oct '08

Hi, If this requirement is to be interpreted literally, then yes, the standard must define all datatypes in all languages. However, the example following this statement shows how an MPI_REAL is transformed into an equivalent C data type. Whether or not this is indeed MPI_REAL is not clear. It may well be an MPI_FLOAT. By the way, this example shows that MPI::Fint may be necessary: MPI_Fint is used here to pass Fortran datatype thru the C function boundary. Imagine a C++ function. There was a ticket #4 calling for removal of the MPI::Fint until it was redefined. Best regards. Alexander -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Hubert Ritzdorf Sent: Friday, October 24, 2008 6:30 PM To: MPI 2.2 Subject: Re: [Mpi-22] Should all constants/types be availablein all languagebindings? Jeff Squyres wrote: > You're right, I was not checking 2.1 implementations. > > While 2.1 changelog item 2 does specifically mention those constants > in all 3 languages, what about the other datatypes? (e.g., MPI_INT vs. > MPI_INTEGER, etc.?) > MPI-2.1 Section 16.3.6 MPI Opaque Objects, page 483, lines 46-47: "All predefined datatypes can be used in datatype constructors in any language." --------------------------------------------------------------------- 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: [Mpi-22] Should all constants/types be available in all languagebindings?
by unknown＠example.com 24 Oct '08

24 Oct '08

Jeff Squyres wrote: > You're right, I was not checking 2.1 implementations. > > While 2.1 changelog item 2 does specifically mention those constants > in all 3 languages, what about the other datatypes? (e.g., MPI_INT vs. > MPI_INTEGER, etc.?) > MPI-2.1 Section 16.3.6 MPI Opaque Objects, page 483, lines 46-47: "All predefined datatypes can be used in datatype constructors in any language." *

1 0

Re: [Mpi-22] Should all constants/types be available in all languagebindings?
by unknown＠example.com 24 Oct '08

24 Oct '08

You're right, I was not checking 2.1 implementations. While 2.1 changelog item 2 does specifically mention those constants in all 3 languages, what about the other datatypes? (e.g., MPI_INT vs. MPI_INTEGER, etc.?) Per Alexander's comments: 1. Why would we artificially limit what types can be accessed from each language? "Probably never" is not really the same thing as "never." It may not be probable, but it is conceivable that a C++ program could call a Fortran computational library -- perhaps the C++ program is essentially the "driver" for a master/worker model, and the Fortran computational library is what does the back-end work. Exporting new handles for already-existing MPI objects to a specific implementation's language bindings is not a lot of work. 2. Regardless of which way we go, I think that the standard should be explicit about which constants are available in which language. Otherwise, codes have the danger of not being source code compatible if different implementations make different decisions. On Oct 24, 2008, at 9:43 AM, Hubert Ritzdorf wrote: > Hi, > > as far as I remember it was cleared in the MPI 2.1 > standardization process that "all" datatypes have to be > defined in all 3 languages. > Changelog item 2 requires this explicitly for MPI_LONG_LONG, > MPI_LONG_LONG_INT, ... > (But I think that some C++ datatypes are missing since there wasn't > defined a name). > > Possibly, Jeff is not referencing MPI 2.1 implementations. > > Supalov, Alexander wrote: >> Hi, >> >> I think we should answer the following questions to decide whether >> and >> how to define the constants: >> >> 1. When would a C MPI program call Fortran MPI subprogram? Probably, >> never. >> 2. When would a Fortran MPI program call a C MPI subprogram? >> Sometimes. >> 3. When would a C++ MPI program call Fortran MPI program? Probably, >> never. >> > I don't agree. I know some programs of this kind. > > Hubert >> 4. When would a Fortran MPI program call a C++ MPI program? Probably, >> never. >> >> Here, "subprogram" means a part of program that relies on the MPI >> use or >> knowledge of MPI datatypes, etc. This may or may not be a direct call >> into the respective MPI library. >> >> >From this, what is needed is to define Fortran datatypes from >> mpif.h in >> C mpi.h. The rest does not seem relevant. Even the existing C++ >> definitions may just reflect C heritage. >> >> Best regards. >> >> Alexander >> >> -----Original Message----- >> From: mpi-22-bounces_at_[hidden] >> [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres >> Sent: Thursday, October 23, 2008 10:13 PM >> To: MPI 2.2 >> Subject: [Mpi-22] Should all constants/types be available in all >> languagebindings? >> >> I notice that OMPI, MPICH2, Intel MPI, and HP MPI all do the >> following: >> >> * define Fortran datatypes in mpi.h (e.g., MPI_INTEGER, MPI_DOUBLE) >> * define Fortran datatypes in the C++ MPI namespace (e.g., >> MPI::INTEGER, MPI::DOUBLE, etc.) >> * do *not* define C datatypes in mpif.h (e.g., MPI_INT, >> MPI_FLOAT, etc.) >> >> Why? AFAICT, there is no rule about what constants have to appear >> in which language bindings. But doesn't that implicitly mean that >> all constants are supposed to appear in all language bindings? >> >> (the argument for having MPI_DOUBLE available in C, for example, >> is that a C routine may be invoked to send or receive a message >> containing Fortran data. Similar arguments exist for why you'd >> want MPI datatypes from other languages available in your language) >> >> This is also related to whether the type MPI::Fint should exist or >> not. >> >> I just filed a ticket about these issues >> (https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/56 ) and >> marked it as "feedback requested", meaning that I need feedback >> from the Forum before a proposal can be made. >> >> What do people think? >> >> > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi-22] Should all constants/types be available inall languagebindings?
by unknown＠example.com 24 Oct '08

24 Oct '08

Thanks. We can surely define all datatypes everywhere in MPI-2.2. It appears however that the current arrangement, with Fortran types defined in C and C++, may be adequate. -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Hubert Ritzdorf Sent: Friday, October 24, 2008 3:43 PM To: MPI 2.2 Subject: Re: [Mpi-22] Should all constants/types be available inall languagebindings? Hi, as far as I remember it was cleared in the MPI 2.1 standardization process that "all" datatypes have to be defined in all 3 languages. Changelog item 2 requires this explicitly for MPI_LONG_LONG, MPI_LONG_LONG_INT, ... (But I think that some C++ datatypes are missing since there wasn't defined a name). Possibly, Jeff is not referencing MPI 2.1 implementations. Supalov, Alexander wrote: > Hi, > > I think we should answer the following questions to decide whether and > how to define the constants: > > 1. When would a C MPI program call Fortran MPI subprogram? Probably, > never. > 2. When would a Fortran MPI program call a C MPI subprogram? Sometimes. > 3. When would a C++ MPI program call Fortran MPI program? Probably, > never. > I don't agree. I know some programs of this kind. Hubert > 4. When would a Fortran MPI program call a C++ MPI program? Probably, > never. > > Here, "subprogram" means a part of program that relies on the MPI use or > knowledge of MPI datatypes, etc. This may or may not be a direct call > into the respective MPI library. > > >From this, what is needed is to define Fortran datatypes from mpif.h in > C mpi.h. The rest does not seem relevant. Even the existing C++ > definitions may just reflect C heritage. > > Best regards. > > Alexander > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] > [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres > Sent: Thursday, October 23, 2008 10:13 PM > To: MPI 2.2 > Subject: [Mpi-22] Should all constants/types be available in all > languagebindings? > > I notice that OMPI, MPICH2, Intel MPI, and HP MPI all do the following: > > * define Fortran datatypes in mpi.h (e.g., MPI_INTEGER, MPI_DOUBLE) > * define Fortran datatypes in the C++ MPI namespace (e.g., > MPI::INTEGER, MPI::DOUBLE, etc.) > * do *not* define C datatypes in mpif.h (e.g., MPI_INT, MPI_FLOAT, > etc.) > > Why? AFAICT, there is no rule about what constants have to appear in > which language bindings. But doesn't that implicitly mean that all > constants are supposed to appear in all language bindings? > > (the argument for having MPI_DOUBLE available in C, for example, is > that a C routine may be invoked to send or receive a message > containing Fortran data. Similar arguments exist for why you'd want > MPI datatypes from other languages available in your language) > > This is also related to whether the type MPI::Fint should exist or not. > > I just filed a ticket about these issues > (https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/56 > ) and marked it as "feedback requested", meaning that I need feedback > from the Forum before a proposal can be made. > > What do people think? > > --------------------------------------------------------------------- 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: [Mpi-22] Should all constants/types be available in all languagebindings?
by unknown＠example.com 24 Oct '08

24 Oct '08

Hi, as far as I remember it was cleared in the MPI 2.1 standardization process that "all" datatypes have to be defined in all 3 languages. Changelog item 2 requires this explicitly for MPI_LONG_LONG, MPI_LONG_LONG_INT, ... (But I think that some C++ datatypes are missing since there wasn't defined a name). Possibly, Jeff is not referencing MPI 2.1 implementations. Supalov, Alexander wrote: > Hi, > > I think we should answer the following questions to decide whether and > how to define the constants: > > 1. When would a C MPI program call Fortran MPI subprogram? Probably, > never. > 2. When would a Fortran MPI program call a C MPI subprogram? Sometimes. > 3. When would a C++ MPI program call Fortran MPI program? Probably, > never. > I don't agree. I know some programs of this kind. Hubert > 4. When would a Fortran MPI program call a C++ MPI program? Probably, > never. > > Here, "subprogram" means a part of program that relies on the MPI use or > knowledge of MPI datatypes, etc. This may or may not be a direct call > into the respective MPI library. > > >From this, what is needed is to define Fortran datatypes from mpif.h in > C mpi.h. The rest does not seem relevant. Even the existing C++ > definitions may just reflect C heritage. > > Best regards. > > Alexander > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] > [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres > Sent: Thursday, October 23, 2008 10:13 PM > To: MPI 2.2 > Subject: [Mpi-22] Should all constants/types be available in all > languagebindings? > > I notice that OMPI, MPICH2, Intel MPI, and HP MPI all do the following: > > * define Fortran datatypes in mpi.h (e.g., MPI_INTEGER, MPI_DOUBLE) > * define Fortran datatypes in the C++ MPI namespace (e.g., > MPI::INTEGER, MPI::DOUBLE, etc.) > * do *not* define C datatypes in mpif.h (e.g., MPI_INT, MPI_FLOAT, > etc.) > > Why? AFAICT, there is no rule about what constants have to appear in > which language bindings. But doesn't that implicitly mean that all > constants are supposed to appear in all language bindings? > > (the argument for having MPI_DOUBLE available in C, for example, is > that a C routine may be invoked to send or receive a message > containing Fortran data. Similar arguments exist for why you'd want > MPI datatypes from other languages available in your language) > > This is also related to whether the type MPI::Fint should exist or not. > > I just filed a ticket about these issues > (https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/56 > ) and marked it as "feedback requested", meaning that I need feedback > from the Forum before a proposal can be made. > > What do people think? > > *

1 0

Re: [Mpi-22] Should all constants/types be available in all languagebindings?
by unknown＠example.com 24 Oct '08

24 Oct '08

Hi, I think we should answer the following questions to decide whether and how to define the constants: 1. When would a C MPI program call Fortran MPI subprogram? Probably, never. 2. When would a Fortran MPI program call a C MPI subprogram? Sometimes. 3. When would a C++ MPI program call Fortran MPI program? Probably, never. 4. When would a Fortran MPI program call a C++ MPI program? Probably, never. Here, "subprogram" means a part of program that relies on the MPI use or knowledge of MPI datatypes, etc. This may or may not be a direct call into the respective MPI library. >From this, what is needed is to define Fortran datatypes from mpif.h in C mpi.h. The rest does not seem relevant. Even the existing C++ definitions may just reflect C heritage. Best regards. Alexander -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Thursday, October 23, 2008 10:13 PM To: MPI 2.2 Subject: [Mpi-22] Should all constants/types be available in all languagebindings? I notice that OMPI, MPICH2, Intel MPI, and HP MPI all do the following: * define Fortran datatypes in mpi.h (e.g., MPI_INTEGER, MPI_DOUBLE) * define Fortran datatypes in the C++ MPI namespace (e.g., MPI::INTEGER, MPI::DOUBLE, etc.) * do *not* define C datatypes in mpif.h (e.g., MPI_INT, MPI_FLOAT, etc.) Why? AFAICT, there is no rule about what constants have to appear in which language bindings. But doesn't that implicitly mean that all constants are supposed to appear in all language bindings? (the argument for having MPI_DOUBLE available in C, for example, is that a C routine may be invoked to send or receive a message containing Fortran data. Similar arguments exist for why you'd want MPI datatypes from other languages available in your language) This is also related to whether the type MPI::Fint should exist or not. I just filed a ticket about these issues (https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/56 ) and marked it as "feedback requested", meaning that I need feedback from the Forum before a proposal can be made. What do people think? -- Jeff Squyres Cisco Systems _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- 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

Should all constants/types be available in all language bindings?
by unknown＠example.com 23 Oct '08

23 Oct '08

I notice that OMPI, MPICH2, Intel MPI, and HP MPI all do the following: * define Fortran datatypes in mpi.h (e.g., MPI_INTEGER, MPI_DOUBLE) * define Fortran datatypes in the C++ MPI namespace (e.g., MPI::INTEGER, MPI::DOUBLE, etc.) * do *not* define C datatypes in mpif.h (e.g., MPI_INT, MPI_FLOAT, etc.) Why? AFAICT, there is no rule about what constants have to appear in which language bindings. But doesn't that implicitly mean that all constants are supposed to appear in all language bindings? (the argument for having MPI_DOUBLE available in C, for example, is that a C routine may be invoked to send or receive a message containing Fortran data. Similar arguments exist for why you'd want MPI datatypes from other languages available in your language) This is also related to whether the type MPI::Fint should exist or not. I just filed a ticket about these issues (https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/56 ) and marked it as "feedback requested", meaning that I need feedback from the Forum before a proposal can be made. What do people think? -- Jeff Squyres Cisco Systems

1 0

Cross-language attributes example wrong
by unknown＠example.com 23 Oct '08

23 Oct '08

I just filed ticket 55, about example 16.17 in MPI-2.1 p487: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/55 The last line of the second sub-example is wrong, but I think the examples themselves are extremely subtle and are worth both making more explicit and adding some comments. More details are available on the ticket. I've asked several people for reviews already. Enjoy. -- Jeff Squyres Cisco Systems

1 0