On Tue, Mar 29, 2011 at 09:25:13PM -0700, Ronald S. Bultje wrote: > Hi, > > On Tue, Mar 29, 2011 at 3:23 PM, Oskar Arvidsson <[email protected]> wrote: > > 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. > > The effects of that can be undone by SIMD'ifying it. I don't expect it > to make it a lot faster than the original, but at least it wouldn't > make it slower anymore. I wouldn't worry about this. Jason, Daniel, me > or anyone else can quickly undo this speed bump. > > > Also, h264.c handles pixel size dynamically. > > Is there anything we can do to decrease the speed effect of that?
We could template some of the most important functions. There only need to be two different versions of each of these functions (one for 8-bit and one for n-bit), so the size hit wouldn't be too big. -- Oskar Arvidsson +46 (0)701-766451 [email protected]
pgpmza4agPmvu.pgp
Description: PGP signature
_______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
