From: treumann@XXXXXXXXXX
X-Lotus-FromDomain: IBMUS
To: rusrabe@XXXXXXXXXXXXXXXXXXXXXXXXXX
cc: raja@XXXXXXXXXX,linda@XXXXXXXXXXX,mpi-core@XXXXXXXXXXX
Date: Tue, 22 Jun 1999 11:20:15 -0400
Subject: Re: Request for interpretation
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-mpi-core@XXXXXXXXXXX
Precedence: bulk
X-UIDL: a920fb9208ed38f68cfde4032ac8117b

Several people have suggested that MPI_Info should be a general purpose string
pair cache.  There are a couple things which I think would have been appropriate
if that were true.

1) MPI_GREQUEST_START should take an info.  It takes only an "extra_state".
2) The MPI_objtype_SET_NAME/GET_NAME functions could have been
   MPI_objtype_SET_INFO/GET_INFO functions with a predefined "name" key.

MPI created extra_state and attribute caching as unconstrained methods for
stashing
and retrieving information. I think much of the value of Info objects is in
the ability of the implementation to understand the operations a user may
attempt
and give meaningful feedback.

========================

Rolf wrote and I insert comments:

>  Summarizing the technical advantages/disadvantages
>
>    A. MPI_Info_get... return exactly the contents store with
>       MPI_Info_set
>
>       + MPI_Info_... can be used in other layered approaches.
>       + MPI_Info_... can be used by the user for other task.
>       - consuming additional memory for keys/keyvalues that are
>         not interpreted by the MPI library.

        - also user has no clue what is being done with key:value pairs
          he may set.  Unrecognized keys, misspelled keys, valid keys
          will meaningless values all seem to work.  The user who
          is trying to tune with the "sky_color" key can spend all day
          experimenting with values for "sky_colour" and have no way
          to detect that he is wasting time
>
>    B. MPI_Info_set filters out all keys that are not interpreted
>       by any other MPI function in the other chapters
>
>       + The user can retrieve the list of used keys.

        + The user can find out what is happening with key:values for
          MPI_WIN_CREATE and MPI_COMM_SPAWN (etc) even though there is no
          MPI_WIN_GET_INFO or MPI_COMM_GET_INFO.  (The Win version could
          be added to MPI 2.1 but the Comm version makes no sense.)

>       - Prohibits any other use of the MPI_Info routines for
>         other layers outside the vendors MPI library.
>
>  If there is no additional argument, then I vote technically for A.
>
>  Additionally I would say that the sentence "If a function does not
>  recognize a key, it will ignore it, unless otherwise specified"
>  does not say >>if a function does not recognize a key, OTHER FUNCTIONS
>  [e.g. MPI_INFO_SET] can ignore it<<.

This language about ignoring keys is part of the section about creating and
accessing info objects, notpart of the sections on functions to which info
objects are passed.  MPI_INFO_SET/INFO_GET etc. are the proximate functions
to this statement.

I do agree one intent of MPI-2, and probably of this statement, is that
MPI_FILE_SET_INFO etc will tolerate a key:value which is intended for spawn.
It is not clear that is the only intent.

>
>  And "unless otherwise specified" points to the semantical definition
>  of MPI_Info_Get (MPI-2, page 45, lines 40-41):

I see no indication this phrase points to page 45, lines 40-41.  I have
idea what it is intended to mean though.

>
>  "This function retrieves the value associated with key in a previous
>  call to MPI_INFO_SET."
>
>  I do not see >>CAN retrieve<<, I see >>RETRIEVE<<.
>

"association" is an operation on the MPI_Info object which the standard
fails to define carefully.  Note that the sentence doe not say "The value
the user provided".   In "signed char cc; cc = 129;"  what is the value
associated
with cc?

>  Therefore only looking at the document and not to the technical
>  reasons above I would vote also for "only A".
>
>  --Rolf

I consider the issue to be between having a defined interface that users can
work with effectively and having a third kind of bucket for layering which will
frustrate the heck out of MPI users.

I vote for giving the users something they can make sense of.

Dick