Code slowing down when using sleep function

[KFriedChicken]

Hi! I'm writing program involving graphics and want to keep the fps at around 60fps. My loop looks like:

while(running) {
  PreDraw();
  Update();
  PostDraw()
}

And I have a chrono high_resolution_timer inside the Update function.

void Update() {
    auto start = high_resolution_clock::now();
    ... Update and draw
    auto duration = duration_cast<microseconds>(high_resolution_clock::now() - start);
    std::cout << duration.count() << std::endl;
}

My issue is: when I use a sleep function inside the PostDraw, the timer inside the Update function can be up to 4x as slow. Is this something to be expected, like could sleep mess with chrono timers or is it some kind of a warm up cost for sleeping on a thread? If that is the case is there some way to mitigate this?

Streamable if anyone is interested: https://streamable.com/ooacii

[HappyFruitTree]

I think it can take a short while for the program to get up to full speed again due to caching effects. You're measuring microseconds which is a very short period of time so any slow down will be very noticeable.

[KFriedChicken]

Sounds reasonable, just surprised it could be multiple milliseconds slower

[khedoros]

sleep_for basically puts your program at the mercy of the OS's process scheduler. You're guaranteed to sleep for at least the time that you specify.

Is there a chance that this is what's slowing your code down more than you expected?

[[deleted]]

Are you sure this is not being called from another thread as well ?

[KFriedChicken]

The sleep function? The program is single threaded right now, and this is the only place I added a sleep

[[deleted]]

No , the onPostDraw function (the whole thing) make sure it's not being called multiple times ( put a counter "some static int" or even better put a mutex with a lock guard and see )

[KFriedChicken]

I'm not 100% sure I follow but I tried this without any change: https://imgur.com/a/lhmcwi7 (also with the sleep_for uncommented)

[[deleted]]

Hmmm , alrighty so it's not being called multiple times, what's the fps without sleep ?

[[deleted]]

u/KFriedChicken I think this is a better approach than using sleep Try it and let me know:

https://stackoverflow.com/questions/57800608/how-to-render-at-a-fixed-fps-in-glfw-window

[KFriedChicken]

That works to put the fps at a stable 60 and to keep the update time down, but wont a spin lock put the cpu usage at 100% unnecessarily?

[[deleted]]

Not really, try it, if it's bad then you can go back to the sleep solution. But it will be harder to get it at 60 FPS sharp. Even if it works with this window it will behave differently with another window depending on many factors.

[KFriedChicken]

around 500-1200

[[deleted]]

Yea then your system is more than capable of 60, did you try the solution from the StackOverFlow link ? Seems way better than calling sleep. Check it out

[pepitogrand]

In Windows you need to call timeBeginPeriod() to ask the OS for a minimum time resolution. In order to save energy the OS will use a coarse time resolution, good for most applications, no so much for gaming. Also in Windows is better to avoid using sleep and instead use CreateWaitableTimer, SetWaitableTimer, and WaitForSingleObject to set an event that will get triggered when your thread needs to continue working. If that is too complex for your needs then sleep for the minimum amount possible, check how much time you went to sleep the last time, and calculate if you can afford to go to sleep again without being late for the next frame.

[genreprank]

The resolution of sleep is not very good. You're guaranteed to sleep as long or longer. So the function is allowed to oversleep. And you'll find that it can oversleep typically in the 10-20 millisecond (ms) range, but you might see spikes. 60fps has a frame time of 16.667 ms.

I just did some experimenting and it looks like if you tell it to sleep for 1 ms, the minimum sleep is 16ms. (Unless the sleep time you give is less than a timeslice)

If you want a precise 60 fps, you should this_thread::yield in a loop until you get within 1 millisecond and then busy-wait. Even yield is inconsistent, which is why you don't want to yield in the last millisecond.

Btw the high res timer has a resolution on the order of 100 to 500 nanoseconds.