Best-practice on fp:fast with JUCE and esp. DSP classes

Development
1

Hello all,

it might be a newbie question: is there a best-practice on if / when to use Floating-Point Behavior fp:fast (controlled by Relax IEEE compliance in Projucer) together with JUCE and esp. the DSP classes (e.g. filters)?
In my plugin I get a 20% performance gain when using fp:fast instead of fp:precise. Of course I would like to have that. But I noticed some uncontrollable behavior on some older systems. My investigation is that the NaN handling is different and causes issues esp. in the filters (e.g. state variable filter).

So what is the guidance? Stay away from fp:fast?

Are there any guidelines one has to comply with in order to use fp:fast without issues?

Thanks

2

I have once had a terrible to track down bug because of different NaN behavior. Someone initialized a variable to NaN to imply optional behavior and declare it as “not set”.

So if your code does not require checks for NaN, you should be totally fine.

3

Yes, that’s true. And it might be the source of the issues I have seen with JUCE and fp:fast. There are some parts where a NaN check is implemented like this
if (x != x)
But according to this blog post here this will not work with fp:fast:

If you specify /fp:fast, the compiler will optimize (x – x) to zero. If not, it will perform the calculation, and thereby run more slowly. If x happens to have the value NaN, then the correct result for (x – x) would have been, not 0, but NaN.
https://blogs.msdn.microsoft.com/vcblog/2015/10/19/do-you-prefer-fast-or-precise/

4

Another one that got me was I was setting the fenv rounding mode in places for an optimization. Turns out fp:fast ignores fenv.

1 Like