[Mpi-forum] Question about MPI_Info set on communicators

Thu Feb 18 14:28:57 CST 2016

We don't have meeting time scheduled for this at the moment, and the agenda
already looks full.  We could back-fill whenever there is a free slot, if
we prepare a few slides for discussion.

 ~Jim.

On Thu, Feb 18, 2016 at 12:56 PM, Jeff Squyres (jsquyres) <
jsquyres at cisco.com> wrote:

> Jim:
>
> Is there a WG session in Chicago where we can discuss this stuff?
>
> I ask because this issue has stalled the Open MPI implementation effort to
> actually start doing interesting/useful things with MPI_COMM_SET_INFO.
>
>
> -----Original Message-----
> From: Jim Dinan <james.dinan at gmail.com>
> Reply: Main MPI Forum mailing list <mpi-forum at lists.mpi-forum.org>
> Date: February 18, 2016 at 11:04:02 AM
> To: Main MPI Forum mailing list <mpi-forum at lists.mpi-forum.org>
> Subject:  Re: [Mpi-forum] Question about MPI_Info set on communicators
>
> > 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 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 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
> > >
> > _______________________________________________
> > mpi-forum mailing list
> > mpi-forum at lists.mpi-forum.org
> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
>
> --
> Jeff Squyres
> jsquyres at cisco.com
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpi-forum/attachments/20160218/370b6809/attachment-0001.html>