[Mpi-forum] Discussion points from the MPI-<next> discussion today

[N.M. Maclaren]

On Sep 21 2012, Jed Brown wrote:
> On Thu, Sep 20, 2012 at 12:14 PM, Jeff Hammond 
> <jhammond at alcf.anl.gov>wrote:
>
>> I would like MPI_(I)RECV_REDUCE, which - as you might guess - does a
>> reduction to the receive buffer instead of a simple write.  This
>> allows one to avoid having to manually buffer incoming messages to be
>> reduced at the receiver.  Torsten and I have discussed it and it seems
>> there are at least a few use cases.
>
>If you do this, _please_ allow a user-defined MPI_Op to be used in the
>reduction (i.e., don't cripple it like one-sided).

On the contrary - that is essential for any kind of sane specification
or implementation of MPI_Irecv_reduce, just as it is for one-sided.
Sorry, but that's needed to get even plausible conformance with any of
the languages MPI is likely to be used from.  MPI_Recv_reduce doesn't
have the same problems.

The point is that none of them allow more-or-less arbitrary functions
to be called asynchronously, and that has been horribly sick in every
modern system that I have looked into in any depth.  It used to work
on some mainframes, but hasn't worked reliably since.  That is precisely
why POSIX has deprecated calling signal handlers asynchronously.  Please
don't perpetrate another feature like passive one-sided!

Even doing it for just built-in types is problematic on some systems,
just as it is for one-sided.  I doubt that there are many such systems
currently in use outside the embedded arena, but there may be some there,
and they may well return to general computing.

A much better idea would be to drop MPI_Irecv_reduce and consider just
MPI_Recv_reduce.


Regards,
Nick Maclaren.