Hi All,

I want to respond to both Richard and Michael's emails in detail but
won't be able to do so until later.  One thing I want to note is the
initial naive multithreaded csound I did:

http://www.nabble.com/Mutlithreaded-Csound-tf3521167.html#a9823048

Particularly the notes about preserving existing Csound processing
expectations that instruments are processed in number order but no
expectation within instances of an instrument number which one will
process first.  We can work with that assumption (which the naive
implementation does) or we will have to analyze all dependencies
(global sigs, zak, bus, UI (FLTK), etc.) and build instrument graphs.
To do the second this could be done either automatically by csound or
by user hints given.  The automated solution would be much more
preferable.

(John and I had some good discussions on all this at LAC this past
spring; it's too bad we can't all meet up somewhere to iron this all
out!)

Does any know what effect it would have to parallelize the work per
instrument instance *and* to implement algorithms in parallel fashion
too?  Would they interfere with each other in any way?

steven


On 9/11/07, Richard Dobson <richarddobson@blueyonder.co.uk> wrote:
> Michael Gogins wrote:
> ..
> >> -build instruments piece by piece in any language that uses csound
> >> -make Csound parallizable (well, makes it easier to do so!)
> >
> >
> > These are the critical elements.
> ..
> > At some point in the not too distant future, 3 years at the LATEST,
> > if Csound cannot run parallel instruments, it will be obsolete. Some
> > of the C++ synthesis frameworks (such as the Create Signal Library)
> > have already begun to address parallel processing.
> >
> > Let us suppose that we are refactoring Csound's internals. My
> > recommendations would be:
> >
> > (I) Rewrite the kernel and basic data structures in C++ and use the
> > standard C++ library template collections to manage lists, strings,
> > and so on.
>
>
> There are at least two fundamental kinds of parallelism - the current
> multi-process kind (supported in e.g. OpenMP, in gcc 4.2 etc), and
> (which may well prove more important for audio processing) large-scale
> synchronous SIMD or vector parallelism. This forms the background to our
> (Bath Uni)  SPV paper (see slides at: http://dream.cs.bath.ac.uk/SDFT).
> The Intel "Polaris" 80-core chip is but one example of the direction the
> industry is taking.  The Cell Broadband Processor (used in the PS3) is
> another, albeit on a much smaller scale. And SSE-type vector processing
> is on an even smaller scale.  The Clearspeed CSX600 chip has 96 parallel
> f/p (double-precision) SIMD cores, and of course multiple chips can be
> run concurrently.
>
> Neither the C nor C++ language directly supports a SIMD programming
> model on this scale, though  C does lend itself to extensions to do so
> (we are already using one such in the Clearspeed "Advance" SDK - another
> example is Berkeley UPC). C++ would appear to be a somewhat worse "fit"
> to such an architecture (at the very least, it would need to be built on
> a parallel C). So if we are truly looking ahead, C++ may not be the
> ideal base from which to evolve a SIMD-parallel implementation of Csound
> (quite apart from the general ongoing debate between the advocates of C
> and C++ per se). SIMD likely offers the route to the greatest
> accelerations on next-generation hardware, but demands a redesign
> fundamentally different in conception from mere object-orientation. We
> may want process and thread-level parallelisation too, but we ignore the
> trends towards large-scale SIMD processing at our peril.
>
> I only have one point to make about the Csound API, as has already been
> exemplified recently - to be a truly future-proof  API, it ~must~ be
> semantically and structurally 100% independent  of any internal Csound
> structures.  The fact that changing internal Csound structs breaks the
> API is not a surprise, it was clearly accepted from the outset as the
> price of getting things done quickly. This would seem to be the thing to
> deal with first, before any consideration of language.
>
> Richard Dobson
>
>
>
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net