On Tue, Jan 29, 2013 at 10:38 PM, Albert Cahalan <[email protected]> wrote:
> ...I still think an AB test is proper, especially since bit differences
> could be an improvement, but a perfect match needs no testing.
>
It seems to me that it may be appropriate to use different methods to test
changes to algorithms versus changes to how the code is compiled.
> If values stay in registers, you get 80-bit intermediates.
> If values are spilled to the stack, you get 64-bit or 32-bit
intermediates.
> Unremarkable changes to nearby integer code can change code
> structure, causing or preventing FPU register spills. Any change of
> the compiler version will also change the FPU register spills.
It might be useful when testing changes to algorithms to temporarily use a
floating point library with consistent characteristics (bit length, etc)
even if it is very slow, just to make sure that any Codec2 bitstream
changes are not due to such effects. Once the the algorithm is shown to be
equivalent, the code could be compiled with whatever compiler version,
options, etc result in the best performance and still be considered
"correct" codec2 output, maybe with an A/B listening test as a sanity check.
I took a small step toward this a month or so ago, but for a completely
different reason. I planned to replace "float" and "double" with typedefs,
then provide a way to optionally swap in a C++ floating point library to do
the calculations. The effort stalled when I realized that codec2 is
compiled as C rather than C++ and I couldn't make it call the C++ math
library. I didn't find the configure.ac file and didn't pursue it any
further (if the configure.ac file isn't in the Subversion repo, maybe it
could be added?).
I am working on a Blackfin (16-bit fixed point) DSP. GCC provides floating
point emulation libraries, but they are way too slow to run Codec2
realtime. I wanted to try using the "half" (16-bit) floating point [1]
library from OpenEXR [2] to see how much it would speed things up. Of
course the limited resolution and range of the half-float datatype would
have some effect on the audio quality, but I thought it would be a lot
easier to try than a fixed-point port. I got the library to build and did
some work on the typedefs; I would be glad to share that work in progress
if anyone wants it.
Steve
[1] - http://en.wikipedia.org/wiki/Half_precision
[2] - http://www.openexr.com/index.html
--
Steve Strobel
Link Communications, Inc.
1035 Cerise Rd
Billings, MT 59101-7378
(406) 245-5002 ext 102
(406) 245-4889 (fax)
WWW: http://www.link-comm.com
MailTo:[email protected]
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
