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

[Baptiste Coudurier]

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.

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

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no