Re: [PD] optimizing big patches

2011-01-13 Thread Frank Barknecht
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

Re: [PD] optimizing big patches

2011-01-12 Thread Mathieu Bouchard
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

Re: [PD] optimizing big patches

2011-01-11 Thread Frank Barknecht
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"-a

Re: [PD] optimizing big patches

2011-01-11 Thread Mathieu Bouchard
On Tue, 11 Jan 2011, András Murányi wrote: 2011/1/11 Mathieu Bouchard 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 tenfo

Re: [PD] optimizing big patches

2011-01-11 Thread András Murányi
2011/1/11 Mathieu Bouchard > 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

Re: [PD] optimizing big patches

2011-01-11 Thread Mathieu Bouchard
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

Re: [PD] optimizing big patches

2011-01-10 Thread Ludwig Maes
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/subpatche

Re: [PD] optimizing big patches

2011-01-09 Thread Mathieu Bouchard
On Mon, 10 Jan 2011, Bastiaan van den Berg wrote: This sounds great, what about spawning each subpatch in a new thread, and have a simple processmonitor in the gui? That would also take a big advantage in the newer processor designs. Pd's execution order model forbids launching threads transp

Re: [PD] optimizing big patches

2011-01-09 Thread Mathieu Bouchard
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. T

Re: [PD] optimizing big patches

2011-01-09 Thread Bastiaan van den Berg
On 1/9/2011 2:09 PM, wrote: > > 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? > > This sounds great, what about spawning each subpatch in a new t

Re: [PD] optimizing big patches

2011-01-09 Thread Michael Matthews
On 1/9/2011 2:09 PM, wrote: 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? One way I can think of that you could do this would be to open e

Re: [PD] optimizing big patches

2011-01-09 Thread Pedro Lopes
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 wrote: > take them out and see the changes. or copy them into a new patch and close > the rest. > > > Hello, one question, if i hav

Re: [PD] optimizing big patches

2011-01-09 Thread João Pais
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] optimizing big patches

2011-01-09 Thread ronni montoya
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 a