[FFmpeg-devel] [PATCH] Faster CABAC H.264 residual decoding

[Reimar Döffinger]

On Mon, Apr 28, 2008 at 01:40:48AM +0200, Michael Niedermayer wrote:
> On Sun, Apr 27, 2008 at 02:09:12PM +0200, Nicolas George wrote:
> > Le nonidi 9 flor?al, an CCXVI, matthieu castet a ?crit?:
> > > > On the advice of #ffmpeg-devel I have made a version with uint8_t
> > > > arrays instead of int.
> > > Don't forget that some cpu (arm for example) don't have native 8 bits 
> > > operation. Everything is done in 32 bits, and 8 bits behavior is 
> > > emulated with extra operation.
> > 
> > I think it may be worth reminding the existence if uint_fast8_t, wihci is
> > the fastest integer type of size at least 8.
> 
> True but is it anywhere different from uint8_t ?
> Anyway iam fine with uint_fast8_t as well, if someone wants to change
> all/most tables in ffmpeg to that _and_ shows that it is faster on at least
> one architecture. (that can be with a #define uint_fast8_t uint32_t or so)

I am strongly against this if uint_fast8_t is indeed 64 bit on x86_64.
And to be honest, I think that *_fast* types should not be used at all,
they simply can never be "fast" always, e.g. if an algorithm is 100%
cache-bound, uint8_t is always fastest, and so only the developer can
know which is the best type for some architecture.
If it makes a speed difference, we will have to do our own
defines/typedefs/whatever.

Greetings,
Reimar D?ffinger