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

[Maksym Planeta]

Hi,

have a look into this paper:

A Case for Application-Oblivious Energy-Efficient MPI Runtime
A. Venkatesh , A. Vishnu , K. Hamidouche , N. Tallent , D. K. Panda , D. 
Kerbyson , and A. Hoise
Supercomputing 2015, Nov 2015

That's about MVAPICH2, not MPICH, but they share a lot of code base.

On 09/29/2016 04:07 PM, 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
>

-- 
Regards,
Maksym Planeta

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5174 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.mpich.org/pipermail/discuss/attachments/20160929/c6e0aead/attachment.p7s>
-------------- next part --------------
_______________________________________________
discuss mailing list     discuss at mpich.org
To manage subscription options or unsubscribe:
https://lists.mpich.org/mailman/listinfo/discuss