[Pdmtl] Analyse audio en C?
matju at artengine.ca
Wed May 20 14:06:50 EDT 2009
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
More information about the Pdmtl