Hi Katja, I tried on my laptop (Intel dual-core 2 duo, 1,66GHz), and it works fine I guess. It takes a little to go from 0 to 1 and back, but there doesn't seem to be any particular issues with NAN and INF numbers.
Now on the Pi : sending a NAN to the lop~ makes it hang. Sending 1 works fine, but sending 0 after that results in a different behaviour compared to that of my laptop : the number of non-zero digits seems to grow much faster, and it never really actually goes to 0. It (apparently) hangs with still about 30 non-zero digits to the right of the very long number. I guess you're not the only one, are you ? Cheers, Pierre. 2013/1/22 katja <katjavet...@gmail.com> > Hey Pierre, > > I've commented patch denorm-test.pd in such a way that it explains the > topic a bit more (see attached). Now I'd like to ask you, if you can > run the patch on a 'normal' computer and on your Raspberry Pi for > comparison. If you have Pd gui on the Pi, you should be able to check > if your Pd install has a denormals issue. It's hard to believe that I > would be the only one experiencing this issue, but I need to be sure. > > In my previous mail I stated that it is easy to avoid subnormals by > just feeding a very small number in objects that may decay into > subnormal range (feedback delay lines and most filters). But in > practice, this is not always so easy, as I am now experiencing while > trying to make a big patch work well on the Pi. There are many more > filters than I was aware of. For example, following a bit-mangling > operation a [hip~] was added to remove DC. Now if the bit-mangler > stops receiving signal input, [hip~] starts to chew subnormals until > it will receive signal again. I found that each filter struggling with > subnormals eats at least 6% CPU time (while they do some 0.25% in > normal state). Pd objects should really take care of this in one way > or another, it's too confusing for the user to sort it out. I'm going > to try recompile Pd with PD_BIGORSMALL checks enabled, and see what it > means for the normal performance of the filter objects. > > Katja > > > On Mon, Jan 21, 2013 at 4:24 PM, Pierre Massat <pimas...@gmail.com> wrote: > > Hi Katja, thank you for your reply! It is now (slightly) clearer. Every > time > > you post something here I feel like some messages from a technical NASA > > mailing list are being accidentally sent to pd-list! > > > > Cheers, > > > > Pierre. > > > > > > 2013/1/21 katja <katjavet...@gmail.com> > >> > >> Pierre, the way how denormals can impact performance on the Pi, is > >> whenever a an object with feedback delay (IIR filter, reverb etc.) > >> stops receiving input signal, it's values decay into the subnormal > >> range, which causes substantial increase of CPU load. Such situations > >> can be avoided by adding a tiny DC value to the object input, like [+~ > >> 1e-21] (note the minus sign in the number notation). When a normal > >> audio signal is present, that number is too small to be added (because > >> of limited precision), but when audio stops, it prevents subnormals. > >> > >> Another thing is, one should be careful not to accidentally send 'inf' > >> or 'nan' into such objects, as they can not recover from it. This > >> would be particularly annoying in a public performance, since you'd > >> need to reload the containing patch to recover. > >> > >> It is possible to prevent denormals via C code, as it is currently > >> done for Pd on Intel processors, but this implements a lot of > >> conditional checks and it means performance loss for many objects. For > >> current Intel computers the extra load is not so much of a problem, > >> but for poor Raspberry Pi one would rather like to save a few > >> instructions, instead of adding more. > >> > >> Katja > >> > >> > >> On Sun, Jan 20, 2013 at 5:27 PM, Pierre Massat <pimas...@gmail.com> > wrote: > >> > Hi, > >> > > >> > Could someone please explain how this impacts Pd's performance on the > >> > Raspberry Pi ? > >> > It doesn't make any sense to me right now, but i'm very curious... > >> > > >> > Cheers, > >> > > >> > Pierre. > >> > > >> > > >> > 2013/1/20 Hans-Christoph Steiner <h...@at.or.at> > >> >> > >> >> > >> >> I think this is what you want, from 'man gcc'. Its interesting to > note > >> >> that > >> >> the NEON mode, which provides SIMD, also does not do denormals: > >> >> > >> >> -mfpu=name > >> >> -mfpe=number > >> >> -mfp=number > >> >> This specifies what floating point hardware (or hardware > emulation) > >> >> is > >> >> available on the target. Permissible names are: fpa, fpe2, fpe3, > >> >> maverick, > >> >> vfp, vfpv3, vfpv3-fp16, vfpv3-d16, vfpv3-d16-fp16, vfpv3xd, > >> >> vfpv3xd-fp16, > >> >> neon, neon-fp16, vfpv4, vfpv4-d16, fpv4-sp-d16 and neon-vfpv4. > >> >> -mfp > >> >> and > >> >> -mfpe are synonyms for -mfpu=fpenumber, for compatibility with > >> >> older > >> >> versions of GCC. > >> >> > >> >> If -msoft-float is specified this specifies the format of > floating > >> >> point > >> >> values. > >> >> > >> >> If the selected floating-point hardware includes the NEON > extension > >> >> (e.g. > >> >> -mfpu=neon), note that floating-point operations will not be used > >> >> by > >> >> GCC's > >> >> auto-vectorization pass unless -funsafe-math-optimizations is > also > >> >> specified. This is because NEON hardware does not fully > implement > >> >> the > >> >> IEEE > >> >> 754 standard for floating-point arithmetic (in particular > denormal > >> >> values > >> >> are treated as zero), so the use of NEON instructions may lead > to a > >> >> loss of > >> >> precision. > >> >> > >> >> > >> >> .hc > >> >> > >> >> On 01/20/2013 06:54 AM, katja wrote: > >> >> > I was assuming, or maybe just hoping? that Raspberry Pi (and ARM > >> >> > devices in general) would not suffer from Denormal's disease like > >> >> > Intel processors do. But guess what: Pi's float coprocessor is IEEE > >> >> > 754 compliant and does all denormals by default (can check with > >> >> > attached denorm-test.pd). Bummer! As if one would use an ARM device > >> >> > to > >> >> > calculate the size of a Majorana particle, rather than doing simple > >> >> > dsp. Do we really need to enable PD-BIGORSMALL() checks for this > poor > >> >> > little processor? There seems to be something called 'RunFast mode' > >> >> > for Pi's float processor vfpv2, but I see no way how to enable this > >> >> > via gcc. Option -ffast-math is allowed but doesn't do the trick. > >> >> > Can't > >> >> > find an option to set vfpv2 specifically, in gcc docs. > >> >> > > >> >> > Katja > >> >> > > >> >> > > >> >> > > >> >> > _______________________________________________ > >> >> > Pd-list@iem.at mailing list > >> >> > UNSUBSCRIBE and account-management -> > >> >> > http://lists.puredata.info/listinfo/pd-list > >> >> > > >> >> > >> >> _______________________________________________ > >> >> Pd-list@iem.at mailing list > >> >> UNSUBSCRIBE and account-management -> > >> >> http://lists.puredata.info/listinfo/pd-list > >> > > >> > > >> > > >> > _______________________________________________ > >> > Pd-list@iem.at mailing list > >> > UNSUBSCRIBE and account-management -> > >> > http://lists.puredata.info/listinfo/pd-list > >> > > > > > >
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list