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

[Rich Felker]

On Tue, Jun 07, 2005 at 04:45:10PM +0200, Michael Niedermayer wrote:
> 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 ...

If the difference is too small to measure, it's too small to make a
difference as to whether someone can play a movie or not.. This is
what I expected anyway.

Rich