[Stk] fast time domain filter implementation

[Stephen Sinclair]

Emile Vrijdags wrote:
> In response to Steven and Immanuel
>
> The problem is that the profiler (vtune) requires the project to be 
> built in debug mode (afaik: I've been using it since last week), and no 
> optimizations are present. So I probably have a distorted image of the 
> performance of that function.
>   

Ha, I thought that might be it.
I think a lot of template code in C++ gets *much* more optimized with 
even the smallest optimization setting.  That said, of course it's 
possible that the Vector class isn't the _most_ efficient thing that 
could be used, since it inserts a functional call before the array 
look-up, not to mention that it will always check for out-of-bounds 
access, etc.  But I think as soon as that function call gets in-lined 
the performance shoots way up.

> In my full application using opengl in multithreaded environment (opengl 
> renderloop, an update filterparameters loop, and the stk callback loop) 
> there is an even more significant performance gain between vs2005 and 
> intel compilers. I can use about double the amount of filters before the 
> audio starts to be chopped up.
>   

That's interesting actually, I remember now that when I first compiled 
my STK Piano program on Windows, I got _very_ choppy audio and was a 
little freaked out by the CPU meter, until I turned on the optimization 
flags--so I guess I've noticed this too.  Comparatively I had never 
noticed this problem on Linux, so I guess GCC does a better job than VS.

If you want to continue your comparison a good test case might be to try 
GCC under Cygwin and/or mingw.

Keep in mind that the tick() function in STK is called on every sample 
for every ugen, so this is always going to be less efficient than 
vectorized code.  On the other hand, it makes it possible to do things 
with single-sample delays (like waveguide modeling) that is impossible 
otherwise.  Call it a trade-off.


Steve