5 ms·
The quest for consistency seems misguided. If your code changes behavior based on the timing of the various sections, you have a bug, a race condition. The so
by markrages 12y ago
The quest for consistency seems misguided.
If your code changes behavior based on the timing of the various sections, you have a bug, a race condition. The solution isn't to lock down your code and build with only one configuration. The solution is to fix the bug.
In the same way, if the behavior of your code is dependent on the order of operations in floating point, it is very likely that you are doing something wrong. The solution is not careful ordering of floating point operations, but using algorithms appropriate to floating-point (and avoiding floating point when it isn't applicable.)
Code that has been ported to many platforms tends to be more stable, because the heterogeneous environments have exposed bugs and flawed assumptions in the code's construction.
- lmm 12y agoSimple use case: a multiplayer game containing physics. I'd like the physics to be reasonably accurate, but more than anything it needs to be consistent, because I want to get the same results on both players' machines, and then the only thing I have to send over the slow internet is a command stream.
- markrages 12y agoBut if infinitesimal disturbances to the results makes a practical difference to the game, then your physics engine is not stable.
- Terr_ 12y ago> But if infinitesimal disturbances to the results makes a practical difference to the game They don't! The system can tolerate answers which are slightly wrong... as long as all machines calculate the SAME slightly-wrong answer. The same logic applies to synchronized PRNGs. It doesn't (directly) matter what the "random" dice-roll result is, as long as all clients get the same answer.
- markrages 12y agoAh, thank you for this response. It "clicked" for me: Game developers are using the low bits (below significance) as pseudorandom numbers! They are overloading a new function on top of the existing use of floating-point numbers.
- Terr_ 12y agoThat's not what I'm saying. I'm just trying to give you an example where a "correct result" is far less-important than a "deterministic result".
- tomlu 12y agoNo physics engine is stable in that sense. Neither is the real world. You need full determinism to do what lmm is saying. Source: Worked on this exact thing for commercial multiplayer games.
- teraflop 12y agoMany interesting physical phenomena are deterministic but chaotic, in the sense that arbitrarily tiny changes in initial conditions can rapidly lead to arbitrarily large changes in behavior. Would you say that anyone who tries to make a game that has the same property is "doing something wrong"?
- Scramblejams 12y agoYou're probably imagining a short-lived game. Think of a game that goes on for months at a time. There are ways around this, but none of them as elegant as a floating point routine which produces the same results on any platform across any ordering of calculations.
- jephir 12y agoEven for short-lived games, if you want to implement a replay system, you need your physics to be deterministic.
- TeMPOraL 12y agoIt's a feature of physics, not physics engines. Many process in the real world are exponential in nature, so even a very small difference gets magnified very quickly.
- idlewords 12y agoI read the article so you don't have to! The author dreams of consistent behavior so he can get: - Reproducible results across platforms - Reproducible results with different build settings (such as debug builds or optimization levels) - Useful test cases for regression testing - Test cases that help him find misbehavior in the optimizer - An improved chance of finding more subtle bugs, absent 'noise' from small changes in floating point operations In particular, he gives examples of how changes to nearby code can change the output of floating point operations, due to hairiness in how registers are allocated. You can see how this would make testing quite painful. These all seem like worthy goals that deserve a better response than "you're doing it wrong", along with some non-sequitur about race conditions.
- markrages 12y agoRegarding race conditions, I was referring to this: > It's not just floating point that's inconsistent across modes – it's code snippets with behavior undefined by the language, buggy dependence on timing, optimizer bugs, conditional compilation, etc.
- pjc50 12y agoThere's quite a few algorithms that are generally vulnerable to precision issues because they can affect comparison order, such as k-means clustering. "Don't do that then" is not a useful answer.
- marcosdumay 12y agoLots of problems dictate code that depend on the ordering of floating point operations. It's not something that you can design away.