Just try out sleeping for 0 ms, this gives the OS the chance to check if there are any other processes currently needing some time or else go back to your program. Usually the CPU load goes also down ...
At least for windowed programs this makes sense, if you have a fullscreen game, why not use 100% of the CPU power like others mentioned before? Thats how games work ^^
How to prevent game from taking 99% CPU?
Quote:Original post by abnormal
Just try out sleeping for 0 ms, this gives the OS the chance to check if there are any other processes currently needing some time or else go back to your program. Usually the CPU load goes also down ...
Lemme respond to that with a quote from one of the above posts:
Quote:
That's correct. Sleep just lets the OS know the app doesn't need the CPU time, but not sleeping doesn't mean the OS wont take it anyway.
The OS doesn't need your permission to check whether other processes need execution time. It just takes what it needs, and distributes leftover time between the processes that are interested. So no, you dont need to call sleep, not ever for 0 ms.
Quote:
At least for windowed programs this makes sense, if you have a fullscreen game, why not use 100% of the CPU power like others mentioned before? Thats how games work ^^
They do the same in Windowed mode.
The only rule is to not take CPU time you don't need. If you have nothing to do, you should definitely call Sleep. If you do have something to do, then do it, and leave the OS to decide how much time you should actually get. If you get 99% CPU, it just means no one else wanted the time.
Quote:Original post by SpoonbenderQuote:That's correct. Sleep just lets the OS know the app doesn't need the CPU time, but not sleeping doesn't mean the OS wont take it anyway.
The OS doesn't need your permission to check whether other processes need execution time. It just takes what it needs, and distributes leftover time between the processes that are interested. So no, you dont need to call sleep, not ever for 0 ms.
msdn sleep link
Quote:MSDN
Parameters
millisecondsTimeout
The number of milliseconds for which the thread is blocked. Specify zero (0) to indicate that this thread should be suspended to allow other waiting threads to execute. Specify Infinite to block the thread indefinitely.
Things are fairly simple. Windows give each thread a timeslice. When a thread's timeslice ends, Windows takes the control off that thread and gives it to the next, regardless whether Sleep() was called or not. The whole thing goes on circularly(or by whatever method the OS uses for distributing time to its threads) for all threads. Whether you call Sleep() or not from your thread doesn't matter, all threads will get their slice. If, however, a thread calls Sleep(0), it gives up the remaining time from its timeslice to the OS, which gives it to a thread of equal priority.
For example, if a thread's timeslice is 200ns and you don't call Sleep(), your thread will be suspended after 200ns, and another one(if other threads exist) will be executed. If you call Sleep() at 100ns, your thread will be suspended at that time and give up the remaining 100ns. Nothing is forcing you to call Sleep(), those 200ns were given to you by the OS and you have the right to use them all. It's not like 16-bit Windows which had pseudo-multithreading and,IIRC, you had to call Yield() in order to allow another thread to execute.
For example, if a thread's timeslice is 200ns and you don't call Sleep(), your thread will be suspended after 200ns, and another one(if other threads exist) will be executed. If you call Sleep() at 100ns, your thread will be suspended at that time and give up the remaining 100ns. Nothing is forcing you to call Sleep(), those 200ns were given to you by the OS and you have the right to use them all. It's not like 16-bit Windows which had pseudo-multithreading and,IIRC, you had to call Yield() in order to allow another thread to execute.
If you use the 'wait for vsync' parameter, your app will be suspended until the swapping of buffers can go on. It means, it will make your app sleep until it is ready to swap the screen buffers. Effectively making your game loop (assuming it is also the render loop) run at the screen refresh rate.
As other says, Sleep( 0 ) make your app give up the remaining of his timeslice. If you don't want to use vsync, that would be a good way to limit the framerate, let say to 100Hz. I think Id's Quake2 engine uses something like:
while( isGameGoingTooFast() )
{
Sleep( 0 );
}
Even with 'vsync on', if the game loop isn't going fast enough to reach the refresh rate of the screen, the CPU will be floored anyway.
As other says, Sleep( 0 ) make your app give up the remaining of his timeslice. If you don't want to use vsync, that would be a good way to limit the framerate, let say to 100Hz. I think Id's Quake2 engine uses something like:
while( isGameGoingTooFast() )
{
Sleep( 0 );
}
Even with 'vsync on', if the game loop isn't going fast enough to reach the refresh rate of the screen, the CPU will be floored anyway.
Quote:Original post by SpoonbenderQuote:
That's correct. Sleep just lets the OS know the app doesn't need the CPU time, but not sleeping doesn't mean the OS wont take it anyway.
The OS doesn't need your permission to check whether other processes need execution time. It just takes what it needs, and distributes leftover time between the processes that are interested. So no, you dont need to call sleep, not ever for 0 ms.
Good thing I didn't say the OS needs your permission then. Sleep *does* let the OS know you're finished with your current timeslice since it implicitly yields.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
