[PD] pd and multi-core processors

[vedran]

Thanks for the extensive description of the solution. I'm currently working
with vvvv on win7 but I'm osx user and this is the main reason why I'd like
to switch to pd+gem. I'll work on visual output only, so I won't do any dsp
(there is a plan for future but lets not think about it). vvvv also uses
only one core per instance (without a solution to somehow split process in
one instance) and my current project is quite heavy to handle it this way.
There is a solution as with pd, to run two or more instances who communicate
and leave the system to handle the multicore spliting. I'll try pd+gem
anyway just to see how it will work...

thanks,
vedran





.....................................................
vedran kolac
.....................................................
gTalk - vedran.kolac at gmail.com
.....................................................
skype - vedrankolac
.....................................................
+385 (0) 91 567 07 17
.....................................................
http://www.onoxo.net
http://www.projectmoe.net
.....................................................


On Mon, Apr 5, 2010 at 8:43 PM, Matteo Sisti Sette <
matteosistisette at gmail.com> wrote:

> (this is a little OT respect to the thread)
>
>
> > nicely enough, pd's graphical interface and the actual process,
> > are separate threads,
>
> The communication between the engine of Pd ("Pd") and the graphical
> interface ("GUI") is not as efficient as you may expect it to be - at least
> not as much as I expected it to be.
>
> When you send a message to a GUI object, such as for example a "set"
> message to the receive-symbol of a slider, the Pd process sends a message to
> the GUI process and the GUI process actually redraws what it has to redraw:
> so the Pd process is not "blocked" while all the (embarassingly cpu
> consuming) draw operation is performed. So you would expect that the time
> needed to send a message to a GUI object is just the time needed to send a
> message through a TCP socket.
>
> Not quite so.
> I don't know why, but when you send a message to a GUI object it takes
> significantly much more CPU time to the Pd process than simply sending a
> message through TCP, though much less than it takes to actually redraw
> things. I _guess_ the Pd process probably waits for some kind of
> aknowledgement or respose from the GUI process or something like that, but
> this is only a guess.
>
> I found this out because I create patches that have to be used "on the
> stage" by users that are not "pd-ers", so I make extensive use of GUI. All
> significant parameters or values that can be changed and/or need to be
> monitored are displayed on the GUI. So I send a lot of messages to the GUI.
> I also store "snapshots" of configuration that are then called (_not_ loaded
> from disk at the moment of calling them), so there often are "massive"
> bursts of messages to a lot of GUI objects in zero logical time (I already
> reduced the messages to only the actually needed ones). So, soon I began to
> have a lot of audio dropouts.
>
> So I tried out a solution that seemed ridiculous at first: I made an
> "engine" patch which does all the audio and midi stuff but has no GUI, and
> an "interface" patch that has only the GUI stuff, and exchanges control data
> (in both senses of course) with the engine patch. And obviously I run them
> on two different instances of Pd.
>
> My "protocol" of communication between the two patches is not even very
> optimized, so I send a lot of messages that could actually be avoided (don't
> tell anybody).
> Well with this system, despite the huge quantity of messages to and from
> GUI, I get no dropouts at all, everything works fine.
>
> I have indeed replicated "at the patch level" the engine-GUI architecture
> that is already implemented in Pd. When I did it, I really was afraid that I
> was doing something stupid; but it did work, and it makes an enormous
> difference (well I did do some test before, that seemed to indicate that it
> may work).
> So the time it takes (meaning the time during which the Pd process is
> either blocked or busy) to send a message through a [netsend] (with even a
> little overhead: passing through a [s] and a [r], a [list prepend send] and
> a [list trim] at the very least) is significantly less than the time it
> takes to send a message to a GUI object.
>
> I am curious to know whether this overhead in the communication between the
> two processes of Pd is entirely necessary (to robustly guarantee consistency
> for example) - and in case it is not, whether it is going to be addressed in
> the gui-rewrite......
>
> --
> Matteo Sisti Sette
> matteosistisette at gmail.com
> http://www.matteosistisette.com
>
> _______________________________________________
>
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20100406/7d5fb128/attachment.htm>