Hello, I just wanted to comment on this. I think a multiprocessor Csound would be amazing! Imagine using all the power of a 8 core machine (like the new Mac Pro) for realtime instruments! I hope Csound gets there soon. Cheers, Hector On Jan 17, 2008 2:20 AM, Steven Yi wrote: > One interesting to note about multiprocessor csound that it's been > done before by Barry Vercoe himself for karaoke machines: > > http://www.epigon.in/pdf/studyRoom1.pdf > http://pubs.media.mit.edu/bttj/Paper20Pages180-186.pdf > > I read through these when I first started to think about the issues > around multi-core but hadn't really returned to them until just now > while looking for them. Interestingly enough, in the second paper > linked above, Figure 3 and the description of dividing the tasks is > similar to what I was going after in the naive implementation I did > and that is in CVS, though I did not compute cpu load and handle voice > stealing as that wasn't a technical interest. I would say though that > the multiprocessor implementation in the papers wouldn't work in a > generic way in canonical csound, so would assume that either the > multiprocessor csound was patched to handle resource contention issues > or orchestras that were designed for it were limited to certain > designs to get around issues of internals. > > Fascinating stuff and looking at it I certainly will be studying them > once again! > steven > > > On Jan 16, 2008 2:27 PM, victor wrote: > > Access to files etc is solved by MPI where things are copied across > > nodes and everything is unified. My approach was more coarsely-grained > > one, where instead of looking how to parallelise Csound internally, > > I would build a host that would run parallel instances of Csound and > > then load distribution would be a matter of starting events on each > > of the nodes. One instance would distribute inputs (if any) and > > collect the outputs, possibly in a blocking way, but asynchronous > > operation also was something to try. Eventually we would move towards > > a software that would load-balance automatically. Of course, not many > > problems are coarsely-grained enough for this type of approach. > > > > So, perhaps we are not talking about a generic cluster solution, but > > one tailored to a particular system, but working from the API level, > > rather than providing support inside Csound. This does not exclude > > a possible SMP version of Csound that runs parallelised without the > > user having to do anything in particular. But that is a different thing > > altogether. > > > > Victor > > > > >> > > >> The problem with a generic clustered solution I saw were having to > > >> deal with network latency, global memory, access to resources (i.e. > > >> wave files, where would they reside? would need copies available to > > >> all nodes on the cluster), and heterogeneous processing profiles due > > >> to possible different cpu types. This all becomes very tricky to > > >> balance and profiling would be necessary to know how to divide all the > > >> work in a way that will make the most use of each CPU and do so in a > > >> way that makes it faster than network latency slows down everything. > > >> Custom clustered solutions where one might say design orchestra's so > > >> no instruments depend on each other or one manually creates an orc per > > >> node or something like that is feasible and may provide performance > > >> gains, but I think a generic clustered solution would be very > > >> difficult and that a multi-core solution would yield more results for > > >> the work put in. > > >> > > >> That's just my two cents on that! =P > > >> steven > > > > > > > > > > Send bugs reports to this list. > > To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound" > > > > > Send bugs reports to this list. > To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound" >