Making an Accurate Sleep() Function

https://blat-blatnik.github.io/computerBear/making-accurate-sleep-function/

by joemanaco • 4 years ago

61 51 4 years ago

blat-blatnik.github.io

You could also drive this using an audio queue which uses hardware to generate the timer events.

kevingadd3• 4 years ago

Unfortunately history has shown that you can't necessarily lean on the audio hardware to give you a stable, reliable clock. Part of the reason Windows moved to doing all its audio mixing in software (a long time ago at this point) was that hardware audio devices and/or drivers tended to be really bad at providing reliable clocks. See this random example from google results:

https://duc.avid.com/showthread.php?t=334589

Winamp had a ton of special purpose code in it just to compensate for bad clocking and timing in consumer sound cards so that you could play back audio at proper rates without gaps or glitches.

Mobile seems to be no better - I remember getting fed up playing rhythm games on a Motorola phone I owned because, I kid you not, the hardware audio clock would occasionally run backwards.

drewcoo• 4 years ago

This seems like an anti-pattern.

I usually tell people that sleeps only belong in one place in their code and they should make linters complain if it pops up anywhere else. The place is the method they call to poll. And even then it's better to wait for something than poll to see if we're ready.

This, though, seems to be trying to sleep to slow down frame rate. What the? Maybe it's intended as some way to make all users' experiences suck equally even if they have fast boxes. Maybe. And depending on the actual scenario maybe it makes sense to handle this with a "better" sleep.

The problem as stated is not a solved problem because it's not generally anything anyone would want to do.

In fact, people might have left this intentionally hard to do to discourage its use.

singron2• 4 years ago

Depending on the graphics api, something needs to sleep somewhere to get decent latency. E.g. in vulkan, if the present mode is fifo, then rendering frames as fast as possible will fill the swapchain with stale frames that won't be presented for a while. It can be a lot better to sleep and render the frame right before it can be presented. But if you sleep a little too long, you will miss the frame, so you need a better sleep function like this.

bsder• 4 years ago

The problem with all the modern graphics APIs isn't sleep()--the graphics card generally can be filled to 100%, and you kick off another render when the swapchain releases a frame.

The problem is knowing how long the actual render is going to take. Scenes can vary vastly in complexity and predicting how long they will take to render a priori is extremely difficult.

devit• 4 years ago

That's what vsync is for.

And despite what some people and games seem to think, vsync isn't an optional feature that you can turn on or off, it's something that must always be enabled since it's essential to display correct graphics.

nemothekid2• 4 years ago

I've used this exact pattern before when designing a homegrown kiosk display renderer with an immediate mode GUI; and I think it is pretty common in games as well (this is how Raylib's renderer works). You could push frames as fast possible, but you will chew up the CPU doing inefficient work and overload the hardware needlessly. If you have something like a physics engine you may also want to design a physics loop that runs every X milliseconds (again, if you let it run as fast as possible, the game world will be in super speed; there have been reports of bad developers who couple their render loop with the physics loop and once the framerate becomes uncapped, the game becomes unplayable).

monocasa2• 4 years ago

Better than that is a vsync event to wait on.

heavenlyblue2• 4 years ago

again, if you let it run as fast as possible, the game world will be in super speed

Not really, you can calculate how long had passed since the last physics recalculation and use that as a delta between frames.

zamalek• 4 years ago

It's for physics. Writing a [stable] fixed time step simulation is significantly simpler than variable time step.

Tons of games do it (console ports are guilty of fixed 30FPS), and it really sucks.

derefr• 4 years ago

In most cases there's no reason to couple physics to graphics.

The game "is" the physics engine (esp. in cases of networked games); while the graphics engine is simply an "observer" of the output of the physics engine, trying to interpolate/extrapolate graphics frames given a stream of physics frames.

Do physics at 30FPS in one thread; draw graphics as fast as you can in a separate thread; and at the beginning of each render frame, get the latest physics integration-state, and how much time it's been since it was calculated, and extrapolate object displacements+rotations (incl. the camera) linearly from existing velocities. Those changes will be so small, and corrected by the next physics-step so soon, that it'll almost always look correct.

The only reason to not do this, is if you can't afford concurrent execution (i.e. you only have a single CPU core and interrupts are expensive), and you also don't have a practical Lowest Common Multiple frequency to run an event-loop at. Which is something that was maybe true in the gameboy era, but hasn't been true for at least 30 years.

boardwaalk• 4 years ago

There are good reasons to do things at certain times (like polling for input or rendering) or slowing down the render loop (adjustable frame rate cap not necessarily the same as refresh rate), and that's really the end of that.

Thinking this might be "intentionally hard" rather than "non-realtime operating systems are just sloppy" is silly.

masklinn• 4 years ago

This, though, seems to be trying to sleep to slow down frame rate. What the? Maybe it's intended as some way to make all users' experiences suck equally even if they have fast boxes. Maybe.

Or to conserve power, why burn CPU and render at hundreds of fps when the output is limited to 60 or even 30?

I don’t need my machine loaded at 100% when playing slay the spire or dungeons of into the breach.

comex• 4 years ago

Which is why you use vsync, ensuring the game renders once for each frame your monitor shows, as opposed to having the game just guess when it should present frames - which can produce tearing or be at the wrong frame rate entirely.

iKlsR• 4 years ago

Unrelated but a "sleep story" nonetheless. Several years ago worked on a desktop Qt app and I spent several weeks juicing platform flags, caching stuff on save to start faster, slimming down the mainwindow classes, everything I could to get the app to boot in under several 500ms down from 5+s only to be told by my boss that it was too fast and he wanted to see the splash screen so after all that to this day, there is a `sleep(rand(x, y))` call somewhere in that codebase.

wongarsu• 4 years ago

You could argue that graphics code should just activate VSYNC and run as fast as possible otherwise. The article hints that that doesn't always work in practice, but even if we pretend that it does that still leaves physics engines and other simulation code.

That kind of code usually works best with a fixed "framerate"/tickrate, but for performance reason that rate is set at something like 20 ticks per second. If your framerate is a multiple of that and graphics and physics runs on the same thread that's trivial (e.g. do physics every third frame for 60fps), but what if you move it to a different thread and some of your users have 75hz monitors? Now you have to sleep, or waste resources.

londons_explore2• 4 years ago

Sleep and functions like it should be [almost] banned...

They choose a time that computation happens. But computation should instead be done as soon as possible, and the output delayed to the necessary time.

For example, in an animation, you don't need to wake up the CPU every 16ms to compute the next frame. You should instead just compute all the frames and send it off to the GPU to display in order and with the right timings.

nemothekid2• 4 years ago

And then when every time the user interacts with the system you would have to trash the GPU queue and recompute everything. If you could compute everything before hand, it would be far simpler just encode the entire scene as a video.

For example, consider a game server that must handle inputs from multiple clients. It can't just compute everything and queue it off to the network because a user input may change the entire game world. A "computation" loop provides a consistent model of which all the game interaction happens.

kevingadd3• 4 years ago

They choose a time that computation happens. But computation should instead be done as soon as possible, and the output delayed to the necessary time.

This is fundamentally not a solution for any problem where you're reading input from outside. If that animation is reacting to user input, rendering the frames 100ms ahead will create 100ms or more of "input lag" that the user can see and feel and they hate it.

londons_explore2• 4 years ago

Well you only do the computation when you have the necessary inputs available, and in the case of something interactive that means waiting till you have the necessary keypresses (or lack of keypresses).

You can still compute ahead if you have a good guess what inputs you'll receive (eg. You predict that no keys will be pressed), but you have to be happy to throw away the results if your prediction was wrong.

ec1096852• 4 years ago

Hmm, what’s wrong with:

  sleep until reddy to blit next frame

  blit frame

  render next frame

repeat

monocasa2• 4 years ago

Rendering can take a variable amount of time, so you instead want to wait on a hardware even like vsync instead of a timer.

sgtnoodle2• 4 years ago

Sleeping a thread doesn't "choose" when something happens, the programmer does. Sleep functions are just abstractions over hardware timer interrupts. There's some inherent complexity there, and abstracting it away is naturally going to impose some limits or compromises. Windows' "sleep" function seems to be especially limited, but being able to precisely schedule a CPU thread to a hardware timer is important for solving a lot of interesting problems. As you push a program to its limits, of course you'll need to carefully choose the abstractions that most optimally achieve your requirements given the available hardware. I agree that bare sleep style functions rarely make sense. Blocking select-style calls with a timeout often do, though, which are largely equivalent to sleep.

The whole point of a CPU is to be general purpose. A CPU isn't optimal for anything. The magic of a computer is that it makes "anything" possible. Why would you want to ban sleep? If somebody makes a crappy arcade game with terrible latency and jitter, good for them. Someone not yet familiar with the nuances of "sleep" will learn a lot faster building some crappy but functional programs than they will trying to learn a modern graphics API. A seasoned expert will readily barf out a crappy program with some sleep calls in it when they know it's good enough to solve the problem at hand.

kayson• 4 years ago

When I was an intern at ON Semi, I worked on a testbed that was designed to stress power mosfets with extremely time-accurate pulses of current. The prototype was using an Arduino microcontroller, and I noticed that when I passed small values to delayMicroseconds(), it was just not accurate at all. After a lot of digging, it turned out that they used a small inline assembly loop to count clock cycles, but they had miscounted the number of clock cycles required by the setup. When you're talking about 2-3us with an 8MHz clock, even half a dozen clock cycles will make a big difference!

kevin_thibedeau• 4 years ago

Arduino is notorious for promoting this sort of synchronous, main-loop only code. It is a horrible model for embedded devices unless they are severely resource constrained.

gsliepen• 4 years ago

It's not uncommon to be resource constrained on embedded devices. I actually worked on something quite similar as kayson, helping create a device to synchronize a camera with a LED that was pulsed with a constant current in order to generate photon transfer curves. The pulses had to be as accurate as possible, and indeed doing the inline assembly loop with NOP instructions was the way to go: simple, deterministic, and the possibility to have pulses down to a single clock cycle. I believe PWM wasn't possible because it couldn't have pulses that short and still support the required minimum interval between pulses.

But I do agree that it would be much more helpful if tutorials for Arduino would promote using timers and interrupts.

scoutt• 4 years ago

If the alternative you propose is RTOS/scheduler then the synchronous main-loop approach for embedded is, by far, more common than the alternative.

tyilo• 4 years ago

This site looks horrible for me due to some font issues?

See https://i.imgur.com/dAHmjSc.png

Const-me• 4 years ago

It's rarely a good idea to implement spin locks as an empty while() loop. Processors have a special instruction for the spinning, _mm_pause()

Deukhoofd• 4 years ago

Linux and MinGW can just use nanosleep().

As for Windows, use CreateWaitableTimerEx, with a CREATE_WAITABLE_TIMER_HIGH_RESOLUTION flag.

leeter• 4 years ago

Windows can also use beginTimePeriod() to set the timer resolution (sadly system wide) so if one needs a 1ms time period that is plausible with defaults. But you do have to set it. Otherwise you have to depend on the variable tick timer to give you want you want. Which don't get me wrong can be good, but if you need more guaranteed timer ticks... it may not be the way.

https://docs.microsoft.com/en-us/windows/win32/api/timeapi/n...

wheybags• 4 years ago

On windows you can get 1ms accuracy out of the built in Sleep() function by calling timeBeginPeriod[1] It sets the resolution of timers in that process to the specified ms value. I've used this + spinning to make high res sleep before and it works well.

1: https://docs.microsoft.com/en-us/windows/win32/api/timeapi/n...

beagle3• 4 years ago

About ~20 years ago, I discovered that using WinSock's "select()" on Win2K can give you microsecond sleep resolution with reasonable (100us or so) precision. It was still that way on XP, I have no idea if it stayed that way for Vista/7/8/8.1/10/11

leni536• 4 years ago

Looks like a good way to drift from the clock and eventually skip frames.

jepler• 4 years ago

Depending on your goals, using a deadline sleep (sleep_until in C++ parlance: https://en.cppreference.com/w/cpp/thread/sleep_until) rather than a duration sleep (sleep_for) is beneficial

signa11• 4 years ago

well, sleep_until(…) will also drift based on vagaries of os scheduling etc. it would be (pleasantly) surprising iff it did not approximately exhibit the same behaviour as author’s first implementation.

nyanpasu64• 4 years ago

Not 100% sure the article doesn't cover this, but if you want a constant rate of wakeups over time (not a precise duration of each sleep call), it's important to schedule your next sleep 1 period after your most recent intended wakeup time (in absolute time), not 1 period after the call to the sleep function (in relative time), to ensure that the time spent after sleep() returns before you call sleep() again doesn't accumulate with every sleep iteration and cause you to fall behind in real time.

sedatk• 4 years ago

It's probably for the sake of an example, but writing a game/render loop with Sleep is a bad idea, perhaps even on a realtime OS. What you should be doing is to render the frame that's meant for the current time. This way slowdowns, hiccups, boosts don't alter the speed of animations, and you can regulate how frequent you render regardless of the timer precision.

Making an Accurate Sleep() Function

Related Stories