Math library like this should produce consistent results regardless where it runs. Currently this won't happen because of use of _mm_rsqrt_ss intrinsic and other places. This instruction produces different results on different systems because of how it allows different precision. Lower precision is fine in general, as long as it documented, but inconsistent results is not. rsqrt is well known to have different results on Intel vs AMD cpu's. This can lead to quite bad situations:

1. clients having bugs in physics, lighting or any other math calculations. But you won't be able to reproduce issues if running different CPU. It's especially critical for physics simulations where determinism is must have.

2. bad shared cache / CI system trashing. Let's say you have asset cache, where you process asset (packaged mesh, compressed texture, etc..), produce hash of it, and if hash is not present in cache you upload asset. But because of this inconsistency if other user or CI system runs on different cpu - asset hash will be different, so you will be uploading asset even if nothing changed. And other people who just wants to get latest data from cache (typically artists who don't touch game code) will need downloading newer asset data when nothing changed. Just useless waste of time of uploading & downloading assets to/from cache.

3. insane patch sizes. Let's say you changed one texture, or maybe fixed one mesh. You rebuild game asset files. Run diff for previous version to create patch file, and expect change in few KB's or few MB's because of tiny change. But because you run it on different system this might change every single texture or mesh or wherever math is used. And you get 20GB patch file (just for tiny change)!

Again - reduced precision is OK. Inconsistent precision is NOT.

Here is list that I found that does not provide consistency:

1. InvSqrtF because of _mm_rsqrt_ss - Intel vs AMD differences. Or when compiled for non-x86 arch.
   rsqrt made sense 15 or something years back when CPU's were slower. Now they are fast. Just do proper sqrt instruction. It will be fine. And in cases it will become performance, usually you want to optimize code explicitly anyway instead of relying on generic math library.

2. DotV4, DotQ, MulQ - they will produce different results for way you written math in SSE vs non-SSE version. Float addition is not associative.