<br><br><div class="gmail_quote">2011/1/11 Mathieu Bouchard <span dir="ltr">&lt;<a href="mailto:matju@artengine.ca">matju@artengine.ca</a>&gt;</span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<div class="im">On Mon, 10 Jan 2011, Ludwig Maes wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
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 &quot;compile&quot; menu item to compile patches/subpatches.<br>


</blockquote>
<br></div>
There are a lot of possible ways to compile patches without having to deal with machine code generation and use. I&#39;m sure you can triple the speed of a lot of patches in this manner, and I wouldn&#39;t be surprised to get tenfold improvements in some cases.<br>


<br></blockquote><div><br>That sounds too cool! Is there a way which includes graphical objects as well?<br><br>Andras<br><br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">


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.<div><div></div><div class="h5"><br>
</div></div></blockquote></div><br>