[mpi-21] Ballot 4 - Re: Request for interpretation

Richard Treumann treumann at [hidden]
Thu Jan 31 15:41:09 CST 2008 

Not quite; For example the standard offers:

{ cb_buffer_size} (integer) {SAME}:
      This hint specifies the total buffer space that can be used for
      collective buffering on each target node, usually a multiple of
      cb_block_size.

The standard says a program is "erroneous" if the value is not the same at
all callers.  That is not exactly the same as the standard defining
behavior for MPI_FILE_OPEN with a valid key and garbage value but pretty
close. If MPI 3 adds new defined keys for new specific functions it may or
may not want to go into defining behavior for some kinds of bad input.

           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/31/2008 03:55:15 PM:

> Do we mean "implementation defined" instead of "undefined"?
>
> On Thu, 31 Jan 2008 14:16:20 -0500
>  Richard Treumann <treumann_at_[hidden]> wrote:
> >Jim
> >
> >The sense I get from the phrase "the behavior is undefined" is that
> >defining the behavior is beyond the scope of the standard.
> >
> >The MPI standard does have some predefined keys and requires an
> >implementation that supports any predefined key to support it as
described
> >by the standard.  That can lead to one place in the standard saying "the
> >behavior is undefined" and another saying "here is the definition of the
> >behavior".
> >
> >Maybe I am reading more than others into the phrase "the behavior is
> >undefined" but it does have this strong implication in my mind.
> >
> >How is this ?
> >
> >An implementation must support info objects as caches for arbitrary
> >key, value) pairs, regardless of whether it recognizes the key.
> >Each function that takes hints in the form of an MPI_Info must
> >be prepared to ignore any key it does not recognize. This description
> >of info objects does not attempt to define how a particular function
> >should react if it recognizes a key but not the associated value.
> >
> >note:
> >I also changed MPI function to simply function because with this free
form
> >approach to the info object, it seems to me a third party library that
is
> >intended to work as part of an MPI program may want to use MPI_Info
objects
> >too.  If someone authors a parallel math library and wants the
> >initialization routine to look like:
> >   init_pmath( MPI_Info info)
> >why not?  They should understand that init_pmath must ignore keys it
does
> >not recognize even if i is not an MPI_ routine.
> >
> >
> >               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/31/2008 09:39:52 AM:
> >
> >> As you are saying, there are two different classes of errors here.
> >>
> >> 1) Keys which are not understood and need to be ignored by functions
> >> which don’t grok them (“JIMS_SECRET_TAG”,”99”)
> >> 2) Keys which are understood by a function, but with a value which
> >> is not (“buffer_size”, “Hello”)
> >>
> >> I think allowing the second type to have undefined behavior is the
> >> right thing to do, since it’s the most general.
> >> If your implementation wants to define the behavior of some out-of-
> >> range values, that’s fine and doesn’t make you non-conforming, it
> >> just means you defined the previously undefined behavior for some
> >> set of values.
> >>
> >> Having that undefined-ness explicit here (in one central place)
> >> seems to make sense (if only because it may be omitted in one of the
> >> other places where it should appear).
> >>
> >> My addition does not alter the existing change which guarantees case
> >> 1, it’s only concerned with case 2.
> >> -- Jim
> >>
> >> James Cownie <james.h.cownie_at_[hidden]>
> >> SSG/DPD/PAT
> >> Tel: +44 117 9071438
> >>
> >> From: mpi-21-bounces_at_[hidden] [mailto:mpi-21-bounces_at_[hidden]]
> >> On Behalf Of Richard Treumann
> >> Sent: 31 January 2008 14:20
> >> To: Mailing list for discussion of MPI 2.1
> >> Subject: Re: [mpi-21] Ballot 4 - Re: Request for interpretation
> >>
> >> Jim -
> >>
> >> I was taking the view that the description of what to do for a
> >> recognized key but dubious value belongs to the function that
> >> recognizes the specific key. For example if MPI_File_open accepts a
> >> "buffer_size" hint with range "32K" to "16M" we may want to define
> >> the behavior of hints that are out of range.
> >>
> >> Once we say an info can have arbitrary keys we need to state that
> >> every info consumer must be prepared to ignore keys it does not
> >> recognize because we have made unrecognizable keys legitimate.
> >>
> >> 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/31/2008 08:43:04 AM:
> >>
> >> > However, you have apparently lost the liberty to have undefined
> >> > behavior which was there in the previous version.
> >> >
> >> > Maybe you should keep that, something like
> >> > An implementation must support info objects as caches for arbitrary
> >> > (key, value) pairs, regardless of whether it recognizes the keys.
> >> > Each MPI function which takes hints in the form of an MPI_Info must
> >> > be prepared to ignore any key it does not recognize. However if a
> >> > function recognizes a key but not the associated value, then the
> >> > behavior is undefined.
> >> > (Modifications in italics)
> >> > -- Jim
> >> >
> >> > James Cownie <james.h.cownie_at_[hidden]>
> >> > SSG/DPD/PAT
> >> > Tel: +44 117 9071438
> >> >
> >> > From: mpi-21-bounces_at_[hidden] [mailto:mpi-21-bounces_at_[hidden]]
> >> > On Behalf Of Richard Treumann
> >> > Sent: 31 January 2008 13:29
> >> > To: Mailing list for discussion of MPI 2.1
> >> > Subject: Re: [mpi-21] Ballot 4 - Re: Request for interpretation
> >> >
> >> > Your wording works for me Rolf. -- Thanks
> >> >
> >> >
> >> > 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/31/2008 05:25:46 AM:
> >> >
> >> > > I try to summarize all 3 replies in one proposal:
> >> > >
> >> > > ___________________________________
> >> > >
> >> > > Proposal:
> >> > > MPI 2.0, Sect. 4.10 Info Objects, page 43, line 38-40 read:
> >> > >    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.
> >> > > but should read:
> >> > >    An implementation must support info objects as caches for
> >arbitrary
> >> > >    (key, value) pairs, regardless of whether it recognizes the
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.
> >> > >
> >> > > Add after MPI 2.0, Sect. 4.10 Info Objects, page 44, line 22 a new
> >> > > paragraph:
> >> > >    Advice to implementors.
> >> > >    Although in MPI functions that take hints in form of an
MPI_Info
> >> > >    (e.g., in process creation and management, one-sided
> >communication,
> >> > >    or parallel file I/O), an implementation must be prepared to
> >ignore
> >> > >    keys that it does not recognize, for the purpose of
> >> MPI_INFO_GET_NKEYS,
> >> > >    MPI_INFO_GET_NTHKEY, MPI_INFO_GET_VALUELEN, and MPI_INFO_GET,
the
> >> > >    implementation must retain all (key,value) pairs so that
layered
> >> > >    functionality can also use the Info object.
> >> > >    (End of advice to implementors.)
> >> > > _____________________________
> >> > > Rationale for this clarification:
> >> > >
> >> > >    The MPI-2.0 text allowed that also MPI_INFO_DELETE,
MPI_INFO_SET,
> >> > >    MPI_INFO_GET, and MPI_INFO_DUP could ignore (key,value) pairs
> >> > >    that are not recognized in routines in other chapters that
> >> > >    take hints with info arguments.
> >> > >    The proposed clarification is necessary when we assume, that
> >> > >    layered implementation of parts of the MPI-2 standard should
> >> > >    be possible and may use the MPI_Info objects for their needs.
> >> > >    This was a goal of the MPI-2 Forum and the MPI-2.0
specification.
> >> > > ___________________________________
> >> > >
> >> > > Bronis, for me, your wording "an MPI implementation may restrict"
was
> >> > > in conflict with the rest of the advice. I hope the formulation
above
> >> > > is also okay. It is based on the new wording from you and Dick in
> >first
> >> > > part of the proposal.
> >> > >
> >> > > 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
> >> >
---------------------------------------------------------------------
> >> > Intel Corporation (UK) Limited
> >> > Registered No. 1134945 (England)
> >> > Registered Office: Pipers Way, Swindon SN3 1RJ
> >> > VAT No: 860 2173 47
> >> >
> >> > This e-mail and any attachments may contain confidential material
for
> >> > the sole use of the intended recipient(s). Any review or
distribution
> >> > by others is strictly prohibited. If you are not the intended
> >> > recipient, please contact the sender and delete all copies.
> >> > _______________________________________________
> >> > mpi-21 mailing list
> >> > mpi-21_at_[hidden]
> >> > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21
> >> ---------------------------------------------------------------------
> >> Intel Corporation (UK) Limited
> >> Registered No. 1134945 (England)
> >> Registered Office: Pipers Way, Swindon SN3 1RJ
> >> VAT No: 860 2173 47
> >>
> >> This e-mail and any attachments may contain confidential material for
> >> the sole use of the intended recipient(s). Any review or distribution
> >> by others is strictly prohibited. If you are not the intended
> >> recipient, please contact the sender and delete all copies.
> >> _______________________________________________
> >> mpi-21 mailing list
> >> mpi-21_at_[hidden]
> >> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21
>
>
>
> 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/20080131/c7640cdd/attachment.html>

More information about the Mpi-21 mailing list