[chuck-users] cheap parallel ChucKing

[kevin]

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 <rogan.carr at gmail.com> 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
> <graham at percival-music.ca> 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 at lists.cs.princeton.edu
> > https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
> >
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20090207/2a6d6943/attachment.htm>