Still live blogging the SC symposium
Single processors are not getting faster, so most development is going for multicore architectures. But, most computer music systems are sequential.
How to parallelise? Pipelining! Split the algorithm into stages. This introduces delay ad stuff goes from one processor to the other. Doesn’t scale well. Each stage would need to have around the same computational cost, also.
You could split blocks into smaller chunks. Pipeline must be filled and them emptied, which is a limit. Not all processors can be working all the time.
SuperCollider has special limitations in that OSC commands come at the control rate and the synth graph changes at that time. Thus no pipelining across control rate blocks. Also, there are small block sizes.
For automatic parallelisation, you have to do do dependency analysis. However, there are implicit dependencies with busses. The synth engine doesn’t know which resources are accesses by a synths. This can even depend on other synths. Resources can be accessed at audio rate. Very hard to tell dependencies ahead of time. Automatic parallelisation for supercollider might be impossible. You can do it with CSound because their instrument graphs are way more limited and the compiler knows what resources each one will be accessing. They just duplicate stuff when it seems like they might need it on both. This results in almost no speedup.
The goals for SC are to not change the language and to be real time safe. Pipelining is not going to work and automatic parallelisation is not feasible. So the solution is to parallelise not automatically and let the user sort it out. So try parallel groups.
Groups with no node ordering constraint, so they can be executed in parallel.
easy to use and understand and compatible with the existing group architecture. doesn’t break existing code. You can mix parallel groups with non-parallel ones.
the problems is that the user needs to figure stuff out and make sure it’s correct. Each node has two dependency relations. There is a node before every parallel group and a node afterwards.
This is not always optimal. Satellite nodes can be set to run before or after another node, so 2 new add actions.
There is an example that shows how this is cool. It could be optimised, so that some nodes have higher precedence.
Semantics
Satellite nodes are ordered in relation w one other node
Each node can have multiple satellite predecessors and satellite successors. They may have their own satellite nodes. They can be addressed by the parent group of their reference node. Their lifetime should relate to the lifetime of their reference node.
This is good because it increases the parallelism and is easier, but it more complicated.
Completely rewritten scsynth w a multiprocessor aware synthesis engine. Has good support for parallel groups, working on support for satellite nodes. Loads only slightly patches Ugens. Tested on linux, w more than 20 concerts. Compiles on OS X, might work. We’ll see. (linux is the future)
supernova is designed for low latency, real time. dependency graph representation has higher overhead. There’s a few microsecond delay.
For resource consistency, spinlocks have been added. Reading the same resource from parallel synths is safe. Writing may be safe. Out.ar is safe. Replace.ar might not be. The infrastructure is already part of the svn trunk.
(I’m wondering if this makes writing UGens harder?)
A graph of benchmarks for supernova. Scales well. Now a graph of average case speedup. W big synths speedup is nearly 4.
Proposed extensions: parallel groups, satellite nodes. Supernova is cool.
There is an article about tis on teh interweb, part of his MA thesis.
Scott Wilson wants to know about dependencies in satellite nodes. All of them have dependencies. Also wants to know if you need parallel nodes if you have satellite nodes. Answer: you need both.
