[PD] SMP Questions
pkstone at ucdavis.edu
Wed Aug 22 02:31:11 CEST 2007
Tim Blechmann wrote:
>> With the small exception that, as Hans mentioned, two cores will be of
>> benefit because the graphics process can run on its own core.
> the benefit is that minimal, that it's hardly worth mentioning ... just
> run your favorite patch and look at the used cpu time ... (for the
> patches that i tested, the cpu time used by the gui process is less than
> 0.1% of the time used by the kernel)
It's nice to use vu-meters without affecting the cpu available to audio
patches on a core-duo. The UI process gets up to about 5% (of one
processor) on my most complex patch; it's nice to keep that separate
from the audio, of which I tend to need as much as I can get.
I'm not disagreeing, really, it's not that significant, but it's better
>>> to make use of a multicore machine the only way to utilize all cores
>>> to run several instances of pd, that are connected via jackdmp.
>> Now *there's* an idea. Would that really work? What would be the
>> downside -- aside from the memory needed to run multiple copies of
> the problems are:
> - scalability: you need (at least) as many pd instances as cpu cores...
> it is always the question, if you can manually split your dsp graph in a
> reasonable way ...
That's what the modular design would accomplish. Each module would
have, at a minimum, audio outputs and optional audio inputs.
Come to think of it, this probably wouldn't work very well unless simple
control messages of some kind (OSC, netpd, actual PD messages) could
pass between the instances, too -- otherwise, each module would have to
be set up and initialized separately, which would be time-consuming in a
> - performance: jackdmp's dsp graph scheduling is less efficient than
> pd's (which is less efficient than nova's :) ... so using _many_ pd
> instances is probably a bad idea
> - communication overhead: you need to synchronize the instances ... easy
> for simple controls (OSC or netsend/receive) difficult for shared
> resources (buffers, busses)
So jackdmp wouldn't be good at patching say, 32 different generation
modules (constituting entire "synthesizers") to a nice long, patchable
filter chain to final audio output? Rats. That's critical to this
being a viable fantasy.
>> I can imagine a very powerful modular system built on this model.
> i somehow doubt, that i would make sense to use a jackdmp-style
> multicore scheduling algorithm for a max/pd/nova dsp graph, which can
> easily contain thousands of nodes (jack graphs are usually rather
> small), because of the scheduling overhead ...
That's too bad. I'll take your word for it that jackdmp wouldn't be
able to manage the inter-process connection in a scalable way -- I'm not
familiar with how it works. I'm disappointed, because it sounded like a
cheap (and yes, slightly inconvenient -- but better than nothing) way to
scale up PD with SMP.
> however, i was thinking about ways to implement a hybrid system with
> automatic segmentation of the dsp graph into parallel dsp chains that
> can be scheduled with a dataflow algorithm ... but it would require lots
> of performance tests to tweak the heuristics of the graph
> segmentation ... for now, i had neither time nor funding ... (but maybe
> it is an interesting topic for my master thesis?)
I can tell you're talking about the *right* way to do all this. I'm
just hoping there's some interim possibility, because even by this time
next year, we'll be seeing a lot more n-cores where n > 2.
Best of luck to you in your endeavors, Tim (especially Nova).
More information about the Pd-list