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 <[email protected]> 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 <[email protected]> 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 >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > [email protected] mailing list >> >> > UNSUBSCRIBE and account-management -> >> >> > http://lists.puredata.info/listinfo/pd-list >> >> > >> >> >> >> _______________________________________________ >> >> [email protected] mailing list >> >> UNSUBSCRIBE and account-management -> >> >> http://lists.puredata.info/listinfo/pd-list >> > >> > _______________________________________________ >> > [email protected] mailing list >> > UNSUBSCRIBE and account-management -> >> > http://lists.puredata.info/listinfo/pd-list _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
