Hi Rogan,

Here's a question I have -- if they are both based on the same system clock, will the two instances of chuck stay in sync, time-wise?

i think this becomes an OS dependent question, but the answer should theoretically be yes. since each instance will stay in sync with itself, and they both stay in sync to a reference sample rate, there shouldn't be any drift. if each instance is playing a loop of the same length at the same sample rate, the loops should stay in the same phase relation. but, interrupts happen, processors time slice, and sometimes you have to wait for i/o (depending on your application in ChucK). it'd be a really fun experiment to collect the sample stream in real time for each and measure the drift on samples and then look at the drift it has on seconds.. since we're on the topic of parallel, has any effort or thought gone into porting the back end of ChucK to a GPGPU like CUDA? The high end ones are expensive, but have 240 cores. fortunately, they made the coding style scalable so that the same code will compile for both a GPU with 24 cores and a GPU with 240 cores (and every available number of cores in between). getting the data to the soundcard shouldn't be too difficult, but probably not trivial. best, kevin On Sat, Feb 7, 2009 at 9:34 AM, Rogan Carr wrote:

Hi Graham,

The only drawback that I can see is that the OS will need to use one of the cores from time to time, so you shouldn't be able to max out both 100% of the time. But if you're not doing much communication with the outside world other than through your soundcard, you shouldn't really see a performance hit, I don't think. I've seen in some multicore supercomputers that you can only run on like 7 of 8 cores per node, because you need the last core to manage system calls and inter-node communications. That said, I don't think that there's such a heavy demand on communications on a two-core stand-alone box that you would see an effect.

Cheers, Rogan

On Sat, Feb 7, 2009 at 5:39 AM, Graham Percival wrote:

...

Hi all,

We're using ChucK as a cheap synthesizer for a bunch of new electronic instruments. To make best use of the dual-core CPU, we're launching ChucK in two separate threads:

$ chuck first-server.ck & $ chuck second-server.ck

This works great (it almost maxes out both cores on a mac mini), although the second instance of chuck complains that it can't bind to port 8888.

Are there any potential pitfalls to this method? I know that we can't (easily[1]) get any communication between these two chuck instances, but in this case we don't need it -- each instrument's synthesis is completely independant of the other one. In CS terms, this problem is "embarrasingly parallel". :)

[1] we could add code to our OSC servers to send messages back and forth via loopback, which isn't precisely "hard", but it's not as easy as everything else we do in ChucK -- this language is awesome. :)

Cheers, - Graham Percival _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

For some information on audio with CUDA see this thread: http://www.nabble.com/CUDA-td19149458.html The idea of using GPU for audio is not impossible, but imposes some very specific limitations to what is possible. I don't think ChucK is at all the language for this, but who knows. :) We should concentrate on getting the VM working on 64-bit computers first imho. Parallelism is not the most important thing to worry about. Graham's use of two ChucK processes is the best way to do it right now, especially since it scales to the use of multiple computers. Steve On Sat, Feb 7, 2009 at 4:36 PM, Rogan Carr wrote:

Hi Kevin,

With CUDA, I would worry about the input/output rate, and the fact that GPUs are "data" parallel. The input/output issue might not be an issue, but the main speedup for CUDA is having your processor blocks all doing the same thing at a time, which would make sense if you had blocks of 32 of the SinOscs running at once, but I imagine that there wouldn't be a performance benefit for normal use. GPUs are sweet for doing math, but I think ChucK is a bit too variable in what it wants to do at any given time.

Cheers, Rogan

On Sat, Feb 7, 2009 at 3:28 PM, kevin wrote:

...

Hi Rogan,

...

Here's a question I have -- if they are both based on the same system clock, will the two instances of chuck stay in sync, time-wise?

i think this becomes an OS dependent question, but the answer should theoretically be yes. since each instance will stay in sync with itself, and they both stay in sync to a reference sample rate, there shouldn't be any drift. if each instance is playing a loop of the same length at the same sample rate, the loops should stay in the same phase relation.

but, interrupts happen, processors time slice, and sometimes you have to wait for i/o (depending on your application in ChucK). it'd be a really fun experiment to collect the sample stream in real time for each and measure the drift on samples and then look at the drift it has on seconds..

since we're on the topic of parallel, has any effort or thought gone into porting the back end of ChucK to a GPGPU like CUDA? The high end ones are expensive, but have 240 cores. fortunately, they made the coding style scalable so that the same code will compile for both a GPU with 24 cores and a GPU with 240 cores (and every available number of cores in between). getting the data to the soundcard shouldn't be too difficult, but probably not trivial.

best, kevin

On Sat, Feb 7, 2009 at 9:34 AM, Rogan Carr wrote:

...

Hi Graham,

The only drawback that I can see is that the OS will need to use one of the cores from time to time, so you shouldn't be able to max out both 100% of the time. But if you're not doing much communication with the outside world other than through your soundcard, you shouldn't really see a performance hit, I don't think. I've seen in some multicore supercomputers that you can only run on like 7 of 8 cores per node, because you need the last core to manage system calls and inter-node communications. That said, I don't think that there's such a heavy demand on communications on a two-core stand-alone box that you would see an effect.

Cheers, Rogan

On Sat, Feb 7, 2009 at 5:39 AM, Graham Percival wrote:

...

Hi all,

We're using ChucK as a cheap synthesizer for a bunch of new electronic instruments. To make best use of the dual-core CPU, we're launching ChucK in two separate threads:

$ chuck first-server.ck & $ chuck second-server.ck

This works great (it almost maxes out both cores on a mac mini), although the second instance of chuck complains that it can't bind to port 8888.

Are there any potential pitfalls to this method? I know that we can't (easily[1]) get any communication between these two chuck instances, but in this case we don't need it -- each instrument's synthesis is completely independant of the other one. In CS terms, this problem is "embarrasingly parallel". :)

[1] we could add code to our OSC servers to send messages back and forth via loopback, which isn't precisely "hard", but it's not as easy as everything else we do in ChucK -- this language is awesome. :)

Cheers, - Graham Percival _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

This makes me wish that there was a way to specify which TCP port the chuck VM listens to when invoked on the commandline. That way I can chuck code at both VMs. I suppose that OSC listeners on both VMs will work properly. I could have nearly doubled the power of my granular synthesis project last semester. *sigh* But you could easily set up an OSC inter-process communication scheme between the two VMs and have one VM act as a slave to the other. UDP is bad for maintaining state, since you can easily lose packets. For the most part, though, I tend to just design the system so that packet-loss isn't that important. Let's here it for the creative mis-use of OSC! -Mike On Tue, Feb 10, 2009 at 6:51 AM, Graham Percival wrote:

On Sat, Feb 07, 2009 at 11:34:37AM -0600, Rogan Carr wrote:

...

The only drawback that I can see is that the OS will need to use one of the cores from time to time, so you shouldn't be able to max out both 100% of the time.

That's fine; 160% (two cores at 80%) is much better than 100%. :)

Besides, I can't reach 100 anyway -- when I get to about 90% usage, chuck decides to drop the audio and the CPU usage falls in half. I suppose I might be able to max out the cpu by doubling the number of (now-silent) ugens, but that isn't very useful for my interactive concert.

Cheers, - Graham Percival _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://michaelclemow.com http://semiotech.org

Well, there you go. :) -mc On Tue, Feb 10, 2009 at 1:43 PM, Tom Lieber wrote:

2009/2/10 mike clemow :

...

This makes me wish that there was a way to specify which TCP port the chuck VM listens to when invoked on the commandline. That way I can chuck code at both VMs.

chuck --port8090

-- Tom Lieber http://AllTom.com/ _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://michaelclemow.com http://semiotech.org