[Ardour-Dev] Hello, some tech talk, etc.

[Fons Adriaensen]

On Sat, Jul 07, 2012 at 02:01:00PM -0500, Gabriel M. Beddingfield wrote:
 
> On 07/07/2012 06:15 AM, Fons Adriaensen wrote:
> >Most time seems to go into the float to integer
> >conversion that is part of _sincos->ind(). There
> >is no way to avoid that, except by replacing the
> >sine/cosine lookup tables by real calls to sinf()
> >and cosf(), but that's even worse.
> 
> Based on past experience, I would bet the the problem is *not* the
> float-to-int conversion but a memory access problem (cache miss).
> I.e. when you access some data, it causes the CPU to refresh its
> cache.  In C++, it's easy to hit this problem by accessing a member
> variable of your class (pointer-to-pointer-to-data).

Well, based on past experience and current observations it seems
that the float to int conversion *is* the main CPU-eater here.
There are only two class variables accessed within the loop, the
two filter coefficients _lf_c1 and _lf_c2. Both are effectively
constants, and _sincos isnt' accessed at all in the latest version.
As to other memory use, there is the sine/cosine table (1.25 Kbytes,
randomly indexed), and of course the signal buffer which is accessed
strictly sequentially. And both exist as well in the original code.

The real difference is that in the old code the phase computation
was done entirely using integers:

  fr += df;
  ph += fr;
  k = ph >> 24;

and this could be done in parallel with the floating point
calculations (the complex multiply). Float to int conversion
was done only every 256 samples or so.

In the PLL version almost every line depends on the previous
one even if you unroll the loop, it's a basic problem with
any DSP algo that depends on feedback without delay. It leaves
very little room for compiler optimisation.

Ciao,

-- 
FA

A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)