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

[Uoti Urpala]

On Tue, 2008-12-16 at 11:48 -0800, Baptiste Coudurier wrote:
> Uoti Urpala wrote:
> > On Tue, 2008-12-16 at 10:55 -0800, Baptiste Coudurier 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.
> >> Could we please see the code ?
> > 
> > I deleted it already - it was just random stuff to add code size. But
> > you can get equivalent effects in a few tries. Just add a global (so
> > it's not optimized away) function in the middle of h264.c and write
> > random stuff there.
> 
> Well, considering the "random" factor is discussed here, I won't take
> words for granted. If you want to make your point valid, give a code
> example.

How would giving a code example affect its validity? Did my description
of the change not give enough information about it? It's not like you
could yourself verify that the particular example I used behaves the way
I said - it's unlikely the random effects would be the same on your
system.

If you want to test the random effects yourself I gave one way to do
that above.

> >>>> if i remove some unneeded code and that results in a 0.5% gain on one machine
> >>>> chances are it also does on most others, its not as if the removial of
> >>>> code will likely make it slower.
> >>> You can expect that removal of useless code won't make things slower _on
> >>> average_. However if the CPU use of the removed code was significantly
> >>> less than 0.5% 
> >> ??? Code was _useless_ so CPU did never _use_ it.
> > 
> > By "useless" I mean both unused code and code which is executed but
> > makes no difference to the computation result.
> 
> I hope and assume this is not the case with current code, so your point
> is void.

Your comment makes no sense whatsoever. What are you trying to say?

You're quoting a part where you seem to confuse "useless" with "unused"
and I clarify what I meant with "useless". From this you jump to
something completely different. What "your point"? Something other than
you quoted? My main point in the thread has been that there are random
changes which mask small real speed changes in benchmarks, but you're
not saying anything sensible related to that either.