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
