[FFmpeg-devel] [PATCH] Faster CABAC H.264 residual decoding
Mon Apr 28 11:36:30 CEST 2008
On Mon, Apr 28, 2008 at 11:22:22AM +0200, Reimar D?ffinger wrote:
> 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.
And what would a ff_typeXY or such help here? Or did i misunderstand what
> 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
I could but then it would not be _my_ signature ;)
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Everything should be made as simple as possible, but not simpler.
-- Albert Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel