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

[Michael Niedermayer]

Hi

On Tuesday 07 June 2005 17:55, Rich Felker wrote:
> 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.

small speed losses accumulate, just add a nop into some often executed asm 
block, i doubt you will be able to notice that with -benchmark, but if you 
add 100 nops you probably will notice it
for comparing the speed of some code START/STOP_TIMER is much better then 
-benchmark, just try it while listening to mp3 or running some other cpu 
eating stuff, START/STOP_TIMER will be practically unaffected by it if the 
tested code is short
now if someone seriously wanted to test that code in such a way that its 
accurate and unaffected by gcc (silly and not worth IMHO) then they could 
edit the asm code after compilation to add some benchmark code

now back to the topic, feel free to apply the patch if u want

[...]
-- 
Michael