[FFmpeg-devel] [RFC] H.264/SQV3 separation: h264data.h
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
(BTW the quoted claim above comes from Panagiotis Issaris, not me like
> 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
(*)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