[PD] optimizing big patches

András Murányi muranyia at gmail.com
Tue Jan 11 20:24:03 CET 2011

2011/1/11 Mathieu Bouchard <matju at 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


> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20110111/a821581d/attachment.htm>

More information about the Pd-list mailing list