Use memcpy instead of std::copy

[atn34]

This should give us a small performance gain once we use a glibc recent
enough that memcpy is faster than memmove

[xumengpanda]

I found in [1] that the performance of std::copy is not always worse than std::memcpy.

Do we still expect this to be merged?
If the recent compiler or arch. improvement can ensure memcpy is always better in performance, we may need some guard to choose between memcpy and std::copy based on the versions of compiler and arch.

[1] https://stackoverflow.com/questions/4707012/is-it-better-to-use-stdmemcpy-or-stdcopy-in-terms-to-performance

[atn34]

The reason memcpy can be faster is that std::copy needs to account for the ranges overlapping but memcpy doesn't. That said I think we can just close this for now, I don't think anyone is really bothered by this.