<div dir="ltr">OK, we'll do this.<div><br></div><div> George.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 18, 2016 at 3:28 PM, Jim Dinan <span dir="ltr"><<a href="mailto:james.dinan@gmail.com" target="_blank">james.dinan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<span class="HOEnZb"><font color="#888888"><div><br></div></font></span><div><div><span class="HOEnZb"><font color="#888888"><div> ~Jim.</div></font></span><div><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 18, 2016 at 12:56 PM, Jeff Squyres (jsquyres) <span dir="ltr"><<a href="mailto:jsquyres@cisco.com" target="_blank">jsquyres@cisco.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Jim:<br>
<br>
Is there a WG session in Chicago where we can discuss this stuff?<br>
<br>
I ask because this issue has stalled the Open MPI implementation effort to actually start doing interesting/useful things with MPI_COMM_SET_INFO.<br>
<span><br>
<br>
-----Original Message-----<br>
From: Jim Dinan <<a href="mailto:james.dinan@gmail.com" target="_blank">james.dinan@gmail.com</a>><br>
Reply: Main MPI Forum mailing list <<a href="mailto:mpi-forum@lists.mpi-forum.org" target="_blank">mpi-forum@lists.mpi-forum.org</a>><br>
</span><span>Date: February 18, 2016 at 11:04:02 AM<br>
To: Main MPI Forum mailing list <<a href="mailto:mpi-forum@lists.mpi-forum.org" target="_blank">mpi-forum@lists.mpi-forum.org</a>><br>
</span><span>Subject: Re: [Mpi-forum] Question about MPI_Info set on communicators<br>
<br>
</span><span>> This is the semantic that we have been working with in the info assertions<br>
> proposal. But, I do see the ambiguity.<br>
><br>
> Several things have come up that would impact the info assertions proposal:<br>
><br>
> 1. If comm_get_info + dup_with_info is not equivalent to comm_dup, then we<br>
> are losing functionality by removing info propagation in dup. We may need<br>
> a new get_info routine to support both types of queries.<br>
><br>
> 2. If comm_get_info does not return values indicating the current<br>
> configuration/behavior of the MPI library then we may need to adjust the<br>
> language we added to comm_set_info indicating that users should check<br>
> whether changes to info key values were accepted by the MPI library.<br>
><br>
> ~Jim.<br>
><br>
</span><span>> On Wed, Feb 17, 2016 at 8:50 PM, Thakur, Rajeev wrote:<br>
><br>
> > In the I/O chapter, an implementation is allowed to ignore the hints<br>
> > provided by the user. MPI_File_get_info returns the current value of hints<br>
> > actually used in the implementation. So suppose a user passes the info key<br>
> > “striping_unit" with value 10, but the system on which the file is created<br>
> > doesn’t support user control of striping unit, the implementation can<br>
> > ignore the user-provided value and, in MPI_File_get_info, return the<br>
> > default striping unit used for the file (which could be 8, say).<br>
> ><br>
> > Rajeev<br>
> ><br>
> ><br>
> ><br>
</span><div><div>> > > On Feb 17, 2016, at 5:57 PM, Schulz Martin wrote:<br>
> > ><br>
> > >><br>
> > >>>> See my reply to Jim: if we're supposed to provide the value of *the<br>
> > >>>> hint*, that to me sounds like the *user's input* (as opposed to what<br>
> > >>> the<br>
> > >>>> system chose to do with that hint).<br>
> > >>><br>
> > >>> I agree, hints are given by the user to express what an application<br>
> > >>> does.<br>
> > >>> Those should never be changed by the MPI library (or no are no longer<br>
> > >>> (user) hints).<br>
> > >><br>
> > >> Even if the MPI implementation should never change the value of these<br>
> > >> hints, my original question still stands, because MPI_COMM_GET_INFO's<br>
> > use<br>
> > >> of the phrase "actually used by the system" is still ambiguous (MPI-3.1<br>
> > >> p250):<br>
> > >><br>
> > >> -----<br>
> > >> // Assume that the MPI implementation understands the "foo" info key<br>
> > >> hint, but<br>
> > >> // is unable to apply it after a communicator is created.<br>
> > >> MPI_Info_set(myinfo, "foo", "yes");<br>
> > >> MPI_Comm_set_info(comm, myinfo);<br>
> > >> MPI_Comm_get_info(comm, myinfo_returned);<br>
> > >> ------<br>
> > >><br>
> > >> So I still don't have a definitive answer as to what is in<br>
> > >> myinfo_returned:<br>
> > >><br>
> > >> 1. "foo" = "yes", because that's what the user set, and the MPI<br>
> > >> implementation understood the "foo" hint key (regardless of what it<br>
> > chose<br>
> > >> to do with that hint)<br>
> > >> --> This is what I think should happen<br>
> > >><br>
> > >> 2. "foo" = "no", because the MPI implementation wasn't able to use the<br>
> > >> "foo" hint<br>
> > >> --> There's at least 2 explicit votes against this behavior (JeffSq,<br>
> > >> Martin)<br>
> > >><br>
> > >> 3. no "foo" key is set, because the MPI implementation wasn't able to<br>
> > use<br>
> > >> the "foo" hint<br>
> > >> --> I'm not a big fan of this, because you can't tell the difference<br>
> > >> between "foo is not understood by the implementation" and "foo is<br>
> > >> understood by the implementation, but this hint can't be used right<br>
> > now".<br>
> > ><br>
> > > I would say, #3 is correct - the system doesnąt use/apply the hint, I.e.,<br>
> > > the behavior is the same as if the hint wasnąt supplied. I agree, this is<br>
> > > not ideal since knowing what an implementation supports would be good,<br>
> > but<br>
> > > the standard never makes that distinction.<br>
> > ><br>
> > >><br>
> > >> =========<br>
> > >><br>
> > >> Regardless of what is returned by MPI_COMM_GET_INFO, what happens in<br>
> > >> MPI_COMM_DUP?<br>
> > >><br>
> > >> The "actually used by the system" ambiguous phrase only applies to<br>
> > >> MPI_COMM_GET_INFO. MPI_COMM_DUP is defined in MPI-3.1 p238:<br>
> > >><br>
> > >> "MPI_COMM_DUP duplicates the existing communicator comm with ... info<br>
> > >> hints."<br>
> > >><br>
> > >> It doesn't have any scoping language about *which* hints are copied --<br>
> > it<br>
> > >> pretty much implies that *all* hints are copied.<br>
> > >><br>
> > >> As such, I think that "foo"="yes" should be propagated to the new<br>
> > >> communicator.<br>
> > ><br>
> > > Yes, I agree - even if the hint is not used and hence not returned by<br>
> > > MPI_COMM_GET_INFO, itąs still set on the communicator. The user set it<br>
> > and<br>
> > > expects it to be set and so it should be part of the duplication.<br>
> > ><br>
> > >> Which is another reason that I think that MPI_COMM_GET_INFO should also<br>
> > >> return "foo"="yes" in myinfo_returned (i.e., so that MPI_COMM_GET_INFO<br>
> > >> and MPI_COMM_DUP both behave the same way).<br>
> > ><br>
> > > I agree, thatąs what it should do - GET and SET should be matching, but<br>
> > > thatąs not how the standard is written (sadly).<br>
> > ><br>
> > > The idea behavior would be three calls, IMHO:<br>
> > ><br>
> > > MPI_COMM_GET_INFO - return all hints set<br>
> > > MPI_COMM_GET_INFO_UNDERSTOOD - return all hints that could be used by an<br>
> > > implementation<br>
> > > MPI_COMM_GET_INFO_USED - return all hints used (thatąs the current<br>
> > > behavior of MPI_COMM_GET_INFO)<br>
> > ><br>
> > > doing this, though, throws into the usual backwards compatibility<br>
> > > problems, though.<br>
> > ><br>
> > > Martin<br>
> > ><br>
> > ><br>
> > ><br>
> > >><br>
> > >> Thoughts?<br>
> > >><br>
> > >> --<br>
> > >> Jeff Squyres<br>
> > >> <a href="mailto:jsquyres@cisco.com" target="_blank">jsquyres@cisco.com</a><br>
> > >> For corporate legal information go to:<br>
> > >> <a href="http://www.cisco.com/web/about/doing_business/legal/cri/" rel="noreferrer" target="_blank">http://www.cisco.com/web/about/doing_business/legal/cri/</a><br>
> > ><br>
> > ><br>
> > > _______________________________________________<br>
> > > mpi-forum mailing list<br>
> > > <a href="mailto:mpi-forum@lists.mpi-forum.org" target="_blank">mpi-forum@lists.mpi-forum.org</a><br>
> > > <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum" rel="noreferrer" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum</a><br>
> ><br>
> > _______________________________________________<br>
> > mpi-forum mailing list<br>
> > <a href="mailto:mpi-forum@lists.mpi-forum.org" target="_blank">mpi-forum@lists.mpi-forum.org</a><br>
> > <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum" rel="noreferrer" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum</a><br>
> ><br>
> _______________________________________________<br>
> mpi-forum mailing list<br>
> <a href="mailto:mpi-forum@lists.mpi-forum.org" target="_blank">mpi-forum@lists.mpi-forum.org</a><br>
> <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum" rel="noreferrer" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum</a><br>
<br>
--<br>
Jeff Squyres<br>
<a href="mailto:jsquyres@cisco.com" target="_blank">jsquyres@cisco.com</a><br>
For corporate legal information go to: <a href="http://www.cisco.com/web/about/doing_business/legal/cri/" rel="noreferrer" target="_blank">http://www.cisco.com/web/about/doing_business/legal/cri/</a></div></div></blockquote></div><br></div></div></div></div></div></div>
<br>_______________________________________________<br>
mpi-forum mailing list<br>
<a href="mailto:mpi-forum@lists.mpi-forum.org">mpi-forum@lists.mpi-forum.org</a><br>
<a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum" rel="noreferrer" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum</a><br></blockquote></div><br></div>