May 2016 - mpiwg-p2p - mailman3.cels.anl.gov

Re: [mpiwg-p2p] Updated Comm. Info Proposal
by Jim Dinan 18 May '16

18 May '16

[ 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(a)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(a)cisco.com> wrote: > >> (NOTE: the "reply to" address on this list is currently incorrect; it is >> mpiwg-p2p(a)mpi-forum.org. If you reply to this address, it will bounce. >> I have emailed IU to get it corrected to mpiwg-p2p(a)***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. >

1 0

Re: [mpiwg-p2p] Updated Comm. Info Proposal
by Jim Dinan 18 May '16

18 May '16

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(a)cisco.com > wrote: > (NOTE: the "reply to" address on this list is currently incorrect; it is > mpiwg-p2p(a)mpi-forum.org. If you reply to this address, it will bounce. > I have emailed IU to get it corrected to mpiwg-p2p(a)***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.

1 0

Meeting Today
by Jim Dinan 09 May '16

09 May '16

Hi All, I'm not sure if there is a meeting planned for today. I don't have anything that I think requires live discussion. I would just ask everyone to please review the draft info proposal. Thanks, ~Jim.

1 0

Re: [mpiwg-p2p] Updated Comm. Info Proposal
by Jeff Squyres (jsquyres) 07 May '16

07 May '16

(NOTE: the "reply to" address on this list is currently incorrect; it is mpiwg-p2p(a)mpi-forum.org. If you reply to this address, it will bounce. I have emailed IU to get it corrected to mpiwg-p2p(a)***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. 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. 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. p415 44: MPI_COMM_GET_INFO should be MPI_WIN_GET_INFO. p500 42: MPI_COMM_GET_INFO should be MPI_FILE_GET_INFO. ------ 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. > On May 6, 2016, at 8:56 PM, Jim Dinan <james.dinan(a)gmail.com> wrote: > > Hi All, > > I have attached the updated communicator info proposal. Based on the feedback at the last meeting, the proposal has been split into three parts with the following "ticket" labels: > > Errta -- MPI 3.1 errata to remove info propagation. This was motivated by George's presentation where we learned that the info hints and values that are propagated is not well defined. This was discovered by the OpenMPI development team. > > IDWI -- Add MPI_Comm_idup_with_info. This should be added to correct the gap introduced to the nonblocking API by the above errata. > > Info -- Proposal to allow info hints to provide assertions and add communicator info hints. > > In addition, default values for the info keys have also been added. > > The deadline to submit the proposal for the next meeting will be May 23. Please review and check if I missed anything. > > Cheers, > ~Jim. > <mpi-report.pdf>_______________________________________________ > mpiwg-p2p mailing list > mpiwg-p2p(a)mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-p2p -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Updated Comm. Info Proposal
by Jim Dinan 06 May '16

06 May '16

Hi All, I have attached the updated communicator info proposal. Based on the feedback at the last meeting, the proposal has been split into three parts with the following "ticket" labels: Errta -- MPI 3.1 errata to remove info propagation. This was motivated by George's presentation where we learned that the info hints and values that are propagated is not well defined. This was discovered by the OpenMPI development team. IDWI -- Add MPI_Comm_idup_with_info. This should be added to correct the gap introduced to the nonblocking API by the above errata. Info -- Proposal to allow info hints to provide assertions and add communicator info hints. In addition, default values for the info keys have also been added. The deadline to submit the proposal for the next meeting will be May 23. Please review and check if I missed anything. Cheers, ~Jim.

1 0