Re: [mpich-discuss] Why does MPICH perform busy wait?
I suggest, to whoever will address this issue, to have a look at how C++ >= 2011 handles the wait on a condition variable. I think the technique to be used should be analogous. Best regards, 2016-09-29 16:35 GMT+02:00 Maksym Planeta <[email protected]>:
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 [email protected] To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss
-- Regards, Maksym Planeta
_______________________________________________ discuss mailing list [email protected] To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss
-- Michele De Stefano Linked In <http://it.linkedin.com/in/micheledestefano> mds-utils: a general purpose Open Source library <http://sourceforge.net/projects/mds-utils/> Personal Web Site <http://www.micheledestefano.altervista.org> _______________________________________________ discuss mailing list [email protected] To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss
participants (1)
-
Michele De Stefano