Re: [sc-users] will there ever be real multiprocessor support?

[nescivi <nescivi@xxxxxxxxx>]

Hiho,

Since synths run fairly independent of each other, and we have a fairly clear 
structure of the graph, as determined by the group tree structure, I think it 
should be possible to determine which synths can run independently, and at 
which points they need to be mixed together.
It would require an analysis of which synths are writing to which buses, and 
which ones are subsequently reading from it. And in the end, you'll need to 
mix everything together.
Mind you, this can still be somewhat of an headache to determine.

Parallellisation in general is always a tradeoff between how independent 
processes are and how much communication is needed between the processes.

sincerely,
Marije

On Thursday 05 March 2009 06:36:02 Scott Wilson wrote:
> As I understand it, the problem is that the big payoffs in multicore
> come from truly parallel processing. Otherwise it is very easy to get
> into a situation where cores are waiting for each other, which
> depending on how the workload is distributed can actually make things
> slower. Tuning the distribution for maximum gain is not trivial, and
> multicore processing itself does have overhead. Large block sizes (or
> in the case of Jack hardware buffers I would imagine?) helps to
> minimize this cost. The Max poly~ documentation points this out:
>
> "It is primarily intended for patches that use a significant amount of
> CPU within multiple voices of the same poly~ object, and the
> multithreading overhead is primarily useful for larger signal vector
> sizes (at least 32 or greater). Other situations will not benefit."
>
> S.
>
> On 5 Mar 2009, at 11:04, Wouter Snoei wrote:
> > Op 5 mrt 2009, om 11:32 heeft Dan Stowell het volgende geschreven:
> >> Yes, it will need to be attempted, but I'm not sure what approach is
> >> going to suit. I'd like to see scsynth able to run its synths on
> >> different cores, but that will need some kind of dependency graph
> >> analysis in order to understand what can be run before what.
> >
> > What essentially would be required is the ability to share buses and
> > buffers over multiple cores. Would it be interesting to look at how
> > Jackosx is setup? They manage to share buses over multiple threads
> > somehow; the program can connect anything to anything, regardless of
> > what cpu it is running on.
> >
> >> Max/MSP does support multicore but not automatically. You need to use
> >> a special object that explicitly multicorifies a bit of the graph.
> >
> > That is essentially the same approach as running multiple servers,
> > but with one big difference: the buses can be mixed together and
> > used for other processes before going to the DA, _inside_ the max
> > application (that also goes for DAW's btw). That is again a form of
> > shared buses. We have shared buses in the internal server right?
> > Couldn't they be reworked to be shared between server apps? Or
> > between multiple scsynths working inside one big multicore scsynth?
> > Or am I talking nonsense now :-)
> >
> > cheers,
> > Wouter
> >
> >> The thing is that a lot of DAWs have a fairly old-school attitude
> >> where each track has an independent processing chain, which makes it
> >> easy to spread the chains over cores. More interesting software like
> >> sc makes that much more tricky...
> >>
> >> Max/MSP does support multicore but not automatically. You need to use
> >> a special object that explicitly multicorifies a bit of the graph.
> >>
> >> Dan
> >>
> >> 2009/3/5, Scott Wilson <s.d.wilson.1@xxxxxxxxxx>:
> >>> It may well be that DAWs and other programming environments are
> >>> multiprocessor, but I would be very curious to know how the work
> >>> is being
> >>> distributed.
> >>>
> >>> SC *is* multiprocessor. The language and server run in different
> >>> processes.
> >>> Different threads can run on different processors. Any background
> >>> OS stuff
> >>> can possibly run on a different core.
> >>>
> >>> What is not multiprocessor is the audio thread. In order to make
> >>> it so you
> >>> would in any case need some way of specifying which audio
> >>> processes are not
> >>> interdependent. Although it may be possible to somehow do this
> >>> automatically, I suspect that any solution would not be
> >>> syntactically very
> >>> different from just sending things to multiple running server
> >>> processes, as
> >>> you can do now.
> >>>
> >>> I also suspect that the DAWs you mention may be dividing things up
> >>> in a
> >>> similar fashion to SC, e.g. graphics on one core, audio on
> >>> another. But as I
> >>> said I'd be curious to know more.
> >>>
> >>> S.
> >>>
> >>> On 5 Mar 2009, at 02:21, Josh Parmenter wrote:
> >>>> Hi Miguel,
> >>>>
> >>>> This isn't a trivial endeavor. It will require rewriting quite a
> >>>> bit of
> >>>
> >>> the foundational code in SuperCollider. I imagine it will happen,
> >>> but not
> >>> quickly. Part of the discussion for work of this scale will also
> >>> include a
> >>> discussion on possible architecture changes (I would imagine).
> >>>
> >>>> The major DAWs pay their coders quite a bit for those tools. That
> >>>> is their
> >>>
> >>> job. Nobody's job here is to build SC. We all have other jobs, and
> >>> do this
> >>> in our other time. So they really can't be compared. Some of us
> >>> have already
> >>> looked at this next step, and it is a big one. It is certainly not
> >>> easy, and
> >>> it will require of most developers the learning of a new tool set.
> >>> Then -
> >>> add in cross-platform concerns, and a whole new mess is created.
> >>>
> >>>> Josh
> >>>>
> >>>> On Mar 4, 2009, at 5:46 PM, Miguel Negrao wrote:
> >>>>> But all the major daws (protools, logic, cubasem nuendo, etc)
> >>>>> support
> >>>
> >>> multi-processors, and now even max/msp supports them and csound has
> >>> experimental multi-core on 5.0.9.
> >>>
> >>>>> I guess putting several servers sending audio to each other
> >>>>> through jack
> >>>
> >>> might be a temporary solution, but still that's a big headache...
> >>>
> >>>>> Off course I'm not saying it's easy, but it just seems to me
> >>>>> that it
> >>>
> >>> will have to be adressed at some point in order for the sc to not
> >>> become
> >>> obsolete. Fierceless sc programmers out there, sink your teeth
> >>> into this
> >>> problem so that you can have the glory of being the one to make sc
> >>> multi-core friendly ! We promise we will build a statue for you! :-)
> >>>
> >>>>> Miguel
> >>>>>
> >>>>> ps: how much of delay is there introduced by sending audio
> >>>>> between two
> >>>
> >>> apps using jack ?
> >>>

_______________________________________________
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/