| >Does any know what effect it would have to parallelize the work per
>instrument instance *and* to implement algorithms in parallel fashion
>too? Would they interfere with each other in any way?
This is what I was getting at with "value copies" of inputs and outputs.
In my latest prototype synthesizer there are 3 steps to each "kperiod." Note: the DSP graph can be ANY directed acyclical graph -- doesn't have to be a linear chain, as in Csound, but can have branches, rejoinings, etc., just can't go "backwards in time."
Step 1: reduce all outputs to inputs. Typically, a source node has signals in its outlets. Several outlets may be connected to an inlet in a sink node. In this step, each sink node inlet computes its signal as the sum of all the signals in its connected source node outlets.
Note, this implies some additional speedup can be achieved by implementing all arate OP arate, krate OP arate, and arate OP krate operations using vectorized BLAS routines (dgemm is just one example).
Step 2: clear all outlet signals.
Step 3: Each node reads its inlet signals, and computes its outlet signals.
Then back to step 1.
This design permits parallelization with mere "parallel for," there is no need for "parallel reduce," as the reduction takes place in step 1. If a performance library were used, the signals could be matrices [frame, channel] and the reduction could use vector parallelization, i.e. a parallel form of dgemm performing matrix addition.
The cost of this design is that the signals must be copied to preserve data independence. My experience is that this is quite tolerable.
The order of nodes, of course, is still important.
So in Csound, this would still work fine. Instances and opcodes would still have to be in the right order. But pfields and out* opcodes and other inlets and outlets would be copied as above (perhaps they already are?). That way one instance can't stomp on another one.
Regards,
Mike
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net |