[Ffmpeg-devel] ac3enc.c modifications

[Rich Felker]

On Thu, May 19, 2005 at 09:53:33PM +0200, Michael Niedermayer wrote:
> both float and int should be supported, there are people with cpus where float 
> IS faster then int

This is only possible if the cpu has a horribly botched integer
implementation. However I have no objection to supporting both if it
can be done without bloat or slowdown for the integer case, but i'm
seriously doubtful that float is ever faster than a well-optimized
integer implementation, especially when the final output will be
integers.

> and int generally requires some care to avoid overflows 
> while maintaining good precission which will result in some shifts the float 
> implementation doesnt need
> 
> just look at multiplications if you have fixed point ints with n and m 
> fractional bits a simple a*b will have n+m fractional bits that would very 
> quickly need some right shift and even if you do a right shift immediatly it 
> will seriously limit precission, now you can do (a*(int64_t)b)>>32) and hope 
> that the cpu architecture has a fast instruction for that and that the 
> compiler is smart enough to use it, but still its quite limiting

Multiply inherently doubles the number of bits, yes. Any sane cpu
design recognizes this, and has an output operand twice the size of
the intputs. If the compiler is too broken to realize that the input
operands are only 32 bit when you cast them up to 64... :(

> for example if you multiply with a constant which is the most common use of 
> multiplications and you want to maintain the number of fractional bits then 

Float doesn't do this; why should fixed point implementations?
Multiplying inherently changes your scale, so you should use a
different appropriate number of fractional bits afterwards.

Rich