[chuck-users] GC vs real-time (was Getting Started with ChucK)

[Hans Aberg]

On 24 Jul 2009, at 17:59, Kassen wrote:

> That is a big problem: Chuck needs to be multi-threaded if it should  
> be able to make use of this new computing power.
>
> Yes. However using multiple CPU's to distribute the work of a  
> program like ChucK is a non-trivial matter. For one thing it's not  
> always possible. consider this;
>
> 5 => int n;
>
> SinOsc sines[n];
>
> for(int i; i< sines.cap(); i++)
>     {
>     2 => sines[i].sync;
>     1 + (10*i) => sines[i].gain;
>     for(int j; j< sines.cap(); j++)
>         {
>         if(i != j) sines[i] => sines[j];
>         }
>     }
>
> sines [0] => dac;
> 5::second => now;
>
> That is a highly interconnected UGen graph and I think we will agree  
> that for any CPU there is a number "n" at which point this will no  
> longer run on that CPU. At that point distributing the calculation  
> will likely not help you much either, if it's possible at all.

Chuck threads, or "shreds", need only be synchronized every sample  
time. So intermediate calculations can be put on several system  
(POSIX) threads. So that is one possibility.

So is that not possible in your example? If not, one may need to  
invent new syntax which is parallelizable. Specifically, highly serial  
"for" loops can probably not be done much about without such rewriting.

A second possibility might be have several Chuck synchronizing  
threads, each synchronizing a set shreds, but between the sets there  
is a less rigid timing requirement, like a hundredth of second. This  
would be suitable to make different sound generators.

   Hans