On Aug 30, 1:25 am, Carlo Milanesi <carlo.nospam.milan...@libero.it>
wrote:
> Sada wrote:
[..]
> > Is memcpy() is better than strcpy()?
>
> No.

This was my first thought, too, but I remember reading an article by
AMD back in 2002 that implementation details ain't that simple even on
a "simple" problem like this.
strcpy() must do it's job sequentially front-to-end since it does not
have any idea how much data to copy. A simplified implementation would
be

void strcpy( char* source, char* target ) {
while ( *target++ = *source++ );
}

Some CPUs even have specialized operations to perform this loop in a
single command.

Even so, with memcpy() the order and chunk size in which the data is
copied is much more free. A greater chunk size, i.e. using 64-bit
transfers instead of byte transfers, or use multi-byte MMX CPU
operations, greatly improves performance. What really surprised me,
reordering the data transfers to a non-intuitive sequence (AFAIR,
working cache buckets in-order, each bucket's data reverse order) is
an even greater optimization. This scheme makes sure data is always
read from the CPU's first level cache and burst-filling the cache
happens in the background while the current bucket is processed.
If I remember properly, an AMD Athlon did the most optimized memcpy()
presented in the article about seven times faster than the simplistic
approach as in the strcpy() above.
strcpy() is much more resistent to such optimizations.
Multi-core CPUs, like the Core i7, or SIMD machines should add another
level of speedup. (E.g. on a 256KB transfer let 256 cores of a massive
parallel machine transfer 1KB each.)

Conclusion, both strcpy() and memcpy() are O(n) for data size n but
the extra information memcpy() receives gives it the edge. A strlen()
followed by a memcpy() instead of a single strcpy() is no alternative,
though... :-)

best,

MiB.



--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]