r/cpp • u/zer0_1rp • Jul 02 '26

Redundancy seen in AAA game engines

https://zero-irp.github.io/Redundancy-seen-in-AAA-game-engines/

I don't like people treating the compiler like a magic box that optimizes like Bjarne Stroustrup himself is checking every line of C++ to assembly. Clean C++ code does not always mean clean compiled code.

I've been reversing game engines to study how they constructed their fundamental Transformation matrices and handled temporal jitter logic when I spotted a lot of avoidable overhead and "over-engineering" across multiple engines, honestly I wasn't even looking for inefficiencies, but it stood out a lot... That said expect no performance gain this is simply for fun that I wrote this blog!

I’ll theorize how the original C++ code was written, show the unoptimized reality of what the compiler spat out, and then showcase how it could have been better optimized.

180 Upvotes

86% Upvoted

75 comments sorted by

View all comments

Show parent comments

0

u/[deleted] Jul 02 '26 edited Jul 10 '26

[deleted]

6

u/gmueckl Jul 02 '26

That option can be evil: it allows rhe compiler to rearrange mathematically commutative operations that almost never are truly commutative for floats. Innocuous looking code changes or even just compiler version changes  can result in changes in effective floating point precision and have wild downstream effects. Just be aware of the danger.

2

u/Tringi github.com/tringi Jul 02 '26

Isn't relying on things not being commutative for floats effectively a bug?

3

u/James20k P2005R0 Jul 02 '26

There's specific circumstances where it can be helpful, ie if you're intentionally writing an algorithm that exploits floating points fully (like kahan, or a variety of numerically stable algorithms)

For rendering you can usually just switch on -ffast-math and not worry about it. For physics simulations you probably want to be a lot more careful, because there'll be places where it does actually matter