<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">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. <div><br></div><div>Casper critically depends on window attributes.</div><div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>Jeff</div><div><br><div dir="ltr">Sent from my iPhone</div><div dir="ltr"><br><blockquote type="cite">On 16. Jan 2023, at 20.27, Holmes, Daniel John <daniel.john.holmes@intel.com> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style>@font-face { font-family: "Cambria Math"; }
@font-face { font-family: Calibri; }
p.MsoNormal, li.MsoNormal, div.MsoNormal { margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; }
a:link, span.MsoHyperlink { color: blue; text-decoration: underline; }
span.EmailStyle18 { font-family: Calibri, sans-serif; color: windowtext; }
.MsoChpDefault { font-family: Calibri, sans-serif; }
@page WordSection1 { size: 612pt 792pt; margin: 72pt; }
div.WordSection1 { page: WordSection1; }</style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Hi Jeff,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">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”.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">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).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Removal of attributes entirely – blocked by back-compat because usage is known to exist.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Expansion of attributes orthogonally – blocked by “attributes in MPI suck” accusations.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Result – inconsistency in the interface that no-one wants to tackle.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Best wishes,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Dan.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> mpi-forum <mpi-forum-bounces@lists.mpi-forum.org>
<b>On Behalf Of </b>Jeff Hammond via mpi-forum<br>
<b>Sent:</b> 16 January 2023 14:40<br>
<b>To:</b> MPI Forum <mpi-forum@lists.mpi-forum.org><br>
<b>Cc:</b> Jeff Hammond <jeff.science@gmail.com><br>
<b>Subject:</b> [Mpi-forum] why do we only support caching on win/comm/datatype?<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">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?<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><a href="https://github.com/mpi-forum/mpi-issues/issues/664">https://github.com/mpi-forum/mpi-issues/issues/664</a> has some details but since I do not understand how MPICH generates the MPI bindings, I only implemented the back-end MPIR
code.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Jeff<br clear="all">
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">-- <o:p></o:p></p>
<div>
<p class="MsoNormal">Jeff Hammond<br>
<a href="mailto:jeff.science@gmail.com" target="_blank">jeff.science@gmail.com</a><br>
<a href="http://jeffhammond.github.io/" target="_blank">http://jeffhammond.github.io/</a><o:p></o:p></p>
</div>
</div>
</div>
</div>
</div></blockquote></div></body></html>