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.ressi@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 katjavetter@gmail.com An: "Christof Ressi" christof.ressi@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.ressi@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 katjavetter@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: pd-list pd-list@iem.at, "Miller Puckette" msp@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.ressi@gmx.at wrote:
Hmmm... I compiled [bob~] myself with MinGW and pd-lib-builder and I noticed two things:
- the CPU rise is gone
- 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.ressi@gmx.at > An: pd-list@iem.at, "Miller Puckette" msp@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