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 <Victor.Lazzarini@nuim.ie> 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"
>