[XviD-devel] Inlined ASM code again
skal
skal at planet-d.net
Thu Aug 21 10:33:16 CEST 2003
Hi all,
On Wed, 2003-08-20 at 20:38, Christoph Lampert wrote:
> On Wed, 20 Aug 2003, Edouard Gomez wrote:
> > Using no inlined code:
> > [edy at leeloo:x86_asm] $ ./a.out
> > Cycles per call: 40 (up to 42)
> >
> > Using inlined code in a simple loop (see [1]):
> > [edy at leeloo:x86_asm] $ ./a.out
> > Cycles per call: 12
>
> For me it was 48 vs. 11.
>
> Actually, it was also 11 when completely removing the call! As could be
> expected, the number was the pure overhead, the call itself was analyzed
> to not modify any mem and then simply removed...
> When I prohibited that, cycle count went up to 27.
>
> Then I modify the loop to not calc SAD from the same position again
> and again, but keeping one pointer fixed aligned and one cycling through a
> 1 MB area with stride 720 (not "realistic", but "more realistic"), I get:
>
an even more realistic test would consist in adding
pile of code before and after the loop, so that
unrolling is made less easier. Etc...
(btw, takling 'bout unrolling magic, i always recommend this
text: www.agner.org/assem/ => pentopt.zip )
But eventually, the only conclusion you may end up
with, when inlined gcc gets better than NASM, is...
that this latter could have been better written.
Same conclusion if gcc manage to better re-order code
behind your back (gee! i hate compilers doing stuff
i'm not aware of).
So, i think this kind of tests are a little misleading.
And just like any tests, you can always tune them to
give the answer you want ;)
It seems to me the real question is: do you think inlined
ASM is more practical/portable? The answer sure is yes,
but let me recall my point of view -i already gave here-:
once ASM is inlined with intrinsics, you can consider
it "carved into stone". Coding in ASM is already painful,
but intrinsics makes it even harder to play with, compared
to NASM-like separate file, with short instructions, fast
compilation, macros, etc...
Just my 0.019999999...
bye!
Skal
More information about the XviD-devel
mailing list