[PD] Raspberry Pi does denormals

[Pierre Massat]

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/20130121/6eeba1b5/attachment.htm>