Re: Performance of copy algorithm

[jlquinn at optonline dot net]

----- Original Message -----
From: Matt Austern <austern@apple.com>
Date: Tuesday, February 4, 2003 1:40 pm
Subject: Re: Performance of copy algorithm

> On Monday, February 3, 2003, at 10:06 PM, Jerry
Quinn wrote:
> 
> > A couple of observations.  First, memcpy is very
fast - the compiler
> > doesn't have enough optimization to squeeze the
same performance out
> > of the straight loop.  Second, we are taking a
HUGE performance 
> hit by
> > using memmove for this case.  I figured memmove
might be about
> > equivalent, but apparently not.
> 
> This is highly system dependent, and you don't say
what OS you're
> using for your test.

Debian gnu/linux woody+testing (glibc 2.2.5) on an
Intel P4.

 
> I know of one OS where memcpy is slower than a
handwritten loop
> (because memcpy on that system is stupid and
always uses byte
> instructions instead of word instructions), and I
know of another OS
> where memmove is very fast and memcpy is nothing
but an alternate
> name for it.

Ideally __builtin_memcpy should do the right thing
for the platform in question.  On my little fake
test, the right thing seems to be to do an inline
optimized memcpy, but the compiler misses the
opportunity.  Even better would be to recognize the
straight copy loop and optimize it to death (but I
know there are many impediments to that goal).

Hmm, I didn't try -funroll-loops or some of the
other more advanced optimizations, but it would be
nice to make this as tight as possible.


> It's entirely possible that what you ought to be
doing is improving
> your OS's libc.  memcpy and memmove ought to be
carefully written
> hand-optimized assembly code.  Your tests might
just show that on
> your system nobody has given them the love and
care that they
> deserve.

I would imagine that glibc memcpy has been beaten on
pretty hard.

BTW, what would be involved in getting the compiler
to have a __builtin_stdcopy?  

Jerry