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@karuna.eclipse.co..uk> wrote:
From: Damon Chaplin damon@karuna.eclipse.co.uk Subject: Re: [PD-dev] denormals: svf, freeverb (was Re: [PD] bug in freeverb???) To: "Ed Kelly" morph_2016@yahoo.co.uk Cc: "PD List" pd-list@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
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-... ....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@karuna.eclipse.co..uk> wrote:
From: Damon Chaplin damon@karuna.eclipse.co.uk Subject: Re: [PD-dev] denormals: svf, freeverb (was Re: [PD] bug in freeverb???) To: "Ed Kelly" morph_2016@yahoo.co.uk Cc: "PD List" pd-list@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
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-... ....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@karuna.eclipse.co..uk> wrote:
From: Damon Chaplin damon@karuna.eclipse.co.uk Subject: Re: [PD-dev] denormals: svf, freeverb (was Re: [PD] bug in freeverb???) To: "Ed Kelly" morph_2016@yahoo.co.uk Cc: "PD List" pd-list@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-list@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
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-...
....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@karuna.eclipse.co..uk> wrote:
From: Damon Chaplin damon@karuna.eclipse.co.uk Subject: Re: [PD-dev] denormals: svf, freeverb (was Re: [PD] bug in freeverb???) To: "Ed Kelly" morph_2016@yahoo.co.uk Cc: "PD List" pd-list@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-list@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
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-...
On 08/15/2009 11:42 PM, Ed Kelly wrote:
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.
as stated before in this thread, denormals can slow down the computation on the fpu. the problem is not as big, when compiling the binary to use the sse unit, though (btw, this is the default, when compiling for x86_64)
pd devel_0_39 did also set the DAZ/FTZ flags, which affect the denormal handling on the sse unit, but that was never merged into vanilla pd
hth, tim
as stated before in this thread, denormals can slow down the computation on the fpu. the problem is not as big, when compiling the binary to use the sse unit, though (btw, this is the default, when compiling for x86_64)
Indeed, but externals that run a little slow are better than those that crash PD in the middle of a performance! This is why I'm trying to find a way of fixing the externals that suffer from this. moog~ is another! Meanwhile, I've rolled back to the old svf~ external so that the metastudio drumsynths don't crash. I had a very successful gig last night as a result..
Who wrote the old svf~?
pd devel_0_39 did also set the DAZ/FTZ flags, which affect the denormal handling on the sse unit, but that was never merged into vanilla pd
I see there's a new pd_devel branch. I should check it out.
Vest, Ed
hth, tim
-- tim@klingt.org http://tim.klingt.org
Only very good and very bad programmers use goto in C
-----Inline Attachment Follows-----
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Send instant messages to your online friends http://uk.messenger.yahoo.com
pd devel_0_39 did also set the DAZ/FTZ flags, which affect the denormal handling on the sse unit, but that was never merged into vanilla pd
I see there's a new pd_devel branch. I should check it out.
i doubt, that the new pd_devel branch shares anything with the old pd_devel except for the name ... also, please note that daz/ftz only deal with the behavior of the sse unit ... if your external is compiled to use the fpu, you will still see performance issues, when denormal numbers occur
best, tim
On Aug 20, 2009, at 12:29 PM, Tim Blechmann wrote:
pd devel_0_39 did also set the DAZ/FTZ flags, which affect the denormal handling on the sse unit, but that was never merged into vanilla pd
I see there's a new pd_devel branch. I should check it out.
i doubt, that the new pd_devel branch shares anything with the old pd_devel except for the name ... also, please note that daz/ftz only deal with the behavior of the sse unit ... if your external is compiled to use the fpu, you will still see performance issues, when denormal numbers occur
Yeah, it was a mistake on our part to name it pd-devel, since its not the same thing. We should have called the pd-devel/0.41.4 branch something like "gui-rewrite", since it does not share anything with earlier pd-devel branches.
.hc
best, tim
-- tim@klingt.org http://tim.klingt.org
The price an artist pays for doing what he wants is that he has to do it. William S. Burroughs
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.
On Sat, 2009-08-15 at 06:48 -0700, 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!
Maybe you didn't get all the denormals. You could try adding checks for denormals throughout the code (just while debugging), using something like:
static inline check_for_denormal (float value) { union { float value; uint32_t i; } u;
u.value = value;
/* A denormal has a 0 exponent and a non-0 mantissa, so check that the value has a non-zero exponent or a 0 mantissa. */ assert ((u.i & 0x7F800000) != 0 || (u.i & 0x007FFFFF) == 0) }
Damon