Handmade Hero » Forums » Code » timeBeginPeriod without matching timeEndPeriod
d7samurai
70 posts

innovation through innovation™

#799 timeBeginPeriod without matching timeEndPeriod
3 years, 11 months ago

At line 970-971 in the source code (of day 24), it says

UINT DesiredSchedulerMS = 1;
bool32 SleepIsGranular = (timeBeginPeriod(DesiredSchedulerMS) == TIMERR_NOERROR);

According to the MSDN documentation for the timeBeginPeriod call (http://msdn.microsoft.com/en-us/l...esktop/dd757624%28v=vs.85%29.aspx):

"You must match each call to timeBeginPeriod with a call to timeEndPeriod, specifying the same minimum resolution in both calls. An application can make multiple timeBeginPeriod calls as long as each call is matched with a call to timeEndPeriod."

However, I cannot see that timeEndPeriod is called anywhere in the source?

software development should be a creative exercise, not a technical ordeal
ambiguous.panda
ambiguous panda
11 posts
#801 timeBeginPeriod without matching timeEndPeriod
3 years, 11 months ago

he is not a big fan of unnecessary cleanups, during one of his streams he talked about allowing the os to do the cleaning on exit, and that its up to you to decide what you want to dispose of, i normally do the cleaning manually, feels ikky if i dont.
cmuratori
Casey Muratori
817 posts / 1 project

Casey Muratori is a programmer at Molly Rocket on the game 1935 and is the host of the educational programming series Handmade Hero.

#802 timeBeginPeriod without matching timeEndPeriod
3 years, 11 months ago

We do not ever want to close the period, because we are trying to keep the scheduler at 1ms for the duration of the application.

We could call it at the very end, before the app closes, but I don't actually know if that would have any actual effect.

- Casey
d7samurai
70 posts

innovation through innovation™

#803 timeBeginPeriod without matching timeEndPeriod
3 years, 11 months ago Edited by d7samurai on Dec. 19, 2014, 2:44 p.m.

Yeah, since timeBeginPeriod was called at the very beginning of execution, it was implied that the corresponding timeEndPeriod should be called at the very end - if at all - but I wasn't sure whether it was redundant or not, like if Windows automatically "wraps it up" / does it for you at the termination of the process or something (since it's not a resource, but rather a global Windows thing*).

*"This function affects a global Windows setting. Windows uses the lowest value (that is, highest resolution) requested by any process. Setting a higher resolution can improve the accuracy of time-out intervals in wait functions. However, it can also reduce overall system performance, because the thread scheduler switches tasks more often. High resolutions can also prevent the CPU power management system from entering power-saving modes. Setting a higher resolution does not improve the accuracy of the high-resolution performance counter."

software development should be a creative exercise, not a technical ordeal
d7samurai
70 posts

innovation through innovation™

#805 timeBeginPeriod without matching timeEndPeriod
3 years, 11 months ago Edited by d7samurai on Dec. 19, 2014, 12:06 p.m.

Turns out that the raised timer frequency is indeed automatically cancelled by Windows when the process terminates. So nevermind *that* point, but anyway:

https://randomascii.wordpress.com...imer-resolution-megawatts-wasted/

"When a process calls timeBeginPeriod this frequency request is in force until it is explicitly cancelled with timeEndPeriod or until the process terminates. Most programs (including my own test program below) never call timeEndPeriod, relying instead on Windows process cleanup. This works, and is reasonable for any application that needs the timer frequency high for its entire lifetime, but for any process whose lifetime may outlast its need for a high frequency timer, it’s time to start calling timeEndPeriod. As Microsoft recommends, this includes movie players that are paused, and games that are minimized. It also includes web browsers that do not currently need high-resolution timers, or are running on battery power."

software development should be a creative exercise, not a technical ordeal
ambiguous.panda
ambiguous panda
11 posts
#806 timeBeginPeriod without matching timeEndPeriod
3 years, 11 months ago Edited by ambiguous panda on Dec. 19, 2014, noon

after reading the documentation more closely, it might be a good idea to call timeEndPeriod on WM_ACTIVATE, SC_MINIMIZE and SC_SCREENSAVE, the article you linked to mentioned that it can effect battery power by almost 25%

also we should call timeGetDevCaps to query the lowest possible value the system is capable of, instead of hard coding it to 1

is there any plans in the future to dynamically switch back and forth between the 33ms wall clock we currently have, and the windows message pump when we go into idle mode ?
mmozeiko
Mārtiņš Možeiko
1831 posts / 1 project
#808 timeBeginPeriod without matching timeEndPeriod
3 years, 11 months ago

When window looses focus you could do even better - pause rendering, stop calling GameUpdateAndRender and most importantly change PeekMessage to GetMessage. This way application will consume least possible CPU time.
ambiguous.panda
ambiguous panda
11 posts
#809 timeBeginPeriod without matching timeEndPeriod
3 years, 11 months ago Edited by ambiguous panda on Dec. 19, 2014, 12:32 p.m.

we can still render on WM_PAINT and a longer wall clock during idle, so you cant cheat by pausing the game with alt-tab

this is kinda off-topic, and probably wont even be a thing for another month or so. :(
Bigpet
19 posts
#810 timeBeginPeriod without matching timeEndPeriod
3 years, 11 months ago Edited by Bigpet on Dec. 19, 2014, 4:02 p.m.

I can confirm that this is not a "useless cleanup". This needs to be called before your process ends.

I both tested this in another project of mine and there's a huge writeup of the effects here: https://randomascii.wordpress.com...imer-resolution-megawatts-wasted/

I just want to highlight this sentence
“Some applications reduce this to 1 ms, which reduces the battery run time on mobile systems by as much as 25 percent.”

edit: nevermind, that already got posted, but I can't delete my post :(

edit2: weird, tested again, it does seem to reset on my current system.
Kladdehelvete
Livet Ersomen Strøm
164 posts
#824 timeBeginPeriod without matching timeEndPeriod
3 years, 11 months ago

a good alternative is

SetWaitableTimerEx function

lpDueTime [in]

The time after which the state of the timer is to be set to signaled, in 100 nanosecond intervals.

sFence
RomulusTFM
Timothy McCarthy
52 posts
#4971 timeBeginPeriod without matching timeEndPeriod
3 years, 1 month ago

AFAIK, timeBeginPeriod affects the granularity of ::Sleep(). I'm only at day 19 right now so this premise may not hold very long.

Will there more than one call to ::Sleep?

If there is only one call than it can be bracketed by begin-end period calls. This would avoid dealing with losing focus, etc.

I'm not sure how a 1 ms timerbeginPeriod affects thread behavior, though.

- tim
btaylor2401
Bryan Taylor
55 posts
#4972 timeBeginPeriod without matching timeEndPeriod
3 years, 1 month ago

RomulusTFM
AFAIK, timeBeginPeriod affects the granularity of ::Sleep(). I'm only at day 19 right now so this premise may not hold very long.

Will there more than one call to ::Sleep?

If there is only one call than it can be bracketed by begin-end period calls. This would avoid dealing with losing focus, etc.

I'm not sure how a 1 ms timerbeginPeriod affects thread behavior, though.

- tim

There is one call to Sleep *per frame*. We don't want to be setting and unsetting the timer resolution every frame. So we set it once before our main loop and leave it alone until the process ends.
RomulusTFM
Timothy McCarthy
52 posts
#4973 timeBeginPeriod without matching timeEndPeriod
3 years, 1 month ago

Right. There is also a MS note someplace saying that you should not keep changing it.

- tim