[mpich-discuss] Why does MPICH perform busy wait?

[Jeff Hammond]

There are bunch of ways to address these issues.

One can save power while still spinning.  See e.g.
http://mug.mvapich.cse.ohio-state.edu/static/media/mug/presentations/2015/mug15-performance_tuning_and_energy_savings_study_with_mvapich2-martin_hilgeman.pdf.
LLNL has done something similar.

Certain types of passive waiting may not work with shared-memory
communication.  monitor-mwait would be interesting if not for the ring-0
issue.

Jeff

On Thu, Sep 29, 2016 at 8:08 AM, Rob Latham <robl at mcs.anl.gov> wrote:

>
> Your proposal introduces latency.  Data centers want power efficiency, but
> several large classes of applications care about message rate.
>
> you don't need usleeep.  There are several event-based system calls you
> could use: sleect(), poll() -- which does not actually poll in most
> implementations.
>
> Also, there are non-spinning channels you can use: e.g. ch3:sock
>
> It's been something we've been thinking about for a while!
> http://trac.mpich.org/projects/mpich/ticket/79
>
>
> ==rob
>
>
>
> On 09/29/2016 09:07 AM, Tim Jammer wrote:
>
>> Hi
>>
>> Within my bachelor thesis I come across that the MPICH Implementation
>> implements a busy wait.
>> In our application, this leads to a waste of energy as all processes are
>> spinning in a barrier while one process performs I/O.
>>
>> Therefore I want to propse to not wait as busy as it is done now.
>> On the test system this saves 50% energy compared to busy wait.
>> My basic prototype implementation causes only a negligible additional
>> runtime overhead.
>>
>> My proposal is to sleep between polling if the communication has not
>> finished yet.
>> Within the first few iterations the implementation should not sleep, to
>> guarantee maximum performance.
>> But if the communication was not finished right away, the importance of
>> saving energy grows.
>> Therefore I propose to sleep and increase this sleeping time after every
>> polling
>> up to a maximum value in order to not waste much additional runtime on
>> waiting.
>> This will allow the CPU to power down and save energy.
>>
>> my basic prototype basically works as follows:
>>
>> int stime=0;
>>     while (/* Incoming data does not match the request*/)
>>     {
>> usleep(stime);
>> stime++;
>> // do the actual polling...
>>
>> I can imagine, that the user can choose to activate this behaviour (i.e.
>> with an environment variable) if he wants to save energy.
>>
>> I have attached the section of my thesis which describe it more in detail.
>>
>>
>> My question is: was something like this considered before and are there
>> any arguments why this was not implemented.
>>
>> Regards
>> Tim Jammer
>>
>>
>> _______________________________________________
>> discuss mailing list     discuss at mpich.org
>> To manage subscription options or unsubscribe:
>> https://lists.mpich.org/mailman/listinfo/discuss
>>
>> _______________________________________________
> discuss mailing list     discuss at mpich.org
> To manage subscription options or unsubscribe:
> https://lists.mpich.org/mailman/listinfo/discuss
>



-- 
Jeff Hammond
jeff.science at gmail.com
http://jeffhammond.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpich.org/pipermail/discuss/attachments/20160929/aaf68bb3/attachment.html>
-------------- next part --------------
_______________________________________________
discuss mailing list     discuss at mpich.org
To manage subscription options or unsubscribe:
https://lists.mpich.org/mailman/listinfo/discuss