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