- mpi-forum - mailman3.cels.anl.gov

MPI Forum Mailing List DNS Fixed
by Wes Bland 18 Jan '23

18 Jan '23

Hi all, As mentioned in the test message, the DNS records for the MPI Forum seem to have had a problem when we moved over to our new provider last month. It seems like things are working now, but it’s possible that you might have missed some recent messages (particularly if you use Gmail for your provider). This applies to both the main list and all of the working groups' mailing lists. As always, you can see the archive of emails on the website: https://lists.mpi-forum.org/pipermail/mpi-forum/ To catch up on all of the announced readings and votes, you can find those on the agenda page for the upcoming meeting: https://www.mpi-forum.org/meetings/2023/02/agenda Remember that reading/vote announcements for this meeting are due today. If you have any questions or issues, please let me know. Thanks, Wes

1 0

Reading requests: language interoperability concerns
by Joseph Schuchart 18 Jan '23

18 Jan '23

On behalf of JeffH I'd like to request a no-no reading and first vote for the following issues/PRs addressing language interoperability issues: *add MPI_Status_{set,get} for 3 status fields* Issue: https://github.com/mpi-forum/mpi-issues/issues/645 PR: https://github.com/mpi-forum/mpi-standard/pull/767 Changes from last reading: https://github.com/mpi-forum/mpi-standard/pull/767/commits/d2510534f4ffd078… *Remove the handle conversion functions from the list of allowed macros* Issue: https://github.com/mpi-forum/mpi-issues/issues/647 PR: https://github.com/mpi-forum/mpi-standard/pull/770 Changes from last reading: https://github.com/mpi-forum/mpi-standard/pull/770/commits/e8e51d3bafb04613… *Remove (P)MPI_Wtime and (P)MPI_Wtick from list of allowed macros* Issue: https://github.com/mpi-forum/mpi-issues/issues/646 PR: https://github.com/mpi-forum/mpi-standard/pull/771 Changes from last reading: https://github.com/mpi-forum/mpi-standard/pull/771/commits/60b770c2936fbead… Cheers Joseph

1 0

Test Message
by Wes Bland 18 Jan '23

18 Jan '23

Hi all, Please ignore this message. We’ve apparently been having problems with the DNS records for the mailing list after moving to our new hosting provider. I believe these should be fixed now, but there may be a series of messages on this thread to test that. Thanks, Wes

1 0

No Virtual Meeting today / Deadline for announcements TODAY
by Martin Schulz 18 Jan '23

18 Jan '23

Hi all, As discussed last week, there is no MPI virtual meeting today. However, please keep in mind that today is the deadline for all ballot and reading announcements for our next voting meeting, which will be February 1st and 8th. Thanks! Martin -- Prof. Dr. Martin Schulz, Chair of Computer Architecture and Parallel Systems Department of Informatics, TU-Munich, Boltzmannstraße 3, D-85748 Garching Member of the Board of Directors at the Leibniz Supercomputing Centre (LRZ) Email: schulzm(a)in.tum.de

1 0

Reading Announcement
by Jim Dinan 17 Jan '23

17 Jan '23

Hi All, The hybrid WG would like to read a revised draft of the Memory Allocation Kind Info proposal at the February Forum meeting: https://github.com/mpi-forum/mpi-issues/issues/580 Cheers, ~Jim.

1 0

MPI voting meeting Feb'23 -- announcements
by Holmes, Daniel John 17 Jan '23

17 Jan '23

Hi all, No-no-votes for things that were read in Dec'22 voting meeting Summary: Section 3.5 - p. 45 - Comment Erroneous Example Issue: https://github.com/mpi-forum/mpi-issues/issues/188 PR: https://github.com/mpi-forum/mpi-standard/pull/203 No-no-vote changes: https://github.com/mpi-forum/mpi-standard/pull/203/files/f55fe47d7a377cd711… Summary: Info key for strict start ordering of persistent collective communication Issue: https://github.com/mpi-forum/mpi-issues/issues/83 PR: https://github.com/mpi-forum/mpi-standard/pull/666 No-no-vote changes: https://github.com/mpi-forum/mpi-standard/pull/666/files/9f85494a73f878456e… Summary: Fix Incorrect Usage of Rank/Task/etc. in Point to Point Chapter Issue: https://github.com/mpi-forum/mpi-issues/issues/472 PR: https://github.com/mpi-forum/mpi-standard/pull/606 No-no-vote changes: https://github.com/mpi-forum/mpi-standard/pull/606/files/ea7da423add7fd70f3… 1st votes for things that were read in Dec'22 voting meeting All of the above issues that have no-no-vote changes plus the following issues that don't. Summary: 'Logically concurrent' isn't Issue: https://github.com/mpi-forum/mpi-issues/issues/117 PR: https://github.com/mpi-forum/mpi-standard/pull/748 Other notes I cannot remember the outcome of the discussion for issue #639: https://github.com/mpi-forum/mpi-issues/issues/639 Thus, I'm going to pause progress on this issue until the will of the Forum is made clear. Best wishes, Dan.

1 0

Tools WG Reading for February Meeting
by Marc-André Hermanns 17 Jan '23

17 Jan '23

Dear all, hopefully still in time I want to announce some readings for the Tools Working Group: LIS entries in MPI_T chapter not reflecting IN vs. INOUT as defined in Term 2.3 chapter Issue: https://github.com/mpi-forum/mpi-issues/issues/443 PR: https://github.com/mpi-forum/mpi-standard/pull/754 Changes to last time: I removed some calls that were debatable whether the pe_session really would fall under Terms 2.3. ======= Mention behavior with potential overflow Issue: https://github.com/mpi-forum/mpi-issues/issues/414 PR: https://github.com/mpi-forum/mpi-standard/pull/723 Changes: We immediately made changes to the wording at the last meeting, so I would like to read those as a no-no and if passed have the first vote on this. NOTE: Please find the changes since last time in the "Conversation" tab under "Resolved" comments of Dec 6, 2022. ======= Correct usage of the terms error and return codes in the tools chapter Issue: https://github.com/mpi-forum/mpi-issues/issues/542 PR: https://github.com/mpi-forum/mpi-standard/pull/646 Changes: I am not quite finished with the requests of last reading of handling `return value` as a term with an index, but this will comm ASAP and will have to be handled as a no-no first anyway. If passed, it would be nice to schedule it for 1st vote ======== I will also like to have plenary discussion for the tickets: Rename Name-Shifted Profiling Interface (PMPI) to Interception Interface ($584) Issue: https://github.com/mpi-forum/mpi-issues/issues/584 PR: https://github.com/mpi-forum/mpi-standard/pull/724 Changes: After our last discussion (which I think were not fully resolved, I wanted to make some wording changes that may exceed the no-no barrier, so I would like to discuss how this ticket will move forward. ========= Jeff and I may want to present/discuss our ideas for resolving the MIN|MAXLOC for large integers, but we don't have text ready yet. Issue: https://github.com/mpi-forum/mpi-issues/issues/520 Cheers, Marc-Andre -- Dr. rer. nat. Marc-André Hermanns IT Center Group: High Performance Computing Division: Computational Science and Engineering RWTH Aachen University Seffenter Weg 23 52074 Aachen Phone: +49 241 80-24381 hermanns(a)itc.rwth-aachen.de www.itc.rwth-aachen.de Social Media Kanäle des IT Centers: https://blog.rwth-aachen.de/itc/ https://www.facebook.com/itcenterrwth https://www.linkedin.com/company/itcenterrwth https://twitter.com/ITCenterRWTH https://www.youtube.com/channel/UCKKDJJukeRwO0LP-ac8x8rQ

1 0

Re: [Mpi-forum] why do we only support caching on win/comm/datatype?
by Jed Brown 16 Jan '23

16 Jan '23

Second that MPI attributes do not suck. PETSc uses communicator attributes heavily to avoid lots of confusing or wasteful behavior when users pass communicators between libraries and similar comments would apply if other MPI objects were passed between libraries in that way. It was before my time, but I think PETSc's use of attributes predates MPI-1.0 and MPI's early and pervasive support for attributes is one of the things I celebrate when discussing software engineering of libraries intended for use by other libraries versus those made for use by applications. Please don't dismiss attributes even if you don't enjoy them. Jeff Hammond via mpi-forum <mpi-forum(a)lists.mpi-forum.org> writes: > The API is annoying but it really only gets used in library middleware by people like us who can figure out the void* casting nonsense and use it correctly. > > Casper critically depends on window attributes. > > Request attributes are the least intrusive way to allow libraries to do completion callbacks. They give users a way to do this that adds zero instructions to the critical path and is completely invisible unless actually requires. > > Attributes do not suck and people should stop preventing those of us who write libraries to make the MPI ecosystem better from doing our jobs because they want to whine about problems they’re too lazy to solve. > > I guess I’ll propose request and op attributes because I need them and people can either solve those problems better ways or get out of the way. > > Jeff > > Sent from my iPhone > >> On 16. Jan 2023, at 20.27, Holmes, Daniel John <daniel.john.holmes(a)intel.com> wrote: >> >> >> Hi Jeff, >> >> When adding session as an object to MPI, a deliberate choice was made not to support attributes for session objects because “attributes in MPI suck”. >> >> This decision was made despite the usage (by some tools) of “at exit” attribute callbacks fired by the destruction of MPI_COMM_SELF during MPI_FINALIZE in the world model and the consequent obvious omission of a similar hook during MPI_SESSION_FINALIZE in the session model (there is also no MPI_COMM_SELF in the session model, so this is not a simple subject). >> >> Removal of attributes entirely – blocked by back-compat because usage is known to exist. >> Expansion of attributes orthogonally – blocked by “attributes in MPI suck” accusations. >> >> Result – inconsistency in the interface that no-one wants to tackle. >> >> Best wishes, >> Dan. >> >> From: mpi-forum <mpi-forum-bounces(a)lists.mpi-forum.org> On Behalf Of Jeff Hammond via mpi-forum >> Sent: 16 January 2023 14:40 >> To: MPI Forum <mpi-forum(a)lists.mpi-forum.org> >> Cc: Jeff Hammond <jeff.science(a)gmail.com> >> Subject: [Mpi-forum] why do we only support caching on win/comm/datatype? >> >> I am curious if there is a good reason from the past as to why we only support caching on win, comm and datatype, and no other handles? >> >> I have a good use case for request attributes and have found that the implementation overhead in MPICH appears to be zero. The implementation in MPICH requires adding a single pointer to an internal struct. This struct member will never be accessed except when the user needs it, and it can be placed at the end of the struct so that it doesn't even pollute the cache. >> >> I wondered if callbacks were a hidden overhead, but they only called explicitly and synchronously, so they would not interfere with critical path uses of requests. >> >> https://github.com/mpi-forum/mpi-issues/issues/664 has some details but since I do not understand how MPICH generates the MPI bindings, I only implemented the back-end MPIR code. >> >> It would make MPI more consistent if all opaque handles supported attributes. In particular, I'd love to have a built-in MPI_Op attribute for the function pointer the user provided (which is similar to how one can query input args associated with MPI_Win) because that appears to be the only way I can implement certain corner cases of MPI F08. >> >> Thanks, >> >> Jeff >> >> -- >> Jeff Hammond >> jeff.science(a)gmail.com >> http://jeffhammond.github.io/ > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

1 0

Re: [Mpi-forum] why do we only support caching on win/comm/datatype?
by Jeff Hammond 16 Jan '23

16 Jan '23

The API is annoying but it really only gets used in library middleware by people like us who can figure out the void* casting nonsense and use it correctly. Casper critically depends on window attributes. Request attributes are the least intrusive way to allow libraries to do completion callbacks. They give users a way to do this that adds zero instructions to the critical path and is completely invisible unless actually requires. Attributes do not suck and people should stop preventing those of us who write libraries to make the MPI ecosystem better from doing our jobs because they want to whine about problems they’re too lazy to solve. I guess I’ll propose request and op attributes because I need them and people can either solve those problems better ways or get out of the way. Jeff Sent from my iPhone > On 16. Jan 2023, at 20.27, Holmes, Daniel John <daniel.john.holmes(a)intel.com> wrote: > > > Hi Jeff, > > When adding session as an object to MPI, a deliberate choice was made not to support attributes for session objects because “attributes in MPI suck”. > > This decision was made despite the usage (by some tools) of “at exit” attribute callbacks fired by the destruction of MPI_COMM_SELF during MPI_FINALIZE in the world model and the consequent obvious omission of a similar hook during MPI_SESSION_FINALIZE in the session model (there is also no MPI_COMM_SELF in the session model, so this is not a simple subject). > > Removal of attributes entirely – blocked by back-compat because usage is known to exist. > Expansion of attributes orthogonally – blocked by “attributes in MPI suck” accusations. > > Result – inconsistency in the interface that no-one wants to tackle. > > Best wishes, > Dan. > > From: mpi-forum <mpi-forum-bounces(a)lists.mpi-forum.org> On Behalf Of Jeff Hammond via mpi-forum > Sent: 16 January 2023 14:40 > To: MPI Forum <mpi-forum(a)lists.mpi-forum.org> > Cc: Jeff Hammond <jeff.science(a)gmail.com> > Subject: [Mpi-forum] why do we only support caching on win/comm/datatype? > > I am curious if there is a good reason from the past as to why we only support caching on win, comm and datatype, and no other handles? > > I have a good use case for request attributes and have found that the implementation overhead in MPICH appears to be zero. The implementation in MPICH requires adding a single pointer to an internal struct. This struct member will never be accessed except when the user needs it, and it can be placed at the end of the struct so that it doesn't even pollute the cache. > > I wondered if callbacks were a hidden overhead, but they only called explicitly and synchronously, so they would not interfere with critical path uses of requests. > > https://github.com/mpi-forum/mpi-issues/issues/664 has some details but since I do not understand how MPICH generates the MPI bindings, I only implemented the back-end MPIR code. > > It would make MPI more consistent if all opaque handles supported attributes. In particular, I'd love to have a built-in MPI_Op attribute for the function pointer the user provided (which is similar to how one can query input args associated with MPI_Win) because that appears to be the only way I can implement certain corner cases of MPI F08. > > Thanks, > > Jeff > > -- > Jeff Hammond > jeff.science(a)gmail.com > http://jeffhammond.github.io/

1 0

Re: [Mpi-forum] why do we only support caching on win/comm/datatype?
by Holmes, Daniel John 16 Jan '23

16 Jan '23

Hi Jeff, When adding session as an object to MPI, a deliberate choice was made not to support attributes for session objects because “attributes in MPI suck”. This decision was made despite the usage (by some tools) of “at exit” attribute callbacks fired by the destruction of MPI_COMM_SELF during MPI_FINALIZE in the world model and the consequent obvious omission of a similar hook during MPI_SESSION_FINALIZE in the session model (there is also no MPI_COMM_SELF in the session model, so this is not a simple subject). Removal of attributes entirely – blocked by back-compat because usage is known to exist. Expansion of attributes orthogonally – blocked by “attributes in MPI suck” accusations. Result – inconsistency in the interface that no-one wants to tackle. Best wishes, Dan. From: mpi-forum <mpi-forum-bounces(a)lists.mpi-forum.org> On Behalf Of Jeff Hammond via mpi-forum Sent: 16 January 2023 14:40 To: MPI Forum <mpi-forum(a)lists.mpi-forum.org> Cc: Jeff Hammond <jeff.science(a)gmail.com> Subject: [Mpi-forum] why do we only support caching on win/comm/datatype? I am curious if there is a good reason from the past as to why we only support caching on win, comm and datatype, and no other handles? I have a good use case for request attributes and have found that the implementation overhead in MPICH appears to be zero. The implementation in MPICH requires adding a single pointer to an internal struct. This struct member will never be accessed except when the user needs it, and it can be placed at the end of the struct so that it doesn't even pollute the cache. I wondered if callbacks were a hidden overhead, but they only called explicitly and synchronously, so they would not interfere with critical path uses of requests. https://github.com/mpi-forum/mpi-issues/issues/664 has some details but since I do not understand how MPICH generates the MPI bindings, I only implemented the back-end MPIR code. It would make MPI more consistent if all opaque handles supported attributes. In particular, I'd love to have a built-in MPI_Op attribute for the function pointer the user provided (which is similar to how one can query input args associated with MPI_Win) because that appears to be the only way I can implement certain corner cases of MPI F08. Thanks, Jeff -- Jeff Hammond jeff.science(a)gmail.com<mailto:[email protected]> http://jeffhammond.github.io/

1 0