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

Reply via email to