“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
