Andre McCurdy armccurdy@yahoo.co.uk wrote:

If you have them, I would also be interested in figures for MAD which compare multiplies using FPM_64BIT, a version which truncates the LSBit (eg FPM_ARM), and FPM_APPROX.

It's probably a good thing you asked for these, because I found out I had broken support for FPM_64BIT and FPM_APPROX. :-/

They're fixed in 0.11.2b, due shortly, along with a host of other improvements including better FPM_APPROX and SSO accuracy.

Here's what I get for compliance, looking only at the rms level against the Layer III compliance bitstream...

First, the situation with 0.11.1b:

without SSO with SSO FPM_64BIT 7.049e-02/N 4.945e-05/L FPM_INTEL 9.000e-08/F 4.946e-05/L FPM_APPROX 7.049e-02/N 1.901e-04/N (none) 3.766e-05/L 4.945e-05/L

/F means full compliance, /L means limited accuracy, /N means not compliant.

Now with 0.11.2b:

without SSO with SSO FPM_64BIT 5.580e-08/F 1.007e-05/L FPM_INTEL 9.000e-08/F 1.008e-05/L FPM_APPROX 6.800e-05/L 6.775e-05/L (none) 1.037e-07/F 1.008e-05/L

N.B. FPM_ARM produces the same output as FPM_INTEL; I haven't checked FPM_MIPS or FPM_SPARC lately, but they should also be the same.

With FPM_ARM and Andre's ARM patch, the rms level improves to 6.921e-08 without SSO.

Curiously, FPM_APPROX is more accurate with SSO than without.

FPM_64BIT is somewhat more accurate than the CPU-specific versions, probably because it performs rounding. It is also probably slower for the same reason.

The slow C version of the FPM routine is apparently lacking in some accuracy; I may revisit it at some point but it doesn't seem too important.

I'll post 0.11.2b either tomorrow or later today.

Cheers, -rob