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 <[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 > >> >> > > >> >> > >> > #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; > _______________________________________________ > [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
