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

Re: [Mpi-22] [Mpi-forum] MPI 2.2 proposal: resolving MPI_Request_free issues
by unknown＠example.com 21 Jul '08

21 Jul '08

On Fri, Jul 18, 2008 at 02:57:19PM -0400, Richard Treumann wrote: > The semantic provided by using MPI_REQUEST_FREE on an active send request > is clearly useful and is clearly mandated by MPI 1.1. My apologies, I wasn't reading the right part of the standard. It is clear and it is mandated, and it does restrict implementations in a way that seems odd. The sending side might have some cleanup work before it thinks the send is complete, yet the recieving side might conclude that the message is complete before the sender does. That's the 'spooky action at a distance' problem I was referring to. Now, the reason I was confused? When you google MPI_REQUEST_FREE, it lands you on the MPICH-1 manpage entry for MPI_REQUEST_FREE, which lacks most of the details of section 3.7.3 on the standard. At the least the manpages ought to refer to/link to the standard, or else they could be replaced by (for example) the OpenMPI manpages, which are much more complete. This doesn't excuse my carelessness, of course, but I'm probably not the only idiot googling routine names expecting complete info. -- greg

1 0

Re: [Mpi-22] MPI-2.1 ambiguity?
by unknown＠example.com 18 Jul '08

18 Jul '08

Its quite common to see code that isn't even valid for MPI, such as a switch statement using predefined datatypes. As there isn't any want to check handle similarity for datatypes, we really need to require equality. As you note, this doesn't affect any implementations. Bill On Jul 18, 2008, at 3:16 PM, Jeff Squyres wrote: > On Jul 18, 2008, at 3:08 PM, William Gropp wrote: > >> Any behavior other than branch A violates the principle of least >> surprise. > > I assume that most MPI implementations will have the values be equal > just by how their f2c/c2f engines work (OMPI will). I was just > wondering if it's necessary to *mandate* that behavior. > > Do apps really check handle equality? If so, I agree that anything > other than path A violates the law of least astonishment. I assumed > that not many apps do this, but I probably don't have a good basis for > reference. > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 William Gropp Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign *

1 0

Re: [Mpi-22] MPI-2.1 ambiguity?
by unknown＠example.com 18 Jul '08

18 Jul '08

On Jul 18, 2008, at 3:08 PM, William Gropp wrote: > Any behavior other than branch A violates the principle of least > surprise. I assume that most MPI implementations will have the values be equal just by how their f2c/c2f engines work (OMPI will). I was just wondering if it's necessary to *mandate* that behavior. Do apps really check handle equality? If so, I agree that anything other than path A violates the law of least astonishment. I assumed that not many apps do this, but I probably don't have a good basis for reference. -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi-22] MPI-2.1 ambiguity?
by unknown＠example.com 18 Jul '08

18 Jul '08

Any behavior other than branch A violates the principle of least surprise. Bill On Jul 18, 2008, at 1:36 PM, Jeff Squyres wrote: > On Jul 18, 2008, at 2:21 PM, William Gropp wrote: > >>> It might be a whole lot simpler to specifically define which >>> predefined handles need to be available in each language. The >>> spectrum ranges from "all languages' predefined handles must be >>> available in every language" to "only that language A's predefined >>> handles must be available in language A". Suggestions? >> >> I'm in favor of explicitly specifying the values and names (because >> of the need to use alternate names when their might be a conflict, >> as in the MPI::F_COMPLEX case), and that these have the exact same >> value as if the handle transfer function was used. > > Do we really need to mandate that they have the same value, or just > exhibit the same behavior? Specifically does it matter if this code > hits branch A or B? > > MPI_Fint ftype; > ftype = MPI_Type_c2f(MPI_INT); > if (MPI_INT == MPI_Type_f2c(ftype)) { > //branch A > } else { > //branch B > } > > Or is it simpler to say that the return from an operation like the > above must behave exactly like the original, regardless of value? > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 William Gropp Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign *

1 0

Re: [Mpi-22] [Mpi-forum] MPI 2.2 proposal: resolving MPI_Request_free issues
by unknown＠example.com 18 Jul '08

18 Jul '08

The semantic provided by using MPI_REQUEST_FREE on an active send request is clearly useful and is clearly mandated by MPI 1.1. It seems to have been a mistake to assume it would always be practical to support this symantic in MPI implementations and we can discuss removing the guarentee or making it optional via MPI_INIT time assertion. I do not see how we can suggest the intent was ever vague. USEFULNESS: The semantic is useful for what amounts to a home rolled get. Say all tasks know that at some point in each step they may need to provide data to other tasks. They do not know what tasks will want which data so they post an IRECV for any incoming data pull commands and TEST or they do IPROBEs and post RECVs when it comes time to accept data pulls. Each RECVed message at a get target represents some remote task describing the data it wants. The task that sent the data pull command (the get origin) posts a receive suitable for the data it requested. The data cannot be sent from the get target until the RECV of the pull command is complete so once the get origin completes the RECV of the data it requested it can be sure the current content of the send buffer with the pull command is obsolete. By immediately after MPI_ISEND, using MPI_REQUEST_FREE on the request handle from the data pull command, the application is spared the need to keep track of that handle until after the data comes in. Immediately calling MPI_WAIT on the ISEND is safe and removes the need to keep track of the handle but delays the application. Saving the request handle to call MPI_WAIT after the pulled data comes in will give good performance because by the time the data has come in the MPI_WAIT should normally be very fast. It does require keeping track of all data pull handles though. There is no magic in reaching a conclusion at the get side that receiving the pulled data means the content of the data pull command buffer is no longer needed. The problem is that the arrival of the reply may not always guarantee that other attributes of the buffer status are complete. MPI 1.1 statement: [] Advice to users. Once a request is freed by a call to MPI_REQUEST_FREE, it is not possible to check for the successful completion of the associated communication with calls to MPI_WAIT or MPI_TEST. Also, if an error occurs subsequently during the communication, an error code cannot be returned to the user --- such an error must be treated as fatal. Questions arise as to how one knows when the operations have completed when using MPI_REQUEST_FREE. Depending on the program logic, there may be other ways in which the program knows that certain operations have completed and this makes usage of MPI_REQUEST_FREE practical. For example, an active send request could be freed when the logic of the program is such that the receiver sends a reply to the message sent --- the arrival of the reply informs the sender that the send has completed and the send buffer can be reused. An active receive request should never be freed as the receiver will have no way to verify that the receive has completed and the receive buffer can be reused. ( End of advice to users.) Dick Dick Treumann - MPI Team/TCEM IBM Systems & Technology Group Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 *

1 0

Re: [Mpi-22] MPI-2.1 ambiguity?
by unknown＠example.com 18 Jul '08

18 Jul '08

On Jul 18, 2008, at 2:21 PM, William Gropp wrote: >> It might be a whole lot simpler to specifically define which >> predefined handles need to be available in each language. The >> spectrum ranges from "all languages' predefined handles must be >> available in every language" to "only that language A's predefined >> handles must be available in language A". Suggestions? > > I'm in favor of explicitly specifying the values and names (because > of the need to use alternate names when their might be a conflict, > as in the MPI::F_COMPLEX case), and that these have the exact same > value as if the handle transfer function was used. Do we really need to mandate that they have the same value, or just exhibit the same behavior? Specifically does it matter if this code hits branch A or B? MPI_Fint ftype; ftype = MPI_Type_c2f(MPI_INT); if (MPI_INT == MPI_Type_f2c(ftype)) { //branch A } else { //branch B } Or is it simpler to say that the return from an operation like the above must behave exactly like the original, regardless of value? -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi-22] MPI-2.1 ambiguity?
by unknown＠example.com 18 Jul '08

18 Jul '08

Notes inline. On Jul 18, 2008, at 1:02 PM, Jeff Squyres wrote: > On Jul 17, 2008, at 12:41 PM, William Gropp wrote: > >> There's another option. Drop the requirement that all of the >> predefined datatypes are predefined in all languages, but specify >> that they may be used (with the appropriate handle conversion) as >> input to any routine where it makes sense. > > Just curious: if you drop the requirement for direct access to all the > predefined datatypes in all languages, why do you need to specify > anything else? MPI-2.1:16.3.4 (transfer of handles -- the *f2c/*c2f > stuff) seems to be sufficient. Is there a need to say something more? The implicit assumption you are making is that the existence of the handle transfer functions means that the handles can be used everywhere. You can certainly argue that nothing else is needed, but MPI 2.0 felt that it was important to make it clear that this applied to the datatype routines, even if those datatypes do not exist in the calling language. In other words, you can't have different versions of MPI_Type_xxx that only know about the predefined datatypes in the calling language. Without this clarification, we could be having that argument instead :) > > Further, if we drop the requirement, do we need a "high quality > implementation" note about making all predefined handles available in > all languages for MPI programmer convenience? I.e., what reasonable > expectation should an MPI programmer have (particularly for already- > existing codes) about accessing language A's predefined handles in > language B? Should they *always* call C to do the translation? > >> For datatypes, this includes the datatype construction routines but >> not the communication routines (don't use MPI_INT when sending >> INTEGERs with Fortran). This is what the Opaque Objects text >> expects. > > To me, dropping the requirement sounds like we're just making the > user's life hard -- a Fortran library may have to introduce C code > into their project, and then figure out all the cross-language > compiling and linking stuff (which is not for the meek). > > It might be a whole lot simpler to specifically define which > predefined handles need to be available in each language. The > spectrum ranges from "all languages' predefined handles must be > available in every language" to "only that language A's predefined > handles must be available in language A". Suggestions? I'm in favor of explicitly specifying the values and names (because of the need to use alternate names when their might be a conflict, as in the MPI::F_COMPLEX case), and that these have the exact same value as if the handle transfer function was used. Bill > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 William Gropp Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign *

1 0

Re: [Mpi-22] MPI-2.1 ambiguity?
by unknown＠example.com 18 Jul '08

18 Jul '08

On Jul 17, 2008, at 12:41 PM, William Gropp wrote: > There's another option. Drop the requirement that all of the > predefined datatypes are predefined in all languages, but specify > that they may be used (with the appropriate handle conversion) as > input to any routine where it makes sense. Just curious: if you drop the requirement for direct access to all the predefined datatypes in all languages, why do you need to specify anything else? MPI-2.1:16.3.4 (transfer of handles -- the *f2c/*c2f stuff) seems to be sufficient. Is there a need to say something more? Further, if we drop the requirement, do we need a "high quality implementation" note about making all predefined handles available in all languages for MPI programmer convenience? I.e., what reasonable expectation should an MPI programmer have (particularly for already- existing codes) about accessing language A's predefined handles in language B? Should they *always* call C to do the translation? > For datatypes, this includes the datatype construction routines but > not the communication routines (don't use MPI_INT when sending > INTEGERs with Fortran). This is what the Opaque Objects text expects. To me, dropping the requirement sounds like we're just making the user's life hard -- a Fortran library may have to introduce C code into their project, and then figure out all the cross-language compiling and linking stuff (which is not for the meek). It might be a whole lot simpler to specifically define which predefined handles need to be available in each language. The spectrum ranges from "all languages' predefined handles must be available in every language" to "only that language A's predefined handles must be available in language A". Suggestions? -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi-22] MPI-2.1 ambiguity?
by unknown＠example.com 18 Jul '08

18 Jul '08

Rolf Rabenseifner wrote: > My primary oal is: > We should make clarifications which state that > each predefined handle must be available in every > language binding. > People may be confused by current wording in several places: > > - MPI-2.1 (June 23, 2008) Section 16.3.6 MPI Opaque Objects, > page 483, lines 46-47: > "All predefined datatypes can be used in datatype constructors > in any language." > > Does this mean, that the C++ datatypes BOOL, COMPLEX, DOUBLE_COMPLEX and LONG_DOUBLE_COMPLEX have to be available in C and Fortran ? If yes, what are the names of them in C and Fortran ? Or is the statement in Annex 1.1 (MPI 2.1, page 495, line 1) "C++-Only Named Predefined Datatypes" indicating, that they are not available in C and Fortran versions of MPI 2.1 ? In this case, the sentence above should be corrected. Hubert *

1 0

Re: [Mpi-22] [Mpi-forum] MPI 2.2 proposal: resolving MPI_Request_free issues
by unknown＠example.com 17 Jul '08

17 Jul '08

> But the MPI standard says this is valid and can be used to avoid the need > to keep track of ISEND request handles. It is clear that if the matching > RECV has completed then the unaltered content of the ISEND buffer is no > longer needed. The RECV cannot have completed unless the message got out. I tend to agree with this sentiment, but the MPI standard has long had a prohibition on touching the transmit buffer, because you never know what the implementation is using that buffer for. So... anything that ever had a reliability protocol and did zero copy has had this issue. > Erez is pointing out a case where the semantic stipulated by the MPI > standard back before RDMA adapters were available becomes flawed with the > way RDMA adapters now work. The content of the ISEND buffer is irrelevant > once the destination RECV has completed but some other things about the > ISEND buffer are still in limbo I don't believe this is new. Anything that ever provided a reason that you couldn't touch the send buffer likely had a similar issue. Keith

1 0