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

[Michael Niedermayer]

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:
> > > > >>> 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?

Please refrain from randomly cliping parts of the discussion silently, and
by that placing what i said under some different text.
Also please refrain from putting words in my mouth, or replying in such
a way as to pretend that I made some ridiculous claim that you now would
try to correct.


Also please refrain from trolling in the style of:
U: > Its always A, thats fact, known by everyone
M: no its not always A

M: > no its not always A
U: Do you really belive its never A?



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

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.

If OTOH you really are just talking about hypothetical changes that have
not happened (or that you dont know or will not name) then i really must
ask you to leave as that would be off topic.

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

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates
-------------- 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/20081216/017f06d0/attachment.pgp>