Re: [Nyquist-users] Nyquist and multiple CPU's

[Evan L. <Ev...@Co...>]

On Sun, 2006-01-08 at 12:50 -0500, Roger Dannenberg wrote:
> Nyquist does not have any way to take advantage of multiple CPU's other than
> that audio output and file I/O might be handled on a separate processor
> automatically by the OS.

Well, my only machine that has more than 1 CPU is a Sparc running a
Linux 2.6 kernel.  File IO is handed off to the SCSI controller, and
there isn't much else that can be done.

> In some ways, Nyquist is ideal for multiple CPU's because of its mainly
> functional language approach with minimal side-effects and shared state. All
> this exposes parallelism, e.g. every time you write (SIM (A) (B) ...) you
> are essentially saying that (A) and (B) and ... can run in parallel.

Yes, and this is the basis for many languages that support automatic
parallelization (sp?), but I'm afraid my LISP is more than a little
rusty, so I'm not aware if there is a version of LISP that supports such
a thing.

> Unfortunately, the lazy evaluation implementation and the hooks that (A) and
> (B) have into the shared Lisp heap and garbage collection would make a
> parallel implementation quite hairy (at least for me -- although Nyquist has
> settled down after a lot of use, I'm still finding obscure and rare little
> bugs in the single-threaded implementation!).

Understandable.

> The rationale for multiple processors would be speed. There may be other

Well, there are some cases when 2 CPUs are faster than 1 CPU that is
twice as fast, and vice versa.  I'm thinking speed isn't necessarily a
concern as much as latency.  While there are always thing here and there
that can be tweaked, parallel tasking combined with proper locking could
allow playback to start earlier while another task was still calculating
the rest of the sample.

> ways to speed up Nyquist. In particular, Nyquist control-rate signals can be
> interpolated with inline code at the expense of a larger executable. At one
> time, in-line interpolation was used everywhere, but I think I turned it off
> because certain unit generators were getting huge. Probably, some
> performance instrumentation could expose some areas for optimization.

I haven't had a chance to look into the code any, as I've abandoned my
computers this weekend in favor of refinishing my studio monitors.  They
look so much better now.  Next weekend I do the grill covers :)  I do
like the idea of nyquist though, and I really will get around to playing
with it more!  As you can see, its a nice combination of my two main
hobbies :)