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@mpich.org
To manage subscription options or unsubscribe:
https://lists.mpich.org/mailman/listinfo/discuss

_______________________________________________
discuss mailing list     discuss@mpich.org
To manage subscription options or unsubscribe:
https://lists.mpich.org/mailman/listinfo/discuss