Hello, one question, if i have a big patch with a lot of subpatches, is it possible to know which parts of the whole patch are consuming more cpu resources?
Is something like this possible?
thanks
R.
take them out and see the changes. or copy them into a new patch and close
the rest.
Hello, one question, if i have a big patch with a lot of subpatches, is it possible to know which parts of the whole patch are consuming more cpu resources?
Is something like this possible?
thanks
R.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
i Guess the question could go a bit further, how can we devise a profiling system for a dataflow programming environment?
On Sun, Jan 9, 2011 at 9:13 PM, João Pais jmmmpais@googlemail.com wrote:
take them out and see the changes. or copy them into a new patch and close the rest.
Hello, one question, if i have a big patch with a lot of subpatches,
is it possible to know which parts of the whole patch are consuming more cpu resources?
Is something like this possible?
thanks
R.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- Friedenstr. 58 10249 Berlin (Deutschland) Tel +49 30 42020091 | Mob +49 162 6843570 Studio +49 30 69509190 jmmmpais@googlemail.com | skype: jmmmpjmmmp
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Sun, 9 Jan 2011, Pedro Lopes wrote:
i Guess the question could go a bit further, how can we devise a profiling system for a dataflow programming environment?
I made two or three of those... GridFlow had several incarnations of such a thing but it only worked for GridFlow's own objects.
Then I made one for the whole of Pd, and it's somewhere in the DesireData branch, but it caused occasional crashes for mysterious reasons, and no-one else looked at the code.
Here's a screenshot of the latter :
http://artengine.ca/desiredata/gallery/simple-benchmark.png
You see that [cos] is over twice slower than [*] but [t f f] minus those two is also a lot, but that's the cost of message-passing, because [t f f] doesn't do any processing. And so on... the top number is the total time for the first message to "return" (every message-passing down a wire is accompanied later by an opposite movement once the job is done... that's "the stack").
GridFlow's profiler instead had a menu in Pd's main window which had a "reset" and a "dump" and the latter would print non-cumulative measurements (i.e. it doesn't include time in objects sent to) in the console (or in the terminal back when there wasn't a console) sorted by decreasing importance.
Ideally we would have both cumulative and non-cumulative figures, because neither is nearly as useful as both together.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
wow, I always felt message passing was unnecessarily expensive but I didnt realise message passing was that expensive! I seriously think it would be good to have a pd front end for gcc, a few of us should take the time to learn GIMPLE and implement a "compile" menu item to compile patches/subpatches.
2011/1/10 Mathieu Bouchard matju@artengine.ca:
On Sun, 9 Jan 2011, Pedro Lopes wrote:
i Guess the question could go a bit further, how can we devise a profiling system for a dataflow programming environment?
I made two or three of those... GridFlow had several incarnations of such a thing but it only worked for GridFlow's own objects.
Then I made one for the whole of Pd, and it's somewhere in the DesireData branch, but it caused occasional crashes for mysterious reasons, and no-one else looked at the code.
Here's a screenshot of the latter :
http://artengine.ca/desiredata/gallery/simple-benchmark.png
You see that [cos] is over twice slower than [*] but [t f f] minus those two is also a lot, but that's the cost of message-passing, because [t f f] doesn't do any processing. And so on... the top number is the total time for the first message to "return" (every message-passing down a wire is accompanied later by an opposite movement once the job is done... that's "the stack").
GridFlow's profiler instead had a menu in Pd's main window which had a "reset" and a "dump" and the latter would print non-cumulative measurements (i.e. it doesn't include time in objects sent to) in the console (or in the terminal back when there wasn't a console) sorted by decreasing importance.
Ideally we would have both cumulative and non-cumulative figures, because neither is nearly as useful as both together.
_______________________________________________________________________ | Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Mon, 10 Jan 2011, Ludwig Maes wrote:
I always felt message passing was unnecessarily expensive but I didnt realise message passing was that expensive! I seriously think it would be good to have a pd front end for gcc, a few of us should take the time to learn GIMPLE and implement a "compile" menu item to compile patches/subpatches.
There are a lot of possible ways to compile patches without having to deal with machine code generation and use. I'm sure you can triple the speed of a lot of patches in this manner, and I wouldn't be surprised to get tenfold improvements in some cases.
OTOH, another way to deal with a slow interpreter, is to pass fewer, bigger messages, to objects that do more work at once. This is much of the original idea for creating GridFlow.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
2011/1/11 Mathieu Bouchard matju@artengine.ca
On Mon, 10 Jan 2011, Ludwig Maes wrote:
I always felt message passing was unnecessarily expensive but I didnt
realise message passing was that expensive! I seriously think it would be good to have a pd front end for gcc, a few of us should take the time to learn GIMPLE and implement a "compile" menu item to compile patches/subpatches.
There are a lot of possible ways to compile patches without having to deal with machine code generation and use. I'm sure you can triple the speed of a lot of patches in this manner, and I wouldn't be surprised to get tenfold improvements in some cases.
That sounds too cool! Is there a way which includes graphical objects as well?
Andras
OTOH, another way to deal with a slow interpreter, is to pass fewer, bigger messages, to objects that do more work at once. This is much of the original idea for creating GridFlow.
On Tue, 11 Jan 2011, András Murányi wrote:
2011/1/11 Mathieu Bouchard matju@artengine.ca
There are a lot of possible ways to compile patches without having to deal with machine code generation and use. I'm sure you can triple the speed of a lot of patches in this manner, and I wouldn't be surprised to get tenfold improvements in some cases.
That sounds too cool! Is there a way which includes graphical objects as well?
I'm only thinking about accelerating the message-passing (outlet_anything, typedmess, zgetfn, etc), that's all. Any graphical accelerations (sys_vgui) are a separate matter, and I think that a patch-compiler is quite irrelevant in that matter. The non-graphical part of the object would still be optimised to the same level though.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
Hi,
On Tue, Jan 11, 2011 at 01:25:33PM -0500, Mathieu Bouchard wrote:
OTOH, another way to deal with a slow interpreter, is to pass fewer,
bigger messages, to objects that do more work at once. This is much of the original idea for creating GridFlow.
It's also the idea behind the "BSP"-approach I described in my LAC2010 paper: http://markmail.org/message/xnerkchl24j6p42k where calculations you'd typically do in message space are made with signal objects.
Frank Barknecht Do You RjDj.me? _ ______footils.org__
On Wed, 12 Jan 2011, Frank Barknecht wrote:
On Tue, Jan 11, 2011 at 01:25:33PM -0500, Mathieu Bouchard wrote:
OTOH, another way to deal with a slow interpreter, is to pass fewer, bigger messages, to objects that do more work at once. This is much of the original idea for creating GridFlow.
It's also the idea behind the "BSP"-approach I described in my LAC2010 paper:
It would be appropriate to pick a more descriptive name than Blocked Signal Processing, because that sounds quite a lot more like what Pd already does in its dsp all of the time, and it doesn't say what you make it do that is any different from what it already does.
http://markmail.org/message/xnerkchl24j6p42k where calculations you'd typically do in message space are made with signal objects.
So, doesn't this mean that they have to be done at a rate that is a power of two times the audio sampling rate ?
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Wed, Jan 12, 2011 at 01:57:33PM -0500, Mathieu Bouchard wrote:
On Wed, 12 Jan 2011, Frank Barknecht wrote:
On Tue, Jan 11, 2011 at 01:25:33PM -0500, Mathieu Bouchard wrote:
OTOH, another way to deal with a slow interpreter, is to pass fewer, bigger messages, to objects that do more work at once. This is much of the original idea for creating GridFlow.
It's also the idea behind the "BSP"-approach I described in my LAC2010 paper:
It would be appropriate to pick a more descriptive name than Blocked
Signal Processing, because that sounds quite a lot more like what Pd
already does in its dsp all of the time, and it doesn't say what you make it do that is any different from what it already does.
I was at first thinking of Interrupted Block Mathemathics, but the acronym looked funny.
http://markmail.org/message/xnerkchl24j6p42k where calculations you'd
typically do in message space are made with signal objects.So, doesn't this mean that they have to be done at a rate that is a power of two times the audio sampling rate ?
The main idea is to use suspended (i.e. [switch~]ed-off) subpatches, so you can run a slower rates than usual dsp rates. But yes, it's quantized.
Frank Barknecht Do You RjDj.me? _ ______footils.org__