[Mpi-forum] Question about MPI_Info set on communicators
schulzm at llnl.gov
Wed Feb 17 17:57:28 CST 2016
>> >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
>> >system chose to do with that hint).
>> I agree, hints are given by the user to express what an application
>> 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
>// Assume that the MPI implementation understands the "foo" info key
>// is unable to apply it after a communicator is created.
>MPI_Info_set(myinfo, "foo", "yes");
>So I still don't have a definitive answer as to what is in
>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
> --> There's at least 2 explicit votes against this behavior (JeffSq,
>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
>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
>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
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
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
>jsquyres at cisco.com
>For corporate legal information go to:
More information about the mpi-forum