On Tue, Mar 29, 2011 at 11:06:50PM +0100, Måns Rullgård wrote: > Oskar Arvidsson <[email protected]> writes: > > > Hi, > > > > On Tue, Mar 29, 2011 at 05:48:45PM +0200, Oskar Arvidsson wrote: > >> Also, I've done some basic benchmarking on how this patchset affects > >> 8-bit decoding. I'll post the data from those runs separately. > > > > Upon request by mru I extended the benchmark somewhat. I didn't bother > > doing this with oprofile though. > > > > 10 runs decoding 8-bit h264: > > > > | Before | After > > ------------------------------------------- > > | 8.629 | 8.726 > > | 8.606 | 8.709 > > | 8.619 | 8.716 > > | 8.609 | 8.683 > > | 8.619 | 8.706 > > | 8.606 | 8.786 > > | 8.643 | 8.659 > > | 8.626 | 8.653 > > | 8.613 | 8.673 > > | 8.629 | 8.733 > > ------------------------------------------- > > Avg: | 8.62 | 8.70 > > Stddev: | 0.012 | 0.040 > > ------------------------------------------- > > Are those user time or elapsed time?
user > > > From the table follows that the patchset gives a speed penalty to 8-bit > > h264 decoding of about 1% (for this clip). > > Note that the change is only slightly greater than one stddev of the > after numbers. It might be worthwhile testing another clip with > different characteristics. good point. > Do you have any idea why it got slower? For one, chroma dequant can't be inlined anymore. Also, h264.c handles pixel size dynamically. -- Oskar Arvidsson +46 (0)701-766451 [email protected]
pgp6Y195M1Bxw.pgp
Description: PGP signature
_______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
