[mpi-21] Ballot 4 - Re: Request for interpretation
Bronis R. de Supinski
bronis at [hidden]
Wed Jan 30 15:39:44 CST 2008
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_at_[hidden] 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_at_[hidden]
> > 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_at_[hidden]
> > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21
More information about the Mpi-21
mailing list