Re: [Mpi-forum] Question about MPI_Info set on communicators
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 <[email protected]> Reply: Main MPI Forum mailing list <[email protected]> Date: February 18, 2016 at 11:04:02 AM To: Main MPI Forum mailing list <[email protected]> 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 [email protected] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
_______________________________________________ mpi-forum mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
_______________________________________________ mpi-forum mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
_______________________________________________ mpi-forum mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
-- Jeff Squyres [email protected] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
participants (1)
-
Jeff Squyres (jsquyres)