[chuck-users] cheap parallel ChucKing

[Rogan Carr]

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 <vacillates at gmail.com> 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 <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
>
>
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>
>