memcpy 与 C 中的赋值答案

【问题标题】：memcpy vs assignment in Cmemcpy 与 C 中的赋值
【发布时间】：2010-09-24 08:27:44
【问题描述】：

在什么情况下我应该期望 memcpys 在现代 INTEL/AMD 硬件上优于分配？我在 32 位 Intel 平台上使用 GCC 4.2.x（但也对 64 位感兴趣）。

【问题讨论】：

有趣的问题！正如您显然关心如何提高内存操作的速度：最近我从开发 pyTables 的人那里读到了压缩在内存传输中的作用：pytables.org/docs/StarvingCPUs.pdf 如那里所述，与他的改进相比，通常使用 memcpy 可能会很慢使用非常快速的压缩器 (blosc)。请仅将其视为高性能的东西！
这个问题比较宽泛。

【解决方案1】：

你永远不应该期望他们胜过分配。原因是，当编译器认为它会更快时（如果您使用优化标志），编译器无论如何都会使用 memcpy。如果不是，并且如果结构合理地小到适合寄存器，则可以使用直接寄存器操作，这根本不需要任何内存访问。

GCC 在内部具有特殊的块移动模式，可以确定何时直接更改寄存器/内存单元，或何时使用 memcpy 函数。请注意，在分配结构时，编译器在编译时知道移动将有多大，因此它可以展开小副本（例如，在行中执行 n 次移动而不是循环）。注意-mno-memcpy：

-mmemcpy
-mno-memcpy
    Force (do not force) the use of "memcpy()" for non-trivial block moves.  
    The default is -mno-memcpy, which allows GCC to inline most constant-sized copies.

谁比编译器本身更了解何时使用 memcpy？

【讨论】：

请注意，相反的情况也可以应用——至少在 GCC 中，较小的常量大小的 memcpy 会被复制指令替换，如果与指向小源和/或目标的指针一起使用不阻止一个或两个被优化到寄存器中。所以：用最简单的代码做任何事情。
你不应该期望一个能胜过另一个。如果您有性能问题，您应该对其进行分析，看看 assignment/memcpy 是否是问题，如果是，请尝试将它们更改为使用另一个，看看是否表现更好。更多的分析，更少的猜测。 ;)
也就是说，鉴于提问者指定了最近的 GCC，我预计“作业将优于 memcpy”也是错误的。但假设不需要强制转换，我同意你使用赋值的建议，因为它会产生最清晰的代码。
@jalf：我完全同意。由于问题是“哪个更快？”，而不是“我应该关心哪个更快吗？”，我认为“无论你做什么，编译器都会处理它”是一个公平的答案，即使从大局来看，真正的答案是可能是“你为什么还要问？” ;-)
永远不要说永远...我们在嵌入式处理器上做了一些工作，该处理器使用软件未对齐的异常处理程序。我们发现结构赋值（使用指针）通常会导致未对齐的异常，而 memcpy 不会。异常的代价非常高，所以在内存不一定对齐的情况下，memcpy 比 assignment 快得多。