If you are going to add inefficiency, then do it where mistakes actually commonly happen. (Eg buffer overruns, including strings, and pointers to memory that has not been allocated or already been freed, including from bad error handling.)

Speed: there are many different ways to do both memcpy and memmove in real world, so one situation doesn’t mean much. Intel processors for example have dedicated memcpy type instructions, and sometimes SSE instruction set. Most modern processors can move 4 bytes much faster than 1.

In summary, memmove and memcpy should be equally faster (otherwise, use another implementation), the overhead of testing if memory overlaps is negligible (but memmove can’t never be faster in real scenarios). So I agree, memmove should always be used preferably over memcpy.

In your example you run memcpy() on uncached memory, memmove() afterwards so it can run on cached memory.

Yes. I guess I didn’t point that out clearly enough in comment #2 and the article. The benchmark isn’t a measure of real-world memmove() vr memcpy() performance.

What is interesting about that benchmark, and why I left it in the article, is that it shows how small (and unpredictable) the performance gains from using the less-safe malloc() generally are. Here I am copying 4194304 bytes of data a hundred times, and changing functions has less of an impact on performance than changing the order they are called in. (The term “premature optimization” comes to mind…)

In some cases using memcpy() matters, but not I think in most cases.

For fairness you should iterate at least once over both of the memory arrays (and write something to every byte in it) before you start any benchmarking.

Yes, I need to warm up the caches. Or make sure they both start cold. But that’s not as easy as just touching every byte once! Each array is twice the size of my L2 cache, so if I wrote to every byte of A, than ditto for B, I’d only have the last half of B in cache. That’s still not fair!

Tom S.

I can’t think of any possible circumstances where memmove could be faster. It should degenerate into memcpy when the blocks don’t overlap.

Here’s a hypothetical one. memcpy is implemented in hand-tuned assembly, and optimized for large chunks of memory. memmove is very simple, less than 6 lines of C (something like my implementation, but with memcpy_{backwards,forward} inlined). But the memmove function is put inline in a header.

Now imagine a loop that copies lots of little data structures.

Invoking memcpy will incur the overhead of a function call, but memmove won’t, because it’s inlined by the compiler. The result: the loop goes faster with memmove. Even if we did inline memcpy, it’s use of naked assembly would prevent the compiler from optimizing the function it was put in — and that would probably be a bigger performance hit.

But I haven’t actually tested this scenario. And I believe that if you don’t test, you don’t know, when it comes to hardware-level optimizations.

memcpy is slow because compilers generally don’t generate great code. If memmove is faster (especialy 40% faster!), it’s because the compiler probably isn’t doing its job (excluding the aforementioned point about warming up the caches). I can’t think of any possible circumstances where memmove could be faster. It should degenerate into memcpy when the blocks don’t overlap. :\

memcpy makes perfect sense to choose as the “natural” method of copying memory: in my experience, most memcpy’s generally occur on two buffers that can’t possibly overlap, and so memcpy is the natural, most sensible, and definitely the best choice for doing the copy. We can all agree that more constraints == more possible optimisation, even if the compiler doesn’t always do it this way. :) Using memmove in these cases wouldn’t be wrong, but it also wouldn’t be good practice. Not much point in adding code to handle situations that can’t possibly occur (excluding, of course, cosmic ray interference).

However! After working at Ericsson in embedded development, I tend to agree with at least considering memmove. We have a lot of subtle problems with memory corruption that could be solved by this, and in a worrying high number of places, we also have _really_ dubious reinvention of the memmove wheel:

> if ((uint32)buf1 + size memcpy()
> else
> strange_memmove_style_code

I guess the obvious bottom line if you’re using C/C++ and using memcpy/memmove is: if can’t use them correctly, then it’s time to move to an easier language. Or time to starting having less coffee and more sleep. ;)

The for-loop ordering thing sounds like bad benchmarking on my part. I should have touched the data first to warm up any caches. I suspect the first iteration of the first loop to run may be taking much longer while data is fetched into caches. That’s why timing memmove first made it slower the memcpy. Mea culpa.

Also, it occurred to me that since restrict is now a keyword in C99, and the compiler might be able to help out a little more with making sure memcpy is being used correctly, memcpy is a less dangerous default choice today.

But it’s still telling, and perhaps disturbing, that memcpy is the cultural choice.

Also, if I swap the order of the for-loops (i.e. do memmove first and memcpy second), I can can also get different results.

Combining the two things, I always get memcpy as the faster run.

(Tested on Intel Core 2 Duo iMac).