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"