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? Ronald _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
