[PD-dev] denormals: svf, freeverb (was Re: [PD] bug in freeverb???)

[Ed Kelly]

> I wonder if this line, right after
> you check "in" for denormality, might not be causing
> trouble:
>                 //
> very slight waveshape for extra stability
>                
> sv->b = sv->b - sv->b * sv->b * sv->b *
> 0.001f;
> Since cubing a tiny number and multiplying it by .001 could
> end up creating a denormal, which isn't checked for until
> it's gone through a series of further computations and ends
> up as the new "in".

Could be, but I tried applying an the exception handler to sv->b (which has a cubed version of itself - 0.001f taken away from it) and still pegged the CPU.

> Also (I don't really know), I thought that denormals were
> caught as a processor exception whenever they occurred, so
> neutralizing them in the code after the fact won't do
> anything to speed up the process, except to prevent a
> cascade of denormals. The thing to do would be to replace
> the exception handler with your own.

It seems from the article you flagged up that the Denormals-Are-Zero (DAZ) mode we really need is an SSE instruction. I wonder if you can do this without using intrinsics and native Intel code. I think there's some resistance to this since the code is meant to be compilable on PPC, i386, i686 and all variants, not just P3-and-beyond, and I'm trying to make my work generically compatible with all Pd-Extended distributions from 0.39 onwards.

> "To avoid serialization and performance issues due to
> denormals and underflow numbers, use the SSE and SSE2
> instructions to set Flush-to-Zero and Denormals-Are-Zero
> modes within the hardware to enable highest performance for
> floating-point applications."

Once again, I personally would like to have this implemented in the PD core, since denormals are a real pain in the ass and often cause CPU pegging. This limits the real-time uses of PD, since there are some performance patches that are realizable but ultimately un-performable. As such I'm surprised it doesn't class as a bug, but I guess this is up to the extern writer.
I notice a post on the pd-dev list - 
denormal bashing for feedback filters - ID: 1145279
cpole~ and rpole~ filters are not denormal save(sic) yet

How did zmoelnig fix this I wonder?

Ed

The article again for anyone reading this in the middle of the thread:
http://software.intel.com/en-us/articles/x87-and-sse-floating-point-assists-in-ia-32-flush-to-zero-ftz-and-denormals-are-zero-daz/