[dvt]

Even though refreshing and enlightening, the article doesn't cover another (major) reason why floating-point math is generally avoided (especially in high-performance applications): computational slowdown when dealing with subnormals[1][2].

I feel that there is a lot of overlap between cases where you may want to minimize error while at the same time still be performant (simulations, ray tracing, rendering, etc.). So you're left with a situation where you end up minimizing error, but still being slow.

[1] http://research.ihost.com/osihpa/osihpa-govind.pdf

[2] https://charm.cs.illinois.edu/newPapers/06-13/paper.pdf

[stephencanon]

A couple points:

Support for subnormals can easily be disabled (usually be enabling "Flush to Zero" behavior) to allow for better performance on essentially all recent hardware.

Over the last few years, subnormal stalls have shrunk rapidly, and gone away entirely in some cases. Intel started this process with the Sandybridge architecture. These stalls are also greatly reduced in some arm64 implementations.

[ntoronto]

We had this discussion on the Racket user's mailing list a couple of years ago. One user with an AMD processor experienced significant stalls; others with Intel processors didn't.

I don't know the status of AMD's floating point at the moment, but I hope they're doing something about that.

[malkia]

AFAIK gpu's and ps3 cell chip did not support subnormals for that reason, also as the other poster said, they can be disabled. Alternatively you can add white-noise to your data to avoid it (Say after an IIR filter on sound data).