[Pdmtl] Analyse audio en C?

[Mathieu Bouchard]

On Wed, 20 May 2009, Stephen Sinclair wrote:

> I was curious about Alex's comment only because in my opinion Pd is 
> actually quite close to optimal in this regard... once you connect a 
> chain of DSP blocks, they are essentially just called one after the 
> other, by walking down a list of function pointers.  From my 
> understanding it's effectively as fast as C++ virtual functions.

Yes, or a bit faster, even, but there are lots more time spent reading 
signals from RAM and storing them back to RAM, even if you have a good 
cache. This is even more obvious once you try accelerations like MMX/SSE, 
and it even becomes a big bottleneck. In that case, the solution is to 
merge operations together so that less read/writes need to be done. You'd 
start with the most common operation sequences. For example, if a bunch of 
[*~ constant] followed by [+~] all of it together is a very common 
operation (it is), then you can replace it by something all-in-one (which 
has already been done).

The alternative is to make a compiler for patches that can take advantage 
of that. However, not only it requires the source code of all DSP classes 
you might put together, it also requires them to be formatted using C 
macros in such a manner that the compiler can pick up pieces and glue them 
together. (I suppose that this compiler would in turn use GCC). Let's call 
this beyond our reach for the foreseeable future. (!)

> One step better is if you don't need to dereference a pointer, i.e., 
> call a function directly (like non-virtual functions, or normal C 
> functions), and one step better (the best possible) is when functions 
> are inlined, which removes the function call overhead completely.

I said the above because even if you compile a bunch of direct calls to 
the DSP functions of Pd, it won't save much time, even if GCC has the 
luxury of being able to inline them, and does. You need to be able to 
remove the massive read/writes to get a significant gain, unless you need 
to have a very small block size (as in your STK example).

  _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec