[FFmpeg-devel] [RFC] H.264/SQV3 separation: h264data.h

Uoti Urpala uoti.urpala
Mon Dec 15 03:52:34 CET 2008


On Mon, 2008-12-15 at 01:33 +0100, Michael Niedermayer wrote:
> One has to weigh the advantage against the disadvantage
> 
> here, advanatge, of the change is largely cosmetic
> disadvantage is a 0.5% speed loss, after 10 such changes our decoder is 5%
> slower.

Real speed change yes, but 0.5% change in benchmark result tells you
very little about whether speed changed or not ("real" speed could have
become faster or slower).

> And thouse claiming randomness, well, if its random a different gcc version
> shouldnt show the speed loss and in that case it could be reconsidered, though
> again if 4 out of 5 gcc versions show the speed loss it still doesnt look too
> good nor random. But if 2 out of 4 are slower and 2 faster it would be ok.

I haven't tested this particular change, but I have benchmarked various
irrelevant changes to the h264 decoder earlier and they typically have
effects at the percent or couple level (even when each resulting binary
is benchmarked enough that the randomness caused by per run variation is
much less).

> also ive developed and optimized other codecs like the mpeg4 variants based
> on this concept and they are pretty much the fastest around. Had i applied
> random changes that made the code by 0.5% slower they would not be as
> fast.

But benchmarking is not a reliable way to tell whether the h264 decoder
really became 0.5% slower (at least you'd need a big collection of
various possible "irrelevant" code changes and of compiler versions to
benchmark against).

> doing optimzation well is not a matter of asking why its slower and then
> ignoring it when its not obvious, its a matter of picking the faster.
> Like in evolution, the question is not why some species is consistently
> 0.5% less effective than another just that it is.

Evolution relies on a large collection of individuals with varying
traits. It wouldn't work if it abandoned a trait when one individual
with it dies.

> if one can find out why its 0.5% worse one may be able to find a solution
> that makes the wanted change and avoids the speedloss, but if not the
> change isnt ok.

What about all the other changes you applied that made it 0.5% slower?
Since the speed varies back and forth with most changes, about half of
them (other than clearly beneficial optimizations) have made it slower,
and a significant portion of those by 0.5% or more. Even changes in
other decoders can affect h264 speed that much (probably some memory
aliasing effect).

> and about other random changes making the code 0.5% faster, these are VERY
> welcome, adding a noinline here, and inline there and such, really!
> [of course only when the patch is clean and doesnt mix unrelated stuff]

Such random changes have about 50% chance of being beneficial on any
other combination of compiler, machine and exact FFmpeg source used. The
changes I tested probably wouldn't have the same effect in ffplay as in
my test under MPlayer. The results really are essentially "random".





More information about the ffmpeg-devel mailing list