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
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
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
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
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
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
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
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
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
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
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
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
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.
___
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
14 matches
Mail list logo