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 <christof.re...@gmx.at> 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 <katjavet...@gmail.com>
>> An: "Christof Ressi" <christof.re...@gmx.at>, "pd-list@lists.iem.at" 
>> <pd-list@lists.iem.at>
>> 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 <christof.re...@gmx.at> 
>> 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 <katjavet...@gmail.com>
>> >> An: "Christof Ressi" <christof.re...@gmx.at>
>> >> Cc: pd-list <pd-l...@iem.at>, "Miller Puckette" <m...@ucsd.edu>
>> >> 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 <christof.re...@gmx.at> 
>> >> 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" <christof.re...@gmx.at>
>> >> >> An: pd-l...@iem.at, "Miller Puckette" <m...@ucsd.edu>
>> >> >> 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_______________________________________________
>> >> >> Pd-list@lists.iem.at mailing list
>> >> >> UNSUBSCRIBE and account-management -> 
>> >> >> https://lists.puredata.info/listinfo/pd-list
>> >> >>
>> >> > _______________________________________________
>> >> > Pd-list@lists.iem.at mailing list
>> >> > UNSUBSCRIBE and account-management -> 
>> >> > https://lists.puredata.info/listinfo/pd-list
>> >> >
>> >>
>>
#N canvas 129 301 620 382 10;
#X symbolatom 18 351 72 0 0 0 - - -;
#X obj 18 323 makefilename %.70f;
#N canvas 0 50 190 245 nan 0;
#X obj 45 17 inlet;
#X obj 46 173 outlet;
#X obj 45 74 t b f;
#X msg 46 96 2;
#X obj 46 143 * 0;
#X obj 46 118 pow 1024;
#X msg 45 49 1024;
#X connect 0 0 6 0;
#X connect 2 0 3 0;
#X connect 2 1 5 1;
#X connect 3 0 5 0;
#X connect 4 0 1 0;
#X connect 5 0 4 0;
#X connect 6 0 2 0;
#X restore 18 44 pd nan;
#X obj 18 20 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1
-1;
#N canvas 0 50 168 259 inf 0;
#X obj 45 17 inlet;
#X obj 46 173 outlet;
#X obj 45 74 t b f;
#X msg 46 96 2;
#X obj 46 118 pow 1024;
#X msg 45 49 1024;
#X connect 0 0 5 0;
#X connect 2 0 3 0;
#X connect 2 1 4 1;
#X connect 3 0 4 0;
#X connect 4 0 1 0;
#X connect 5 0 2 0;
#X restore 71 44 pd inf;
#X obj 71 20 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1
-1;
#X floatatom 18 181 8 0 0 0 - - -;
#X msg 72 116 1;
#X msg 72 86 0;
#X msg 106 202 \; pd dsp 1;
#X msg 106 241 \; pd dsp 0;
#X obj 106 179 loadbang;
#N canvas 0 50 200 224 unsig~ 0;
#X obj 32 40 inlet~;
#X obj 32 122 snapshot~;
#X obj 61 89 metro 200;
#X obj 61 62 tgl 15 1 empty empty empty 17 7 0 10 -262144 -1 -1 1 1
;
#X obj 32 153 outlet;
#X connect 0 0 1 0;
#X connect 1 0 4 0;
#X connect 2 0 1 0;
#X connect 3 0 2 0;
#X restore 18 266 pd unsig~;
#X floatatom 18 296 17 0 0 0 - - -;
#X text 183 133 Small floats which can't be expressed with the bits
of the datatype are also denormal \, more specifically: subnormal.
Computations with subnormal numbers are still possible \, but very
CPU intensive. Test: click 1 first \, then 0 to see how small the numbers
become. If all is OK \, numbers smaller than ~1e-19 are flushed to
zero. If not OK \, numbers smaller than 1e-39 are seen. These are subnormals.
Check CPU load difference. It is always possible to recover from subnormals
by sending a normal number (like 1) in.;
#X text 184 320 Katja Vetter Jan 2013;
#X obj 18 216 lop~ 1;
#X text 183 261 IIR filters have internal feedback delay lines \, therefore
objects like [lop~] \, [hip~] and [biquad~] must be protected against
denormals.;
#X text 183 18 NaN and inf are denormal numbers. When inf or nan starts
recirculating in a feedback delay line \, the object can't do further
calculations \, even if the input goes back to normal. Therefore Pd
must avoid writing nan or inf into a feedback delay line. Test: click
nan or inf first \, and 1 thereafter. If all is OK \, the output returns
to normal. If not OK \, inf or nan will stay at the output and the
patch must be reloaded to recover.;
#X connect 1 0 0 0;
#X connect 2 0 6 0;
#X connect 3 0 2 0;
#X connect 4 0 6 0;
#X connect 5 0 4 0;
#X connect 6 0 16 0;
#X connect 7 0 6 0;
#X connect 8 0 6 0;
#X connect 11 0 9 0;
#X connect 12 0 13 0;
#X connect 13 0 1 0;
#X connect 16 0 12 0;
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Reply via email to