Hacker News Reader

Comment by Const-me | Hacker News Reader

> transforming a float based algorithm to integers in order to make it bit-exact

Modern CPUs, and most programming languages, guarantee bit-exactness for floats most of the times, because they implement IEEE 754.

Relatively easy to break (approximate instructions like rsqrtps, FMA instructions, compiler switches like -ffast-math or /fp:fast, MXCSR rounding modes) but I think fixing bugs is probably easier than refactoring everything from FP into fixed-point.

BTW, multiplication/division/rounding instructions are much faster for floats. I think a fixed-point version will only be a performance win when the integers are 8 or 16 bits wide, and the algorithm is vectorizable.

View on HN

Floating point operations are not deterministic in other situations: https://randomascii.wordpress.com/2013/07/16/floating-point-...

This can be terribly hard to manage in tests if you don't have a threshold infrastructure in place (which is hard and sometimes impossible to setup if you don't want to preserve huge references).

Also, and this is a bit off topic, even if I remained in the float domain for my use case, I would have to re-implement the lib math routines anyway (in my case cbrt and pow) because they are not implemented the same in all the libc, making them again victim to non determinism.

So far I observed better performance with integer arithmetic anyway, but that's not the reason that motivated me.

Also note that there are other situations were you may want to keep integers; typically in the kernel, or on arch were the floating point is not optimal or even available.

> Floating point operations are not deterministic in other situations

That article was written in 2013. A decade has passed, and in modern world these situations became rather rare.

x87 FPU is deprecated and not used by 64-bit programs. Returns values are passed in XMM0 register. Temporary values are either FP32 or FP64. Modern C++ compilers evaluate FP expression from left to right, and they don't use FMA unless explicitly allowed with -ffast-math or /fp:fast compiler switch. Programmers rarely using estimate instructions because modern CPUs complete precise division and square root in 10-15 cycles, little profit from the faster approximations.

The only variable thing which remains is MXCSR register in the thread state.

> I would have to re-implement the lib math routines anyway (in my case cbrt and pow)

Or you can copy-paste them from OpenBSD. The license is permissive, they are implemented in C without assembly, and the code quality is pretty good.

Reply on news.ycombinator.com