[Ffmpeg-cvslog] r6586 - in trunk/libavcodec: cabac.c cabac.h h264.c

[Michael Niedermayer]

Hi

On Mon, Oct 09, 2006 at 02:52:48AM +0300, Uoti Urpala wrote:
> On Mon, 2006-10-09 at 01:19 +0200, Michael Niedermayer wrote:
> > > On Athlon the C version "*state= c->mps_state[s];" (without the other
> > > redundant C there) is faster than the asm. The difference is small,
> > > around 0.3%, but the times do seem consistent.
> > 
> > with START/STOP_TIMER? without it such small differences are meaningless
> > IMO, they could be caused by arrays or functions ending up at slightly
> > more favorable addresses or such aka systematic error
> 
> Without. It certainly could be some such "random effect". However I
> think the results from START/STOP_TIMER would be an even less reliable
> indicator when comparing which version would be "better in general". The

if i want to
optimize X i need to know if X is faster, not if Y from which X is <10%
is faster, especially if my only way to benchmark Y is very timeconsuming
and inaccurate while i can benchmark X very accurately

and yes, code and data size do matter and their effects could make X faster
while Y would get slower, but if code and data size doesnt increase then this
also doesnt happen and no overall benchmark is needed

also i would suggest that you move this benchmarking disscussion elsewhere
its offtopic here, what would have been on topic where benchmarking
scores from START/STOP_TIMER from athlon&p4 ...

and if you have such a deep dissagreement with me and think your method
of benchmarking is supperior, why dont you use it to optimize some code
somewhere be it ffmpeg or another project?

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is