Re: [fluid-dev] Floats and doubles, simd and interpolation

[Element Green]

Hello David,

On Mon, Nov 22, 2010 at 12:17 AM, David Henningsson <address@hidden> wrote:
> Just a short dump of what's been on my mind the last few weeks...
>
> Yesterday, I tried to chase down a bug I discovered - I rendered a song but
> a few notes were slightly out of tune, but only when using floats, not when
> using doubles! I never bought that doubles should sound better than floats -
> floats has 24 bits of mantissa precision, that's the best you can get out of
> a soundcard anyway, and since all 24 bits soundcards have a noise floor that
> make them no more than 20 bits anyway (right?), floats should be enough,
> even given some rounding errors. (Not to mention all the analog components
> after the DAC...)
> I also doubt that anyone would hear the difference between 440.000 Hz and
> 440.001 Hz, if the error is that way. So it must be a bug somewhere.
>
> While looking at that I saw that the interpolation routines has conversions
> to and from double (not fluid_real_t), so I suspect that could be why some
> people claim that doubles are faster than floats in some cases.
>
> So the reason I like floats is that with SSE, you can process 4 floats
> simultaneously, but only 2 doubles. From running a perf I know that 2/3 of
> the time (for my testcase) was spent in the interpolation routine. Can we
> SIMD:ize that, we might get 3-4x speed improvement, that's at least what I
> hope for.
>
> There is a library called "ORC", anybody heard of it? You write some
> pseudo-assembly code, and on first run ORC translates it into SSE, MMX,
> Altivec, etc, or plain old C depending on your hardware. I think it sounds
> interesting, and was hoping to see if I could make a test soon, but then I
> got busy trying to find that bug instead.
>
> // David
>

There was some work done in the past by Markus Nentwig in the area of
SIMD and the interpolation routines.  Unfortunately it did not provide
a very substantial gain.  Perhaps this should be revisited though,
since there is the possibility it wasn't coded optimally.  We could
probably search through the SVN log to find the code though as a
basis.  I think its based on some macros I copied from the MPlayer
source code, if I remember correctly.

ORC, does indeed sound interesting.

I wonder what is causing the bug you described though.  If we could
setup a reproducible file rendering case it would probably help track
down the problem.

Element