Hello,
I've installed Pd-extended 0.43 versions (Linux and OSX) from the autobuilds several times in the past year. The latest builds seem to work fine in many aspects, but they are still so CPU-hungry: ~ 50% more than Pd-extended 0.42. How come?
A while ago, the new PortAudio version was blamed (http://www.mail-archive.com/pd-list@iem.at/msg50357.html). Indeed, using Jack solves the load difference for OSX.
But on Debian I also observe a 50% load increase for the new Pd-extended. No matter if ALSA or Jack is used. Does anyone have similar observations with Linux builds?
BTW, I'm happy with Tk 8.5's antialiased font! Initially, I feared that antialiasing was responsible for increased load on Debian, but disabling GUI updates did not make noticeable difference. It seems that antialiasing is done rather efficiently, the performance drop must be somewhere else.
Katja
I honestly don't know the cause, and haven't really checked on numbers. I mostly work on my four year old laptop, and test by running patches I know (solitude is a good test of heavy CPU usage, it won't run on a machine less than 1.6GHz, from my experience).
As for drawing operations like anti-aliasing, those would not show up in the 'pd' process, but rather the 'pd-gui' process, since that's the Tk part.
Are you seeing the CPU increase in the 'pd' process? How are you measuring this?
.hc
On May 4, 2012, at 9:31 AM, katja wrote:
Hello,
I've installed Pd-extended 0.43 versions (Linux and OSX) from the autobuilds several times in the past year. The latest builds seem to work fine in many aspects, but they are still so CPU-hungry: ~ 50% more than Pd-extended 0.42. How come?
A while ago, the new PortAudio version was blamed (http://www.mail-archive.com/pd-list@iem.at/msg50357.html). Indeed, using Jack solves the load difference for OSX.
But on Debian I also observe a 50% load increase for the new Pd-extended. No matter if ALSA or Jack is used. Does anyone have similar observations with Linux builds?
BTW, I'm happy with Tk 8.5's antialiased font! Initially, I feared that antialiasing was responsible for increased load on Debian, but disabling GUI updates did not make noticeable difference. It seems that antialiasing is done rather efficiently, the performance drop must be somewhere else.
Katja
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On OSX I use 'Activity Monitor' for quick check of CPU load and Shark.app for serious performance profiling, but for GNU/Linux I don't know a good equivalent of Shark. So on Debian I just start top, and for my live performance setup which does ~40% CPU load with Pd-extended 0.42, it is ~60% with 0.43. Top makes distinction between 'pdextended' and pd-gui, but heavy GUI use is reflected in increasing percentages for Xorg process as well. However, the load-increase with Pd-extended 0.43 is on account of the pdextended process (with my setups at least). Wish I could track that down to specific functions like with Shark.app.
In the case of OSX it was clearly the Apple dsp function calls consuming a great deal of CPU time, which could be avoided by using an external soundcard instead of the internal card, and Jack instead of PortAudio.
I've tried to use Oprofile on Debian, but this gives me a kernel failure soon as I start sampling. Does anyone know of a fine performance profiler for GNU/Linux?
Katja
On 5/4/12, Hans-Christoph Steiner hans@at.or.at wrote:
I honestly don't know the cause, and haven't really checked on numbers. I mostly work on my four year old laptop, and test by running patches I know (solitude is a good test of heavy CPU usage, it won't run on a machine less than 1.6GHz, from my experience).
As for drawing operations like anti-aliasing, those would not show up in the 'pd' process, but rather the 'pd-gui' process, since that's the Tk part.
Are you seeing the CPU increase in the 'pd' process? How are you measuring this?
.hc
On May 4, 2012, at 9:31 AM, katja wrote:
Hello,
I've installed Pd-extended 0.43 versions (Linux and OSX) from the autobuilds several times in the past year. The latest builds seem to work fine in many aspects, but they are still so CPU-hungry: ~ 50% more than Pd-extended 0.42. How come?
A while ago, the new PortAudio version was blamed (http://www.mail-archive.com/pd-list@iem.at/msg50357.html). Indeed, using Jack solves the load difference for OSX.
But on Debian I also observe a 50% load increase for the new Pd-extended. No matter if ALSA or Jack is used. Does anyone have similar observations with Linux builds?
BTW, I'm happy with Tk 8.5's antialiased font! Initially, I feared that antialiasing was responsible for increased load on Debian, but disabling GUI updates did not make noticeable difference. It seems that antialiasing is done rather efficiently, the performance drop must be somewhere else.
Katja
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
----- Original Message -----
From: katja katjavetter@gmail.com To: pd-list pd-list@iem.at Cc: Sent: Saturday, May 5, 2012 3:43 PM Subject: Re: [PD] what makes Pd-extended 0.43 so CPU-hungry?
On OSX I use 'Activity Monitor' for quick check of CPU load and Shark.app for serious performance profiling, but for GNU/Linux I don't know a good equivalent of Shark. So on Debian I just start top, and for my live performance setup which does ~40% CPU load with Pd-extended 0.42, it is ~60% with 0.43. Top makes distinction between 'pdextended' and pd-gui, but heavy GUI use is reflected in increasing percentages for Xorg process as well.
Have you compared with pd-l2ork in Debian? Without doing any direct measurements, I seem to remember the pd-0.43-ext nightly build looking sluggish on my laptop when moving around GUI objects, which I didn't see with pd-l2ork.
-Jonathan
However, the load-increase with Pd-extended 0.43 is on account of the pdextended process (with my setups at least). Wish I could track that down to specific functions like with Shark.app.
In the case of OSX it was clearly the Apple dsp function calls consuming a great deal of CPU time, which could be avoided by using an external soundcard instead of the internal card, and Jack instead of PortAudio.
I've tried to use Oprofile on Debian, but this gives me a kernel failure soon as I start sampling. Does anyone know of a fine performance profiler for GNU/Linux?
Katja
On 5/4/12, Hans-Christoph Steiner hans@at.or.at wrote:
I honestly don't know the cause, and haven't really checked on
numbers. I
mostly work on my four year old laptop, and test by running patches I know (solitude is a good test of heavy CPU usage, it won't run on a machine
less
than 1.6GHz, from my experience).
As for drawing operations like anti-aliasing, those would not show up in
the
'pd' process, but rather the 'pd-gui' process, since
that's the Tk part.
Are you seeing the CPU increase in the 'pd' process? How are you
measuring
this?
.hc
On May 4, 2012, at 9:31 AM, katja wrote:
Hello,
I've installed Pd-extended 0.43 versions (Linux and OSX) from the autobuilds several times in the past year. The latest builds seem to work fine in many aspects, but they are still so CPU-hungry: ~ 50% more than Pd-extended 0.42. How come?
A while ago, the new PortAudio version was blamed (http://www.mail-archive.com/pd-list@iem.at/msg50357.html). Indeed, using Jack solves the load difference for OSX.
But on Debian I also observe a 50% load increase for the new Pd-extended. No matter if ALSA or Jack is used. Does anyone have similar observations with Linux builds?
BTW, I'm happy with Tk 8.5's antialiased font! Initially, I
feared
that antialiasing was responsible for increased load on Debian, but disabling GUI updates did not make noticeable difference. It seems that antialiasing is done rather efficiently, the performance drop must be somewhere else.
Katja
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 05/05/2012 03:58 PM, Jonathan Wilkes wrote:
Have you compared with pd-l2ork in Debian? Without doing any direct measurements, I seem to remember the pd-0.43-ext nightly build looking sluggish on my laptop when moving around GUI objects, which I didn't see with pd-l2ork. -Jonathan
That is because pd-l2ork does moving of objects using tcl/tk tags which is *much* more efficient than trying to redraw them on every gui update, particularly GOP objects. On my netbook (Atom) things are as smooth as butter because of this, whereas they used to make larger patches literally unresponsive.
Cheers!
Could it be the VU meters embedded in the main window? Those are known to be fairly cpu intensive if updated too often.
Hmm, interesting idea. Katja, do you have the CPU meters on?
.hc
On May 5, 2012, at 4:57 PM, Ivica Ico Bukvic wrote:
Could it be the VU meters embedded in the main window? Those are known to be fairly cpu intensive if updated too often.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Katja,
On 5 May 2012, at 20:43, katja katjavetter@gmail.com wrote:
I've tried to use Oprofile on Debian, but this gives me a kernel failure soon as I start sampling. Does anyone know of a fine performance profiler for GNU/Linux?
Katja
You might want to try callgrind + kcachegrind...
http://www.slac.stanford.edu/BFROOT/www/Computing/Optimization/genprof.html
best,
Jamie
Finally I have some clue what's wrong with Pd-E 0.43 for GNU/Linux, or for Debian Squeeze at least. Sorry that it took me so long to sit down and sort it out.
The problem is still there, with version 0.43.4: my live performance setups run with almost double CPU load, when compared to 0.42. Now I also tested with some comprehensive patches which are known to be pure vanilla, like Martin Brinkmann's 'chaosmonster'. Remarkably, these patches do not show an increased CPU load. Therefore I guessed that it must be in external classes.
I tried using callgrind and kcachegrind (thanks for the hint Jamie). Though callgrind makes Pd choke completely (while recording the complete call history of a process instead of taking samples), the output gave a clue. Freeverb~ was shown to make a couple hundred function calls within the perform loop. Functions which are written as 'inline' in the C file. An isolated freeverb~ instance turned out to do 10% CPU load. Admittedly, this computer (1.8 GHz core duo 2006) is not the latest. But freeverb~ normally does some 1% per instance.
So, freeverb~ is the messenger; without it I might not have noticed any problem. But what is the message? Is Pd-E 0.43 compiled without optimization? I searched for more inline functions in external libs, and found one in bsaylor/svf~. In this case again, the executable implements it as a call. The core code however is almost certainly compiled with properly inlined functions. There's one frequently called inline function in the API (PD_BIGORSMALL, which used to be a macro in the past). If this would be compiled as a call, a patch like 'chaosmonster' would definitely show performance loss.
Note that I'm talking about debian binaries so far, more precisely Pd-E 0.43.4 for debian squeeze, as downloaded from puredata.info downloads page. In contrast, I checked freeverb~ in the distribution for OSX i386, and here the inlining was done properly.
Another difference between those distributions: SSE instructions are used for OSX, not for debian. Simple operations like addition and multiplication of floats are done on the FPU in debian, while xmm registers are used with OSX. This also means that things like abs() and ifnan() are function calls for debian, while they could be simple instructions on the xmm registers. (Instructions can be viewed by dissassembling executables with command objdump -d <file>.)
My conclusion from these observations: at least some Pd 0.43 externals for debian squeeze are compiled with -0O for some reason (don't know about other Linuxes). How come? The template makefile (also used for freeverb~) has optimization -O6. The root makefile for the packages have certain optimization flags as well. Are they somehow conflicting, producing an undefined result? Not for OSX, apparently. But for debian something goes wrong. The build system stuff is really over my head, hopefully someone else has better overview to find the exact cause.
Katja
On 5/6/12, Jamie Bullock jamie.b.bullock@gmail.com wrote:
Hi Katja,
On 5 May 2012, at 20:43, katja katjavetter@gmail.com wrote:
I've tried to use Oprofile on Debian, but this gives me a kernel failure soon as I start sampling. Does anyone know of a fine performance profiler for GNU/Linux?
Katja
You might want to try callgrind + kcachegrind...
http://www.slac.stanford.edu/BFROOT/www/Computing/Optimization/genprof.html
best,
Jamie
Thanks for this write-up and all that testing, its definitely very helpful. So in the end, you're talking about Pd-extended on debian only? It sounds like your tests show that 0.43 was not slower on Mac OS X.
It does look like the Debian-i386 builds don't have optimization turned on, you can look at the build log to see exactly how it was built:
http://autobuild.puredata.info/auto-build/2012-12-07/logs/2012-12-07_06.27.5...
cc -I"/home/pd/auto-build/pd-extended/pd/include/pd" -DPD -DVERSION='"1.2.1"' -fPIC -DPD -DHAVE_G_CANVAS_H -I/home/pd/auto-build/pd-extended/pd/src -Wall -W -ggdb -I/home/pd/auto-build/pd-extended/externals/Gem -I/home/pd/auto-build/pd-extended/externals/pdp/include -DUNIX -Dunix -DDL_OPEN -fPIC -g -fno-inline-functions -fno-omit-frame-pointer -DDEBUG_SOUNDFILE -Wstrict-aliasing=2 -o "freeverb~.o" -c "freeverb~.c"
If you want to mess with the flags, try adding things to OPT_CFLAGS in packages/linux_make/Makefile, that should affect the almost all of the build. If you just want to test freeverb, you can do this:
cd externals/freeverb make OPT_CFLAGS="-O6 -msse -msse2 -mfpmath=sse -ftree-vectorize -ftree-vectorizer-verbose=1"
Or things like that... I'd be very interested to hear about profiling results of using these flags. I only did a little profiling when I stuck those in.
.hc
On Dec 7, 2012, at 4:36 PM, katja wrote:
Finally I have some clue what's wrong with Pd-E 0.43 for GNU/Linux, or for Debian Squeeze at least. Sorry that it took me so long to sit down and sort it out.
The problem is still there, with version 0.43.4: my live performance setups run with almost double CPU load, when compared to 0.42. Now I also tested with some comprehensive patches which are known to be pure vanilla, like Martin Brinkmann's 'chaosmonster'. Remarkably, these patches do not show an increased CPU load. Therefore I guessed that it must be in external classes.
I tried using callgrind and kcachegrind (thanks for the hint Jamie). Though callgrind makes Pd choke completely (while recording the complete call history of a process instead of taking samples), the output gave a clue. Freeverb~ was shown to make a couple hundred function calls within the perform loop. Functions which are written as 'inline' in the C file. An isolated freeverb~ instance turned out to do 10% CPU load. Admittedly, this computer (1.8 GHz core duo 2006) is not the latest. But freeverb~ normally does some 1% per instance.
So, freeverb~ is the messenger; without it I might not have noticed any problem. But what is the message? Is Pd-E 0.43 compiled without optimization? I searched for more inline functions in external libs, and found one in bsaylor/svf~. In this case again, the executable implements it as a call. The core code however is almost certainly compiled with properly inlined functions. There's one frequently called inline function in the API (PD_BIGORSMALL, which used to be a macro in the past). If this would be compiled as a call, a patch like 'chaosmonster' would definitely show performance loss.
Note that I'm talking about debian binaries so far, more precisely Pd-E 0.43.4 for debian squeeze, as downloaded from puredata.info downloads page. In contrast, I checked freeverb~ in the distribution for OSX i386, and here the inlining was done properly.
Another difference between those distributions: SSE instructions are used for OSX, not for debian. Simple operations like addition and multiplication of floats are done on the FPU in debian, while xmm registers are used with OSX. This also means that things like abs() and ifnan() are function calls for debian, while they could be simple instructions on the xmm registers. (Instructions can be viewed by dissassembling executables with command objdump -d <file>.)
My conclusion from these observations: at least some Pd 0.43 externals for debian squeeze are compiled with -0O for some reason (don't know about other Linuxes). How come? The template makefile (also used for freeverb~) has optimization -O6. The root makefile for the packages have certain optimization flags as well. Are they somehow conflicting, producing an undefined result? Not for OSX, apparently. But for debian something goes wrong. The build system stuff is really over my head, hopefully someone else has better overview to find the exact cause.
Katja
On 5/6/12, Jamie Bullock jamie.b.bullock@gmail.com wrote:
Hi Katja,
On 5 May 2012, at 20:43, katja katjavetter@gmail.com wrote:
I've tried to use Oprofile on Debian, but this gives me a kernel failure soon as I start sampling. Does anyone know of a fine performance profiler for GNU/Linux?
Katja
You might want to try callgrind + kcachegrind...
http://www.slac.stanford.edu/BFROOT/www/Computing/Optimization/genprof.html
best,
Jamie
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Fri, Dec 7, 2012 at 11:46 PM, Hans-Christoph Steiner hans@at.or.at wrote:
Thanks for this write-up and all that testing, its definitely very helpful. So in the end, you're talking about Pd-extended on debian only? It sounds like your tests show that 0.43 was not slower on Mac OS X.
It does look like the Debian-i386 builds don't have optimization turned on, you can look at the build log to see exactly how it was built
Hans I checked build logs for various Linux builds and for OSX. As it turns out, Pd core is optimized as well as some external libs (ie GEM), but other externals (like freeverb~) are optimized for OSX and not for Debian.
I suspect the problem is in Makefiles according to the template. They have lines like "OPT_FLAGS = -O6 -funroll-loops -fomit-frame-pointer". But Makefiles for packages have OPT_FLAGS as well, therefore in the library template it should be OPT_FLAGS +=, no? The darwin_app package makefile defines a lot of OPT_FLAGS, including -fast. The linux package makefile defines several OPT_FLAGS according to target platform, but no optimization level. Apparently, OPT_FLAGS in the package Makefile are implemented, and not the ones in the template.
I don't have a Pd autobuild or SVN setup on my Linux box now, can't test a modification rightaway. Anyhow, I guess the problem is now identified. I am sorry about my blunt subject title 'what makes Pd 0.43 so CPU hungry?'. It wasn't even about Pd, but Pd-extended.
Katja
On Dec 10, 2012, at 9:40 AM, katja wrote:
On Fri, Dec 7, 2012 at 11:46 PM, Hans-Christoph Steiner hans@at.or.at wrote:
Thanks for this write-up and all that testing, its definitely very helpful. So in the end, you're talking about Pd-extended on debian only? It sounds like your tests show that 0.43 was not slower on Mac OS X.
It does look like the Debian-i386 builds don't have optimization turned on, you can look at the build log to see exactly how it was built
Hans I checked build logs for various Linux builds and for OSX. As it turns out, Pd core is optimized as well as some external libs (ie GEM), but other externals (like freeverb~) are optimized for OSX and not for Debian.
I suspect the problem is in Makefiles according to the template. They have lines like "OPT_FLAGS = -O6 -funroll-loops -fomit-frame-pointer". But Makefiles for packages have OPT_FLAGS as well, therefore in the library template it should be OPT_FLAGS +=, no? The darwin_app package makefile defines a lot of OPT_FLAGS, including -fast. The linux package makefile defines several OPT_FLAGS according to target platform, but no optimization level. Apparently, OPT_FLAGS in the package Makefile are implemented, and not the ones in the template.
I don't have a Pd autobuild or SVN setup on my Linux box now, can't test a modification rightaway. Anyhow, I guess the problem is now identified. I am sorry about my blunt subject title 'what makes Pd 0.43 so CPU hungry?'. It wasn't even about Pd, but Pd-extended.
I added optimization flags to the GNU/Linux and Windows builds:
http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revision&revi... http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revision&revi... http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revision&revi...
I just remembered one issue: one thing that makes it tricky to set optimization flags for all of Pd-extended is the last few remaining type punning issues: http://autobuild.puredata.info/auto-build/2012-12-11/logs/type-punning-2012-...
I fixed a few recently. Want to try fixing bsaylor/svf~ or oscx? As for 'extra', I think I'll include your pd-double fixes in the pd-extended 0.43 branch.
.hc
On Tue, Dec 11, 2012 at 8:58 PM, Hans-Christoph Steiner hans@at.or.at wrote:
I added optimization flags to the GNU/Linux and Windows builds:
http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revision&revi... http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revision&revi... http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revision&revi...
Installed the latest build for Debian Squeeze today. Very happy to see that optimization is working again for all libs. CPU loads are back to normal. Probably freeverb~ was the main victim of non-optimization, with a couple hundred function calls in the perform loop, functions which are supposed to be inlined. The object was almost ten times more expensive with all those function calls. And it was just coincidence that my live setups have four instances of freeverb~ each. Otherwise I might not have noticed the issue at all.
I just remembered one issue: one thing that makes it tricky to set optimization flags for all of Pd-extended is the last few remaining type punning issues: http://autobuild.puredata.info/auto-build/2012-12-11/logs/type-punning-2012-...
I fixed a few recently. Want to try fixing bsaylor/svf~ or oscx? As for 'extra', I think I'll include your pd-double fixes in the pd-extended 0.43 branch.
Yeah it's better to get rid of all the overt type punning so the -fno-strict-aliasing need not be set. In bsaylor/svf~ is a type punning method to avoid denormals, this could probably be replaced by the PD_BIGORSMALL(). I'll check that.
Katja
-
Hans-Christoph Steiner -
Ivica Ico Bukvic -
Jamie Bullock -
Jonathan Wilkes -
katja