[mpiwg-p2p] Updated Comm. Info Proposal

[Jim Dinan]

Hi Jeff,

Thanks for reviewing the proposal!  A few responses inline below:

On Sat, May 7, 2016 at 12:25 PM, Jeff Squyres (jsquyres) <jsquyres at cisco.com
> wrote:

> (NOTE: the "reply to" address on this list is currently incorrect; it is
> mpiwg-p2p at mpi-forum.org.  If you reply to this address, it will bounce.
> I have emailed IU to get it corrected to mpiwg-p2p@***lists.***
> mpi.forum.org)
>
> p249 33-34:
>
> "Hints may be propagated using a communicator creation routine that
> accepts an info argument."
>
> "Propagated" is not the right verb here.
>

This sentence seems redundant now.  Can we just delete it?


> p250 39-40:
>
> "Users should check whether info hints, for which new values were given,
> are used by the MPI implementation."
>
> I see where you are going with the phrase "for which new values were
> given" -- but there's no reference point/time in the text to define "new".
> I'd just leave that phrase out -- i.e., users should check for *all* values
> that they send in via COMM_SET_INFO.
>

The concern that caused us to add this is a user trying to change something
like mpi_assert_no_any_tag from true to false.  How about replacing this
with "Users should check whether updates to existing hints have been
recognized by the MPI implementation."?

p365 20-23:
>
> "Some info hints allow the MPI library to change its behavior in order to
> improve performance or resource utilization. If an application provides
> such an info hint, it must be compatible with any changes in the behavior
> of the MPI library that are allowed by the info hint."
>
> What info hint -- assertion or otherwise -- exists other than to change an
> MPI implementation's behavior?  I see where you're going with this text,
> but it's a bit fuzzy because *all* info hints are provided to allow an MPI
> implementation to change its behavior.  And that change in behavior may not
> be for improving performance or resource utilization -- they may be for
> other reasons, but still may require the application to conform to new
> behavior.
>

Yeah, this is horribly vague.  Instead of "change its behavior", how about
"restrict its support for certain operations"?

p415 44:
>
> MPI_COMM_GET_INFO should be MPI_WIN_GET_INFO.
>
> p500 42:
>
> MPI_COMM_GET_INFO should be MPI_FILE_GET_INFO.
>

Nice catch -- fixed.

Per discussion at the last MPI Forum meeting, do you have a followup
> proposal for fixing the train wreck that is MPI_COMM_SET_INFO /
> MPI_COMM_GET_INFO?  These MPI assertion info keys are somewhat useless
> without it.
>

Not yet.  Haven't forgotten about this..

 ~Jim.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-p2p/attachments/20160518/32e82418/attachment-0001.html>