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 <da...@karuna.eclipse.co..uk> wrote:
From: Damon Chaplin <da...@karuna.eclipse.co.uk>
Subject: Re: [PD-dev] denormals: svf, freeverb (was Re: [PD] bug in
freeverb???)
To: "Ed Kelly" <morph_2...@yahoo.co.uk>
Cc: "PD List" <pd-l...@iem.at>, "pddev" <pd-dev@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@iem.at
http://lists.puredata.info/listinfo/pd-dev
_______________________________________________
pd-l...@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
_______________________________________________
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
