Page 1 of 2

love.timer.sleep resolution test

Posted: Mon Sep 27, 2021 7:22 am
by grump
I have doubts about the use of love.timer.sleep(0.001) in the default love.run, especially after reading this.

The uncertainty is killing me, but I don't have an up-to-date Windows installation to verify this, so I would like to ask you guys to run this small test and report your results and your OS version. For science.

sleep.png
sleep.png (17.13 KiB) Viewed 6302 times
Thanks!

Re: love.timer.sleep resolution test

Posted: Mon Sep 27, 2021 8:02 am
by darkfrei
grump wrote: Mon Sep 27, 2021 7:22 am I have doubts about the use of love.timer.sleep(0.001) in the default love.run, especially after reading this.

The uncertainty is killing me, but I don't have an up-to-date Windows installation to verify this, so I would like to ask you guys to run this small test and report your results and your OS version. For science.


sleep.png

Thanks!
https://youtu.be/YuTPZOpPtdU

And you cannot set the sleep less than 0.001 s.

Re: love.timer.sleep resolution test

Posted: Mon Sep 27, 2021 8:51 am
by grump
Thanks. Looks better than expected. What version of Windows is this?
darkfrei wrote: Mon Sep 27, 2021 8:02 am And you cannot set the sleep less than 0.001 s.
You can wait 0 ms and give other threads a chance to run, or not wait at all. It's not optimal but better than possibly spending 90% of your frame time sleeping, as the linked article suggests.

Re: love.timer.sleep resolution test

Posted: Mon Sep 27, 2021 9:09 am
by togFox
Image

Windows 10 i5 16 gb ram yadda yadda whateva

Re: love.timer.sleep resolution test

Posted: Mon Sep 27, 2021 10:18 am
by pgimeno
My screen looks pretty much like your snapshot, Linux included, except instead of 10.2 I get 10.1, and the font is less blurred. I get a boring .1 everywhere. Debian Stretch (9.6) system.

Re: love.timer.sleep resolution test

Posted: Mon Sep 27, 2021 12:50 pm
by slime
love - via SDL - calls timeBeginPeriod(1) in its own process in order to allow Sleep to work when 1ms is requested on Windows, so the article in the original post doesn't really apply since it's just talking about a change to what happens to other processes.

That being said you should never rely on it being extremely precise, but it's generally fine to assume it will be within 1-2ms of the target duration.

Re: love.timer.sleep resolution test

Posted: Mon Sep 27, 2021 7:11 pm
by zorg
Win7; Mine's mostly on-time for each timer, if it isn't, it's less by .1 rather than more.

Re: love.timer.sleep resolution test

Posted: Tue Sep 28, 2021 11:30 am
by grump
slime wrote: Mon Sep 27, 2021 12:50 pm love - via SDL - calls timeBeginPeriod(1) in its own process in order to allow Sleep to work when 1ms is requested on Windows
That is reassuring and alleviates my worries.

I'm still unsure about the unconditional sleep. Windows 10 tends to sleep around 2 ms. That's ~1/8 of the frame time at 60 fps and in the worst case that makes the difference between running at 60 fps and 30 fps with vsync on, even though it could run at 60 fps if it wasn't for the sleep.

It's no big deal to make your own love.run, but maybe this is something that you should be able to opt-out of more easily.

Re: love.timer.sleep resolution test

Posted: Tue Sep 28, 2021 12:55 pm
by slime
If you have a suggestion that's more robust while providing similar benefits I'm interested, but as-is the heat / battery drain / CPU usage benefits far outweigh the ~1ms extra cost in my opinion. Apps that struggle to keep below 16ms/frame can opt in to remove the 1ms sleep if they want.

The 2ms sleep you observe in Windows can drop to 1ms under heavy load, so it's not as bad as you might think when looking at an empty project. I believe the OS is just opting to use less power when it knows the majority of time in an app is spent sleeping, so it wakes it up slightly less frequently than when the majority of time in the app is spent doing actual work.

Re: love.timer.sleep resolution test

Posted: Tue Sep 28, 2021 4:52 pm
by milon
pgimeno wrote: Mon Sep 27, 2021 10:18 am My screen looks pretty much like your snapshot, Linux included, except instead of 10.2 I get 10.1, and the font is less blurred. I get a boring .1 everywhere. Debian Stretch (9.6) system.
This, except I rarely see a brief .0 which very quickly becomes .1 again. It can appear on any random line, it seems.
I'm running Linux Mint 20.2 Uma (based on Ubuntu 20.04 Focal).