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

[Uoti Urpala]

On Wed, 2008-12-17 at 01:15 +0100, Michael Niedermayer wrote:
> On Wed, Dec 17, 2008 at 01:39:57AM +0200, Uoti Urpala wrote:
> > On Tue, 2008-12-16 at 22:43 +0100, Michael Niedermayer wrote:
> > > On Tue, Dec 16, 2008 at 10:54:35PM +0200, Uoti Urpala wrote:
> > > > 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:
> [...]
> > You: How is it known that small speed changes are not consistent across
> > machines?
> 
> i did not ask this.

I think that is an OK way to paraphrase the discussion around your "What
evidence..." to Panagiotis Issaris. It's obviously not meant to be an
exact quote.

> You claimed that small speed changes behave completely random across machines.

Essentially yes.

> I pointed out that you had no evidence for this claim and where presenting
> your wild guesses as facts.

False. The claim was based on the fact that you can see how "random"
effects affect the performance even on individual machines, and the
changes are triggered by differences smaller than the typical
differences between machines. That does not require any "wild guesses".

> this has mislead ffmpeg developers in beliving these claims and could
> damage the quality of the project, thus i strongly suggest you back your
> claims up or say that you are sorry for making such baseless claims.

I think I have already explained the reasoning. You can see that
irrelevant changes randomly affect the performance of a binary, and also
combine with the additional effect of applying a patch so that a patch
can be "harmful" but after an irrelevant change elsewhere adding it can
be "beneficial" or the other way around. I have personally tested that
to some degree with the h264 decoder in particular on two different
systems.

> > Me: You can see that the speed is affected by random effects like this
> > even on a single machine.
> 
> > You: How does that show all the machines do not behave the same?
> 
> I did not ask this
> first, because the way its worded would implicate that you did show a
> random effect on a single machine, you did _NOT_ show this to begin

Does your claim "not show" mean anything else than that there's no way I
could strictly speaking "prove" I really ran the test I said I had run?

> with. You _claimed_ to have found that _DIFFERENT_ code was executing
> at different speed. This is not disputed though strictly you even refused
> to provide any details about what exactly you tested.

Actually the example I gave was adding completely unused code to h264.c.

> how that now relates to a random effect on a single machine is entirely
> in your head it seems, the following step:

It shows that the performance of the binary depends to some degree on
small details such as the existence of unused code somewhere (and exact
length of rarely used code, etc). That means it has an essentially
random component since you can't control all the relevant variables with
enough precision.

> > Me: Once we know there's a random component it's unlikely all the
> > machines would get the same random result isn't it?
> 
> its not hard to proof anything based on a false assumtation.

What exactly are you calling false? Are you saying that the performance
of the h264 decoder has no noticeable dependence on small details that
are going to differ between almost every version and machine?

> > What I said on IRC was that a 0.28% change in the h264 decoder tells
> > essentially nothing. A 0.28% slowdown in a benchmark is not a much

> An interrestingly convoluted way of saying you were totally wrong

I still don't think a 0.28% benchmark change tells anything significant.
So what I said earlier was not wrong, and I did not say it was.