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

Michael Niedermayer michaelni at gmx.at
Tue Jun 7 16:45:10 CEST 2005


Hi

On Tuesday 07 June 2005 14:54, Rich Felker wrote:
> On Tue, Jun 07, 2005 at 09:49:06AM +0200, Guillaume POIRIER 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...
>
> IMO it won't work. adding timer code in the function itself could
> easily change how gcc decides to load the registers/addresses for the
> asm block. Just time the _whole program_ with mplayer -benchmark

waste of time, its not accurate enough to show small differences ...

[...]
-- 
Michael




More information about the MPlayer-dev-eng mailing list