hi,

some comments on parcs & supernova,

> Of course I am biased by long experience with Csound, but I try to
> keep abreast of what is happening in computer music and to know what
> is going on, and planned, in the development of the other major
> software synthesis systems. And I do try to be objective. But frankly,
> the ParCS branch of Csound is the most productive music programming
> environment I know about. The only remotely comparable systems are the
> SuperNova version of SuperCollider and Max/MSP.
> 
> In SuperNova, parallel groups have been introduced into the system,
> and the user is responsible for programming these groups and placing
> suitable parallelizable blocks of code in them.

supercollider and csound implement different concepts. the reason for adding 
parallel groups is their expressive power and the way, they integrate into 
supercollider. the main assumption is, that the user knows more about the 
semantics of the audio synthesis than the runtime.
the programming model is somehow comparable with occam's seq and par.


> A somewhat similar approach is taken in Max/MSP, where it is possible
> to configure poly~ to run individual instances of patches within poly~
> on separate cores. Again, the user is responsible for balancing costs
> and benefits and organizing the parallelism.

please don't call max/poly~ and supernova/parallel groups `similar'. poly~ 
is neither dynamic, nor does it support running different abstractions in 
parallel. also i don't know, if poly~ can be nested.


> But in ParCS, the parallel constructs are invisible to the user.
> Regular Csound code is parsed into a data flow graph grouped by signal
> flow and variable assignment dependency. Each node in the graph is
> evaluated to see if it makes sense, balancing the cost of threading
> with the possible benefits of threading, to run its elements in
> parallel. Global variables are automatically synchronized, too.

automatic dependency analysis is convenient for the user, but for keeping 
the semantics of the original code, some assumptions/dependency constraints 
need to be done, that may limit the parallelism. if instrument i1 writes to 
a buffer b1, and instrument i2 reads from an arbitrary buffer, that can be 
set at audio rate (not sure, if csound allows this), one would need to 
constrain the execution order of i1 and i2. however the user may know, that 
i2 is never reading from the buffer, that i1 writes to.


> I think this design has much more of a future – especially because it
> already affords significant speedups in realistic situations. At ksmps
> of around 100 with compute-intensive instruments, every time the
> number of cores doubles, ParCS speeds up the performance by roughly
> 150%.

measuring the speedup of supernova heavily depends on the application. in a 
synthetic benchmark with few expensive synths, i get a speedup of about 97% 
(average case) and 91% (worst case) per core (measured with 64 single-
precision float samples per block). of course, the speedup is less, when 
using many synths, that are computationally cheap.

cheers, tim

-- 
tim@klingt.org
http://tim.klingt.org

The aim of education is the knowledge, not of facts, but of values
  William S. Burroughs



------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel