I’m surprisingly unable to find much data about the cost of bounds checking in real-world high performance applications like games.
Did you ever perform or find a representative study @repi ? Or anyone using @bevy ?
Intuitively I expect modern CPUs to hardly break a sweat about all these untaken branches, but I have no data. I’m left wondering if gamedevs would not rather skip all bounds checks in release builds 🤔
@anji anecdata but in C# while writing interpreters I have found it is worth changing from an array to a pointer when fetching opcodes in order to avoid the bounds checks
@anji@repi@bevy I'd naively guess that it's likely a bit worse than you'd think. Hot loops will predict though add instruction overhead (not sure how this affects OOO dependency chains). All the other inlined sites would individually need to be predicted and may not stay in the prediction cache and thus randomly fail costing a misprediction. Needs measuring again though.
@adrianb3000@anji@repi@bevy Putting "unlikely" annotations on those branches (for compilers that support such) should help with branch misprediction on cold cache. And the bounds check calculations will probably execute in parallel with (speculatively) executing the guarded code, given enough CPU execution resources?
@reedbeta@adrianb3000@anji@repi@bevy My experience staring at compiler output from gcc and clang is that side branches like this, even if they're never taken and they're default predicted correctly, can do bad (sometimes horrible) things to code quality on the main branches.
@pervognsen@reedbeta@adrianb3000@anji@repi@bevy Yeah that seems about what we see in practice too. It's like, not a huge deal, but sometimes causes issues unrelated really to the bounds check itself. But to be completely honest, I think it's pretty well within the realms of possible to just ship with bounds checks on, with potentially some specific areas disabled.
Add comment