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