I've thought about multicore quite a bit and csound internally can not
handle it at this time.  I did commit a naive implementation a year or
so ago.  The problem is that there are certain things that are not
safe, particularly things like the global currevt (I think that's the
name) pointing to the to current instrument instance being run that is
used by things like goto's to walk the chain of opcodes to find
labels.  I mentioned a while back about changing the instrument
building from single linked list to double linked list so that a goto
could search out from itself to find labels.  There are other things
that would need to be done such as introducing mutexes or semaphores
to protect access to global data like ftables, though much of that may
require user coding in csound to define where to do mutex
locks/unlocks.  (There are mutex opcodes I wrote that are in csound
but undocumented so that users can do the mutex locks/unlocks in their
csound code).

Either way, the internals of Csound can not handle multicore at this
time.  If anyone wants to take a stab at it, I've thought about it a
number of times and have some ideas as to what needs to change so
might be able to help out there.

steven



On Thu, Apr 17, 2008 at 2:49 AM, Oeyvind Brandtsegg <obrandts@gmail.com> wrote:
> I've been wondering about multicore issue a bit,
>  it seems ProTools have managed multi CPU (multi DSP) operation with
>  their DSP Farm cards for many years (decades). As a result it also
>  seems that they managed the transition to multicore computers pretty
>  easily.
>  I do not know the technical details, just thinking "conceptually"
>  about the issue.
>  Is there anything in terms of general approach that we could "borrow"
>  from ProTools to make Csound multicore enabled ?
>
>  best
>  Oeyvind
>
>
>  2008/4/17, Richard Dobson <richarddobson@blueyonder.co.uk>:
>
>
> > Brian Redfern wrote:
>  > > Which again wouldn't likely make a difference as I bet most media apps
>  > work the same way, so at best maybe the os knows how to use an idle
>  > processor, but I don't know of any multi-core optimized sequencers.
>  > >
>  > >
>  >
>  > There's a strong chance there aren't any (to use above two cores). I have
>  > just acquired Logic 8 Pro, which is great fun, but on the dual-core iMac
>  > here it is clear that all the audio is on one core and the gui is on the
>  > other (no surprises there). I suppose a quad  machine would allow Logic and
>  > Csound to run comfortably together.
>  >
>  > How to use multicore and concurrent processing for audio is (or should be!)
>  > a significant research question (implementation questions; how can one get
>  > an 8-core mac Pro to use all 8 cores, devote 4 cores to one plugin, etc);
>  > but our attempts to get funding have so far fallen on stony ground  - not an
>  > important enough topic, apparently. Heaven only knows what we will be able
>  > to do with 80 cores - probably much the same as we are doing with two.
>  >
>  > In the meantime, getting lots of memory will be at least as important as
>  > getting lots of cores. So if it is a toss-up between 2 cores and 4GB or 4
>  > cores and 2GB, I would go for the former.
>  >
>  >
>  > Richard Dobson
>  >
>  >
>  >
>  >
>  > 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"
>