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

[Compn]

On Tue, 20 Feb 2007 02:24:16 +0100, 
Michael Niedermayer <michaelni at gmx.at> scribed:

> Hi
> 
> On Mon, Feb 19, 2007 at 12:19:42PM +0100, Dominik 'Rathann'
> Mierzejewski wrote:
> > On Sunday, 18 February 2007 at 14:17, Michael Niedermayer wrote:
> > > 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)
> > 
> > Maybe include AMD64 (in 64bit mode) as a third class here?
> 
> ok, so assuming the relative lack of comments means everyone is so
> enthusiastic they are speechless lets see what needs to be done


i have an idea...

email corecodec people and ask how they do it so fast :)

-compn