<meta http-equiv="Content-Type" content="text/html; charset=utf-8"><div dir="ltr">There are bunch of ways to address these issues.<div><br></div><div>One can save power while still spinning. See e.g. <a href="http://mug.mvapich.cse.ohio-state.edu/static/media/mug/presentations/2015/mug15-performance_tuning_and_energy_savings_study_with_mvapich2-martin_hilgeman.pdf">http://mug.mvapich.cse.ohio-state.edu/static/media/mug/presentations/2015/mug15-performance_tuning_and_energy_savings_study_with_mvapich2-martin_hilgeman.pdf</a>. LLNL has done something similar.<div><br></div><div>Certain types of passive waiting may not work with shared-memory communication. monitor-mwait would be interesting if not for the ring-0 issue.<br><div><br></div><div>Jeff</div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 29, 2016 at 8:08 AM, Rob Latham <span dir="ltr"><<a href="mailto:robl@mcs.anl.gov" target="_blank">robl@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Your proposal introduces latency. Data centers want power efficiency, but several large classes of applications care about message rate.<br>
<br>
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.<br>
<br>
Also, there are non-spinning channels you can use: e.g. ch3:sock<br>
<br>
It's been something we've been thinking about for a while!<br>
<a href="http://trac.mpich.org/projects/mpich/ticket/79" rel="noreferrer" target="_blank">http://trac.mpich.org/projects<wbr>/mpich/ticket/79</a><span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
==rob</font></span><div><div class="h5"><br>
<br>
<br>
On 09/29/2016 09:07 AM, Tim Jammer wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
Hi<br>
<br>
Within my bachelor thesis I come across that the MPICH Implementation<br>
implements a busy wait.<br>
In our application, this leads to a waste of energy as all processes are<br>
spinning in a barrier while one process performs I/O.<br>
<br>
Therefore I want to propse to not wait as busy as it is done now.<br>
On the test system this saves 50% energy compared to busy wait.<br>
My basic prototype implementation causes only a negligible additional<br>
runtime overhead.<br>
<br>
My proposal is to sleep between polling if the communication has not<br>
finished yet.<br>
Within the first few iterations the implementation should not sleep, to<br>
guarantee maximum performance.<br>
But if the communication was not finished right away, the importance of<br>
saving energy grows.<br>
Therefore I propose to sleep and increase this sleeping time after every<br>
polling<br>
up to a maximum value in order to not waste much additional runtime on<br>
waiting.<br>
This will allow the CPU to power down and save energy.<br>
<br>
my basic prototype basically works as follows:<br>
<br>
int stime=0;<br>
while (/* Incoming data does not match the request*/)<br>
{<br>
usleep(stime);<br>
stime++;<br>
// do the actual polling...<br>
<br>
I can imagine, that the user can choose to activate this behaviour (i.e.<br>
with an environment variable) if he wants to save energy.<br>
<br>
I have attached the section of my thesis which describe it more in detail.<br>
<br>
<br>
My question is: was something like this considered before and are there<br>
any arguments why this was not implemented.<br>
<br>
Regards<br>
Tim Jammer<br>
<br>
<br></div></div><span class="">
______________________________<wbr>_________________<br>
discuss mailing list <a href="mailto:discuss@mpich.org" target="_blank">discuss@mpich.org</a><br>
To manage subscription options or unsubscribe:<br>
<a href="https://lists.mpich.org/mailman/listinfo/discuss" rel="noreferrer" target="_blank">https://lists.mpich.org/mailma<wbr>n/listinfo/discuss</a><br>
<br>
</span></blockquote><div class="HOEnZb"><div class="h5">
______________________________<wbr>_________________<br>
discuss mailing list <a href="mailto:discuss@mpich.org" target="_blank">discuss@mpich.org</a><br>
To manage subscription options or unsubscribe:<br>
<a href="https://lists.mpich.org/mailman/listinfo/discuss" rel="noreferrer" target="_blank">https://lists.mpich.org/mailma<wbr>n/listinfo/discuss</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Jeff Hammond<br><a href="mailto:jeff.science@gmail.com" target="_blank">jeff.science@gmail.com</a><br><a href="http://jeffhammond.github.io/" target="_blank">http://jeffhammond.github.io/</a></div>
</div>