From: "Bronis R. de Supinski" Date: January 30, 2008 3:39:44 PM CST To: "Mailing list for discussion of MPI 2.1" Subject: Re: [mpi-21] Ballot 4 - Re: Request for interpretation Reply-To: "Bronis R. de Supinski" for discussion of MPI 2.1" Dick: Re: > 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 Did you mean "do not have any problem"? Otherwise the sentence is hard to parse. > 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. Minor grammar tweak: An info object is a cache for arbitrary ( key, value) pairs. Each MPI function that takes hints in the form of an MPI_Info must be prepared to ignore any key it does not recognize. I think I see what you mean. I'm a little worried that this could still be considered ambiguous. Perhaps changing the first sentence to: An implementation must support info objects as caches for arbitrary (key, value) pairs, regardless of whether the it recognizes the pairs. Bronis > ============ > > 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 rabenseifner@XXXXXXX >> High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 >> University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 >> Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner >> Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) >> _______________________________________________ >> mpi-21 mailing list >> mpi-21@XXXXXXXXXXX >> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 _______________________________________________ mpi-21 mailing list mpi-21@XXXXXXXXXXX http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21