> 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-in-ia-32-flush-to-zero-ftz-and-denormals-are-zero-daz/ _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
