[Mpi-forum] Question about MPI_Info set on communicators

[Jim Dinan]

This is the semantic that we have been working with in the info assertions
proposal.  But, I do see the ambiguity.

Several things have come up that would impact the info assertions proposal:

1. If comm_get_info + dup_with_info is not equivalent to comm_dup, then we
are losing functionality by removing info propagation in dup.  We may need
a new get_info routine to support both types of queries.

2. If comm_get_info does not return values indicating the current
configuration/behavior of the MPI library then we may need to adjust the
language we added to comm_set_info indicating that users should check
whether changes to info key values were accepted by the MPI library.

 ~Jim.

On Wed, Feb 17, 2016 at 8:50 PM, Thakur, Rajeev <thakur at mcs.anl.gov> wrote:

> In the I/O chapter, an implementation is allowed to ignore the hints
> provided by the user. MPI_File_get_info returns the current value of hints
> actually used in the implementation. So suppose a user passes the info key
> “striping_unit" with value 10, but the system on which the file is created
> doesn’t support user control of striping unit, the implementation can
> ignore the user-provided value and, in MPI_File_get_info, return the
> default striping unit used for the file (which could be 8, say).
>
> Rajeev
>
>
>
> > On Feb 17, 2016, at 5:57 PM, Schulz Martin <schulzm at llnl.gov> wrote:
> >
> >>
> >>>> See my reply to Jim: if we're supposed to provide the value of *the
> >>>> hint*, that to me sounds like the *user's input* (as opposed to what
> >>> the
> >>>> system chose to do with that hint).
> >>>
> >>> I agree, hints are given by the user to express what an application
> >>> does.
> >>> Those should never be changed by the MPI library (or no are no longer
> >>> (user) hints).
> >>
> >> Even if the MPI implementation should never change the value of these
> >> hints, my original question still stands, because MPI_COMM_GET_INFO's
> use
> >> of the phrase "actually used by the system" is still ambiguous (MPI-3.1
> >> p250):
> >>
> >> -----
> >> // Assume that the MPI implementation understands the "foo" info key
> >> hint, but
> >> // is unable to apply it after a communicator is created.
> >> MPI_Info_set(myinfo, "foo", "yes");
> >> MPI_Comm_set_info(comm, myinfo);
> >> MPI_Comm_get_info(comm, myinfo_returned);
> >> ------
> >>
> >> So I still don't have a definitive answer as to what is in
> >> myinfo_returned:
> >>
> >> 1. "foo" = "yes", because that's what the user set, and the MPI
> >> implementation understood the "foo" hint key (regardless of what it
> chose
> >> to do with that hint)
> >> --> This is what I think should happen
> >>
> >> 2. "foo" = "no", because the MPI implementation wasn't able to use the
> >> "foo" hint
> >> --> There's at least 2 explicit votes against this behavior (JeffSq,
> >> Martin)
> >>
> >> 3. no "foo" key is set, because the MPI implementation wasn't able to
> use
> >> the "foo" hint
> >> --> I'm not a big fan of this, because you can't tell the difference
> >> between "foo is not understood by the implementation" and "foo is
> >> understood by the implementation, but this hint can't be used right
> now".
> >
> > I would say, #3 is correct - the system doesnąt use/apply the hint, I.e.,
> > the behavior is the same as if the hint wasnąt supplied. I agree, this is
> > not ideal since knowing what an implementation supports would be good,
> but
> > the standard never makes that distinction.
> >
> >>
> >> =========
> >>
> >> Regardless of what is returned by MPI_COMM_GET_INFO, what happens in
> >> MPI_COMM_DUP?
> >>
> >> The "actually used by the system" ambiguous phrase only applies to
> >> MPI_COMM_GET_INFO.  MPI_COMM_DUP is defined in MPI-3.1 p238:
> >>
> >>  "MPI_COMM_DUP duplicates the existing communicator comm with ... info
> >> hints."
> >>
> >> It doesn't have any scoping language about *which* hints are copied --
> it
> >> pretty much implies that *all* hints are copied.
> >>
> >> As such, I think that "foo"="yes" should be propagated to the new
> >> communicator.
> >
> > Yes, I agree - even if the hint is not used and hence not returned by
> > MPI_COMM_GET_INFO, itąs still set on the communicator. The user set it
> and
> > expects it to be set and so it should be part of the duplication.
> >
> >> Which is another reason that I think that MPI_COMM_GET_INFO should also
> >> return "foo"="yes" in myinfo_returned (i.e., so that MPI_COMM_GET_INFO
> >> and MPI_COMM_DUP both behave the same way).
> >
> > I agree, thatąs what it should do - GET and SET should be matching, but
> > thatąs not how the standard is written (sadly).
> >
> > The idea behavior would be three calls, IMHO:
> >
> > MPI_COMM_GET_INFO - return all hints set
> > MPI_COMM_GET_INFO_UNDERSTOOD - return all hints that could be used by an
> > implementation
> > MPI_COMM_GET_INFO_USED - return all hints used (thatąs the current
> > behavior of MPI_COMM_GET_INFO)
> >
> > doing this, though, throws into the usual backwards compatibility
> > problems, though.
> >
> > Martin
> >
> >
> >
> >>
> >> Thoughts?
> >>
> >> --
> >> Jeff Squyres
> >> jsquyres at cisco.com
> >> For corporate legal information go to:
> >> http://www.cisco.com/web/about/doing_business/legal/cri/
> >
> >
> > _______________________________________________
> > mpi-forum mailing list
> > mpi-forum at lists.mpi-forum.org
> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
>
> _______________________________________________
> mpi-forum mailing list
> mpi-forum at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpi-forum/attachments/20160218/8419a36e/attachment-0001.html>