From: rusrabe@awsrr.rus.uni-stuttgart.de (Rolf Rabenseifner)
Message-Id: <199906210838.KAA18824@awsrr.rus.uni-stuttgart.de>
Subject: Re: Request for interpretation
To: raja@rsn.hp.com
Date: Mon, 21 Jun 1999 10:38:14 +0200 (DST)
Cc: linda@k2.llnl.gov, mpi-core@mcs.anl.gov, treumann@us.ibm.com
In-Reply-To: <199906182009.QAA20433@atlrel2.hp.com> from "Raja Daoud" at Jun 18, 99 03:09:02 pm
Content-Type: text
Sender: owner-mpi-core@mcs.anl.gov
Precedence: bulk

My strong feeling is, that we should not forget one main goal 
of MPI: source-code portability.

Therefore we should not allow both interpretations, because then
the users have nothing.

Raja pointed out, that both interpretations allow the same optimization
of compute time (but not memory consummation). 

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 .

  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.
     - 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<<.

And "unless otherwise specified" points to the semantical definition
of MPI_Info_Get (MPI-2, page 45, lines 40-41):

"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<<.

Therefore only looking at the document and not to the technical
reasons above I would vote also for "only A". 

--Rolf 

Raja wrote: 
> I think the point to resolve is to decide what this sentence means:
> 
> "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."
> 
> (I don't have the page/line reference, it's in
> www.mpi-forum.org/docs/mpi-20-html/node53.html).
 
MPI-2.0 page 43 lines 38-40 

> Does "function" include MPI_Info_set() or not?  If it does, IBM's
> implementation is valid (and actually provides additional value to
> users).  I think it doesn't follow the spirit of MPI_Info as I remember
> it from the Forum meetings (i.e. users wanting and winning the vote
> for MPI_Info to be a glorified bucket of key/value strings).

Yes, I remember the same. 

> If "function" only refers to the routines that interpret/consume the
> info keys, then filtering is not allowed and MPI_Info has to keep track
> of all strings in order.  Note that it can in addition, under-the-table,
> compile an optimized/filtered representation for faster use by the
> consuming routines, but that representation would not be used by the
> MPI_Info_* retrieval functions.
> 
> 
> I don't have a strong feeling on this one.  The handling of recognized
> keys is a benefit to implementations, and it is not in dispute.  The
> handling of unrecognized keys or invalid values is mostly a service to
> users.  We have two valid ways to handle that case, and both provide
> some value but take away another (layerability vs. more visibility into
> an implementation's internal parameters).
> 
> Which of these two approaches does the majority of users prefer to have,
> or do you prefer to allow both to be valid?
> 
> --Raja


Rolf Rabenseifner                          High Performance Computing
Parallel Computing                         Center Stuttgart    (HLRS)
Rechenzentrum Universitaet Stuttgart (RUS) Phone:    ++49 711 6855530
Allmandring 30                             FAX:      ++49 711 6787626
D-70550 Stuttgart                   rabenseifner@rus.uni-stuttgart.de
Germany                        http://www.hlrs.de/people/rabenseifner