Re: [mpich-devel] MPI_Recv, blocking call concept
Ali MoradiAlamdarloo <[email protected]> writes:
On Fri, Jun 8, 2018 at 2:30 AM, Jeff Hammond <[email protected]> wrote:
It spins because that is optimal for latency and how the shared-memory protocols work.
On Fri, Jun 8, 2018 at 4:22 AM, Jeff Hammond <[email protected]> wrote:
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 Fri, Jun 8, 2018 at 4:48 AM, Jed Brown <[email protected]> wrote:
On the flipside, MPI would be more attractive to some (latency-insensitive) users if the implementations were not so committed to spinning.
I'm trying to have a bit contribution on preparing MPI for next generation of computing systems (Exascale). It seems current MPI implementations cares about latency and performance more than power. I believe future MPI implementations must consider power as a high priority goal so i'm doing something much similar to what @Jeff linked it as my MS.c thesis.
Your assumption is that exascale machines will be homogeneous, filled with dirt-cheap hardware that requires lots of power, and operated by low-wage workers, and also that applications will be highly latency tolerant while also having such atrocious load imbalance that reducing power while waiting on communication will significantly reduce total operating costs? Dystopic.
participants (1)
-
Jed Brown