Floating-Point Error Handling in C++: What Works

Floating-Point Error Handling in C++: What Actually Works - Johnny's Software Lab Sticky bits, traps, compiler flags, and the optimizer trade-offs people rarely talk about. Master software performance in just 16 hours! Join our Software Optimization for the Memory Subsystem Workshop taking place from May 18th to May 21st. Click here to express interest or register.In this post we are going to investigate how to efficiently handle floating-point errors in software. The first part gives an introduction to different ways of detecting floating-point errors – from simply inspecting the result (checking for infinities or NaNs), over relying on the sticky exception flags in the floating-point status register, and finally to enabling hardware traps. In the second part, we apply these techniques to a small example to see how they actually behave and what kind of performance overhead they introduce. If you are an experienced engineer, you might want to skip the parts that are already familiar. For everyone else, I’ll try to explain everything you need to understand the context of floating-point errors. Table Of Contents The Beautiful TheoryWhat are floating-point errors?How are floating-point errors signaled to your program?Software Signalling – Check the ResultHardware Signalling – Sticky BitsHardware Signalling – Traps

The RealityThe BaselineManual Error HandlingVerdict Sticky BitsThe Compiler Can Optimize Away Instructions Producing NaNsVerdict Hardware Traps, The sigsetjmp / siglongjmp ApproachThe Order of Instruction MattersVerdict Throwing C++ Exceptions from an FP Trap

Conclusion

The Beautiful Theory What are floating-point errors? Floating-point formats do not represent only finite numbers. They also have representations for ±infinity and NaN (not a number). For example: // Produce Infinity float a0 = 25.0 / 0.0; // Results in +Infinity float a1 = a0 + 4.0; // Infinity propagated to a1 float inf = std::numeric_limits::infinity();

// Produce NaN float b0 = sqrt(-1); // Results in NaN float b1 = b0 * 1.5; // NaN propagated to b1 float b2 = 0.0 * inf;In this article we will treat infinities and NaNs as “true errors”, because the result is no longer a usable finite value and will typically poison the rest of the computation. Apart from these, there are also exceptions related to rounding and precision loss. The full list of IEEE-754 floating-point exceptions (from /) is: FE_DIVBYZERO – Raised when a non-zero finite number is divided by zero, producing ±infinity. FE_INEXACT – Raised when a result cannot be represented exactly and had to be rounded. (This exception happens very often.) FE_INVALID – Raised when an operation has no mathematically defined result (e.g. 0/0, ∞−∞, sqrt(−1)). FE_OVERFLOW – Raised when a finite result is too large to be represented and overflows to ±infinity. FE_UNDERFLOW – Raised when a non-zero result is too small to be represented normally and is rounded to a subnormal or zero. By default, these exceptions do not stop program execution. They merely set sticky flags in the floating-point status register. How are floating-point errors signaled to your program? In some cases you want to be notified when a floating-point error occurs. For example, you might want to know when an operation produces a NaN, overflows to infinity, or triggers some other exception. There are a few ways to achieve this. We list them here and compare them later. Software Signalling – Check the Result One straightforward approach is to check the result directly. C++ offers std::isnan and std::isinf, which you can use to test whether the result of an operation is NaN or infinity. For example: uint64_t total_nans = 0;

for (size_t i = 0; i The disadvantage of this approach is that every result is explicitly tested. A performance-conscious developer immediately sees the potential issue: additional work is executed in every iteration of the loop. Even if the check itself is cheap, it is still extra logic in the hot path. Also note that this approach only detects NaNs or infinities – it does not detect exceptions such as inexact or underflow directly. Hardware Signalling – Sticky Bits Some errors cannot be detected by simply observing the result. For example, the result of 1.0 / 3.0 cannot be represented in finite precision – it must be rounded. In this case precision is lost, and the floating-point unit signals this by setting the FE_INEXACT flag. When an exception occurs, the floating-point hardware sets a corresponding bit in the CPU’s status register1. This bit remains set until we explicitly clear it – the flag is sticky. We will omit the hardware details here, but the standard way to test whether an exception occurred is to use fetestexcept and feclearexcept, for example: // Clear all exception flags feclearexcept(FE_ALL_EXCEPT);

// Floating-point work here

// Test whether an exception occurred if (fetestexcept(FE_INVALID | FE_DIVBYZERO | FE_OVERFLOW)) { // Handle error }The typical workflow is simple: clear...

Floating-Point Error Handling in C++: What Works

Related Articles

The Newest Instagram "Exploit" Is the Goofiest I've Seen

It's Not Just X. It's Y

Amazon, Facebook, FBI have access to a private intelligence-sharing network

Show HN: GoPeek – open links in live mini browser windows without new tabs

Agent Memory: An Anatomy