But how often is determinism in the LSB really needed?

What does LSB mean?

Least significant bit

For IEE 754 [1] the last bit of the the mantissa [2] is also the last bit of the binary representation. So, changing it is results in the smallest possible change in the number.

There are some things that end up "accidentally" demanding exact equality of floats. Comparing the reference output of a program that writes floating-point numbers comes to mind. A multiplayer game that relies on each client computing gamestate locally can get desyncs to happen if two clients compute floats that differ even by that last bit.

Another, admittedly niche, scenario is that numerics code can use lower-precision types to emulate higher-precision types (e.g., represent a number with a pair of doubles).

This is totally off the cuff, but if you were using a pair of doubles like that, you’d essentially need to represent these new operations with numerical algorithms on the pair of doubles, right? So the algorithms would presumably need to deal with the last bit being a bit dodgy at times, right?

With appropriate rounding modes, the basic operations (+, -, *) are fairly short code sequences. Things like exp and 1/x can become adventures, but they're not too bad.

Division is actually pretty straightforward: compute a residual using the multiply-add that you already have, divide _that_, and then add it to the quotient.

Or (roughly equivalently, but maybe easier to understand) do a native double division, then do a Newton-Raphson step, which requires only multiplication and addition (just like you would refine a reciprocal estimate).

AFAICT any modern multiplayer games use a central node that forces a coherent state of the world on all clients, otherwise cheating through desync becomes a serious problem. (Trusting clients in adversarial transactions, like deathmatch, is hard in general: cheating through altered rendering also used to be a thing.)

Depends on the game and platform. RTS games tend to still have peer to peer netcode. Deterministic simulation is still a thing.

Here is an interesting GDC talk on building a fixed precision engine core to ensure determinism: https://youtu.be/wwLW6CjswxM

It is typical to have a need for exact bit-by-bit equality between outputs. For integrity and security purposes.

Happens very frequently in multiplayer games. As a result, if you don't have it, you can't byte-compare floats and need to have an "approximate" function with some predefined epsilon slop.

I recall LHC@Home had some issue with this[1]. They ran simulations of beams in the LHC using BOINC, each run could be up to a million revolutions. The goal was to do parameter searches to find the best magnet settings before going live, so they could spend less time tuning the real thing.

Anyway, as with other BOINC projects, they sent each work unit (simulation run) to at least two (or was it three?) different computers and compared results, to ensure correctness. And they found that they got quite a lot of work units which disagreed and had to be sent to more computers for validation.

After some digging and eliminating factors like overclocked CPUs, they found that usually, all Intel machines would agree and all AMDs would agree, but Intel and AMD would disagree. Like, a run that would hit the detector wall after 30 revolutions on Intels could go on for many thousands of revolutions on AMDs.

Further digging led to the discrepancy in lower bits of transcendental operations in the FPUs[2]. After switching to a software library for these operations, at the cost of a few % in speed, they got Intels and AMDs to agree.

So yeah, when you do a large number of iterated operations like this, even a single LSB of difference can lead to issues.

As an aside, the LHC@Home was initially run almost like a hobby project by a few researchers connected to the LHC, without much official support. However the data the project produced was AFAIK highly beneficial to the machine commissioning, and it later became a more official part of the High Luminocity upgrade.

[1]: https://cds.cern.ch/record/1463291/files/CERN-ATS-2012-159.p...

[2]: https://epaper.kek.jp/icap06/PAPERS/MOM1MP01.PDF

I looked into this issue with rsqrt (and with rcp as well) between Intel and AMD processors in connection with CERN some years ago (2016). An unpublished report can be found at [1].

TL;DR: The same (very small) executables gave different results when run on Intel and AMD processors because the rsqrt and rcp instructions produced slightly different outputs on the two systems.

[1]: https://github.com/jeff-arnold/math_routines/blob/main/rsqrt....

Interesting results, thanks for sharing!

Determinism in the LSB is often a prerequisite for epsilon-determinism in the result. Algorithms with many possible solutions and any step that bifurcates on a floating point value should be treated with suspicion.

Classic examples include most under-constrained randomized algorithms, like training a neural network. Rejection sampling is required to accurately produce some sorts of randomness, and that yields bifurcations in the initialization if you don't have LSB determinism. The complicated loss landscape then virtually guarantees you'll converge to a different minima. Even with a deterministic seed, algorithms guaranteed to converge, a principled way to ensure that concurrent computations yield bitwise identical results no matter the execution order, and most of your operations being bitwise identical, a few stray LSB issues in your inverse square roots or transcendentals will still nearly ensure that the final result isn't even approximately the same.

As to why that latter thing matters, it varies, but at a minimum reproducibility makes lots of federated processes cheaper (and not just federated in the "folding at home" sense, but generally when some people are performing computations and other people are making actions based on them -- being able to explain credit scores or parole denials or whatever, or validating that several people you trust yield the same compiled binary). Bitwise reproducibility would be better, but even being approximately right would probably be good enough and isn't tenable without bitwise identical building blocks.

> for that there's still no better approach than using the Q_rsqrt idea

Or you can just take a square root and divide; these are (partially-)pipelined operations on modern CPUs, with _much_ shorter latency than they had when "fast inverse square root" was a thing.

It still has a niche, but that niche is very, very narrow today.

If you're doing ~20 other FP ops (not including division) per inverse square root and not using a huge dependency chain of inverse square roots, you might not even notice the impact of using an exact inverse square root with this method.

Short of functions like exp and the trig functions, DIY approximations are usually not worth it these days.

polynomials are still king. a 6th degree polynomial is often enough and will be faster than a 2nd degree rational.

A 6th degree polynomial is firmly in the "fast approximation" category. I think sin/cos are ~15th degree polynomials for 1 ULP of precision.

https://github.com/rutgers-apl/The-RLIBM-Project/blob/main/l... has a lot less and claims to be correctly rounded.

For 32-bit float, yes. For double precision, not so much.

sin/cos commonly use 2 different 5th degree polynomials (depending on quadrant of the sin graph) https://github.com/JuliaLang/julia/blob/bb83df1d61fb649efd15...

What do you mean by "taking the square root"? sqrtps has exactly the same problem, it's not standardized, so you need a custom algorithm.

square root is an IEEE 754 basic operation, correctly rounded (and therefore bitwise reproducible) on all compliant systems. What made you think that it isn't?

Sqrt is standardized by IEEE, it is required to be the correctly rounded value.

> rsqrtps is implemented differently on different CPUs

That applies to x86 for sure. But the designers of ARM and RISC-V had the foresight to standardise the implementation of rsqrt to make it deterministic ... on each respective platform. But on either, the precision is only 7 bits.

If you're only on x86 and only recent processors then AMD's and Intel's implementations yield similar enough results that it could be feasible to use a lookup-table for the differences. <https://robert.ocallahan.org/2021/09/emulating-amd-rsqrtss-e...>

the point of 7 bits is that you can double the digits with newton if you need, so a bad but fast version lets you choose how accurate you need it.

> Your only remaining option is to use a totally IEEE-754 compliant algorithm that is guaranteed to work the same on every CPU that implements IEEE-754 floats

OK but, doesn't intel internally use 80 bits of precision for float64 computations? If that's the case, you can't even guarantee that float64 multiplication and addition would behave the same on say x86 vs arm.

The higher internal precision only applies to the classic x87 operations under most circumstances, AFAIK.

That was the old x87 stack, that has been (almost) completely replaced by SSE and other vector instruction sets that operate on 32/64 sized elements. Unless you need 80 bit floats or have a mountain of ancient 32 bit intel CPUs without SSE support lying around you should get the expected rounding behavior by default.

This is a good point, I updated the article to include a comparison where the naive method is only using standardized floating-point operations. When not using -funsafe-math-optimizations the compiler emits sqrtps followed by divps (sqrtps seems to implement sqrt of ieee-754).

In this case, the Q_rsqrt actually seems to provide a 2-4x speedup compared to the reproducible naive method.