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

Uoti Urpala uoti.urpala
Tue Dec 16 20:09:55 CET 2008


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.

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





More information about the ffmpeg-devel mailing list