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

Additional Reading #543 at MPI-Forum meeting Feb 1+8, 2023 (related to Terms and Contexts)
by Rolf Rabenseifner 18 Jan '23

18 Jan '23

Dear MPI forum members, dear Wesley, I would like to have the following issue (and its PR) read: Issue 543 / PR791 "Pending operation" not defined, pending proper definition Issue https://github.com/mpi-forum/mpi-issues/issues/543 PR791 https://github.com/mpi-forum/mpi-standard/pull/791 pdf https://github.com/mpi-forum/mpi-standard/files/10449690/mpi41-report_Issue… Best regards Rolf -- Dr. Rolf Rabenseifner . . . . . . . . . .. . . rabenseifner(a)hlrs.de . High Performance Computing Center (HLRS) . . . ++49(0)711/685-65530 . University of Stuttgart . . . . . . www.hlrs.de/people/rabenseifner . Nobelstr. 19, 70569 Stuttgart, Germany

1 0

Re: [Mpi-forum] why do we only support caching on win/comm/datatype?
by Skjellum, Anthony 18 Jan '23

18 Jan '23

Dan correctly interpreted my meaning. But Jeff is right that we should be modest. Tony Anthony Skjellum, PhD Professor of Computer Science and Chair of Excellence Director, SimCenter University of Tennessee at Chattanooga (UTC) tony-skjellum(a)utc.edu [or skjellum(a)gmail.com] cell: 205-807-4968 ________________________________ From: mpi-forum <mpi-forum-bounces(a)lists.mpi-forum.org> on behalf of Holmes, Daniel John via mpi-forum <mpi-forum(a)lists.mpi-forum.org> Sent: Wednesday, January 18, 2023 12:40 PM To: Main MPI Forum mailing list <mpi-forum(a)lists.mpi-forum.org> Cc: Holmes, Daniel John <daniel.john.holmes(a)intel.com> Subject: Re: [Mpi-forum] why do we only support caching on win/comm/datatype? Hi all, I believe “orthogonality” here is intended to mean “every object needs this feature” rather than “every Forum member needs to be involved” (at least, I hope so). We have a single location for attributes-that-have-callbacks: section 7.7 in MPI-4.0 – although there are also window attributes (in section 12.2.6), which are something else entirely. It looks like that subsection (7.7) could/should be moved into the External Interfaces chapter, which would mean all the objects to which it applies have been lexically introduced before the feature/aspect is described. It looks like subsection 7.8 should appear later in the document too. Best wishes, Dan. From: mpi-forum <mpi-forum-bounces(a)lists.mpi-forum.org> On Behalf Of Jeff Hammond via mpi-forum Sent: 18 January 2023 17:28 To: Main MPI Forum mailing list <mpi-forum(a)lists.mpi-forum.org> Cc: Jeff Hammond <jeff.science(a)gmail.com> Subject: Re: [Mpi-forum] why do we only support caching on win/comm/datatype? This isn’t an orthogonality issues. The issue is not linear dependence of features but a null space caused by a surprising failure to pursue consistency in the attributes feature set. We have a chapter for attributes. I see no need for another WG to fix this. Sent from my iPhone On 18. Jan 2023, at 19.21, Skjellum, Anthony via mpi-forum <mpi-forum(a)lists.mpi-forum.org<mailto:[email protected]>> wrote: We need a cross-cutting WG on "orthogonality" of feature set in MPI-5. Anthony Skjellum, PhD Professor of Computer Science and Chair of Excellence Director, SimCenter University of Tennessee at Chattanooga (UTC) tony-skjellum(a)utc.edu<mailto:[email protected]> [or skjellum(a)gmail.com<mailto:[email protected]>] cell: 205-807-4968 ________________________________ From: mpi-forum <mpi-forum-bounces(a)lists.mpi-forum.org<mailto:[email protected]>> on behalf of Koziol, Quincey via mpi-forum <mpi-forum(a)lists.mpi-forum.org<mailto:[email protected]>> Sent: Wednesday, January 18, 2023 12:14 PM To: Main MPI Forum mailing list <mpi-forum(a)lists.mpi-forum.org<mailto:[email protected]>> Cc: Koziol, Quincey <qkoziol(a)amazon.com<mailto:[email protected]>> Subject: Re: [Mpi-forum] why do we only support caching on win/comm/datatype? “third” on attributes are necessary for MPI. HDF5 uses them to make certain that cached file data gets written to the file (and it is closed properly) before MPI_Finalize() in the world model. Frankly, I wasn’t paying enough attention to the sessions work ten years ago and didn’t realize that they aren’t available as a mechanism for getting this same action when a session is terminated. This is a critical need to avoid corrupting user data. Jeff - please add me to your work on adding attributes to requests and ops, and I’ll write text for adding attributes to sessions. Quincey > On Jan 16, 2023, at 2:10 PM, Jed Brown via mpi-forum <mpi-forum(a)lists.mpi-forum.org<mailto:[email protected]>> wrote: > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > 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<mailto:[email protected]>> 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<mailto:[email protected]>> 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<mailto:[email protected]>> On Behalf Of Jeff Hammond via mpi-forum >>> Sent: 16 January 2023 14:40 >>> To: MPI Forum <mpi-forum(a)lists.mpi-forum.org<mailto:[email protected]>> >>> Cc: Jeff Hammond <jeff.science(a)gmail.com<mailto:[email protected]>> >>> 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…> 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]> >>> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fjeffhammon…<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fjeffhammon…> >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org<mailto:[email protected]> >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mpi…<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mpi…> > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org<mailto:[email protected]> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mpi…<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mpi…> _______________________________________________ mpi-forum mailing list mpi-forum(a)lists.mpi-forum.org<mailto:[email protected]> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mpi…<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mpi…> _______________________________________________ mpi-forum mailing list mpi-forum(a)lists.mpi-forum.org<mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpi-forum<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mpi…>

1 0

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

18 Jan '23

Fair but let’s not try to boil the ocean and just start with ‘every object needs attributes’. The forum tends to be more successful with modestly scoped efforts. Sent from my iPhone > On 18. Jan 2023, at 19.40, Holmes, Daniel John <daniel.john.holmes(a)intel.com> wrote: > > > Hi all, > > I believe “orthogonality” here is intended to mean “every object needs this feature” rather than “every Forum member needs to be involved” (at least, I hope so). > > We have a single location for attributes-that-have-callbacks: section 7.7 in MPI-4.0 – although there are also window attributes (in section 12.2.6), which are something else entirely. It looks like that subsection (7.7) could/should be moved into the External Interfaces chapter, which would mean all the objects to which it applies have been lexically introduced before the feature/aspect is described. It looks like subsection 7.8 should appear later in the document too. > > Best wishes, > Dan. > > From: mpi-forum <mpi-forum-bounces(a)lists.mpi-forum.org> On Behalf Of Jeff Hammond via mpi-forum > Sent: 18 January 2023 17:28 > To: Main MPI Forum mailing list <mpi-forum(a)lists.mpi-forum.org> > Cc: Jeff Hammond <jeff.science(a)gmail.com> > Subject: Re: [Mpi-forum] why do we only support caching on win/comm/datatype? > > This isn’t an orthogonality issues. The issue is not linear dependence of features but a null space caused by a surprising failure to pursue consistency in the attributes feature set. > > We have a chapter for attributes. I see no need for another WG to fix this. > > Sent from my iPhone > > > On 18. Jan 2023, at 19.21, Skjellum, Anthony via mpi-forum <mpi-forum(a)lists.mpi-forum.org> wrote: > > > We need a cross-cutting WG on "orthogonality" of feature set in MPI-5. > > > Anthony Skjellum, PhD > Professor of Computer Science and Chair of Excellence > Director, SimCenter > University of Tennessee at Chattanooga (UTC) > tony-skjellum(a)utc.edu [or skjellum(a)gmail.com] > cell: 205-807-4968 > > From: mpi-forum <mpi-forum-bounces(a)lists.mpi-forum.org> on behalf of Koziol, Quincey via mpi-forum <mpi-forum(a)lists.mpi-forum.org> > Sent: Wednesday, January 18, 2023 12:14 PM > To: Main MPI Forum mailing list <mpi-forum(a)lists.mpi-forum.org> > Cc: Koziol, Quincey <qkoziol(a)amazon.com> > Subject: Re: [Mpi-forum] why do we only support caching on win/comm/datatype? > > “third” on attributes are necessary for MPI. HDF5 uses them to make certain that cached file data gets written to the file (and it is closed properly) before MPI_Finalize() in the world model. Frankly, I wasn’t paying enough attention to the sessions work ten years ago and didn’t realize that they aren’t available as a mechanism for getting this same action when a session is terminated. This is a critical need to avoid corrupting user data. > > Jeff - please add me to your work on adding attributes to requests and ops, and I’ll write text for adding attributes to sessions. > > Quincey > > > > On Jan 16, 2023, at 2:10 PM, Jed Brown via mpi-forum <mpi-forum(a)lists.mpi-forum.org> wrote: > > > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > > > > > 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co… 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 > >>> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fjeffhammon… > >> _______________________________________________ > >> mpi-forum mailing list > >> mpi-forum(a)lists.mpi-forum.org > >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mpi… > > _______________________________________________ > > mpi-forum mailing list > > mpi-forum(a)lists.mpi-forum.org > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mpi… > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mpi… > _______________________________________________ > 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 Holmes, Daniel John 18 Jan '23

18 Jan '23

Hi all, I believe “orthogonality” here is intended to mean “every object needs this feature” rather than “every Forum member needs to be involved” (at least, I hope so). We have a single location for attributes-that-have-callbacks: section 7.7 in MPI-4.0 – although there are also window attributes (in section 12.2.6), which are something else entirely. It looks like that subsection (7.7) could/should be moved into the External Interfaces chapter, which would mean all the objects to which it applies have been lexically introduced before the feature/aspect is described. It looks like subsection 7.8 should appear later in the document too. Best wishes, Dan. From: mpi-forum <mpi-forum-bounces(a)lists.mpi-forum.org> On Behalf Of Jeff Hammond via mpi-forum Sent: 18 January 2023 17:28 To: Main MPI Forum mailing list <mpi-forum(a)lists.mpi-forum.org> Cc: Jeff Hammond <jeff.science(a)gmail.com> Subject: Re: [Mpi-forum] why do we only support caching on win/comm/datatype? This isn’t an orthogonality issues. The issue is not linear dependence of features but a null space caused by a surprising failure to pursue consistency in the attributes feature set. We have a chapter for attributes. I see no need for another WG to fix this. Sent from my iPhone On 18. Jan 2023, at 19.21, Skjellum, Anthony via mpi-forum <mpi-forum(a)lists.mpi-forum.org<mailto:[email protected]>> wrote: We need a cross-cutting WG on "orthogonality" of feature set in MPI-5. Anthony Skjellum, PhD Professor of Computer Science and Chair of Excellence Director, SimCenter University of Tennessee at Chattanooga (UTC) tony-skjellum(a)utc.edu<mailto:[email protected]> [or skjellum(a)gmail.com<mailto:[email protected]>] cell: 205-807-4968 ________________________________ From: mpi-forum <mpi-forum-bounces(a)lists.mpi-forum.org<mailto:[email protected]>> on behalf of Koziol, Quincey via mpi-forum <mpi-forum(a)lists.mpi-forum.org<mailto:[email protected]>> Sent: Wednesday, January 18, 2023 12:14 PM To: Main MPI Forum mailing list <mpi-forum(a)lists.mpi-forum.org<mailto:[email protected]>> Cc: Koziol, Quincey <qkoziol(a)amazon.com<mailto:[email protected]>> Subject: Re: [Mpi-forum] why do we only support caching on win/comm/datatype? “third” on attributes are necessary for MPI. HDF5 uses them to make certain that cached file data gets written to the file (and it is closed properly) before MPI_Finalize() in the world model. Frankly, I wasn’t paying enough attention to the sessions work ten years ago and didn’t realize that they aren’t available as a mechanism for getting this same action when a session is terminated. This is a critical need to avoid corrupting user data. Jeff - please add me to your work on adding attributes to requests and ops, and I’ll write text for adding attributes to sessions. Quincey > On Jan 16, 2023, at 2:10 PM, Jed Brown via mpi-forum <mpi-forum(a)lists.mpi-forum.org<mailto:[email protected]>> wrote: > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > 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<mailto:[email protected]>> 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<mailto:[email protected]>> 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<mailto:[email protected]>> On Behalf Of Jeff Hammond via mpi-forum >>> Sent: 16 January 2023 14:40 >>> To: MPI Forum <mpi-forum(a)lists.mpi-forum.org<mailto:[email protected]>> >>> Cc: Jeff Hammond <jeff.science(a)gmail.com<mailto:[email protected]>> >>> 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co… 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]> >>> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fjeffhammon… >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org<mailto:[email protected]> >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mpi… > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org<mailto:[email protected]> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mpi… _______________________________________________ mpi-forum mailing list mpi-forum(a)lists.mpi-forum.org<mailto:[email protected]> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mpi… _______________________________________________ mpi-forum mailing list mpi-forum(a)lists.mpi-forum.org<mailto:[email protected]> 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 18 Jan '23

18 Jan '23

This isn’t an orthogonality issues. The issue is not linear dependence of features but a null space caused by a surprising failure to pursue consistency in the attributes feature set. We have a chapter for attributes. I see no need for another WG to fix this. Sent from my iPhone > On 18. Jan 2023, at 19.21, Skjellum, Anthony via mpi-forum <mpi-forum(a)lists.mpi-forum.org> wrote: > > > We need a cross-cutting WG on "orthogonality" of feature set in MPI-5. > > > Anthony Skjellum, PhD > Professor of Computer Science and Chair of Excellence > Director, SimCenter > University of Tennessee at Chattanooga (UTC) > tony-skjellum(a)utc.edu [or skjellum(a)gmail.com] > cell: 205-807-4968 > > From: mpi-forum <mpi-forum-bounces(a)lists.mpi-forum.org> on behalf of Koziol, Quincey via mpi-forum <mpi-forum(a)lists.mpi-forum.org> > Sent: Wednesday, January 18, 2023 12:14 PM > To: Main MPI Forum mailing list <mpi-forum(a)lists.mpi-forum.org> > Cc: Koziol, Quincey <qkoziol(a)amazon.com> > Subject: Re: [Mpi-forum] why do we only support caching on win/comm/datatype? > > “third” on attributes are necessary for MPI. HDF5 uses them to make certain that cached file data gets written to the file (and it is closed properly) before MPI_Finalize() in the world model. Frankly, I wasn’t paying enough attention to the sessions work ten years ago and didn’t realize that they aren’t available as a mechanism for getting this same action when a session is terminated. This is a critical need to avoid corrupting user data. > > Jeff - please add me to your work on adding attributes to requests and ops, and I’ll write text for adding attributes to sessions. > > Quincey > > > > On Jan 16, 2023, at 2:10 PM, Jed Brown via mpi-forum <mpi-forum(a)lists.mpi-forum.org> wrote: > > > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > > > > > 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co… 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 > >>> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fjeffhammon… > >> _______________________________________________ > >> mpi-forum mailing list > >> mpi-forum(a)lists.mpi-forum.org > >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mpi… > > _______________________________________________ > > mpi-forum mailing list > > mpi-forum(a)lists.mpi-forum.org > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mpi… > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mpi… > _______________________________________________ > 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 18 Jan '23

18 Jan '23

https://github.com/mpi-forum/mpi-issues/issues/667 https://github.com/mpi-forum/mpi-issues/issues/664 You should create a new issue for sessions attributes. We can merge into a single meta issue later if appropriate. Sent from my iPhone > On 18. Jan 2023, at 19.17, Koziol, Quincey via mpi-forum <mpi-forum(a)lists.mpi-forum.org> wrote: > > “third” on attributes are necessary for MPI. HDF5 uses them to make certain that cached file data gets written to the file (and it is closed properly) before MPI_Finalize() in the world model. Frankly, I wasn’t paying enough attention to the sessions work ten years ago and didn’t realize that they aren’t available as a mechanism for getting this same action when a session is terminated. This is a critical need to avoid corrupting user data. > > Jeff - please add me to your work on adding attributes to requests and ops, and I’ll write text for adding attributes to sessions. > > Quincey > > >> On Jan 16, 2023, at 2:10 PM, Jed Brown via mpi-forum <mpi-forum(a)lists.mpi-forum.org> wrote: >> >> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. >> >> >> >> 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 >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> https://lists.mpi-forum.org/mailman/listinfo/mpi-forum > > _______________________________________________ > 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 Skjellum, Anthony 18 Jan '23

18 Jan '23

We need a cross-cutting WG on "orthogonality" of feature set in MPI-5. Anthony Skjellum, PhD Professor of Computer Science and Chair of Excellence Director, SimCenter University of Tennessee at Chattanooga (UTC) tony-skjellum(a)utc.edu [or skjellum(a)gmail.com] cell: 205-807-4968 ________________________________ From: mpi-forum <mpi-forum-bounces(a)lists.mpi-forum.org> on behalf of Koziol, Quincey via mpi-forum <mpi-forum(a)lists.mpi-forum.org> Sent: Wednesday, January 18, 2023 12:14 PM To: Main MPI Forum mailing list <mpi-forum(a)lists.mpi-forum.org> Cc: Koziol, Quincey <qkoziol(a)amazon.com> Subject: Re: [Mpi-forum] why do we only support caching on win/comm/datatype? “third” on attributes are necessary for MPI. HDF5 uses them to make certain that cached file data gets written to the file (and it is closed properly) before MPI_Finalize() in the world model. Frankly, I wasn’t paying enough attention to the sessions work ten years ago and didn’t realize that they aren’t available as a mechanism for getting this same action when a session is terminated. This is a critical need to avoid corrupting user data. Jeff - please add me to your work on adding attributes to requests and ops, and I’ll write text for adding attributes to sessions. Quincey > On Jan 16, 2023, at 2:10 PM, Jed Brown via mpi-forum <mpi-forum(a)lists.mpi-forum.org> wrote: > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co… 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 >>> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fjeffhammon… >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mpi… > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mpi… _______________________________________________ mpi-forum mailing list mpi-forum(a)lists.mpi-forum.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mpi…

1 0

Re: [Mpi-forum] why do we only support caching on win/comm/datatype?
by Koziol, Quincey 18 Jan '23

18 Jan '23

“third” on attributes are necessary for MPI. HDF5 uses them to make certain that cached file data gets written to the file (and it is closed properly) before MPI_Finalize() in the world model. Frankly, I wasn’t paying enough attention to the sessions work ten years ago and didn’t realize that they aren’t available as a mechanism for getting this same action when a session is terminated. This is a critical need to avoid corrupting user data. Jeff - please add me to your work on adding attributes to requests and ops, and I’ll write text for adding attributes to sessions. Quincey > On Jan 16, 2023, at 2:10 PM, Jed Brown via mpi-forum <mpi-forum(a)lists.mpi-forum.org> wrote: > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > 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 > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

1 0

RMA WG reading/vote announcements
by Joseph Schuchart 18 Jan '23

18 Jan '23

1 0

Additional Reading #669 at MPI-Forum meeting Feb 1+8, 2023 (related to Terms)
by Rolf Rabenseifner 18 Jan '23

18 Jan '23

Dear MPI forum members, dear Wesley, I would like to have the following issues (and their PRs) read. Issue 669 / PR788 Add operation state "enabled" and "local calls" into Terms Issue https://github.com/mpi-forum/mpi-issues/issues/669 PR788 https://github.com/mpi-forum/mpi-standard/pull/788 pdf https://github.com/mpi-forum/mpi-standard/files/10448462/mpi41-report_Issue… Best regards Rolf -- Dr. Rolf Rabenseifner . . . . . . . . . .. . . rabenseifner(a)hlrs.de . High Performance Computing Center (HLRS) . . . ++49(0)711/685-65530 . University of Stuttgart . . . . . . www.hlrs.de/people/rabenseifner . Nobelstr. 19, 70569 Stuttgart, Germany

1 0