[Mpi-forum] why do we only support caching on win/comm/datatype?

[Jeff Hammond]

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 at gmail.com
http://jeffhammond.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpi-forum/attachments/20230116/d9b826e3/attachment-0001.html>