[mpich-devel] MPI_Recv, blocking call concept

[Jed Brown]

Jeff Hammond <jeff.science at gmail.com> writes:

> As blocking poll is largely incompatible with low-latency and shared-memory
> protocols, I don't think there is any implementation that is going to do a
> good job at this, since it would not be very appealing to the majority of
> MPI users.  

On the flipside, MPI would be more attractive to some
(latency-insensitive) users if the implementations were not so committed
to spinning.

> The PETSc folks appear to be the biggest proponents of blocking poll
> (solely for purposes of running dozens of MPI processes on their
> laptops, it seems) and they seem to prefer ch3:sock.  I defer to their
> experience as to whether a better implementation exists.

Indeed, the test suite has several tests that use 9-16 ranks and take
less than 1 second even when oversubscribed using ch3:sock, but are
disturbingly slow with modern MPICH.  The conundrum of developers not
being able to debug tests on their laptop and many CI solutions not
being able to execute those tests is reminiscent of the testing fiasco
that is multi-GPU development.