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

[Michael Niedermayer]

On Sun, Dec 14, 2008 at 03:58:26PM -0800, Jason Garrett-Glaser wrote:
> > no, the apparent slowdown of cathedral-beta2-400extra-crop-avc.mp4 is not ok
> 
> Why is this not ok, while disabling filter_mb_fast was OK?  I measure
> a 25% performance increase on a sample here by re-enabling
> filter_mb_fast.  Why is 0.5% here intolerable, but 25% there is just
> fine?

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.
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.

About filter_mb_fast, this function did not work. And that was why it was
disabled, its not a subtile change in the code that makes it slower but
rather a clear disabling because its broken. When it is fixed the speed gain
it provided will be back.

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.

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.
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.

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]


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is not what we do, but why we do it that matters.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20081215/d6335dce/attachment.pgp>