At the moment I'm compiling Pd using mingw but having to rely on
Microsoft Visual C for "pd.lib" (apparently linker information) and
all the eterns in "extra" - I never could get that part to work in
mingw.  I think it's time I tried again to get everything moved over to
mingw, especially since it's apparently generating much faster code.

Probably wont be able to do and test this till I get back to a windows
machine, perhaps January...

M

On Wed, Sep 21, 2016 at 11:47:14PM +0200, katja wrote:
> 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


_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Reply via email to