Std: Clamp generates less efficient assembly than std:min(max,std:max(min,v))

Re:Std: Clamp generates less efficient assembly than std:min... by PaulDavisThe1st on Tuesday January 16, 2024 @12:38PM (#39016155)

> 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.

[ Parent | on HN ]

Re:Std: Clamp generates less efficient assembly than std:min... by dahart on Tuesday January 16, 2024 @03:10PM (#39018422)

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?

[ Parent | on HN ]

Re:Std: Clamp generates less efficient assembly than std:min... by PaulDavisThe1st on Tuesday January 16, 2024 @06:08PM (#39020477)

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.

[ Parent | on HN ]

Re:Std: Clamp generates less efficient assembly than std:min... by mabster on Tuesday January 16, 2024 @06:23PM (#39020624)

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.

[ Parent | on HN ]