From a few posts ago it looks like -O3 is what causes denormals to
stick around, but I don't really know what I'm talking about. RK4 (which
is what bob~ uses to solve the system) will never 'naturally' bring the
filter state exactly back to 0 unless forced to in some way so if the
denormals aren't handled elegantly, they will abound with 0 input to the
filter no matter what (once some input has gone into the filter that
is). My guess is that a slow decay doesn't push the filter states down
into that region.
It is stupid and certainly sub-optimal, but maybe:
x = (x<DENORMAL_THRESH ? 0 : x);
where DENORMAL_THRESH is some very, very small normal number? This would
have to be done on the negative side of 0, too. 2x compares is probably
not as bad as the potential 100x slowdown (according to Wikipedia) that
denormal arithmetic might cause.
It should be the case that the same compiler flags (for plain C anyway)
produce, within limits, the same behavior across different compilers but
that probably isn't true. This would be an interesting check. I'd like
to know if leaving off -03 has the same effect with gcc.
On 9/21/2016 3:26 PM, katja wrote:
On Linux i386 bob~ produces subnormals as well and very high cpu load.
It is not the slowly decaying signal that other filters tend to give,
but a quick decay to a fixed small number.
It's weird indeed when subnormals cause different CPU load depending
on how they are compiled. Since MinGW is a gcc port I would think it
uses the same math implementation which produces such high CPU load
for bob~ subnormals on my system.
On Thu, Sep 22, 2016 at 12:01 AM, Christof Ressi <[email protected]> wrote:
I tried your patch with the [bob~] object shipped with the Windows binaries. I
clearly get subnormals! It's actually no wonder because there isn't any
protection against subnormals in the code (at least I couldn't spot it).
But the weird thing is: the [bob~] I compiled myself would also show subnormals
in your patch but the CPU load is not affected...
Gesendet: Mittwoch, 21. September 2016 um 23:47 Uhr
Von: katja <[email protected]>
An: "Christof Ressi" <[email protected]>
Cc: "[email protected]" <[email protected]>
Betreff: Re: Re: Re: [PD] [bob~] denormals issue?
Without -O flags you get debug-level and all function inlining is
disabled, depending on the code it can make a huge difference indeed.
But Pd is probably compiled with at least -O2. So the flags don't make
much difference. The compiler? Doesn't Miller compile with MinGW
nowadays, I don't know. MinGW brings its own standard C libs, which
may implement math functions differently than MS. But regarding
denormals I guess they both respect the IEEE 754 standard.
You can check if you really have subnormals using attached patch
denorm-test.pd you. The patch tests lop~, change it to bob~.
On Wed, Sep 21, 2016 at 11:18 PM, Christof Ressi <[email protected]> wrote:
the SSE optimizations don't seem to matter at all. skipping -ffast-math gives a
slight overall CPU rise, while skipping -O3 gives me huge CPU rise (20 bob~
filters are already to much for one core). Even when skipping all of those
flags, the denormals issue is still not present.
Maybe it has something to do with the compiler?
Gesendet: Mittwoch, 21. September 2016 um 22:47 Uhr
Von: katja <[email protected]>
An: "Christof Ressi" <[email protected]>, "[email protected]"
<[email protected]>
Betreff: Re: Re: [PD] [bob~] denormals issue?
I'm curious to know if the flags do flush denormals on your processor.
Forgot to mention that '-O3 -ffast-math' are also set,
platform-independent. So if you have a chance to try which flag does
something... It's just curiosity.
On Wed, Sep 21, 2016 at 10:34 PM, Christof Ressi <[email protected]> wrote:
Hi Katja,
Even if your test reveals a beneficial effect from compiler flags,
it is better when denormals are detected and flushed in the C code.
definitely! Maybe using the PD_BIGORSMALL macro on each filter state at the end
of the DSP routine does the trick, just like in all the other recursive filters
in Pd.
Von: katja <[email protected]>
An: "Christof Ressi" <[email protected]>
Cc: pd-list <[email protected]>, "Miller Puckette" <[email protected]>
Betreff: Re: [PD] [bob~] denormals issue?
Hi Christof,
Makefile.pdlibbuilder passes flags '-march=pentium4 -msse -msse2
-mfpmath=sse' for optimization to the compiler on Windows. You could
try compiling without (some of) these flags to see if they are
responsible for the different behavior. Makefile-defined optimization
flags can be overriden with argument CFLAGS given on command line.
The effect of optimization flags on denormals varies per processor
type, unfortunately. When we had denormals on Raspberry Pi ARMv6 they
wouldn't go away no matter what flags, is what I remember. Even if
your test reveals a beneficial effect from compiler flags, it is
better when denormals are detected and flushed in the C code. Anyway,
it is still interesting to know what makes the difference.
Katja
On Wed, Sep 21, 2016 at 12:32 AM, Christof Ressi <[email protected]> wrote:
Hmmm... I compiled [bob~] myself with MinGW and pd-lib-builder and I noticed
two things:
1) the CPU rise is gone
2) it needs only half the CPU. I put 20 [bob~] objects in a switched subpatch
and measured the CPU load. The DLL which comes with the Windows binaries needs
15%, while my own DLL needs only 7%! That's quite a deal...
Christof
PS: I attached the DLL in case you wanna try it yourself.
Gesendet: Samstag, 17. September 2016 um 22:58 Uhr
Von: "Christof Ressi" <[email protected]>
An: [email protected], "Miller Puckette" <[email protected]>
Betreff: [PD] [bob~] denormals issue?
Hi Miller,
feeding audio into [bob~] and then going to zero will increase the CPU load by
ca. 6%. Clearing the filter or adding a tiny amount of noise brings the CPU
load back to its usual level immediately, so I guess it's a problem with
denormals.
My Pd load meter won't really show the increase, but it's clearly visibly on
Process Explorer.
See my attached patch. Tried with Pd 0.47.1, Lenovo Thinkpad L440, Windows 7.
Christof_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
