缓慢的 memcpy 性能答案

【问题标题】：Slow memcpy Performance缓慢的 memcpy 性能
【发布时间】：2021-02-03 19:45:58
【问题描述】：

对你们中的一些人来说，这可能是一个愚蠢/明显的问题，但我还在学习，所以请温柔哈哈。

我正在编写一个没有 CRT 的应用程序，所以我必须实现自己的 memcpy 函数。在完成所有工作并使其正常工作后，我注意到该应用程序的执行速度明显慢于 CRT 对应应用程序。过了一会儿，我找到了我的自定义 memcpy 函数。

void* _memcpy(void* destination, void* source, size_t num)
{
    char* d = (char*)destination;
    char* s = (char*)source;
    while (num--)
        *d++ = *s++;
    return destination;
}

我的朋友告诉我这是一个完整的 sh*t 实现，所以我在此处发布此内容是为了询问我如何至少改进它以满足其 CRT 对应物的性能。还要解释为什么它这么慢

【问题讨论】：

@MemeMachine -- 库版本的维护者花费了大量时间来确保优化 memcpy，可能用汇编语言和/或使用内在函数编写它。你几乎没有机会超过或等于已经提供的东西。 memcpy 之所以被“超优化”，是因为这个函数实际上是使软件“快速”的支柱，因此将所有性能挤出来非常重要。
这里所有不理解编译器知道这是一个 memcpy 的东西都是错误的。 @MM 有唯一值得一看的答案。为未优化的构建进行优化是浪费时间，除非您积极需要提高调试性能（这里可能不是这种情况）
@MemeMachine -- 你说不想使用 CRT 并不意味着你不能看一看 CRT 是如何实现这个功能的。然后，您可以将其用作创建自己的指南，而不是尝试从头开始执行此操作并希望您编写的代码足够快。如果你这样做了，你的朋友就没有什么可抱怨的了。
@JosephLarson memcpy 处理这个吗？没想到
最佳解决方案也将取决于 CPU 架构。见这篇文章：danielvik.com/2010/02/fast-memcpy-in-c.html

标签： c++ memcpy

【解决方案1】：

第一件事。计算机用文字处理事情。典型的字长为 4 或 8 字节长（某些 8 位微控制器除外）。如果你可以一次复制一个单词，事情会快很多。

虽然有一些并发症。许多处理器不喜欢未对齐的访问，因此每个副本都应该在字边界上。

其他优化可能包括预取数据，但这些开始变得更加复杂。

看看 newlib-nano 的实现以获得灵感。 https://github.com/eblot/newlib/blob/master/newlib/libc/string/memcpy.c

【讨论】：