[PD] Raspberry Pi does denormals

Tue Jan 22 20:40:53 CET 2013

Hi Katja,

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.

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.

I guess you're not the only one, are you ?

Cheers,

Pierre.

2013/1/22 katja <katjavetter at gmail.com>

> 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20130122/65b8fc5b/attachment-0001.htm>