[PD] readsf~ harddisc access [denormals once again]

[derek holzer]

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.
-- 
derek holzer ::: http://www.umatic.nl
---Oblique Strategy # 148:
"State the problem in words as clearly as possible"