C语言中的memcpy与赋值

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

你绝对不应该期望它们的性能优于指定。原因是，当编译器认为memcpy会更快时（如果使用优化标志），它无论如何都会使用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比赋值快得多。有趣的问题！正如您显然关心如何提高内存操作的速度：最近，我从开发pyTables的人那里了解到压缩在内存传输中的作用：如上所述，与使用非常快的压缩程序（）相比，通常使用memcpy的速度可能较慢。请仅将此视为高性能材料！这个问题相当广泛。