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.
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 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@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
>