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.
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?
Cheers,
Rogan
On Sat, Feb 7, 2009 at 5:39 AM, Graham Percival
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