This is the mail archive of the
mailing list for the libstdc++ project.
Re: Performance of copy algorithm
- From: jlquinn at optonline dot net
- To: Matt Austern <austern at apple dot com>
- Cc: libstdc++ at gcc dot gnu dot org
- Date: Tue, 04 Feb 2003 17:43:02 -0500
- Subject: Re: Performance of copy algorithm
----- Original Message -----
From: Matt Austern <email@example.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
> > 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
> 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
> I know of one OS where memcpy is slower than a
> (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
> hand-optimized assembly code. Your tests might
just show that on
> your system nobody has given them the love and
care that they
I would imagine that glibc memcpy has been beaten on
BTW, what would be involved in getting the compiler
to have a __builtin_stdcopy?