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

Uoti Urpala uoti.urpala
Tue Dec 16 21:54:35 CET 2008


On Tue, 2008-12-16 at 20:45 +0100, Michael Niedermayer wrote:
> > > Uoti Urpala wrote:
> > > > On Tue, 2008-12-16 at 13:31 +0100, Michael Niedermayer wrote:
> > > >> On Tue, Dec 16, 2008 at 11:01:34AM +0100, Panagiotis Issaris wrote:
> > > >>> Besides that, in my opinion you can't benchmark code on one particular
> > > >>> machine and expect a 0.5% performance loss to say anything about the
> > > >>> codes performance on other machines (other then that the code hasn't
> > > >>> introduced a substantial performance change on similar machines).
> > > >> What evidence is there to support this claim?
> > > > 
> > > > Many known cases where changes that are known not to affect the real
> > > > quality of the code alter performance by more than 0.5%. I just tried
> > > > adding an unused global function to h264.c. The first attempt didn't
> > > > show any quickly measurable difference. Then I made the function a bit
> > > > larger, and now the benchmark ran consistently 0.8% faster. Removing the
> > > > unused function made things correspondingly 0.8% slower again.

> What iam wondering is how a speed effect from random unused code on a
> single machine is related to your claim above of lack of correlations
> between the speed on different machines.

Do you really expect adding an unused function to consistently increase
speed everywhere?

(BTW the quoted claim above comes from Panagiotis Issaris, not me like
you claimed).

> One actual case here, that is the table split showed a slowdown consistant
> across machines, thus contradicting your claim.

Why would it contradict my claim (even if verified to be consistent, I'm
not sure whether there were enough reports for that yet)? I myself
reported a 8% slowdown which is more than the ordinary random variation.
Of course you'll see consistent change _direction_ if there's a big
enough real effect on speed.

What should be rare according to my claim is a nontrivial(*) change
having a consistent small negative or consistent small positive effect
across machines.

(*)mainly meant to exclude changes which have no effect on code
generation or memory layout - something like changing the number of
iterations in a loop could have a consistent effect





More information about the ffmpeg-devel mailing list