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@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@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://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.scie...@gmail.com >>>>> http://jeffhammond.github.io/ >>> _______________________________________________ >>> 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 > > _______________________________________________ > 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