The Beowulf idea is pretty good. This would work, of course, only for
systems where threads do not interact but simply sum their results. It would
amount to parceling out a Csound score to separate Csounds and then mixing
the resulting soundfiles. In fact, that sort of approach would be only
moderately difficult to code.

This could work as follows. A master Csound parcels out its score.srt and
orc.srt files, and fires up sub-Csounds, each one on a separate processor or
computer. The sub-Csounds have soundfile output functions that use sockets
to send soundfile buffers back to the master Csound, which acts as a mix
server. The soundfile buffers could even be compressed so that the whole
scheme would be practical over dialup connections.

-----Original Message-----
From: Sean Costello 
To: Michael Gogins 
Cc: CSOUND 
Date: Friday, March 12, 1999 9:45 PM
Subject: Re: Csound Performance on Multiprocessor Intel Systems?


>Michael Gogins wrote:
>>
>> I don't have specific experience with double processor systems and
Csound,
>> but I am a long time Csound user and contributor, and I work as a
>> programmer. I think the story would be that you will not see large
>> improvements in performance using Csound on a multi-processing system
>> because Csound is a single-threaded application. You would see a slight
>> improvement because one processor could devote itself mostly to running
>> Csound, and the other could handle the other things happening on the
>> machine, but this would probably do nothing like double the speed, and
might
>> not even be noticeable.
>
>Bummer.  A dual processor system seemed so attractive - the price of two
>Pentium II 350's is considerably less than a single Pentium II 450.  Are
>there any multi-threaded computer music languages out there? I know
>Quasimodo is, but it doesn't seem to be fully functional as yet.  Is CLM
>multi-threaded? Are there any CLM users out there who can attest to the
>speed differences between CLM and Csound?
>
>> Csound could be rewritten to take advantage of multiprocessing, but the
>> rewrite would be difficult and at a low level; it would involve creating
a
>> pool of threads, from which new instrument instances would receive one.
This
>> would improve performance only if the number of instrument instances was
>> fairly large, because there would some additional processor overhead
>> incurred by requiring each thread to synchronize with the ksmps period,
and
>> to manage the threads.
>
>It sounds like the processing I was doing this week (sndwarp and fog,
>with lots of overlaps) wouldn't be helped by multithreading.  However, a
>pvadd orchestra, with Common Music generated score (i.e. calling a pvadd
>instrument for every bin, via a CM-generated score) would greatly
>benefit from a multithreaded system.
>
>Wishful thinking computer music idea of the day: A multithreaded Csound
>that can run on a Beowulf-type distributed system.  Get a bunch of cheap
>K6-2 motherboards, and have a home "audio supercomputer" for rendering
>sndwarp and pvoc files.
>
>Sean Costello