[XviD-devel] [RFC] memcpy thingy

[Edouard Gomez]

Christoph Lampert (chl at math.uni-bonn.de) wrote:
> 1% on what plattform?  Windows, I guess?

No, GNU/Linux. Hopefully, my PC  will probably never run Windows (except
in a bochs session).

> I find 1%  just by memcpy rather much, considering  that the OS should
> have MMX-optmized memcpy already (Linux does, Windows I don't know).

The OS may have optimized  routines (see string.h, memcpy.c and mmx.c in
arch/i386/), but  they are  not part  of the user  space calls  that the
kernel exports (iirc).  That's why usually the libc defines its own, and
gcc compilers provide builtin versions (iirc).

> If it's really close to 1%,  we could of course add a function pointer
> for memcpy just as for DCT etc.  It's not much of a deal to change the
> few calls.

My patch does that. Of course all non ia32 platforms just use plain old
memcpy functions.

> On the other  hand, if memcpy really needs a  nontrivial part of time,
> it might be better to write e.g. a special NASMed setedges() routine.

setdges  has proved  to  be quite  CPU  eager for  doing  so few  useful
work. Emulating edges is not  that slow too, ffmpeg performs rather well
and is able to  not use edges. Btw i don't know  how it's implemented so
don't think i'm saying "go for emulated edges"

But anyway, i can achieve a bigger speed improvement just compiling XviD
for my specific arch/cpu and  omiting the frame-pointer and removing PIC
code generation. That's why i ask, "is it worth it ?" :-)

Or may I ask it this way:
"Is every possible improvement commitable ?"

-- 
Edouard Gomez