[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