[mpiwg-rma] RMA WG Telecon

[Balaji, Pavan]

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 <mpiwg-rma at lists.mpi-forum.org> 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 <mpiwg-rma at lists.mpi-forum.org> 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
> > mpiwg-rma at lists.mpi-forum.org
> > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-rma
> > 
> _______________________________________________
> mpiwg-rma mailing list
> mpiwg-rma at lists.mpi-forum.org
> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-rma
> _______________________________________________
> mpiwg-rma mailing list
> mpiwg-rma at lists.mpi-forum.org
> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-rma