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

[Jed Brown via mpi-forum]

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  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 
>>  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  On Behalf Of Jeff 
>> Hammond via mpi-forum
>> Sent: 16 January 2023 14:40
>> To: MPI Forum 
>> Cc: Jeff Hammond 
>> 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

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

[Jeff Hammond via mpi-forum]

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  
> 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  On Behalf Of Jeff 
> Hammond via mpi-forum
> Sent: 16 January 2023 14:40
> To: MPI Forum 
> Cc: Jeff Hammond 
> 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

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

[Holmes, Daniel John via mpi-forum]

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  On Behalf Of Jeff 
Hammond via mpi-forum
Sent: 16 January 2023 14:40
To: MPI Forum 
Cc: Jeff Hammond 
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] why do we only support caching on win/comm/datatype?

[Jeff Hammond via mpi-forum]

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