Given the evident difficulty of speeding up Csound otherwise, I've been 
thinking of ways of making canonical Csound render in parallel.

I outline some possible approaches below -- I know some of these have 
discussed or even implemented before. Please comment!

Parallelize Polyphonic Instances Only
-------------------------------------

In this case, only multiple instances of the same instrument template would 
run in parallel. This is probably the easiest to implement, and in many 
styles of music
would provide an immediate speedup mostly linear without the number of 
cores. But it would not provide speedups in analysis/resynthesis heavy 
pieces, or in pieces with only one or a few voices. As long as one instance 
of a template does not try sending or receiving with another instance of the 
template, it is thread safe.

Analyze and Partition DSP Graph
-------------------------------

In this case, the Csound orchestra compiler would, at the same time as it 
compiles the DSP graph, also infer and maintain a list of mutually 
independent instrument templates. At run time, each independent pool of 
templates could safely run in its own thread.


Declare Thread
--------------

In this case, the orchestra programmer would be responsible for declaring 
which templates are independent, and the templates would be assigned to a 
thread based on a declared thread ID.

Channels, zak, tables, and other globals
----------------------------------------

In each of these alternatives, side effects between instances can occur as a 
result of reading/writing control channels, mixer channels, zak tables, or 
other global variables.

The easiest solution is to place all templates that perform operations with 
global side effects in a main graph that does not attempt to parallelize 
rendering.

The next easiest solution is to declare the thread of the operation.

Finally, the current Csound DSP graph (which is a list (with gaps) of lists) 
could be replaced with a regular signal flow graph/synchronous data flow 
graph, from which the total ordering of static operations can easily be 
inferred. In principle, this should not be too difficult. The main 
complication comes from polyphonic instruments.

Finally, if there are any operations that dynamically re-order the DSP graph 
at run time, for example switching off a runtime value to dispatch to one or 
another global variable, all bets are off.

Instrument template order
-------------------------

I assume that, regardless of which of the above approaches is chosen, within 
the threading algorithm instrument instances will run, as they now do, in 
order of ascending instrument number. 


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi Mike,
Some random thoughts....
On 23/04/2008, at 10:19 AM, Michael Gogins wrote:
> Given the evident difficulty of speeding up Csound otherwise, I've  
> been
> thinking of ways of making canonical Csound render in parallel.
>
> I outline some possible approaches below -- I know some of these have
> discussed or even implemented before. Please comment!
>
> Parallelize Polyphonic Instances Only
> -------------------------------------
It would be good, IMO, to start  here and work towards more  
complexity. Unintended side-effects are thus minimized
Im not sure whether you intended it wrt this (PPIO) but some form of  
on multiple machine parallelization (what's called a 'render farm' in  
animation) would be a amazing - presumably controlled via OSC or  
whatever.
User control (tweaking) of the thread-order provides good flexibility  
(see below).
I such a system summing of instance output buffers does not always  
need to be sample accurate. Actually, in my experience, a more "cohere- 
ant" sound is achieved if it isn't (sample accurate). Perhaps (RT)  
coordination at (instantiation-specific) k-rates would be simplest/ 
flexible enough.
...
> Declare Thread
> --------------
>
> In this case, the orchestra programmer would be responsible for  
> declaring
> which templates are independent, and the templates would be assigned  
> to a
> thread based on a declared thread ID.
Yes - then if it is automated later, the resulting factorisation is  
likely to lead to a more stable system.
...
> Instrument template order
> -------------------------
>
> I assume that, regardless of which of the above approaches is  
> chosen, within
> the threading algorithm instrument instances will run, as they now  
> do, in
> order of ascending instrument number.
As I suggested above, it would be good to have this under user  
control. In heavily multiple-threaded SW I've written in the past, I  
found that being able to adjust the thread order added significant  
qualitative control. Rather than assume an ideal world where audio OP  
is thread-transparent, assume it isn't and that there is a  
(psychoacoustic) optimal thread-order, best adjusted by audition.  
Adjustment by instrument number alone would be cumbersome. An  
instrument No. re-mapping table could alleviate that somewhat, and  
afford ascending instrument number. However, in the real-world,  
assuming the major issue is thread-coordination (temporal blurring) it  
is the nature of the material being produced by an instrument c.f.  
what else is going on (in separate threads, say) that dictates the  
best way direction to time-smudge in order to get the best blur.  
Simple eg. imagine short high tones from one thread over longer low  
tones from two others. In order for these to be heard as coincident,  
the low tones need to begin first.

-David.



-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net