[MPlayer-dev-eng] Re: Re: PATCH [0/12] CoreAVCDecoder support

[Michael Niedermayer]

Hi

On Sat, Feb 17, 2007 at 10:27:42PM -0700, Loren Merritt wrote:
> On Sat, 17 Feb 2007, Rich Felker wrote:
> >On Sun, Feb 18, 2007 at 01:42:02AM +0100, Michael Niedermayer wrote:
> >
> >>this wont happen and it shouldnt, its the compilers job, this is not
> >>2 pages of code its more like 200 pages of c code ...
> >
> >bleh.. :(
> >is there any sane way to isolate the parts that are actually the most
> >performance-intensive and only write them in asm? or is h264 just THAT
> >idiotic that it has 200 pages of performance-intensive code do to
> >massive overcomplexity?
> 
> If we define "performance-intensive" to be anything that runs 
> per-macroblock, then that makes up 5488 of the 8653 lines in h264.c
> (not counting anything in dsputil since that has already been asmed).
> Of course not all of that is used on every video, e.g. a bunch of code is 
> separate for cabac and cavlc. But all of it needs to be considered for 
> optimization if we want all videos to be faster.
> It can't be narrowed too much farther, since a significant fraction of the 
> cpu-time is spent in code that runs only once per macroblock.

so my 200 page guess is pretty close 200*25=5000

5000 lines of code is a pretty large amount no matter if its to be asm
optimized or some more highlevel optimizations, maybe we could do some
contest where the winner gets a real 10l cola (and all the fame of being
the best) so

the winner could be selected by simply benchmarking
there could be 2 classes (P4 and athlon maybe so 2 winners)

rules could be:
1. code must be submitted as clean patches conforing to svn policy/patch
   submission guidlines (break nothing, seperate cosmetics, ...) and
   1 patch per seperate optimization
2. optimizations should be plain C (that way more people can participate
   and we could do a seperate contest for asm later)
3. code must be under LGPL
4. all conformance bitstreams which did decode correctly must still decode
   correctly (=bit identical) after the patch (ive a tiny script which tests
   that ...)

oppinions, comments?

[...]
-- 
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: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20070218/8fef5392/attachment.pgp>