I agree, this is the way to go at this time.

N instances of Csound created. Each starts and compiles the same orchestra.

Just read a score file and send each line to 1 of the instances in turn, round-robin.

Each instance runs in its own thread. When each thread has finished computing its buffer it waits, the buffers are summed into a real output buffer, when all threads are waiting the real output buffer is written to the real output, and the threads are signaled to resume.

This is all fine as long as instruments in different instances don't talk to each other.

Regards,
Mike

-----Original Message-----
>From: victor 
>Sent: Apr 17, 2008 3:33 PM
>To: csound@lists.bath.ac.uk
>Subject: [Csnd] Parallel hosts (was Re: Best hardware for Csound?)
>
>yes, but that doesn't stop a parallel processing
>host being built, whereby two or more instances are
>run side by side.
>I think this might be a good way of going about it.
>
>Eventually a parser could be built that looks at a
>CSD and splits it into two or more running
>instances.
>
>Because Csound is reentrant, this is perfectly
>feasible. Also because we can go down to
>a ksmos level of granularity, this might not
>perform too badly.
>
>Victor
>
>----- Original Message ----- 
>From: "Steven Yi" 
>To: 
>Sent: Thursday, April 17, 2008 7:37 PM
>Subject: [Csnd] Re: Re: Re: Re: Re: Re: Best hardware for Csound?
>
>
>> 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  
>> 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 :
>>>
>>>
>>> > 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"
>>>
>>
>>
>> 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"

I don't like this idea.  It will work as long as the instruments don't talk to each 
other, or modify global global structures such as f-tables (or some number of other 
conditions).  However, I expect that a large number of orcs do one or more of those, 
and that complicated orchestras (and real-time pieces) for which multicore 
capabilities would be most useful are more likely to have complex inter-instrument 
communication, or modify f-tables, etc.  Properly handling those situations would 
require dealing with the issues that Steven mentioned.

In short, even though I doubt this would take more than an afternoon for someone 
familiar with the csound internals to implement, I would prefer that developer time 
be spent actually working on a viable parallel engine rather than this.

John W. Lato
Sarah and Ernest Butler School of Music
The University of Texas at Austin
1 University Station E3100
Austin, TX 78712-0435
(512) 232-2090

Michael Gogins wrote:
> I agree, this is the way to go at this time.
> 
> N instances of Csound created. Each starts and compiles the same orchestra.
> 
> Just read a score file and send each line to 1 of the instances in turn, round-robin.
> 
> Each instance runs in its own thread. When each thread has finished computing its buffer it waits, the buffers are summed into a real output buffer, when all threads are waiting the real output buffer is written to the real output, and the threads are signaled to resume.
> 
> This is all fine as long as instruments in different instances don't talk to each other.
> 
> Regards,
> Mike
> 
> -----Original Message-----
>> From: victor 
>> Sent: Apr 17, 2008 3:33 PM
>> To: csound@lists.bath.ac.uk
>> Subject: [Csnd] Parallel hosts (was Re: Best hardware for Csound?)
>>
>> yes, but that doesn't stop a parallel processing
>> host being built, whereby two or more instances are
>> run side by side.
>> I think this might be a good way of going about it.
>>
>> Eventually a parser could be built that looks at a
>> CSD and splits it into two or more running
>> instances.
>>
>> Because Csound is reentrant, this is perfectly
>> feasible. Also because we can go down to
>> a ksmos level of granularity, this might not
>> perform too badly.
>>
>> Victor
>>
>> ----- Original Message ----- 
>> From: "Steven Yi" 
>> To: 
>> Sent: Thursday, April 17, 2008 7:37 PM
>> Subject: [Csnd] Re: Re: Re: Re: Re: Re: Best hardware for Csound?
>>
>>
>>> 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