[PD] Raspberry Pi does denormals

Tue Jan 22 13:04:12 CET 2013

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 at 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 at 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 at 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 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 at iem.at mailing list
>> >> > UNSUBSCRIBE and account-management ->
>> >> > http://lists.puredata.info/listinfo/pd-list
>> >> >
>> >>
>> >> _______________________________________________
>> >> Pd-list at iem.at mailing list
>> >> UNSUBSCRIBE and account-management ->
>> >> http://lists.puredata.info/listinfo/pd-list
>> >
>> >
>> >
>> > _______________________________________________
>> > Pd-list at iem.at mailing list
>> > UNSUBSCRIBE and account-management ->
>> > http://lists.puredata.info/listinfo/pd-list
>> >
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: denorm-test.pd
Type: application/octet-stream
Size: 2824 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20130122/d0b3fa6f/attachment.obj>