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

[Jed Brown]

On Fri, Sep 21, 2012 at 10:49 AM, N.M. Maclaren <nmm1 at cam.ac.uk> wrote:

> 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!
>

This is totally different than passive one-sided because it has a request
and isn't guaranteed to make progress when not in the MPI stack. An
implementation using comm threads also need not use interrupts.

I haven't heard of any system that supports ALL combinations of built-in
ops and datatypes in dedicated hardware, therefore you have some code
running in a context where it could call the user-defined MPI_Op.

A lot of the controversy seems to come down to not trusting the user to be
able to write a pure function that is actually pure. You should realize
that in many cases (including the most important ones to me), the MPI_Op is
just SUM or MAX, but applied to datatypes that MPI does not cover (e.g.
quad precision). The other concern people raised when this issue was last
discussed for one-sided was the need for an API allowing collective
specification of MPI_Ops. That isn't needed here because the reduction is
specified by the receiving rank.


> 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.
>

I hate this. It will will force the application to poll (or pay the penalty
of receiving the messages in a fixed order, which may slow things down more
than requiring a copy).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpi-forum/attachments/20120921/e508d8d1/attachment-0001.html>