[chuck-users] GC vs real-time (was Getting Started with ChucK)
haberg at math.su.se
Fri Jul 24 13:17:39 EDT 2009
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  => 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.
More information about the chuck-users