hi
how can I reduce CPU usage generally?
I made a patch that uses almost 90% CPU and everything gets really slow. (graphically) It uses 82% CPU also if its "stands still" and does nothing. I m working on a Apple G4 1 Ghz, 1GB RAM etc.
I would be glad if somebody would help me with my patch so it gets "faster".
download it at . www.gezetera.ch/noise/supercpu.pd
thank you in advance.
miyazaki s
On Sunday, June 22, 2003, at 07:19 AM, Shintaro Miyazaki wrote:
hi
how can I reduce CPU usage generally?
I made a patch that uses almost 90% CPU and everything gets really slow. (graphically) It uses 82% CPU also if its "stands still" and does nothing. I m working on a Apple G4 1 Ghz, 1GB RAM etc.
I would be glad if somebody would help me with my patch so it gets "faster".
download it at . www.gezetera.ch/noise/supercpu.pd
thank you in advance.
hello miyazaki,
...very nice looking patch, but that is the problem (unfortunately)...all that use of color is pretty, but horribly un-optimized, at least on the mac tcl/tk side...this is an incredible limitation to the usage of pd in any but an "experimental" manner...I have been working on moving tcl/tk's graphics to native coregraphics calls, but it is a big project, and I'm not convinced that it wouldn't be better to rewrite the pd gui in something else...but it's also apparent that the problem is not just the OSX tcl/tk, because I also get about 56% pd cpu usage with the patch sitting idle, and tcl/tk is barely 5-10%...it's disappointing that pd spends so much time with inefficient drawing calls...
...I would be interested in finding out how this performs on a linux box...
...lastly, It would be very helpful if, when posting patches like this, you mention what libraries you are loading: I have zexy, but don't know where most of the other stuff comes from!
l8r, jamie
On that subject, I'm thinking about (someday) rewriting Pd's whole graphics layer, probably in "wx", to make it faster. I'm hoping not to have to do that until I understand how the whole GUI should work better than I do now.
cheers Miller
On Sun, Jun 22, 2003 at 03:55:13PM -0400, tigital wrote:
On Sunday, June 22, 2003, at 07:19 AM, Shintaro Miyazaki wrote:
hi
how can I reduce CPU usage generally?
I made a patch that uses almost 90% CPU and everything gets really slow. (graphically) It uses 82% CPU also if its "stands still" and does nothing. I m working on a Apple G4 1 Ghz, 1GB RAM etc.
I would be glad if somebody would help me with my patch so it gets "faster".
download it at . www.gezetera.ch/noise/supercpu.pd
thank you in advance.
hello miyazaki,
...very nice looking patch, but that is the problem (unfortunately)...all that use of color is pretty, but horribly un-optimized, at least on the mac tcl/tk side...this is an incredible limitation to the usage of pd in any but an "experimental" manner...I have been working on moving tcl/tk's graphics to native coregraphics calls, but it is a big project, and I'm not convinced that it wouldn't be better to rewrite the pd gui in something else...but it's also apparent that the problem is not just the OSX tcl/tk, because I also get about 56% pd cpu usage with the patch sitting idle, and tcl/tk is barely 5-10%...it's disappointing that pd spends so much time with inefficient drawing calls...
...I would be interested in finding out how this performs on a linux box...
...lastly, It would be very helpful if, when posting patches like this, you mention what libraries you are loading: I have zexy, but don't know where most of the other stuff comes from!
l8r, jamie
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
it looks like in this thread from the profiling data jamie posted that tcl/tk is not the culprit in this case, thouse i wouldnt be surprised if it were in many other instances. i'm wondering though, how extensively have you profiled your code to find out if it really an archetectural flaw in tcl/tk? are there other large tcl/tk applications we know of that we could test and/or look into the code of to see if they are able to squeeze better performance out of?
there are some really great advantages to the PD gui being done in a scripting language (take look at Krzysztof widget/tot/toy if you havnt already).
WX would have some advantages, probably in speed, availablity of some more advanced widgets and blending into the native environment (espeically on linux) that would make a shift to it really slick, and maybe even some of the same functionality of widget/tot/toy could be accomplished using the wxpython bindings.
definitely worth some close investigation at any rate.
-josh
Miller Puckette wrote:
On that subject, I'm thinking about (someday) rewriting Pd's whole graphics layer, probably in "wx", to make it faster. I'm hoping not to have to do that until I understand how the whole GUI should work better than I do now.
cheers Miller
At 2:18 PM -0700 6/22/03, Josh Steiner wrote:
http://www.gnu.org/manual/gprof-2.9.1/html_mono/gprof.html
or
those pretty look useful but they are different from shikari in that they are both profilers for specific apps that require traces to be produced for the profiler to breakdown. shikari is a system wide profiler that records every function running on the machine, which allows you to see problems that exist outside of your app. it's a really amazing thing to use when writing code, and i've become somewhat dependent on it. oh and there's another little OSX tool called OpenGL Profiler that i'm fond of as well. ;)
it looks like in this thread from the profiling data jamie posted that tcl/tk is not the culprit in this case, thouse i wouldnt be surprised if it were in many other instances. i'm wondering though, how extensively have you profiled your code to find out if it really an archetectural flaw in tcl/tk? are there other large tcl/tk applications we know of that we could test and/or look into the code of to see if they are able to squeeze better performance out of?
there is a huge flaw in the way the pd and/or tcl/tk does screen updates on OSX. i posted an example of this a while back which illustrated this by putting two number boxes in the opposite corners of a large pd patcher. the number boxes displayed the output of a random object fed by a metro, and turning one on didn't use much CPU but turning the second on created a huge spike. when i used the OSX app QuartzDebug to show the are of the screen updated by the patch, it revealed that the entire area in between the two boxes was updated not just the two number boxes. this is of course hugely inefficient and completely wasteful, but i have yet to figure out if it's something done by pd or by tcl/tk in general.
At 3:19 PM -0700 6/22/03, Josh Steiner wrote:
you want the [switch~] object, it disables audio processing in subpatches
oh yeah that's the ticket. i can't believe i forgot about that.
Hi,
Zitat von Josh Steiner josh@vitriolix.com:
there are some really great advantages to the PD gui being done in a scripting language (take look at Krzysztof widget/tot/toy if you havnt already).
I don't understand tcl ... ^_^ The jMax crew is going an alternative approach. Because of license issues with Java/Swing, there is work going on to port the GUI side to Python with a yet undecided toolkit, probably wxPy I guess. This could in the end open up GUI scriptability while still having a fast (enough) GUI. I don't think, that Tk is much too slow for Pd, but there are issues with the GUI disturbing the DSP chain, and that is really bad. I don't understand the exact reason for this (I would like to) but if I understand what was said about this here correctly it has to do with the protocol that Pd uses to communicate between the audio engine and the GUI.
With a proper design, in the end it should be possible to embed any decent scripting language to also control GUI elements.
Miller Puckette wrote:
On that subject, I'm thinking about (someday) rewriting Pd's whole graphics layer, probably in "wx", to make it faster. I'm hoping not to have to do that until I understand how the whole GUI should work better than I do now.
This is great to hear. As it is currently, Pd is very useable IMO. But with the introduction of advanced GUI options (graph-on-parent, data structures) people will build more GUI heavy patches, and that must not disturb the audio chain.
ciao
Frank Barknecht _ ___footils.org_
This is a really top idea. Wx is nice to dev with, and OS native widgets would just be so much nicer on the eyes than Tk (of course, this is subjective), not to mention the speed. Just voicing support for this idea.
Chris.
On Sun, 22 Jun 2003 13:19:40 -0700 Miller Puckette mpuckett@man104-1.ucsd.edu wrote:
On that subject, I'm thinking about (someday) rewriting Pd's whole graphics layer, probably in "wx", to make it faster. I'm hoping not to have to do that until I understand how the whole GUI should work better than I do now.
cheers Miller
On Sun, Jun 22, 2003 at 03:55:13PM -0400, tigital wrote:
On Sunday, June 22, 2003, at 07:19 AM, Shintaro Miyazaki wrote:
hi
how can I reduce CPU usage generally?
I made a patch that uses almost 90% CPU and everything gets really slow. (graphically) It uses 82% CPU also if its "stands still" and does nothing. I m working on a Apple G4 1 Ghz, 1GB RAM etc.
I would be glad if somebody would help me with my patch so it gets "faster".
download it at . www.gezetera.ch/noise/supercpu.pd
thank you in advance.
hello miyazaki,
...very nice looking patch, but that is the problem (unfortunately)...all that use of color is pretty, but horribly un-optimized, at least on the mac tcl/tk side...this is an incredible limitation to the usage of pd in any but an "experimental" manner...I have been working on moving tcl/tk's graphics to native coregraphics calls, but it is a big project, and I'm not convinced that it wouldn't be better to rewrite the pd gui in something else...but it's also apparent that the problem is not just the OSX tcl/tk, because I also get about 56% pd cpu usage with the patch sitting idle, and tcl/tk is barely 5-10%...it's disappointing that pd spends so much time with inefficient drawing calls...
...I would be interested in finding out how this performs on a linux box...
...lastly, It would be very helpful if, when posting patches like this, you mention what libraries you are loading: I have zexy, but don't know where most of the other stuff comes from!
l8r, jamie
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
chris@mccormick.cx http://www.mccormick.cx http://www.hypercube.com.au http://www.sciencegirlrecords.com
i just noticed there Gnocl which is a tk-like binding for Tcl/Gtk+ ... basically it lets your Tcl apps use Gtk+ widgets, and supposedly the API is pretty similar to Tk. This might be an path to look into for speeding up the gui, it might be a LOT less work to port to this than rewrite everything in wx.
Wx has the advantage of giving pd real native widgets on all supported platforms, but gtk+ is portable and is able to emulate natice look pretty well:
http://gtk-wimp.sourceforge.net/screenshots/
i'll add this to my endless list of "things i'd love to look into in depth" :)
-josh
Miller Puckette wrote:
On that subject, I'm thinking about (someday) rewriting Pd's whole graphics layer, probably in "wx", to make it faster. I'm hoping not to have to do that until I understand how the whole GUI should work better than I do now.
cheers Miller
On Sunday, June 22, 2003, at 03:55 PM, tigital wrote:
On Sunday, June 22, 2003, at 07:19 AM, Shintaro Miyazaki wrote:
download it at . www.gezetera.ch/noise/supercpu.pd
thank you in advance.
hello miyazaki,
...very nice looking patch, but that is the problem (unfortunately)...all that use of color is pretty, but horribly un-optimized, at least on the mac tcl/tk side...this is an incredible limitation to the usage of pd in any but an "experimental" manner...I have been working on moving tcl/tk's graphics to native coregraphics calls, but it is a big project, and I'm not convinced that it wouldn't be better to rewrite the pd gui in something else...but it's also apparent that the problem is not just the OSX tcl/tk, because I also get about 56% pd cpu usage with the patch sitting idle, and tcl/tk is barely 5-10%...it's disappointing that pd spends so much time with inefficient drawing calls...
...just as a bit of followup, I looked at the idle patch open via shikari, and here's how the function usage is breaking down for pd & zexy:
17.8% sighip_perform pd
11.7% tabread4_tilde_perform pd
9.7% siglop_perform pd
6.8% plus_perf8 pd
5.3% scalartimes_perf8 pd
3.5% times_perf8 pd
2.3% osc_perform pd
2.2% line_perform pd
1.8% sigvd_perform pd
1.3% cos_perform pd
1.3% tabosc4_tilde_perform pd
1.0% sig_perf8 pd
0.9% phasor_perform pd
0.7% dsp_tick pd
0.5% sigwrap_perform pd
0.4% pa_send_dacs pd
0.3% noise_perform pd
0.2% plus_perform pd
0.2% sigbp_perform pd
0.2% copy_perf8 pd
0.1% sys_getrealtime pd
0.1% tabwrite_tilde_perform pd
0.1% m_scheduler pd
0.1% sys_addhist pd
0.1% scalarplus_perf8 pd
0.1% readsf_perform pd
0.1% sigdelwrite_perform pd
0.1% RingBuffer_GetReadRegions pd
0.0% PaOSX_HandleInputOutput pd
0.0% ReadAudioStream pd
0.0% restFP pd
0.0% sys_pollmidiinqueue pd
0.0% scalarminus_perf8 pd
0.0% sig_perform pd
0.0% sys_domicrosleep pd
0.0% sys_poll_midi pd
0.0% sys_pollmidioutqueue pd
0.0% RingBuffer_Write pd
0.0% Pa_EndUsageCalculation pd
0.0% Pa_StartUsageCalculation pd
0.0% RingBuffer_GetWriteRegions pd
12.5% z_index_setup zexy.pd_darwin
3.9% z_sigbin_setup zexy.pd_darwin
1.3% z_noise_setup zexy.pd_darwin
1.0% z_pdf_setup zexy.pd_darwin
0.1% zexy_setup zexy.pd_darwin
...so, we'd need to findout what all the zexy setup functions are for, not to mention those pd *_perform functions...
...wish shell, on the other hand, isn't really doing anything once the patch is open, but that would change if any gui stuff changes...
l8r, jamie
Hi all,
d at the idle patch open via shikari, and here's how the function usage is breaking down for pd & zexy:
oh, thanks for the pointer to shikari
which that raises one more question for me.... is there a free code profiler for linux?
best greetings, Thomas
http://www.gnu.org/manual/gprof-2.9.1/html_mono/gprof.html
or
http://kcachegrind.sourceforge.net/
Thomas Grill wrote:
Hi all,
d at the idle patch open via shikari, and here's how the function usage is breaking down for pd & zexy:
oh, thanks for the pointer to shikari
which that raises one more question for me.... is there a free code profiler for linux?
best greetings, Thomas
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
On Sun, 22 Jun 2003, tigital wrote:
On Sunday, June 22, 2003, at 03:55 PM, tigital wrote:
On Sunday, June 22, 2003, at 07:19 AM, Shintaro Miyazaki wrote:
download it at . www.gezetera.ch/noise/supercpu.pd
thank you in advance.
hello miyazaki,
...very nice looking patch, but that is the problem (unfortunately)...all that use of color is pretty, but horribly un-optimized, at least on the mac tcl/tk side...this is an incredible limitation to the usage of pd in any but an "experimental" manner...I have been working on moving tcl/tk's graphics to native coregraphics calls, but it is a big project, and I'm not convinced that it wouldn't be better to rewrite the pd gui in something else...but it's also apparent that the problem is not just the OSX tcl/tk, because I also get about 56% pd cpu usage with the patch sitting idle, and tcl/tk is barely 5-10%...it's disappointing that pd spends so much time with inefficient drawing calls...
...just as a bit of followup, I looked at the idle patch open via shikari, and here's how the function usage is breaking down for pd & zexy:
17.8% sighip_perform pd 11.7% tabread4_tilde_perform pd 9.7% siglop_perform pd 6.8% plus_perf8 pd 5.3% scalartimes_perf8 pd 3.5% times_perf8 pd 2.3% osc_perform pd 2.2% line_perform pd 1.8% sigvd_perform pd 1.3% cos_perform pd 1.3% tabosc4_tilde_perform pd 1.0% sig_perf8 pd 0.9% phasor_perform pd 0.7% dsp_tick pd 0.5% sigwrap_perform pd 0.4% pa_send_dacs pd 0.3% noise_perform pd 0.2% plus_perform pd 0.2% sigbp_perform pd 0.2% copy_perf8 pd 0.1% sys_getrealtime pd 0.1% tabwrite_tilde_perform pd 0.1% m_scheduler pd 0.1% sys_addhist pd 0.1% scalarplus_perf8 pd 0.1% readsf_perform pd 0.1% sigdelwrite_perform pd 0.1% RingBuffer_GetReadRegions pd 0.0% PaOSX_HandleInputOutput pd 0.0% ReadAudioStream pd 0.0% restFP pd 0.0% sys_pollmidiinqueue pd 0.0% scalarminus_perf8 pd 0.0% sig_perform pd 0.0% sys_domicrosleep pd 0.0% sys_poll_midi pd 0.0% sys_pollmidioutqueue pd 0.0% RingBuffer_Write pd 0.0% Pa_EndUsageCalculation pd 0.0% Pa_StartUsageCalculation pd 0.0% RingBuffer_GetWriteRegions pd 12.5% z_index_setup zexy.pd_darwin 3.9% z_sigbin_setup zexy.pd_darwin 1.3% z_noise_setup zexy.pd_darwin 1.0% z_pdf_setup zexy.pd_darwin 0.1% zexy_setup zexy.pd_darwin
...so, we'd need to findout what all the zexy setup functions are for, not to mention those pd *_perform functions...
Seems that there is something wrong with the profiling, because all of these setup functions are only called once, and therefore should not contribute anything.
OTOH it is normal that the perform functions use the bigger part of the CPU, because this is where the work is done.
Depending on how many of these hip~, lop~ and tabread4~ objects are in the patch (I can't access it to check myself), there might be a problem with the optimization of this code on PowerPC's.
Well, some one would have to check these and take a look why the Mac compiler has problems there.
Guenter
...wish shell, on the other hand, isn't really doing anything once the patch is open, but that would change if any gui stuff changes...
l8r, jamie
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
hi
how can I reduce CPU usage generally?
I made a patch that uses almost 90% CPU and everything gets really slow. (graphically) It uses 82% CPU also if its "stands still" and does nothing. I m working on a Apple G4 1 Ghz, 1GB RAM etc.
the basic problem with your patch is that everything is on all the time. even when you aren't using freeverb~ it's still processing audio, same for everything else in the patch. that's why loading one or two sound files doesn't change the CPU load at all. i don't actually know if pd has the equivalent of MSP mute~ object which turns processing on and off selectively (there's no mute~ in pd 0.36). that would make a world of difference in a large patch like this.
freeverb~ is definitely the most CPU consuming part of your patch so consider using less of them. perhaps use a send~ or throw~ with a *~ to send each signal chain off to one freeverb~ like a send on a mixer rather than use a separate one for each chain. maybe a mixer patch would be a better way to control this patch in general. you might also want to come with a way to break the patch into smaller patcher and only load parts as you need them. this would cut down on cpu load when you are only using one or two sound files.
I would be glad if somebody would help me with my patch so it gets "faster".
another big problem for you is that pd and none of it's externals are written for PowerPC. a lot of the dsp functions have just about the worst PPC code scheduling possible - the dis-assembly shows a horrifying number of stalls. but to be fair most if not all of the external writers even have access to PPC boxes (although i can't imagine that some of the code runs well on any platform). just looking at the 10 most CPU intensive functions in your patch i think the CPU load could easily be cut in half by re-writing the code to be more efficient.
download it at . www.gezetera.ch/noise/supercpu.pd
it's a very cool patch, and i have to say it's one of the better looking ones i've seen. it only took me a few minutes to figure out what was going on, which is great for something that complex.
one suggestion i have is that if you really want to do very complex large scale patches on PPC/OSX your best bet is probably SuperCollider as it's extensively optimized and would be able to run a patch like this easily. of course it requires knowing SC and the way you would implement a patch like this would be entirely different.
thank you in advance.
miyazaki s
chris clepper wrote:
the basic problem with your patch is that everything is on all the time. even when you aren't using freeverb~ it's still processing audio, same for everything else in the patch. that's why loading one or two sound files doesn't change the CPU load at all. i don't actually know if pd has the equivalent of MSP mute~ object which turns processing on and off selectively (there's no mute~ in pd 0.36). that would make a world of difference in a large patch like this.
you want the [switch~] object, it disables audio processing in subpatches
-
chris clepper -
Chris McCormick -
Frank Barknecht -
guenter geiger -
Josh Steiner -
Miller Puckette -
Shintaro Miyazaki -
Thomas Grill -
tigital