derek holzer wrote:

You might examine other possibilities as well. One big one is if you have a Pentium 4 processor. I've been fighting with CPU spikes in PD for a very long time now, and often find them related to denormal numbers. These are numbers very close to absolute zero, but not quite there, and are characterized by an extremely long series of digits after the decimal point, and which kick a P4 CPU into extremely slow and accurate mode. I found the problem to be much worse under Linux, but that doesn't mean it doesn't exist under windoze.

So, i've read some of the previous postings on this, and it surely sounds like that has happened to me. I read a tip about adding noise to critical sections of the patch, but can't really figure out how much and in what kind of situations. It would be great to see a patch which does this.

Otherwise, does anyone have any other practical tips in how to design a patch to make it immune against the slow and accurate mode?

thanks! Johannes

Tim Blechmann wrote:

...

...

You might examine other possibilities as well. One big one is if you have a Pentium 4 processor. I've been fighting with CPU spikes in PD for a very long time now, and often find them related to denormal numbers. These are numbers very close to absolute zero, but not quite there, and are characterized by an extremely long series of digits after the decimal point, and which kick a P4 CPU into extremely slow and accurate mode. I found the problem to be much worse under Linux, but that doesn't mean it doesn't exist under windoze.

So, i've read some of the previous postings on this, and it surely sounds like that has happened to me. I read a tip about adding noise to critical sections of the patch, but can't really figure out how much and in what kind of situations. It would be great to see a patch which does this.

one possibility is to add noise of about 1e-10 ... also the PD_BADFLOAT macro that's supposed to flush denormal numbers to zero ... but it's only killing numbers that are already denormals... i'd suggest to use the devel_0_37 branch since it contains a small patch that flushes almost denormal numbers to zero ... it helped to reduce cpu spikes on my p4 ...

Yes, you should certainly try the devel_0.37 and see if it helps you out. Dealing with denormals is quite difficult, and Intel has no plans to correct this problem any time in the future, so either people have to not buy Pentium processors for audio work, or programmers need to account for this problem in their code. Since a lot of programmers I know don't have a P4 handy to test on all the time, it makes it difficult. Trust me, PD is not the only program which suffers from denormals.

Denormals tend to happen in two places: in filters, where certain frequency componants are greatly attentuated, leading to very low sample values, and in any kind of feedback situation where the signal is attenuated over time [classic example is the tail of a reverb or delay]. Since the denormals happen *inside* the objects, you have to add whatever "safety noise" in at a point where it will remain present whereever denormals may occur, but I think it would be impossible to catch every place where you might get them. In a feedback delay patch, for example, you might have to add it *after* the attentuator for the signal which is fed back into the system.

For filters, you don't have much of a choice. The attentuation happens inside, so their code must be written to handle denormals. I know for a fact that the standard high, low and band pass filters in Miller's PD do not take denormals into account, for example. It is one of the big weaknesses of digital filters [at least on a P4], along with the possibility of "blowing up" when you run too much signal through them [see C. Roads "Computer Music Tutorial" or Boulanger ed. "The CSound Book" for big discussions on digital filters].

good luck, d.

Tim Blechmann wrote: there are some ways to avoid denormals ... one of them is using the simd

instructions that are said to help ... i'm still experiencing denormal problems with steve harris's ladspa plugins ...

Tom Szilagyi is going through some serious work on his TAP plugins for exactly the same reason. He never tested them on Pentium before.

if you are planing to buy a new processor for audio, stay away from intel... btw, i don't know if this makes sense, but when used a suse linux on my machine a year ago, i could use some tools, that i can't use on my gentoo system any more (e.g. steve harris's flanger) i don't know what might cause that (it's not related to a difference in compilation ... i tried the same binaries) maybe suse is doing some fancy stuff with their glibc ... i'm still confused by that...

What is SuSE's exact position on licenses? Not to open this box one more time for theoretical squabbling, but I wonder if they have cribbed something from the Intel compiler?

d.

On Jun 15, 2004, at 2:39 PM, Tim Blechmann wrote:

...

...

i'm still experiencing denormal problems with steve harris's ladspa plugins ...

Tom Szilagyi is going through some serious work on his TAP plugins for exactly the same reason. He never tested them on Pentium before.

developers should have slow machines with big denormal problems ;-)

...

What is SuSE's exact position on licenses? Not to open this box one more time for theoretical squabbling, but I wonder if they have cribbed something from the Intel compiler?

i'm not sure ... maybe they used a commercial compiler... it it said, that the intel compiler had some improvements to detect and remove denormal numbers, but i've never been able to prove that ... i tried several compiler flags without success, the only success i had was changing the PD_BADFLOAT macro... the best sollution would probably be to rewrite the critical operations in assembler for the critical (p4) systems ... using sse instructions...

thomas grill did something like that, but iirc only for altivec and visual c, not for gcc (although i don't know the difference between vc and gcc) ... when i have too much time, i'll probably look into it...

Has anyone tested gcc's -mfpmath=sse2 option in regards to denormals?
If SSE helps with denormals, it seems like all of Pd should be compiled with this option.

.hc

                                 http://at.or.at/hans/

thanks for all the help so far. It seems like devel_0.37 might be a good thing, but unfortunately i'm a complete newbie in terms of compiling my own pd. The best thing would of course be a compiled-and-ready package, but that might be asking too much. I don't mind learning something new, but I just don't know where to start looking. I'm on windows (xp), i do have an installation of VC++ 6.0, have downloaded the source code, have browsed in the cvs and googled around just to make sure i'm not missing something obvious, but now i'm stuck. Any help would be great.

Johannes

derek holzer wrote:

Tim Blechmann wrote:

...

one possibility is to add noise of about 1e-10 ... also the PD_BADFLOAT macro that's supposed to flush denormal numbers to zero ... but it's only killing numbers that are already denormals... i'd suggest to use the devel_0_37 branch since it contains a small patch that flushes almost denormal numbers to zero ... it helped to reduce cpu spikes on my p4 ...

Yes, you should certainly try the devel_0.37 and see if it helps you out. Dealing with denormals is quite difficult, and Intel has no plans to correct this problem any time in the future, so either people have to not buy Pentium processors for audio work, or programmers need to account for this problem in their code. Since a lot of programmers I know don't have a P4 handy to test on all the time, it makes it difficult. Trust me, PD is not the only program which suffers from denormals.

Denormals tend to happen in two places: in filters, where certain frequency componants are greatly attentuated, leading to very low sample values, and in any kind of feedback situation where the signal is attenuated over time [classic example is the tail of a reverb or delay]. Since the denormals happen *inside* the objects, you have to add whatever "safety noise" in at a point where it will remain present whereever denormals may occur, but I think it would be impossible to catch every place where you might get them. In a feedback delay patch, for example, you might have to add it *after* the attentuator for the signal which is fed back into the system.

For filters, you don't have much of a choice. The attentuation happens inside, so their code must be written to handle denormals. I know for a fact that the standard high, low and band pass filters in Miller's PD do not take denormals into account, for example. It is one of the big weaknesses of digital filters [at least on a P4], along with the possibility of "blowing up" when you run too much signal through them [see C. Roads "Computer Music Tutorial" or Boulanger ed. "The CSound Book" for big discussions on digital filters].

good luck, d.