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

[Martin Peach]

It seems -ffast-math is not currently one of the CFLAGS except for 
darwin externals and some others like pdp. If it fixes the denormal 
problem it should probably be there. The gcc docs are very terse about 
what it actually does though.

Also the PD_BADFLOAT macro in m_pd.h never gets called by any code:

#define PD_BADFLOAT(f) ((((*(unsigned int*)&(f))&0x7f800000)==0) || \
     (((*(unsigned int*)&(f))&0x7f800000)==0x7f800000))

, maybe because a floating point calculation that results in a denormal 
will be trapped before the user code can test it, unless the processor 
is set to ignore denormals. PD_BADFLOAT works if you're doing integer 
fixed point math and packing the result into a floating point frame, as 
in osc~.

Martin

Hans-Christoph Steiner wrote:
> 
> I thought that compiling with -ffast-math disabled the denormal stuff.  
> Or maybe it was a different compiler flag. That might be an easier route 
> to deal with denormals.
> 
> .hc
> 
> On Aug 15, 2009, at 11:12 AM, Martin Peach wrote:
> 
>> 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".
>>
>> 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.
>>
>> A bunch of interesting stuff here:
>> 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/ 
>>
>> ....where the conclusion reads:
>>
>> "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."
>>
>>
>> Martin
>>
>>
>> Ed Kelly wrote:
>>> Hi Damon,
>>> I have tried to implement this technique, to fix the svf~ and I am 
>>> still getting denormal errors pegging the CPU. Is there anything I 
>>> have missed do you think? After reading a little bit about unions and 
>>> uint32_t I think I've used them correctly...
>>> If this bug can be zapped for good then I'd like to eliminate 
>>> denormal errors from the svn for good!
>>> Best,
>>> Ed
>>> --- On Fri, 14/8/09, Damon Chaplin <damon at karuna.eclipse.co..uk> wrote:
>>>> From: Damon Chaplin <damon at karuna.eclipse.co.uk>
>>>> Subject: Re: [PD-dev] denormals: svf, freeverb (was Re: [PD] bug in 
>>>> freeverb???)
>>>> To: "Ed Kelly" <morph_2016 at yahoo.co.uk>
>>>> Cc: "PD List" <pd-list at iem.at>, "pddev" <pd-dev at iem.at>
>>>> Date: Friday, 14 August, 2009, 1:51 PM
>>>>
>>>> On Fri, 2009-08-14 at 13:06 +0100, Damon Chaplin wrote:
>>>>> On Fri, 2009-08-14 at 13:03 +0100, Damon Chaplin
>>>> wrote:
>>>>>>   if (u.int_value &
>>>> 0x7f800000)
>>>>>>      fv = 0.0f;
>>>>> Oops. That should be:
>>>>>
>>>>>  if (u.int_value & 0x7f800000 == 0)
>>>>>      fv = 0.0f;
>>>> Or even better:
>>>>
>>>> if ((u.int_value & 0x7f800000) == 0)
>>>>    fv = 0.0f;
>>>>
>>>> Damon
>>>>
>>>>
>>>>
>>>      
>>> ------------------------------------------------------------------------
>>> _______________________________________________
>>> Pd-dev mailing list
>>> Pd-dev at iem.at
>>> http://lists.puredata.info/listinfo/pd-dev
>>
>>
>> _______________________________________________
>> Pd-list at iem.at mailing list
>> UNSUBSCRIBE and account-management -> 
>> http://lists.puredata.info/listinfo/pd-list
> 
> 
> ---------------------------------------------------------------------------- 
> 
> 
> Access to computers should be unlimited and total.  - the hacker ethic
> 
> 
> 
>