如何提高memcpy的性能

Question

摘要：

在真实或测试应用程序中，memcpy 似乎无法在我的系统上传输超过 2GB/秒。我该怎么做才能获得更快的内存到内存复制？

完整细节：

作为数据捕获应用程序的一部分（使用一些专用硬件），我需要将大约 3 GB/秒从临时缓冲区复制到主内存中。为了获取数据，我为硬件驱动程序提供了一系列缓冲区（每个缓冲区 2MB）。硬件 DMA 将数据传输到每个缓冲区，然后在每个缓冲区已满时通知我的程序。我的程序清空缓冲区（memcpy 到另一个更大的 RAM 块），并将处理后的缓冲区重新发布到卡上以再次填充。我在 memcpy 移动数据速度不够快时遇到问题。看起来内存到内存的复制应该足够快，可以在我运行的硬件上支持 3GB/秒。 Lavalys EVEREST 为我提供了 9337MB/秒的内存复制基准测试结果，但即使在简单的测试程序中，我也无法使用 memcpy 达到接近这些速度的速度。

我通过在缓冲区处理代码中添加/删除 memcpy 调用来隔离性能问题。如果没有 memcpy，我可以运行全数据速率 - 大约 3GB/秒。启用 memcpy 后，我的速度限制为大约 550Mb/秒（使用当前编译器）。

为了在我的系统上对 memcpy 进行基准测试，我编写了一个单独的测试程序，它只对某些数据块调用 memcpy。 （我已经发布了下面的代码）我已经在我使用的编译器/IDE（National Instruments CVI）以及 Visual Studio 2010 中运行了这个。虽然我目前没有使用 Visual Studio，但我愿意如果能够产生必要的性能，则进行转换。然而，在盲目转移之前，我想确保它能够解决我的 memcpy 性能问题。

Visual C++ 2010：1900 MB/秒

NI CVI 2009：550 MB/秒

虽然我对 CVI 明显慢于 Visual Studio 并不感到惊讶，但我对 memcpy 性能如此之低感到惊讶。虽然我不确定这是否可以直接比较，但这比 EVEREST 基准带宽低得多。虽然我不需要那么高的性能水平，但至少需要 3GB/秒。当然，标准库的实现不会比 EVEREST 使用的任何东西差那么多！

在这种情况下，我能做些什么来使 memcpy 更快？

---

硬件详细信息： AMD Magny Cours - 4x 八进制核心 128GB DDR3 Windows Server 2003 Enterprise X64

测试程序：

#include <windows.h>
#include <stdio.h>

const size_t NUM_ELEMENTS = 2*1024 * 1024;
const size_t ITERATIONS = 10000;

int main (int argc, char *argv[])
{
    LARGE_INTEGER start, stop, frequency;

    QueryPerformanceFrequency(&frequency);

    unsigned short * src = (unsigned short *) malloc(sizeof(unsigned short) * NUM_ELEMENTS);
    unsigned short * dest = (unsigned short *) malloc(sizeof(unsigned short) * NUM_ELEMENTS);

    for(int ctr = 0; ctr < NUM_ELEMENTS; ctr++)
    {
        src[ctr] = rand();
    }

    QueryPerformanceCounter(&start);

    for(int iter = 0; iter < ITERATIONS; iter++)
        memcpy(dest, src, NUM_ELEMENTS * sizeof(unsigned short));

    QueryPerformanceCounter(&stop);

    __int64 duration = stop.QuadPart - start.QuadPart;

    double duration_d = (double)duration / (double) frequency.QuadPart;

    double bytes_sec = (ITERATIONS * (NUM_ELEMENTS/1024/1024) * sizeof(unsigned short)) / duration_d;

    printf("Duration: %.5lfs for %d iterations, %.3lfMB/sec\n", duration_d, ITERATIONS, bytes_sec);

    free(src);
    free(dest);

    getchar();

    return 0;
}

编辑：如果您有额外的五分钟时间并且想要做出贡献，您可以在您的计算机上运行上述代码并将您的时间作为评论发布吗？

Answer 1

我找到了一种在这种情况下提高速度的方法。我编写了一个多线程版本的 memcpy，在线程之间分割要复制的区域。以下是设定块大小的一些性能缩放数字，使用与上面相同的计时代码。我不知道性能，特别是对于这么小的块来说，会扩展到这么多线程。我怀疑这与这台机器上的大量内存控制器（16个）有关。

Performance (10000x 4MB block memcpy):

 1 thread :  1826 MB/sec
 2 threads:  3118 MB/sec
 3 threads:  4121 MB/sec
 4 threads: 10020 MB/sec
 5 threads: 12848 MB/sec
 6 threads: 14340 MB/sec
 8 threads: 17892 MB/sec
10 threads: 21781 MB/sec
12 threads: 25721 MB/sec
14 threads: 25318 MB/sec
16 threads: 19965 MB/sec
24 threads: 13158 MB/sec
32 threads: 12497 MB/sec

我不明白 3 线程和 4 线程之间的巨大性能跳跃。什么会导致这样的跳跃？

我已经包含了我在下面为可能遇到同样问题的其他人编写的 memcpy 代码。请注意，此代码中没有错误检查 - 可能需要为您的应用程序添加此代码。

#define NUM_CPY_THREADS 4

HANDLE hCopyThreads[NUM_CPY_THREADS] = {0};
HANDLE hCopyStartSemaphores[NUM_CPY_THREADS] = {0};
HANDLE hCopyStopSemaphores[NUM_CPY_THREADS] = {0};
typedef struct
{
    int ct;
    void * src, * dest;
    size_t size;
} mt_cpy_t;

mt_cpy_t mtParamters[NUM_CPY_THREADS] = {0};

DWORD WINAPI thread_copy_proc(LPVOID param)
{
    mt_cpy_t * p = (mt_cpy_t * ) param;

    while(1)
    {
        WaitForSingleObject(hCopyStartSemaphores[p->ct], INFINITE);
        memcpy(p->dest, p->src, p->size);
        ReleaseSemaphore(hCopyStopSemaphores[p->ct], 1, NULL);
    }

    return 0;
}

int startCopyThreads()
{
    for(int ctr = 0; ctr < NUM_CPY_THREADS; ctr++)
    {
        hCopyStartSemaphores[ctr] = CreateSemaphore(NULL, 0, 1, NULL);
        hCopyStopSemaphores[ctr] = CreateSemaphore(NULL, 0, 1, NULL);
        mtParamters[ctr].ct = ctr;
        hCopyThreads[ctr] = CreateThread(0, 0, thread_copy_proc, &mtParamters[ctr], 0, NULL); 
    }

    return 0;
}

void * mt_memcpy(void * dest, void * src, size_t bytes)
{
    //set up parameters
    for(int ctr = 0; ctr < NUM_CPY_THREADS; ctr++)
    {
        mtParamters[ctr].dest = (char *) dest + ctr * bytes / NUM_CPY_THREADS;
        mtParamters[ctr].src = (char *) src + ctr * bytes / NUM_CPY_THREADS;
        mtParamters[ctr].size = (ctr + 1) * bytes / NUM_CPY_THREADS - ctr * bytes / NUM_CPY_THREADS;
    }

    //release semaphores to start computation
    for(int ctr = 0; ctr < NUM_CPY_THREADS; ctr++)
        ReleaseSemaphore(hCopyStartSemaphores[ctr], 1, NULL);

    //wait for all threads to finish
    WaitForMultipleObjects(NUM_CPY_THREADS, hCopyStopSemaphores, TRUE, INFINITE);

    return dest;
}

int stopCopyThreads()
{
    for(int ctr = 0; ctr < NUM_CPY_THREADS; ctr++)
    {
        TerminateThread(hCopyThreads[ctr], 0);
        CloseHandle(hCopyStartSemaphores[ctr]);
        CloseHandle(hCopyStopSemaphores[ctr]);
    }
    return 0;
}

Answer 2

我不确定它是在运行时完成还是必须在编译时完成，但您应该启用 SSE 或类似的扩展，因为向量单元通常可以向内存写入 128 位，而 CPU 则为 64 位。

尝试这个实现。

是的，并确保源和目标均与 128 位对齐。如果你的源和目标没有相互对齐，你的 memcpy() 将不得不做一些严肃的事情。 :)

Answer 3

需要注意的一件事是，您的进程（以及 memcpy() 的性能）受到操作系统任务调度的影响 - 很难说这对您的计时有多大影响，但是山雀很难控制。设备 DMA 操作不受此影响，因为一旦启动，它就不再在 CPU 上运行。由于您的应用程序是一个实际的实时应用程序，因此您可能想尝试一下 Windows 的进程/线程优先级设置（如果您还没有这样做的话）。请记住，您必须小心这一点，因为它可能会对其他进程（以及计算机上的用户体验）产生真正的负面影响。

另一件需要记住的事情是，操作系统内存虚拟化可能会产生影响 - 如果您要复制到的内存页面实际上并未由物理 RAM 页面支持，则 memcpy() 操作将操作系统的故障导致物理支持到位。您的 DMA 页可能被锁定到物理内存中（因为它们必须用于 DMA 操作），因此 memcpy() 的源内存在这方面可能不是问题。您可能会考虑使用 Win32 VirtualAlloc() API 来确保 memcpy() 的目标内存已提交（我认为 VirtualAlloc()是正确的 API，但可能有一个更好的 API，我忘记了 - 我已经有一段时间没有需要做这样的事情了）。

最后，看看您是否可以使用Skizz 解释的技术完全避免使用 memcpy() - 如果资源允许，这是最好的选择。

Answer 4

要获得所需的内存性能，存在一些障碍：

1. 带宽 - 数据从内存移动到 CPU 并再次返回的速度存在限制。根据这篇维基百科文章，266MHz DDR3 RAM 的上限约为 17GB/s。现在，使用 memcpy，您需要将其减半才能获得最大传输速率，因为数据是读取然后写入的。从您的基准测试结果来看，您的系统似乎没有运行最快的 RAM。如果您负担得起，请升级主板/RAM（而且价格不会便宜，英国的超频玩家目前拥有 3x4GB PC16000，售价 400 英镑）

2. 操作系统 - Windows 是一个抢占式多任务操作系统，因此您的进程经常会受到影响将被挂起以允许其他进程查看并执行操作。这将破坏您的缓存并阻止您的传输。在最坏的情况下，您的整个进程可能会缓存到磁盘！

3. CPU - 正在移动的数据还有很长的路要走：RAM ->二级缓存-> L1 缓存 ->中央处理器-> L1-> L2->内存。甚至可能还有 L3 缓存。如果你想涉及 CPU，你确实需要在复制 L1 的同时加载 L2。不幸的是，现代 CPU 运行 L1 缓存块的速度比加载 L1 所需的时间还要快。 CPU 有一个内存控制器，在您将数据按顺序流式传输到 CPU 但仍然会遇到问题的情况下，它可以提供很大帮助。

当然，做某事更快的方法就是不做。捕获的数据可以写入 RAM 中的任何位置，还是在固定位置使用缓冲区。如果你可以把它写在任何地方，那么你根本不需要memcpy。如果它是固定的，您可以就地处理数据并使用双缓冲区类型系统吗？即开始捕获数据，当数据半满时，开始处理前半部分数据。当缓冲区已满时，开始将捕获的数据写入开头并处理后半部分。这要求算法处理数据的速度比采集卡产生数据的速度快。它还假设数据在处理后被丢弃。实际上，这是一个在复制过程中进行转换的 memcpy，因此您可以：

load -> transform -> save
\--/                 \--/
 capture card        RAM
   buffer

而不是：

load -> save -> load -> transform -> save
\-----------/
memcpy from
capture card
buffer to RAM

或者获得更快的 RAM！

编辑：另一种选择是处理数据源和 PC 之间的数据 - 你能在那里放置 DSP / FPGA 吗？定制硬件总是比通用 CPU 更快。

另一个想法：我已经有一段时间没有做过任何高性能图形工作了，但是你能将数据 DMA 到显卡中，然后再次 DMA 出来吗？您甚至可以利用 CUDA 进行一些处理。这将使 CPU 完全脱离内存传输循环。

Answer 5

首先，您需要检查内存是否在 16 字节边界上对齐，否则您会受到惩罚。这是最重要的。

如果您不需要符合标准的解决方案，您可以通过使用某些编译器特定的扩展（例如memcpy64）来检查情况是否有所改善（如果有可用的东西，请检查您的编译器文档）。事实上，memcpy 必须能够处理单字节复制，但如果没有此限制，一次移动 4 或 8 个字节会快得多。

同样，您可以选择编写内联汇编代码吗？

Answer 6

也许您可以更多地解释一下如何处理更大的内存区域？

在您的应用程序中是否可以简单地传递缓冲区的所有权，而不是复制它？这将完全消除问题。

或者您使用 memcpy 不仅仅用于复制？也许您正在使用更大的内存区域来根据捕获的数据构建顺序数据流？特别是如果你一次处理一个角色，你可能会半途而废。例如，可以调整处理代码以适应表示为“缓冲区数组”而不是“连续内存区域”的流。

Answer 7

您可以使用 SSE2 寄存器编写更好的 memcpy 实现。 VC2010的版本已经做到了这一点。所以问题是，如果你要给它对齐的内存。

也许你可以比 VC 2010 的版本做得更好，但它确实需要一些了解如何去做。

PS：您可以在反向调用中将缓冲区传递给用户模式程序，以完全防止复制。

Answer 8

我建议您阅读的一个来源是 MPlayer 的 fast_memcpy 函数。还要考虑预期的使用模式，并注意现代 cpu 具有特殊的存储指令，可让您通知 cpu 是否需要读回正在写入的数据。使用指示您不会读回数据（因此不需要缓存）的指令对于大型 memcpy 操作来说可能是一个巨大的胜利。