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 pimassat@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 katjavetter@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 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