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 pimassat@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 hans@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 floatingpoint 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