[PD-dev] denormals: svf, freeverb (was Re: [PD] bug in freeverb???)
morph_2016 at yahoo.co.uk
Sat Aug 15 23:42:31 CEST 2009
> I wonder if this line, right after
> you check "in" for denormality, might not be causing
> very slight waveshape for extra stability
> sv->b = sv->b - sv->b * sv->b * sv->b *
> 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?
The article again for anyone reading this in the middle of the thread:
More information about the Pd-dev