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

Reimar Döffinger Reimar.Doeffinger
Mon Apr 28 11:22:22 CEST 2008

On Mon, Apr 28, 2008 at 10:59:38AM +0200, Michael Niedermayer wrote:
> On Mon, Apr 28, 2008 at 09:20:19AM +0200, Reimar D?ffinger wrote:
> > 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.
> NIH syndrom? Or what is the advantage
> (more) cache bound -> uintXY_t
> (more) cpu bound   -> uint_fastXY_t

It may well depend on the architecture which of these it is.
Also, e.g. on x86 which one to use very likely depends on which
operations you use. Is it used as an index? Use 32 bit. For most
other things use 8 bit. On some architectures it might even depend
on whether it is used in an addition or a multiplication.
Anyway, this discussion is probably pointless, IMO we'd need some
examples where it makes a speed difference then we will see which
solution makes most sense.

> -- 
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> Awnsering whenever a program halts or runs forever is

Argl. At least in your signature you could write it right :-P

More information about the ffmpeg-devel mailing list