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@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-skjel...@utc.edu [or skjel...@gmail.com] > cell: 205-807-4968 > > From: mpi-forum <mpi-forum-boun...@lists.mpi-forum.org> on behalf of Koziol, > Quincey via mpi-forum <mpi-forum@lists.mpi-forum.org> > Sent: Wednesday, January 18, 2023 12:14 PM > To: Main MPI Forum mailing list <mpi-forum@lists.mpi-forum.org> > Cc: Koziol, Quincey <qkoz...@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@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@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.hol...@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-boun...@lists.mpi-forum.org> On Behalf Of Jeff > >>> Hammond via mpi-forum > >>> Sent: 16 January 2023 14:40 > >>> To: MPI Forum <mpi-forum@lists.mpi-forum.org> > >>> Cc: Jeff Hammond <jeff.scie...@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.com%2Fmpi-forum%2Fmpi-issues%2Fissues%2F664&data=05%7C01%7Ctony-skjellum%40utc.edu%7C71288300412347af22bf08daf977ebd0%7C515813d9717d45dd9eca9aa19c09d6f9%7C0%7C0%7C638096590702699453%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=OXCxZASNLE2rJ8t8UWEwEzm5rkYwQZ25HpFU57ZECEA%3D&reserved=0 > >>> 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.scie...@gmail.com > >>> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fjeffhammond.github.io%2F&data=05%7C01%7Ctony-skjellum%40utc.edu%7C71288300412347af22bf08daf977ebd0%7C515813d9717d45dd9eca9aa19c09d6f9%7C0%7C0%7C638096590702699453%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=uIdErXggxKjgBJiyfwqmEGTL%2BTk8vNwBdyWqReClTB0%3D&reserved=0 > >> _______________________________________________ > >> mpi-forum mailing list > >> mpi-forum@lists.mpi-forum.org > >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mpi-forum.org%2Fmailman%2Flistinfo%2Fmpi-forum&data=05%7C01%7Ctony-skjellum%40utc.edu%7C71288300412347af22bf08daf977ebd0%7C515813d9717d45dd9eca9aa19c09d6f9%7C0%7C0%7C638096590702699453%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=08Xt3YjjE%2BXjjDLeix%2FCek6%2Fr6NwTNxUbwSc0GDGju0%3D&reserved=0 > > _______________________________________________ > > mpi-forum mailing list > > mpi-forum@lists.mpi-forum.org > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mpi-forum.org%2Fmailman%2Flistinfo%2Fmpi-forum&data=05%7C01%7Ctony-skjellum%40utc.edu%7C71288300412347af22bf08daf977ebd0%7C515813d9717d45dd9eca9aa19c09d6f9%7C0%7C0%7C638096590702699453%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=08Xt3YjjE%2BXjjDLeix%2FCek6%2Fr6NwTNxUbwSc0GDGju0%3D&reserved=0 > > _______________________________________________ > mpi-forum mailing list > mpi-forum@lists.mpi-forum.org > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mpi-forum.org%2Fmailman%2Flistinfo%2Fmpi-forum&data=05%7C01%7Ctony-skjellum%40utc.edu%7C71288300412347af22bf08daf977ebd0%7C515813d9717d45dd9eca9aa19c09d6f9%7C0%7C0%7C638096590702699453%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=08Xt3YjjE%2BXjjDLeix%2FCek6%2Fr6NwTNxUbwSc0GDGju0%3D&reserved=0 > _______________________________________________ > mpi-forum mailing list > mpi-forum@lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpi-forum
_______________________________________________ mpi-forum mailing list mpi-forum@lists.mpi-forum.org https://lists.mpi-forum.org/mailman/listinfo/mpi-forum
