[XviD-devel] [RFC] memcpy thingy

Edouard Gomez ed.gomez at free.fr
Fri Oct 31 22:58:50 CET 2003


Michael Militzer (michael at xvid.org) wrote:
> I'd say no. It's not needed to have special AMD optimized memcopy code
> that gives just a very  minor improvement. It seems more reasonable to
> optimize  such code  for  more  platforms (so  generic  mmx code)  and
> instead of  a simple memcpy()  replacement there should be  a specific
> mmx  replacement  for  memcpy  using   code  -  this  should  be  even
> faster.

Hmmm, my code  is not the AMD one,  that is what the doom9  guy did. His
hack was  1/ ugly  2/ not  acceptable in XviD  because of  the copyright
issues.

I  ported _xine's_ memcpy  functions which  are LGPL  or maybe  GPL.  It
provides fast memcpy for x86 (a bit faster than the glibc version), mmx,
and mmx with software prefecthing, and even a sse version but it's a bit
slow for small blocks (~scanline  sizes) whereas mmx versions are always
faster than  the 386 code. They  all take care of  alignment to maximize
throughput, see  the xine  CVS for more  comments about  the improvement
they've made to their routines.

> BTW:  I'd  say that  at  least the  Intel  compiler  (maybe gcc  also)
> automatically replaces  memcpy calls with  specifically optimized code
> (depending on the selected platform).

That's called builtins in gcc.

@gruel:  i don't  understand why  changing the  memcpy would  be  a post
1.0. memcpy  is a trivial  function and  checking if  it's not  buggy is
quite  easy. Be  sure  i've done  all  the necessary  tests before  even
proposing the code here.

-- 
Edouard Gomez


More information about the XviD-devel mailing list