From: Richard Treumann Date: January 30, 2008 2:05:26 PM CST To: "Mailing list for discussion of MPI 2.1" Subject: Re: [mpi-21] Ballot 4 - Re: Request for interpretation Reply-To: "Mailing list for discussion of MPI 2.1" IBM long ago chose the real-politic approach of supporting both interpretations. By default we restrict INFO objects to key:value pairs that mean something to our functions that take INFO arguments and quietly discard key:value pairs we do not recognize. As far as I know this has not been a problem for anyone writing portable MPI applications. ( ( I can see that hint filtering would restrict someone who wants to use an INFO for layered libraries. For that reason, any user who wishes to use an INFO object as a general purpose cache for key:value pairs that mean nothing to our MPI implementation can set an environment variable or command line option (MP_HINTS_FILTERED/-hints_filtered = no) and get the behavior Linda was expecting.( ( I do have any problem with clarifying the standard to say that an MPI_Info object should be prepared to manage unrecognized key:value string pairs. I suggest changing:( ( ==============( If a function does not recognize a key, it will ignore it, unless otherwise specified. If an implementation recognizes a key but does not recognize the format of the corresponding value, the result is undefined. ( ( to( ( An info object is a cache for arbitrary ( key, value) pairs. Each MPI function which takes hints in the form of an MPI_Info must be prepared to ignore any key it does not recognize.( ============( ( I think this approach implies that any statements about what happens when a recognized key has a garbage value belong with the function that recognizes the key. By insulating the info description from the descriptions of particular MPI functions that take MPI_Info hints, we leave people the option of using info objects as hints for third party libraries that work with MPI but are not part of the MPI API.( ( 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( ( ( mpi-21-bounces@XXXXXXXXXXX wrote on 01/30/2008 12:33:34 PM:( ( > This is a proposal for MPI 2.1, Ballot 4.( > ( > I'm asking especially ( > Linda Stanberry, Bill Gropp, rajeev Thakur, Dick Treumann, Raja Daoud,( > the participants of the email-discussion in 1999, to review this proposal.( > ( > This is a follow up to:( > What info keys can be set? ( > in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-( > errata/index.html( > with mail discussion in( > http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-( > errata/discuss/infoset/( > ___________________________________( > Background:( > The sentence MPI 2.0, Sect. 4.10 Info Objects, page 43, line 38( > ( > "If a function does not recognize a key, it will ignore it, ( > unless otherwise specified."( > ( > was interpreted in two different ways:( > 1. This sentence is only valid in the routines in other chapters( > (e.g. processs creation and management, one-sided communication, ( > parallel file I/O) where infos may be used to specify portable( > and implementation defined hints.( > 2. This interpretation is also valid for MPI_INFO_DELETE, MPI_INFO_SET,( > MPI_INFO_GET, and MPI_INFO_DUP.( > The following proposal ist based on Option 1.( > Option 2 is rejected due to the reason shown after the proposal.( > ___________________________________( > ( > Proposal:( > MPI 2.0, Sect. 4.10 Info Objects, page 43, line 38 read:( > If a function does not recognize a key, ( > it will ignore it, unless otherwise specified.( > but should read:( > If a function in another section of the MPI standard ( > does not recognize a key, ( > it will ignore it, unless otherwise specified.( > The routines in this section. ( > The functions in this section must not ignore any (key,value) pair. ( > ( > Add after MPI 2.0, Sect. 4.10 Info Objects, page 44, line 22 a new( > paragraph:( > Advice to implementors.( > For optimization, an MPI implementation may already sort out( > which (key,value) pair can be recognized for use in other chapters( > (e.g., in processs creation and management, one-sided communication, ( > parallel file I/O) to guarantee a fast access to the appropriate( > information when used in routines of those chapters.( > For porpose of MPI_INFO_GET_NKEYS, MPI_INFO_GET_NTHKEY,( > MPI_INFO_GET_VALUELEN, and MPI_INFO_GET, the implementation( > must still keep also all other (key,value) pairs that cannot be( > recognized by that MPI implementation. ( > (End of advice to implementors.)( > ________________________________( > Rationale for this clarification:( > ( > The first of the two interpretation options mentioned in the ( > background information is the only valid interpretation ( > when we assume, that layered implementation of parts of ( > the MPI-2 standard should be possible.( > This was a goal of the MPI-2 Forum and the MPI-2.0 specification.( > ___________________________________( > ( > Comment:( > In the discussion (see the mails from 1999) ( > one can clearly see, that an implementation of option 2 (done by IBM) ( > cannot coexist with a layered implementation of MPI parallel( > file I/O, because MPI parallel file I/O routine need a different ( > implementation of the INFO routines. Other chapters of MPI (e.g. 1-sided)( > need the original INF implementation.( > Two different INFO implementations cannot coexist in the same MPI library.( > ( > We could see the ouutcome of such problems with MPI_Wait & co.( > as long as a generalized request concept was not available.( > ROMIO had to define non-standard MPIO_Wait & co. routines.( > And they persist for a long time!( > ( > Without the clarification above, we have the same problem with the ( > INFO handling. ( > ( > Best regards( > Rolf( > ( > ( > ( > ( > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifn _______________________________________________ mpi-21 mailing list mpi-21@XXXXXXXXXXX http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21