[Mpi-forum] Question about MPI_Info set on communicators

[Thakur, Rajeev]

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