[mpi-21] Ballot 4 - Re: Request for interpretation
Richard Treumann
treumann at [hidden]
Wed Jan 30 14:05:26 CST 2008
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_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
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpi-21/attachments/20080130/c083274e/attachment.html>
More information about the Mpi-21
mailing list