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

[Uoti Urpala]

On Mon, 2006-10-09 at 02:46 +0200, Michael Niedermayer wrote:
> 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

The part I don't completely agree with is the "can benchmark X very
accurately" part. If the code is a relatively fast inlined block I don't
feel too confident that putting start/stop timer code around it would
catch its effect on the surrounding function with that high an accuracy.

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

My previous post was just explaining what I did measure, I didn't mean
to start a "benchmarking discussion". If you still want to see the
START/STOP_TIMER results here they are:
asm: 421 dezicycles in get_cabac, 268402720 runs, 32736 skips
"*state= c->mps_state[s];": 368 dezicycles in get_cabac, 268390585 runs, 44871 skips

> 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

I think you interpreted what I said as a more general statement about
benchmarking methodology than I meant it.