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

[Michael Niedermayer]

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
you suggested?


> 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.

yes


> 
> > -- 
> > 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
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080428/033786b5/attachment.pgp>