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!<br><br>Cheers,<br><br>
Pierre.<br><br><div class="gmail_quote">2013/1/21 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">
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>
<span class="HOEnZb"><font color="#888888"><br>
Katja<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On Sun, Jan 20, 2013 at 5:27 PM, Pierre Massat <<a href="mailto:pimassat@gmail.com">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">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) 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. -mfp<br>
>> and<br>
>> -mfpe are synonyms for -mfpu=fpenumber, for compatibility with 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 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 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 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. 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">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">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">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>
</div></div></blockquote></div><br>