[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [sc-users] Re: will there ever be real multiprocessor support?
I had missed this suggestion. It's a very interesting suggestion,
essentially it would be the same approach as Max currently uses,
allowing the user to explicitly define a parallelisable subgraph.
Would one be able to add serial-groups inside a parallel-group? Hope
so.
I'm trying to remember the parallellisation APIs I read a while back.
I think they would make this possible - no technical objections spring
to mind yet...
(btw it could probably simply be a new property of a group - default
serial but can flag as parallel - which would mean very little change
to scsynth's osc interface)
Dan
2009/3/6 James Harkins <jamshark70@xxxxxxxxx>:
> Is there a technical objection to my suggestion of a second group node type,
> that allows parallelism within it?
> It seems to me this is a fairly simple and elegant idea that just might do
> exactly what we need: tell the server that this bunch of nodes must follow
> this other node, and precede the next node, but within it, it's a
> free-for-all.
> The group node that we have now would be a "serial group," and the new type
> would allow parallelism among its immediate children. So if you wanted to
> distribute several source --> effect chains among different threads, you
> would have a "parallel group" containing a number of "serial groups." Within
> the serial groups, order of execution is guaranteed, but each of these
> serial groups contained within the parallel group could run independently on
> a separate processor.
> This is loosely inspired by Faust's parallelism operator, adapted to sc's
> node structure. There could easily be a technical reason why this would
> simply not work, but in the absence of that reason, it seems to me this is a
> reasonably small conceptual leap for end-users and it would also involve the
> least surgery. (I would say, whatever the final user interface is, it has to
> be simple. SC is confusing enough as it is!)
> hjh
--
http://www.mcld.co.uk
_______________________________________________
sc-users mailing list
info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-users/
search: https://listarc.bham.ac.uk/lists/sc-users/search/