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