[mpiwg-p2p] Updated Comm. Info Proposal

[Jim Dinan]

[ re-sending to @lists.*, in case the original didn't get through ]

On Wed, May 18, 2016 at 4:57 PM, Jim Dinan <james.dinan at gmail.com> wrote:

> 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/9163c5bd/attachment-0001.html>