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

Baptiste Coudurier baptiste.coudurier
Tue Dec 16 21:32:56 CET 2008

Uoti Urpala wrote:
> 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?

You know, what is called "proof".

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

What are you trying to say here ?
That no benchmark ever can be trusted, because it has everything has
random effects on every system ?

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

Im saying that your point is void because the current code is assumed to
not contain anything useless, and adding "useless" code would be stupid,
but I thought mentioning this would be useless as this is obvious.


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

More information about the ffmpeg-devel mailing list