当 memcpy() 比 memmove() 更快时，什么是真正重要的情况？

Question

memcpy() 之间的主要区别和 memmove() 的优点是，当源和目标重叠时，memmove() 可以正常工作。当缓冲区肯定不重叠时 memcpy()更可取，因为它可能更快。

让我烦恼的是这个潜在。这是一个微优化，还是有真正重要的例子，当 memcpy() 更快时，我们确实需要使用 memcpy() 而不是坚持使用 memmove()到处都是？

Answer 1

如果编译器无法推断出重叠是不可能的，那么至少有一个隐式分支可以向前或向后复制 memmove() 。这意味着，如果无法针对 memcpy() 进行优化，memmove() 至少会慢一个分支，并且内联指令占用的任何额外空间都需要处理每种情况（如果可以内联）。

阅读 eglibc-2.11.1 代码://www.eglibc.org/cgi-bin/viewcvs.cgi/trunk/libc/string/memcpy.c?rev=77&view=markup" rel="noreferrer">memcpy() 和 memmove() 证实了这一点。此外，在向后复制期间不可能进行页面复制，只有在没有重叠机会的情况下才能显着加快速度。

总之，这意味着：如果您可以保证区域不重叠，那么选择 memcpy() 而不是 memmove() 可以避免分支。如果源和目标包含相应的页面对齐和页面大小区域，并且不重叠，则某些架构可以为这些区域使用硬件加速副本，无论您调用的是 memmove() 还是 memcpy()。

Update0

除了我上面列出的假设和观察结果之外，实际上还有一个差异。从 C99 开始，这两个函数存在以下原型：

void *memcpy(void * restrict s1, const void * restrict s2, size_t n);
void *memmove(void * s1, const void * s2, size_t n);

由于能够假设 2 个指针 s1 和 s2 不指向重叠内存，因此可以直接使用 C 实现memcpy 能够利用这一点生成更高效的代码，而无需求助于汇编程序，请参阅 此处了解更多信息。我确信 memmove 可以做到这一点，但是除了我在 eglibc 中看到的检查之外，还需要进行额外的检查，这意味着性能成本可能略高于单个分支这些函数的 C 实现。

Answer 2

最好的情况是，调用 memcpy 而不是 memmove 将保存指针比较和条件分支。对于大型副本来说，这完全是微不足道的。如果您要制作许多小副本，那么可能值得衡量差异；这是你判断它是否重要的​​唯一方法。

这绝对是一个微优化，但这并不意味着当您可以轻松证明它是安全的时，您不应该使用memcpy。过早的悲观主义是万恶之源。

Answer 3

嗯，当源和目标重叠时，memmove 必须向后复制，并且源位于目标之前。因此，当源位于目标之前时，memmove 的某些实现只是向后复制，而不考虑两个区域是否重叠。

memmove 的高质量实现可以检测区域是否重叠，并在不重叠时进行前向复制。在这种情况下，与 memcpy 相比，唯一的额外开销就是重叠检查。

Answer 4

简单来说，memmove 需要测试重叠，然后执行适当的操作；使用memcpy，可以断言不存在重叠，因此不需要额外的测试。

话虽如此，我见过具有完全相同的 memcpy 和 memmove 代码的平台。

Answer 5

当然有可能 memcpy 只是对 memmove 的调用，在这种情况下，使用 memcpy 没有任何好处。在另一个极端，实现者可能假设很少使用 memmove，并使用 C 中最简单的一次字节循环来实现它，在这种情况下，它可能是十次比优化的 memcpy 慢。正如其他人所说，最可能的情况是 memmove 在检测到可以进行正向复制时使用 memcpy，但某些实现可能只是简单地比较源地址和目标地址而不查看为重叠。

话虽如此，我建议永远不要使用 memmove ，除非您要在单个缓冲区内移动数据。它可能不会慢，但话又说回来，它可能会慢，所以当您知道不需要 memmove 时为什么还要冒险呢？

Answer 6

只需简化并始终使用 memmove。始终正确的函数比只有一半正确的函数要好。

Answer 7

在大多数实现中，在定义了两者行为的任何场景中，memmove() 函数调用的成本完全有可能不会显着大于 memcpy()。不过，还有两点尚未提及：

1. 在某些实现中，地址重叠的确定可能代价高昂。标准 C 中无法确定源对象和目标对象是否指向同一分配的内存区域，因此无法在不自发地导致猫和狗的情况下对它们使用大于或小于运算符彼此相处（或调用其他未定义的行为）。任何实际的实现都可能有一些有效的方法来确定指针是否重叠，但标准并不要求存在这样的方法。在许多平台上，完全用可移植 C 语言编写的 memmove() 函数的执行时间可能至少是完全用可移植 C 语言编写的 memcpy() 的两倍。
2. 当这样做不会改变它们的语义时，允许实现内联扩展函数。在 80x86 编译器上，如果 ESI 和 EDI 寄存器恰好没有保存任何重要内容，则 memcpy(src, dest, 1234) 可以生成代码：
   <前> mov esi,[src]
   mov edi,[目的地]
   mov ecx,1234/4;编译器可能会注意到它是一个常量
   CLD
   代表 movsl
   
   这将需要相同数量的内联代码，但运行速度比：
   <前>推[源]
   推[目的地]
   推送双字 1234
   调用_memcpy

   ...

   _memcpy：
   推送ebp
   移动 ebp,esp
   mov ecx,[ebp+numbytes]
   测试 ecx,3 ；看看是否是四的倍数
   jz 四倍数

   四倍数：
   推ESI；无法知道调用者是否需要保留该值
   推送电子数据交换；无法知道调用者是否需要保留该值
   mov esi,[ebp+src]
   mov edi,[ebp+dest]
   代表 movsl
   流行电子数据编辑
   流行ESI
   雷特
   

相当多的编译器会使用 memcpy() 执行此类优化。我不知道有什么可以用 memmove 来做到这一点，尽管在某些情况下 memcpy 的优化版本可能提供与 memmove 相同的语义。例如，如果 numbytes 为 20：

; Assuming values in eax, ebx, ecx, edx, esi, and edi are not needed
  mov esi,[src]
  mov eax,[esi]
  mov ebx,[esi+4]
  mov ecx,[esi+8]
  mov edx,[esi+12]
  mov edi,[esi+16]
  mov esi,[dest]
  mov [esi],eax
  mov [esi+4],ebx
  mov [esi+8],ecx
  mov [esi+12],edx
  mov [esi+16],edi

即使地址范围重叠，这也能正常工作，因为它在写入任何内容之前有效地复制了要移动的整个区域（在寄存器中）。理论上，编译器可以通过查看将 memmove() 作为 memcpy() 执行是否会产生即使地址范围重叠也是安全的实现来处理 memmove()，并在无法替换 memcpy() 实现的情况下调用 _memmove安全的。不过，我不知道有谁做过这样的优化。