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

Michael Niedermayer michaelni
Wed Dec 17 01:15:29 CET 2008


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:
> > > > > > >> On Tue, Dec 16, 2008 at 11:01:34AM +0100, Panagiotis Issaris wrote:
[...]
> You: How is it known that small speed changes are not consistent across
> machines?

i did not ask this.
You claimed that small speed changes behave completely random across machines.
I pointed out that you had no evidence for this claim and where presenting
your wild guesses as facts.

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.


> 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
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.
how that now relates to a random effect on a single machine is entirely
in your head it seems, the following step:

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


[...]
> > > > 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.
> > 
> > well the split seems to have a rather consistant effect across machines.
> > that is its slower. And peoples reactions, like diego posting a IRC log
> > from you shows that you made people belive that your claims where related
> > to the actual code changes.
> 
> 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
> bigger sign of real slowdown than a 0.28% benchmark speedup would be. So
> my claims there were about the interpretation of that one benchmark
> result. After hearing of Diego's -0.28% result alone there was little
> reason to expect the speed change to be consistently up or to be
> consistently down. Only after knowing of my -8% result too was there
> evidence of some effect that might make results consistently slower.

An interrestingly convoluted way of saying you were totally wrong

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
-------------- 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/20081217/dfb46072/attachment.pgp>



More information about the ffmpeg-devel mailing list