Thanks for your responses. This is getting really interesting. 

Thanks also for the link to your paper! And especially for the work on the SDFT. I am beginning to get the point after reading your paper and looking at the example csd. This looks musically very useful!

>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. 

I would prefer to call them "thread parallelism" and "vector parallelism," as "multi-process" is usually understood as meaning one thread per process with multiple processes. But what I am talking about here is multiple threads per process, with multiple CPUs on the same chip.

>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.

Vector parallelism works at the level of, most commonly, vector matrix operations (though not limited to them), e.g. c = A b or c += A b or C += A B. Scaling is thus often limited by the number of elementary multiplications or additions within one vector or matrix operation --- and also limited by the number of elements in the SIMD vector. It can also apply to loops where the compiler can infer data independence.

Thread parallelism works at a much higher level of granularity, typically 1 to 10 thousand machine operations per task. This is roughly the size of a Csound instrument kperiod. But scaling is limited only by CPU count. In the future there will be dozens or hundreds of CPUs on a single chip. There also exists the potential to scale across the network with clusters.

I think this shows clearly that BOTH vector parallelism, and thread parallelism, are essential to the future of software sound synthesis. But ultimately, thread parallelism will scale to higher levels of performance than vector parallelism.

The Intel C++ compiler and performance libraries support BOTH kinds of parallelism. The compiler can automatically vectorize loops. The performance examples show how to use C++ templates to adapt performance library functions with C++ classes, and demonstrate this with audio processing in C++ (an IIR).

I have been thinking for some time that Csound, if it ever gets any money, should invest in a build server with the latest Intel tools and libraries.

>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.

I think the productivity of the approach that we did take shows it is more important to have an API, than to have an abstracted API. However, you are of course right that abstraction and encapsulation are important. 

I think Csound should define, in a formal way, an abstracted and encapsulated API both for clients of Csound, and for scripting Csound, i.e. a new API for controlling opcodes and for creating instruments using those opcodes. I think it would much easier to do this in C++ than in C. 

Another benefit of "thinking in C++" is that SWIG has proved a reliable and effective tool for automatically generating wrappers in many different langauges for C++ code. Therefore, if we did define an 2nd generation API for Csound including instrument construction, we would without much further effort get Python, Java, Lisp, Lua, etc., wrappers as well.

Regards,
Mike




-------------------------------------------------------------------------
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