zlacker

[parent] [thread] 4 comments
1. dahart+(OP)[view] [source] 2024-01-16 16:28:01
Thank you, great points. I’d have to agree that disabling denorms globally is pretty bad, even if (or maybe especially if) caring about denorms is rare.

> Fast-math can cause hard range guarantees to fail. Maybe you’ve got code that you can prove that, even with rounding error, the result will still be >= 0.

Floats do this too, it’s pretty routine to bump into epsilon out-of-range issues without fast-math. Most people don’t prove things about their rounding error, and if they do, it’s easy for them to account for 3 ULPs of fast-math error compared to 1/2 ULP for the more accurate operations. Like, nobody who knows what they’re doing will call sqrt() on a number that is fresh out of a multiplier and might be anywhere near zero without testing for zero explicitly, right? I’m sure someone has done it, but I’ve never seen it, and it ranks high on the list of bad ideas even if you steer completely clear of fast-math, no?

I guess I just wanted to resist the unspecific parts of the FUD just a little bit. I like your list a lot because it’s specific. Fast-math does carry some additional risks for accuracy sensitive code, and clearly as you and others showed, can infect and impact your whole app, and it can sometimes lead to situations where things break that wouldn’t have happened otherwise. But I think in the grand scheme these situations are quite rare compared to how often people mess up regular floating point math. For a very wide swath of people doing casual arithmetic, fast-math is not likely to cause more problems than floats cause, but it’s fair to want to be careful and pay attention.

replies(1): >>PaulDa+7g
2. PaulDa+7g[view] [source] 2024-01-16 17:38:43
>>dahart+(OP)
> I’d have to agree that disabling denorms globally is pretty bad,

and yet, for audio processing, this is an option that most DAWs either implement silently, or offer users the choice, because denormals are inevitable in reverb tails and on most Intel processors they slow things by orders of magnitude.

replies(2): >>dahart+GQ >>mabste+cq1
◧◩
3. dahart+GQ[view] [source] [discussion] 2024-01-16 20:10:53
>>PaulDa+7g
I would think for audio, there’s no audible difference between a denorm and a flushed zero. Are there cases where denorms are important to audio?
replies(1): >>PaulDa+Pn1
◧◩◪
4. PaulDa+Pn1[view] [source] [discussion] 2024-01-16 23:08:06
>>dahart+GQ
They are important in the negative sense: Intel processors are appalling at handling them, and they can break realtime code because of this.

My DAW uses both "denormals are zero" and "flush denormals to zero" to try to avoid them; it also offers a "DC Bias" option where extremely small values are added to samples to avoid denormals.

◧◩
5. mabste+cq1[view] [source] [discussion] 2024-01-16 23:23:38
>>PaulDa+7g
For game development we had them off as well because of performance issues. Most stuff calculates around 0 so it was pretty common to trigger denorms.

The slowing down on Intel platforms has always frustrated me because denorms provide nice smoothing around 0.

At the same time it was nice only having to consider normal floating point when trying to get more accuracy out of calculations, etc.

[go to top]