This design can still be salvaged by providing methods for instances to 
communicate in a thread safe way. These could either be new opcodes, or 
thread-safety features in existing opcodes.

The same logic that leads you to plead for a new "engine" leads one to wish 
for a clean design of a new software synthesis system, instead of continuing 
to wrestle with Csound.

Like an idiot, I am both pursing a clean design of a new SWSS, AND 
continuing to wrestle with Csound.

Regards,
Mike

----- Original Message ----- 
From: "John Lato" 
To: 
Sent: Thursday, April 17, 2008 6:09 PM
Subject: [Csnd] Re: Re: Parallel hosts (was Re: Best hardware for 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
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
> csound" 

Although I have nothing against making it possible for csounders to control threading 
through opcodes, I don't like the idea of it being required in order to make use of 
multiple processors.  With the variety of different types of inter-instrument 
communication, I think it would make more sense to develop a parallelization system 
that would work in most (all?) situations, with minimal effort on the part of the 
csound user.

In fact, I do wish for a clean design of a new SWSS, which has led me to look at 
Supercollider, ChucK, and other systems.  What keeps me coming back to csound is the 
huge variety of (often very sophisticated) processing available, which is far greater 
than most other systems.  Even so, there are certain aspects of csound development I 
disagree with.  As I'm not a csound developer, and I don't have time to devote to the 
effort, I've kept my mouth shut.  Since I've already spoken up, though, I'll speak 
plainly.  This approach strikes me as a very poor parallelization model (for multiple 
reasons), and I don't want to see it added to csound and then have further 
development hobbled by the need to continually support a (IMO) poor decision.  I 
don't mean this as a disparagement to the developers, who continue to do good work 
and accomplish some amazing improvements in csound.  I just think that, in a 
situation where features are never rescinded, a little more care should be taken 
before implementing far-reaching changes.

Cheers,
John

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:
> This design can still be salvaged by providing methods for instances to 
> communicate in a thread safe way. These could either be new opcodes, or 
> thread-safety features in existing opcodes.
> 
> The same logic that leads you to plead for a new "engine" leads one to 
> wish for a clean design of a new software synthesis system, instead of 
> continuing to wrestle with Csound.
> 
> Like an idiot, I am both pursing a clean design of a new SWSS, AND 
> continuing to wrestle with Csound.
> 
> Regards,
> Mike
> 
> ----- Original Message ----- From: "John Lato" 
> To: 
> Sent: Thursday, April 17, 2008 6:09 PM
> Subject: [Csnd] Re: Re: Parallel hosts (was Re: Best hardware for 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
>>
>>
>> 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"