Hi, On Tue, Mar 29, 2011 at 10:52 PM, Oskar Arvidsson <[email protected]> wrote: > 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.
That sounds like a good solution. Can you test if that helps any in speeding it back up? Ronald _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
