Re: [PD] [bob~] denormals issue?
On 2016-09-22 01:10, David Medine wrote: > x = (x signature.asc Description: OpenPGP digital signature ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [bob~] denormals issue?
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 = (xwhere 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 <christof.re...@gmx.at> 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 <katjavet...@gmail.com> An: "Christof Ressi" <christof.re...@gmx.at> Cc: "pd-list@lists.iem.at" <pd-list@lists.iem.at> 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 <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. Eve
Re: [PD] [bob~] denormals issue?
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 <christof.re...@gmx.at> 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 <katjavet...@gmail.com> >> An: "Christof Ressi" <christof.re...@gmx.at> >> Cc: "pd-list@lists.iem.at" <pd-list@lists.iem.at> >> 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 <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 >> >> &
Re: [PD] [bob~] denormals issue?
Yeah, I want to find out more about that :) M On Thu, Sep 22, 2016 at 12:01:31AM +0200, Christof Ressi 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 <katjavet...@gmail.com> > > An: "Christof Ressi" <christof.re...@gmx.at> > > Cc: "pd-list@lists.iem.at" <pd-list@lists.iem.at> > > 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 <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 w
Re: [PD] [bob~] denormals issue?
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 <katjavet...@gmail.com> > An: "Christof Ressi" <christof.re...@gmx.at> > Cc: "pd-list@lists.iem.at" <pd-list@lists.iem.at> > 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 <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 i
Re: [PD] [bob~] denormals issue?
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 > >> >> > Win
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 <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 filte
Re: [PD] [bob~] denormals issue?
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 > >> > > >> > ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [bob~] denormals issue?
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 > > > ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
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 > ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
[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#N canvas 565 278 755 300 10; #X obj 42 242 bob~; #X obj 119 216 sig~ 1; #X obj 54 215 sig~ 400; #X obj 42 97 osc~ 400; #X obj 43 152 *~; #X obj 129 118 line~; #X obj 129 60 dbtorms; #X msg 129 89 \$1 50; #X obj 129 32 nbx 5 14 0 100 0 0 empty empty empty 0 -8 0 10 -262144 -1 -1 0 256; #X obj 36 38 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1 ; #X msg 36 64 \; pd dsp \$1; #X obj 42 179 +~; #X obj 115 147 noise~; #X obj 115 169 *~ 0.001; #X obj 115 191 *~ 0; #X obj 155 191 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X msg 118 240 clear; #X msg 129 5 100; #X text 108 4 1); #X text 165 5 2); #X msg 193 7 0; #X text 230 7 3) watch CPU load rise; #X text 232 33 4) clear the filter or add some noise to kill the denormals , f 32; #X text 176 190 adding tiny noise; #X text 167 241 clear the filter; #X connect 1 0 0 2; #X connect 2 0 0 1; #X connect 3 0 4 0; #X connect 4 0 11 0; #X connect 5 0 4 1; #X connect 6 0 7 0; #X connect 7 0 5 0; #X connect 8 0 6 0; #X connect 9 0 10 0; #X connect 11 0 0 0; #X connect 12 0 13 0; #X connect 13 0 14 0; #X connect 14 0 11 1; #X connect 15 0 14 1; #X connect 16 0 0 0; #X connect 17 0 8 0; #X connect 20 0 8 0; ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
