7 ms·

> When we were debating whether WebAssembly should support subnormal numbers (i.e. be IEEE compliant), some people often cited these mythical subnormal slowdow

> When we were debating whether WebAssembly should support subnormal numbers (i.e. be IEEE compliant), some people often cited these mythical subnormal slowdowns. So Dan Gohman ran some benchmarks and the scary-sounding slowdowns amounted to something like less than 1% (i.e. noise) for almost all benchmarks. Interestingly, one benchmark did not converge correctly with FTZ (i.e. no subnormals) and actually ran 3x more iterations, leading to a 3x slowdown. I recently built a modular additive music synthesizer called Flow (https://github.com/eclab/flow https://github.com/eclab/flow). When certain modules in the synthesizer [gradually] push certain state variables into the denormal range, my synthesizer will experience a roughly 100x slowdown. Mind you, this isn't due to DSP or even sound processing, and Flow isn't written in C, but in 100% pure *Java*. Since Java can't turn off denormals, I have to manually check for and zero them at strategic locations to avoid getting mired in the denormal quicksand.

titzer 5y ago
Complain to Intel. AMD and ARM chips have no such 100x penalties.
- SeanLuke 5y ago
  Perhaps true. But the point is: you're calling denormal failures "edge cases", yet my primary experience with denormals is exactly this.
  - titzer 5y ago
    I sympathize. Software/hardware is littered with one person's edge cases being another person's entire world. But in the grand scheme, yes, subnormals are exceedingly rare. Clearly Intel microarchitecture designers think that, as they seem perfectly willing to continue punishing some applications with a massive performance cliff. Their mitigation should never have been "we'll add a cheat switch for speed" but rather "we'll work as hard as our competitors do to make these cases fast." Standards are supposed to do that, but cheaters abound (and yes I am being a bit perjorative--cheaters don't think of themselves as cheating, they merely have important use cases that demand special dispensation). GPU hardware is a different, but similar story, from what I can see. It saves transistors to do FTZ, and the originally niche usage of FP to put pixels on the screen didn't really care so much about niggling details. But GPUs became general purpose and important, and they've been dragged into full compliance by application demands. It's the only sane outcome in the end. Instead, all this FTZ stuff has just made a mess at layers above. It would all be unnecessary if subnormals were as fast as AMD, ARM, IBM, and other chip manufacturers have managed to make them.
adrian_b 5y ago
This is strange, so it is likely that it might be more of a Java problem than a CPU problem. I do not know how Java handles this, but maybe it actually enables exceptions for underflow which invoke some handler. Otherwise I cannot see how you can obtain such a huge slowdown, unless your code consists entirely of back-to-back operations with denormals and of nothing else. I am not sure what you mean by "state variables", but if they are pushed into the denormal range, they should be changed to double, not float. If you push double variables into the denormals range, then it is likely that the algorithm must be modified, because this should not happen. Underflows, i.e. denormals, are difficult to avoid when using float variables, which can be mandatory in DSP algorithms for audio or video, but outside the arrays processed with SIMD instructions at maximum speed, the scalar variables can be double, which should never underflow in most correct algorithms. For computations run on CPUs, not GPUs, only very seldom there can be reasons to use a scalar float variable. Normally float should be used only for arrays.
- nitrogen 5y ago
  entirely of back-to-back operations with denormals In the context of sound, I could see this happening with an exponentially decaying envelope generator (or an IIR filter).
  - spacechild1 5y ago
    Yes. It is very easy to accidentally produce denormals in recursive audio algorithms.
  - SeanLuke 5y ago
    100% correct. Many audio and synthesis algorithms, including mine, perform LOTS of iterated exponential or high-polynomial decays on variables, such as x <- x * 0.1, or x <- x * x or whatnot. These decays rapidly pull values to the denormal range and keep them there, never hitting zero. Depending on the CPU, this in turn forces everything to go into microcode or software emulation, producing a gigantic slowdown. There are other common cases as well. The only way to get around this in languages like Java, which cannot flush to zero, is to vigilantly check the values and flush them to zero manually.

titzer 5y ago

Complain to Intel. AMD and ARM chips have no such 100x penalties.

SeanLuke 5y ago
Perhaps true. But the point is: you're calling denormal failures "edge cases", yet my primary experience with denormals is exactly this.
- titzer 5y ago
  I sympathize. Software/hardware is littered with one person's edge cases being another person's entire world. But in the grand scheme, yes, subnormals are exceedingly rare. Clearly Intel microarchitecture designers think that, as they seem perfectly willing to continue punishing some applications with a massive performance cliff. Their mitigation should never have been "we'll add a cheat switch for speed" but rather "we'll work as hard as our competitors do to make these cases fast." Standards are supposed to do that, but cheaters abound (and yes I am being a bit perjorative--cheaters don't think of themselves as cheating, they merely have important use cases that demand special dispensation). GPU hardware is a different, but similar story, from what I can see. It saves transistors to do FTZ, and the originally niche usage of FP to put pixels on the screen didn't really care so much about niggling details. But GPUs became general purpose and important, and they've been dragged into full compliance by application demands. It's the only sane outcome in the end. Instead, all this FTZ stuff has just made a mess at layers above. It would all be unnecessary if subnormals were as fast as AMD, ARM, IBM, and other chip manufacturers have managed to make them.

adrian_b 5y ago

This is strange, so it is likely that it might be more of a Java problem than a CPU problem. I do not know how Java handles this, but maybe it actually enables exceptions for underflow which invoke some handler. Otherwise I cannot see how you can obtain such a huge slowdown, unless your code consists entirely of back-to-back operations with denormals and of nothing else. I am not sure what you mean by "state variables", but if they are pushed into the denormal range, they should be changed to double, not float. If you push double variables into the denormals range, then it is likely that the algorithm must be modified, because this should not happen. Underflows, i.e. denormals, are difficult to avoid when using float variables, which can be mandatory in DSP algorithms for audio or video, but outside the arrays processed with SIMD instructions at maximum speed, the scalar variables can be double, which should never underflow in most correct algorithms. For computations run on CPUs, not GPUs, only very seldom there can be reasons to use a scalar float variable. Normally float should be used only for arrays.

nitrogen 5y ago
entirely of back-to-back operations with denormals In the context of sound, I could see this happening with an exponentially decaying envelope generator (or an IIR filter).
- spacechild1 5y ago
  Yes. It is very easy to accidentally produce denormals in recursive audio algorithms.
- SeanLuke 5y ago
  100% correct. Many audio and synthesis algorithms, including mine, perform LOTS of iterated exponential or high-polynomial decays on variables, such as x <- x * 0.1, or x <- x * x or whatnot. These decays rapidly pull values to the denormal range and keep them there, never hitting zero. Depending on the CPU, this in turn forces everything to go into microcode or software emulation, producing a gigantic slowdown. There are other common cases as well. The only way to get around this in languages like Java, which cannot flush to zero, is to vigilantly check the values and flush them to zero manually.