<div dir="ltr"><div dir="ltr">In addition to op, hardware acceleration can also be tied to datatype.  For example, MPI_SUM may be accelerated for integer types, but not floating point types.  I think it's possible to support such a query using the recent tools interfaces.  I created a ticket, so we remember to discuss: <a href="https://github.com/mpiwg-rma/rma-issues/issues/6">https://github.com/mpiwg-rma/rma-issues/issues/6</a></div><div dir="ltr"><br></div><div> ~Jim.</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Sep 12, 2018 at 4:26 AM Joseph Schuchart via mpiwg-rma <<a href="mailto:mpiwg-rma@lists.mpi-forum.org">mpiwg-rma@lists.mpi-forum.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Pavan,<br>
<br>
I listened in for the MPI-RMA WG telco yesterday and found some <br>
interesting points in it. In particular, I am interested in the <br>
discussion on atomics and same_op. I support the notion that MPI should <br>
choose a conservative default to make sure users do not run into <br>
surprising UB because the implementation expects or supports only <br>
same_op, which the user may not be aware of.<br>
<br>
As a developer of a framework built on top of MPI RMA I would also be <br>
interested in getting information from the MPI implementation on which <br>
atomic operations are actually supported in hardware on the current <br>
system, which would allow me to pick different implementations of a <br>
specific feature to fully exploit the available hardware capabilities <br>
(similar to C++ `std::atomic_is_lock_free`). Are there any plans to <br>
provide such an interface? This could be used in combination with an <br>
info key (say `native_op`) that promises that the user will only use a <br>
mix of operations that are supported in hardware, which would then avoid <br>
the required fall-back to active messages discussed yesterday.<br>
<br>
Last but not least, I am also interested in the shared memory <br>
optimization for collectives (iirc, MPI_DISCARD?). I couldn't find an <br>
issue on Github on this. Is there any publicly available information you <br>
can share?<br>
<br>
Any input would be much appreciated.<br>
<br>
Many thanks in advance,<br>
Joseph<br>
<br>
On 09/10/2018 09:21 PM, Balaji, Pavan via mpiwg-rma wrote:<br>
> <br>
> <br>
> _______________________________________________<br>
> mpiwg-rma mailing list<br>
> <a href="mailto:mpiwg-rma@lists.mpi-forum.org" target="_blank">mpiwg-rma@lists.mpi-forum.org</a><br>
> <a href="https://lists.mpi-forum.org/mailman/listinfo/mpiwg-rma" rel="noreferrer" target="_blank">https://lists.mpi-forum.org/mailman/listinfo/mpiwg-rma</a><br>
> <br>
_______________________________________________<br>
mpiwg-rma mailing list<br>
<a href="mailto:mpiwg-rma@lists.mpi-forum.org" target="_blank">mpiwg-rma@lists.mpi-forum.org</a><br>
<a href="https://lists.mpi-forum.org/mailman/listinfo/mpiwg-rma" rel="noreferrer" target="_blank">https://lists.mpi-forum.org/mailman/listinfo/mpiwg-rma</a><br>
</blockquote></div>