From: Christer P. <pa...@no...> - 2002-02-16 18:01:45
|
Hi James! James Courtier-Dutton wrote: > Summary: Use "memmove" instead of "memcpy". > > It is because of the "undefined" behaviour of memcpy when regions overlay > that no kernel or library tries to optimise memcpy for a particular > platform. The reason memcpy is never optimised is because some applications > use memcpy when they should have used memmove. > The glib people do not wish to break these badly behaved applications, so > the solution to this was to only optimise the memmove functions. > To me, this just sounds plainly false. Do you happen to have any numbers to back this up? I mean, if there would be a problem with that "some applications use memcpy when they should have used memmove", why would the library implementor not just have memcpy() use the more restrictive memmove() internally (resulting in identical behaviour and thus performance)? Regarding the statement about glib, I checked out the source and it seems like glibc _does_ provide optimized memcpy() for alpha, i586, i686, ia64, s390-32, s390-64, Super Hitachi, sparc32 and sparc64. A quick inspection of the code furthermore suggests that, contrary to your statements, the glibc memcpy() _does_ take advantage of the undefined aspects of memcpy(), which should actually result in better performance. The glibc memmove, on the other hand, actually seems to use simpler, more generic, optimizations on most platforms. -- Christer Palm |