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

[Michael Niedermayer]

Hi

On Sat, Feb 17, 2007 at 06:33:31PM -0500, Rich Felker wrote:
> On Sat, Feb 17, 2007 at 10:56:01PM +0100, Michael Niedermayer wrote:
> > Hi
> > 
> > On Sat, Feb 17, 2007 at 05:52:03PM +0100, elupus wrote:
> > > Xbox 1 CPU
> > > vendor_id : GenuineIntel
> > > cpu family : 6
> > > model  : 8
> > > stepping : 10
> > > flags  : fpu vme de pse tsc msr pae mce cx8 apic sep pge mca cmov pat pse36 
> > > mmx fxsr sse
> > > cpu MHz  : 733.332
> > > model name : Celeron (Coppermine)
> > > 
> > > Harrry Potter Goblet of Fire quicktime trailer 
> > > (harry_potter_goblet-tlr2_h720p.mov) 1280x544. No idea what codec options 
> > > are in use thou.
> > > 
> > > CoreAVC
> > > BENCHMARKs: VC: 130.384s VO:  16.412s A:   0.000s Sys:   1.969s =  148.765s
> > > BENCHMARK%: VC: 87.6440% VO: 11.0323% A:  0.0000% Sys:  1.3237% = 100.0000%
> > > 
> > > FFMpeg
> > > BENCHMARKs: VC: 169.442s VO:  15.894s A:   0.000s Sys:   1.914s =  187.250s
> > > BENCHMARK%: VC: 90.4896% VO:  8.4880% A:  0.0000% Sys:  1.0224% = 100.0000%
> > > 
> > > About a 20% speed gain by using coreavc in this case, quite noticable on 
> > > our limited hardware. Even skipping inloop filter for ffh264 doesn't get it 
> > > up anywhere near the speed of coreavc. I wonder what industry secret they 
> > > are using. 
> > 
> > well i guess that the choice of compiler does have some effect on the speed
> > gcc is not a particulary good choice ... and theres alot more c code in h264
> > decoding then in mpeg4 asp, rewriting it all in asm by hand does of course
> > work but it doesnt seem like the right solution
> 
> imo relying on the compiler to optimize the performance-critical parts
> of your code isn't the right solution. 

this depends on the size of these parts, look in h264.c, rewrite half of
it in asm for every cpu supported ...
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 ...


> do we really want to tell
> people "go use proprietary software if you want this to be fast"? imo
> that's a very bad message to give. aside from that there's also the
> issue that having performance-critical code depend on the compiler
> discourages anyone from trying to replace gcc since it will take a
> while to get comparable optimization..
> 
> my view is that any performance-critical code should be considered for
> asm optimization. however, take that for what it's worth since i'm not
> the one volunteering to write the asm.. :( perhaps you could enlighten
> us on the nature of the c code that's a bottleneck..?

see above, h264 is messy there is alot of code outside MC/DCT/CABAC which
is executed per block or macroblock the whole mb loop almost certainly
doesnt fit in the L1 code cache which is likely one serious bottleneck
especially for the crap tracecache P4 which is limited to 1 instruction
per cpu cycle if the stuff isnt in the code cache ...
the luma MC code alone at -O3 was something like 70kb thats also why its
faster at -O2 or with disabled inlining as it is now in svn

maybe someone should try benchmarking h264.c compiled with -Os ?


> 
> rereading your message, i get the idea that maybe you're just saying
> the difference between coreavc and lavc decoder could be explained
> away by differences in the compiler, and not that people "should" be
> using intel cc. if so, sorry for getting ot.

yes, iam trying to understand why coreavc is faster iam not advocating
the use of a propriatary compiler or codec though i dont think its just
the compiler ...

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras
-------------- 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/1973dd69/attachment.pgp>