Joseph, Jim, all, I had brought up something similar to this during MPI-2.2. The biggest pushback on that proposal was that the MPI implementation might choose to decide what to support in hardware based on dynamic circumstances. The example given (by JeffS at that time) was memory registration. Something along these lines: I can do this in hardware as long as I can register the user memory, but when such memory registration fails I'll need to fallback to active messages. You are welcome to open the discussion again, but my guess is that the same pushback will still be there. -- Pavan

On Sep 12, 2018, at 7:21 AM, Jim Dinan via mpiwg-rma <[email protected]> wrote:

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: https://github.com/mpiwg-rma/rma-issues/issues/6

~Jim.

On Wed, Sep 12, 2018 at 4:26 AM Joseph Schuchart via mpiwg-rma <[email protected]> wrote: Pavan,

I listened in for the MPI-RMA WG telco yesterday and found some interesting points in it. In particular, I am interested in the discussion on atomics and same_op. I support the notion that MPI should choose a conservative default to make sure users do not run into surprising UB because the implementation expects or supports only same_op, which the user may not be aware of.

As a developer of a framework built on top of MPI RMA I would also be interested in getting information from the MPI implementation on which atomic operations are actually supported in hardware on the current system, which would allow me to pick different implementations of a specific feature to fully exploit the available hardware capabilities (similar to C++ `std::atomic_is_lock_free`). Are there any plans to provide such an interface? This could be used in combination with an info key (say `native_op`) that promises that the user will only use a mix of operations that are supported in hardware, which would then avoid the required fall-back to active messages discussed yesterday.

Last but not least, I am also interested in the shared memory optimization for collectives (iirc, MPI_DISCARD?). I couldn't find an issue on Github on this. Is there any publicly available information you can share?

Any input would be much appreciated.

Many thanks in advance, Joseph

On 09/10/2018 09:21 PM, Balaji, Pavan via mpiwg-rma wrote:

...

_______________________________________________ mpiwg-rma mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-rma

_______________________________________________ mpiwg-rma mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-rma _______________________________________________ mpiwg-rma mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-rma