Re: [mpg123-devel] fixed point decoders
Brought to you by:
sobukus
From: Thomas O. <tho...@or...> - 2009-05-31 09:29:21
|
Am Sun, 31 May 2009 13:49:11 +0900 schrieb Taihei Monma <tm...@ma...>: > On 2009/05/31, at 4:06, Taihei Monma wrote: > > > fl15.bit is still weird... I should look into more. > > Gah, I made a stupid mistake... The layer2 decoder is correct now, and > all tests pass limited accuracy :) Nice! I see that one basically needs special code for each kind of multiplication... lots of different fixed point numbers. I notice that we managed to get away without having to change the synth code... And earlier discussion: > Thomas: >> Seems like we'd need to add fixed point assembler optimizations to >> catch up (MAD has some assembler stuff, particulary for ARM, too). > > Asm optimization will help, but I think using the same codebase for > both integer and fp decoder is disadvantageous in terms of performance > (of the int decoder). So we are talking of the workhorse parts of layerX.c ... do you think separating that out for fixed point, but leaving the synth code alone, would fly? It would be reasonable duplicating a bit of code there... as long as the tricky stream parsing / dequantization (with all these pointers strolling around in various memory areas) is not duplicated. Currently, the integer code is about 13% slower than generic fpu code here, which could be taken as argument for "hey, floating point math is better", but that may be flawed;-) I wonder how had fpu kernel emulation compares to that. Still would be interesting to test on a i386 with and without fpu, could be that integer is better there (not sure how much fpu speed improved). Anyhow, the state we have now is how it should have been when first introducing the fixed-point hack. We have limited accuracy, that means we can still call it MPEG decoder and that should be fine for 1.8.0 . Alrighty then, Thomas. |