Re: [mpich-devel] MPI_Recv, blocking call concept
Jeff Hammond <[email protected]> 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.
participants (1)
-
Jed Brown