[MPlayer-dev-eng] swscale question
Michael Niedermayer
michaelni at gmx.at
Tue Oct 30 20:23:36 CET 2001
Hi
On Tuesday 30 October 2001 19:14, Nick Kurshev wrote:
> Hello, Michael!
>
> I've looking on your code and have some question for you:
> 1. For what reason you've added "normal" asm optimization?
> #endif
> //NO MMX just normal asm ...
> asm volatile(
> "xorl %%eax, %%eax \n\t" // i
> "xorl %%ebx, %%ebx \n\t" // xx
> "xorl %%ecx, %%ecx \n\t" // 2*xalpha
> "1: \n\t"
> "movzbl (%0, %%ebx), %%edi \n\t" //src[xx]
> "movzbl 1(%0, %%ebx), %%esi \n\t" //src[xx+1]
> For what cpu it's optimized (pent, pent-mmx, ppro or k6, k7)?
hmm, mine ;) ... (P3 at 500)
it was written before the mmx2 code
> IMHO we should not ignore optimizing possibilities of gcc which
> produces enough optimized code for targeted architectures.
> (Even if you've win 1-2% on your cpu it doesn't mean that
> we'll get the same speedup on every cpu).
i fully agree with useing gcc if it outputs sane code, although a simple
./mplayer -vo x11 -pp 0 -zoom -xy 2 ~/ff.mpg -benchmark shows:
gcc: 16.532 sec
asm: 12.467 sec
looking at the output of gcc, it seems there is at least one partial register
stall (5 cycles loss on ppro,p2,p3)
the c functions are not really optimized (this one does 2 multiplies
allthough 1 would be enough, ...)
gcc neither used add/adc, ...
> From other side - togheter withh gcc exists other compilers which
> can produce better code that gcc now, but I hope that in the
> future gcc will be improved enough for that.
>
> 2. Althrough your code was enough well scheduled but first lines could be
> scheduled better (in addition they are first thing which watch everyone) :
i cant see a difference with -benchmark, did u try it?
...
>
> Friendly! Nick
Michael
More information about the MPlayer-dev-eng
mailing list