1
\$\begingroup\$

According to James Demmel's article, "Faster Numerical Algorithms via Exception Handling", IEEE Trans. on Computers 43 (1994), 983-992, the way a floating-point processor handles overflow can be important to the speed of operations that are not typically expected to overflow, because it is often the case that we have a choice between a fast algorithm that can overflow for rare inputs, or a slow algorithm that guards against overflow in all cases, so it is useful to be able to use this strategy:

  1. Try the fast algorithm
  2. In the rare case where overflow occurred, go back and redo the calculation with the slow algorithm

There are basically two ways to detect overflow:

  1. Trap. To be usable for this strategy, it must be possible to trap to user code. To trap at the precise operation would incur an unreasonably large performance penalty for pipelined implementations, so it has to be accepted that it will be imprecise.
  2. Infinity/quiet NaN/sticky status bit. Keep going, but remember that an overflow occurred, so that an explicit check can be carried out occasionally. To be usable for this strategy, the presence of NaN operands must not cause too dramatic a slowdown. (There have been a number of processors on which NaNs slowed arithmetic operations by a couple of orders of magnitude.)

Modern processors like x64 typically default to the second strategy.

My question here is about the hardware implementation of floating-point traps versus NaN. Is it actually less costly to implement quiet NaN without slowdown, than to provide even imprecise trap on overflow? Or is quiet NaN widely used today for a different reason?

\$\endgroup\$
2
\$\begingroup\$

It isn't the arithmetic that slows things down, it's the exception processing -- especially the processing required to clean up after an imprecise trap. qNaN defers exceptions, keeping the pipeline full for a greater percentage of the time.

There's no inherent reason that processing NaNs should be any slower than normal numbers, because the rules are quite clear. In fact, if anything, I would expect them to be faster.

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ Right, certainly I would expect cleaning up after an imprecise trap, to be slow compared to an arithmetic operation. But does the mere possibility of having to do so, slow things down in the normal case? I had thought the advantage of imprecise over precise traps was that at least the normal case is not slowed down. \$\endgroup\$ – rwallace Mar 6 '19 at 18:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.