[MPlayer-dev-eng] [Patch] swscale on gcc4+amd64

[Ivan Kalvachev]

On 6/7/05, Guillaume POIRIER <poirierg at gmail.com> wrote:
> Hi,
> 
> On 6/7/05, Rich Felker <dalias at aerifal.cx> wrote:
> > On Sun, Jun 05, 2005 at 02:06:09PM +0000, Mean wrote:
> > > Hello
> > > The attached patch enabled me to compile postproc/ on amd64 with gcc4
> > > and gcc 3.3.5
> > > Thanks
> >
> > I read the asm diffs and they're mostly trivial. It would be nice if
> > someone could benchmark this too and make sure it doesn't hurt
> > performance, but otherwise I'm ok with it..
> 
> Ivan briefly explained to on IRC me yesterday that ffmpeg featured the
> macros START_TIMER("func_name") and STOP_TIMER("func_name"), which
> prints the figures on the console.
> I think that this will look like something like this:
> 2287 dezicycles in loop_vl_16bit, 1048386 runs, 190 skips
> 
> Problem is: I don't know what all those figures mean: I guess we want
> "dezicycles" to always be at least the same between 2 runs, or lower
> in case the second run is an optimized one.
> As for "runs" and "skips", I'm not sure what they mean.
> 
> Ok now, but where am I supposed to put those timer calls? right
> *before* an ASM block? At the *beginning* of an ASM block...
> 
> So many questions... really sorry for all the trouble.
> --
> I should have invented the tape recorder,
> that way people would have more quotes of
> me to put at the bottom of their e-mails
> -- Benjamin Franklin
> 

You put one START_TIMER before the block you want to benchmark
and STOP_TIMER("name") after it to print the statistic.
The dezicycles are the CPU clock counter difference between start and
stop. The problem is that if the block is large it is very probable
that the process will be interupter and take an much larger time
(executing another process). So these functions calculate an average
and throw away measures that are too big (190skips). Also because of
different cache usage on every run you get different results.

BTW
have somebody used oprofile? there are patches for kernel 2.4.x too.

   Ivan Kalvachev
 iive