[mpich-devel] MPI_Recv, blocking call concept

[Jed Brown]

Ali MoradiAlamdarloo <timndus at gmail.com> writes:

> On Fri, Jun 8, 2018 at 2:30 AM, Jeff Hammond <jeff.science at gmail.com> 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 <jeff.science at gmail.com> 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 <jed at jedbrown.org> 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.