[XviD-devel] [RFC] memcpy thingy

[Christoph Lampert]

On Fri, 31 Oct 2003, Michael Militzer wrote:
> Quoting Christoph Lampert <chl at math.uni-bonn.de>:
> > On Fri, 31 Oct 2003, Edouard Gomez wrote:
> > > "Is every possible improvement commitable ?"
> > 
> > I'd say: "If it's just replacing a few calls to routines by 
> > their optimized versions and function pointers, then yes."
> 
> 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. 

I don't see much use in simply replacing memcpy(), either. But it also
wouldn't hurt to have a "optimal" memcpy() available for the current
platform. The difference AMD/Intel might not be big, but e.g. in the
workstation or embedded world, where we don't have ASM support, it might
be useful one day. Or maybe not...

Anyway, what you say about optimizing the code itslef was, what I meant
with writing a NASMed setedges() instead. A general memcpy() hasn't much
to gain, it would still have to deal with arbitrary sized and alignment
issues.  
For XVID, we should rather identify where memcpy() is used , and with
which parameters (most likely multiples of 16, etc), and then create a
version which is adapted to that.  The same for memset(), where we know
that we just need it to set 128 bytes to 0x00.  I once tried to write a
replacement for this, but it turned out that the kernel's memset() was
already optimized and rather good. Just to know the size in advance
doesn't save that much. 

gruel