Off topic: a guaranteed way to start a flame war in an automotive forum is to state that there is no such thing as "backpressure" and that fluid dynamics and the continuity equation fully explain why restricting exhaust pipe diameter results in increased performance.
It gets even more fun when the back pressure is in the intake side (aka boost). I was tuning a friends turbo 300zx after he upgraded to a bigger turbo. At the same boost levels as before the car was slower. He was confused. After a quick chat around turbos, air speed, etc., I simply told him we needed to crank up the boost. Some tweaks to timing and fuel maps and this thing could now really fly.
I have often found limiting the buffer size as a simple way to communicate back to producers that more work can't be taken. Then what happens is all a producer strategy to drop work or wait for a period of time then drop or just hold onto the work until the buffer has a clear space. Its about the simplest message from consumer to producer you can do and how games tend to do backpressure and how Go channels work.
It is how DirectX works. The call to present that ends the stream of the commands to the GPU and tells it to render causes the CPU to be stalled waiting for this to be possible. This causes a backpressure into the game engine as the next simulation can't start or at the very least the next frame can't be started to be processed until it returns. It has been used by GPU makers to frame pace games as well to avoid stuttering.
So its not just some games, its all games its part of the core of how DX works.
its still pretty easy to screw up. how does the system you're using handle back pressure and how does that behavior affect other parts of your system. if you have two systems that each do back pressure, are you certain that the system remains closed? that is if those systems aren't coupled implicitly through the scheduler or explicitly in some other way, then you can balloon state or drop results between them.
This whole topic seems to be a re-discovery of https://en.wikipedia.org/wiki/Control_theory and https://en.wikipedia.org/wiki/System_dynamics with non-linearities and saturation.
In the same vein, on the consumer side we talk of admission control (which is just another name for "drop incoming messages") and throttling...
Off topic: a guaranteed way to start a flame war in an automotive forum is to state that there is no such thing as "backpressure" and that fluid dynamics and the continuity equation fully explain why restricting exhaust pipe diameter results in increased performance.
Light the fire and then sit back and enjoy.
It gets even more fun when the back pressure is in the intake side (aka boost). I was tuning a friends turbo 300zx after he upgraded to a bigger turbo. At the same boost levels as before the car was slower. He was confused. After a quick chat around turbos, air speed, etc., I simply told him we needed to crank up the boost. Some tweaks to timing and fuel maps and this thing could now really fly.
I wanna tell them how torque vs horsepower isn't real, horsepower is all that matters unless your transmission sucks
(Not to say that the width of the power band doesn't matter)
I have often found limiting the buffer size as a simple way to communicate back to producers that more work can't be taken. Then what happens is all a producer strategy to drop work or wait for a period of time then drop or just hold onto the work until the buffer has a clear space. Its about the simplest message from consumer to producer you can do and how games tend to do backpressure and how Go channels work.
Can you give examples of which games have implemented this (if open source) for reference?
It is how DirectX works. The call to present that ends the stream of the commands to the GPU and tells it to render causes the CPU to be stalled waiting for this to be possible. This causes a backpressure into the game engine as the next simulation can't start or at the very least the next frame can't be started to be processed until it returns. It has been used by GPU makers to frame pace games as well to avoid stuttering.
So its not just some games, its all games its part of the core of how DX works.
I feel like backpressure was a common topic in 2010, and now modern event driven system design just naturally handles this issue.
Not all modern systems are event-driven. The large-scale systems I've worked on have plenty of RPC.
Backpressure applies to regular request-based systems just as well.
As in: should your request handler try to do retries if one of the dependent services fails?
I recall this in the form of buffer bloat.
its still pretty easy to screw up. how does the system you're using handle back pressure and how does that behavior affect other parts of your system. if you have two systems that each do back pressure, are you certain that the system remains closed? that is if those systems aren't coupled implicitly through the scheduler or explicitly in some other way, then you can balloon state or drop results between them.
I want to believe
Hi, author of above blog here.
Thanks for posting, I'm glad you found this interesting.
Would be glad to know any feedback or requests you have, to improve further.