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

[Michael Niedermayer]

On Mon, Apr 28, 2008 at 09:20:19AM +0200, Reimar D?ffinger wrote:
> 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.

One could always #define it to uint8_t to get exactly what one had before.


> 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

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
-------------- 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/32600afa/attachment.pgp>