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 than nothing.
to make use of a multicore machine the only way to utilize all cores
is
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 PD?
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 large system.
- 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).
Phil