[PD] Raspberry Pi does denormals

[katja]

Tried the 0.44.0 build from your website. It has the same issue with
subnormal values. My test patch is with [lop~]. If inf or nan is fed
into [lop~], these 'values' keep circulating in the object, it can no
longer process normal signal values.

I also tried my reverb stuff with specific compiler options for Pi's processor:

-march=armv6zk
-mcpu=arm1176jzf-s
-mtune=arm1176jzf-s

With these options, gcc should be able to decide that RunFast mode is
permitted. But even in combination with -ffast-math (which in turn
sets -funsafe-math-optimizations and -fno-trapping-math amongst
others), denormals are still there. I'm literally out of options for
the moment. Sorry for not having better news.

Katja



On Sun, Jan 20, 2013 at 9:51 PM, Miller Puckette <msp at ucsd.edu> wrote:
> OK.. but try the 0.44 build on my site - the one from Raspian is quite old :)
>
> M
>
> On Sun, Jan 20, 2013 at 09:28:30PM +0100, katja wrote:
>> Miller, the vanilla Pd which can be installed from Raspbian with
>> apt-get or Synaptic does have the subnormals problem, as can be
>> checked with a test patch attached with my first post. When an input
>> signal to [lop~] is shut off, CPU load increases substantially. Output
>> values go down in the order of 1e-44, subnormal range. I was working
>> on reverb algo's showing the same problem, and compiled with option
>> -ffastmath / --fast-math to see if that would turn on RunFast mode,
>> but it didn't.
>>
>> I'm not familiar with ARM and it's coprocessors, but from Intel I do
>> know that gcc doesn't implement certain specified optimization options
>> (notably SSE versions) unless you also mention a processor type that
>> can handle it . A similar case could be with Rpi's vfpv2; it can do
>> RunFast mode but gcc doesn't implement it, until you find a way to
>> specify vfpv2 (vfpv1 can't do RunFast). Miller, if you succeeded in
>> getting automatic flush-to-zero on the Pi, it may be related to other
>> flags which you've set. Arch flags which I've set so far are
>> -march=armv6 and -mfpu=vfp. Option -mfpu=vfpv2 is not allowed. I would
>> be happy to do further testing with compiler options, if you know
>> some. The big-or-small checks are rather expensive for RPi, that's
>> what I've found.
>>
>> Katja
>>
>>
>> On Sun, Jan 20, 2013 at 8:24 PM, Miller Puckette <msp at ucsd.edu> wrote:
>> > Hi all...
>> >
>> > I think it's possible to get flush-to-zero behavior on the Pi (ARMv6) by
>> > calling gcc with --fast-math.  At any rate what I found was that, if I
>> > compiled without --fast-math, when numbers got small (e.g., when a
>> > reverberator decays down past 10^-38 or so), the patch would suddenly jump
>> > in CPI usage as if it were trappnig to the kernel (as it does for i386).
>> > But when I added --fast-math the problem went away.
>> >
>> > On i386 and x86_64, I believe that one can't get flush-to-zero (at least in
>> > the "normal" non-SSE floating point instructions) so there's no choice but
>> > to use a macro such as PD_BADFLOAT to protect against that.  So in m_pd.h the
>> > PD_BADFLOAT macro is only "turned on" for Intel.
>> >
>> > However I've been mistaken many times about all this in the past and won't
>> > be surprised if I'm mistaken again.
>> >
>> > cheers
>> > Miller
>> >
>> > On Sun, Jan 20, 2013 at 11:12:28AM -0500, Hans-Christoph Steiner wrote:
>> >>
>> >> 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