自制内存拷贝函数学习笔记



　　本文尝试自己实现内存拷贝函数并且对各种大小的拷贝性能进行测试，与linux系统调用memcpy进行对比，旨在深入理解内存访问方式，以及对内存访问在程序执行中占用时间比有一定的认识。

　　测试环境为：

* 64位linux

* Intel(R) Xeon(R) 8 Core 2GHZ

* cache大小8192KB，cache对齐字节数64字节，一次缓存分组数：8

* gcc-4.1.2，编译参数-O2

　　几种实现方式：

1. 无任何优化

void* mymemcpy_naive(void* dest, const void* src, size_t len){    char* destc = (char*)dest;    const char* srcc = (const char*)src;    while (len-- > 0) {        *destc++ = *srcc++;    }    return dest;}

2. 以64/32/16/8字节单位进行传输

void* mymemcpy_64(void* dest, const void* src, size_t len){    char* destc = (char*)dest;    const char* srcc = (const char*)src;    // first do 64 bytes align    while (((size_t)srcc) & 0x3F != 0 && len > 0) {        *destc++ = *srcc++;        --len;    }    COPY64(destc, srcc);    COPY32(destc, srcc);    COPY16(destc, srcc);    COPY8(destc, srcc);    COPY4(destc, srcc);    while (len-- > 0) {        *destc++ = *srcc++;    }    return dest;}

其中COPY64宏定义如下：

#define COPY64(destc, srcc)     \    while (len >= 64) { \        register unsigned long q1 = *(unsigned long*)srcc;          \        register unsigned long q2 = *(unsigned long*)(srcc+8);      \        register unsigned long q3 = *(unsigned long*)(srcc+16);     \        register unsigned long q4 = *(unsigned long*)(srcc+24);     \        register unsigned long q5 = *(unsigned long*)(srcc+32);     \        register unsigned long q6 = *(unsigned long*)(srcc+40);     \        register unsigned long q7 = *(unsigned long*)(srcc+48);     \        register unsigned long q8 = *(unsigned long*)(srcc+56);     \        *(unsigned long*)destc = q1;        \        *(unsigned long*)(destc+8) = q2;    \        *(unsigned long*)(destc+16) = q3;   \        *(unsigned long*)(destc+24) = q4;   \        *(unsigned long*)(destc+32) = q5;   \        *(unsigned long*)(destc+40) = q6;   \        *(unsigned long*)(destc+48) = q7;   \        *(unsigned long*)(destc+56) = q8;   \        srcc+=64;   \        destc+=64;  \        len-=64;    \    }

COPY32/COPY16/COPY8等类似COPY64定义。此处略。

3. 在传输中间加上memory barrier。代码同上，只是COPY64/COPY32/COPY16等换为COPY64B/COPY32B/COPY16B。其中COPY64定义如下：

#define COPY64B(destc, srcc)     \    while (len >= 64) { \        register unsigned long q1 = *(unsigned long*)srcc;          \        register unsigned long q2 = *(unsigned long*)(srcc+8);      \        register unsigned long q3 = *(unsigned long*)(srcc+16);     \        register unsigned long q4 = *(unsigned long*)(srcc+24);     \        register unsigned long q5 = *(unsigned long*)(srcc+32);     \        register unsigned long q6 = *(unsigned long*)(srcc+40);     \        register unsigned long q7 = *(unsigned long*)(srcc+48);     \        register unsigned long q8 = *(unsigned long*)(srcc+56);     \        __memory_barrier();                 \        *(unsigned long*)destc = q1;        \        *(unsigned long*)(destc+8) = q2;    \        *(unsigned long*)(destc+16) = q3;   \        *(unsigned long*)(destc+24) = q4;   \        *(unsigned long*)(destc+32) = q5;   \        *(unsigned long*)(destc+40) = q6;   \        *(unsigned long*)(destc+48) = q7;   \        *(unsigned long*)(destc+56) = q8;   \        srcc+=64;   \        destc+=64;  \        len-=64;    \    }

__memory_barrier()定义如下：

#define __memory_barrier()      asm volatile("":::"memory")

注：

* 加上memory barrier有什么效果？

实测-O2优化情况下，COPY64宏展开之后的循环体内部，会编译为以下代码：

mov    0x8(%r11),%rdxmov    0x10(%r11),%rcxsub    $0x40,%rbpmov    0x18(%r11),%rsimov    0x20(%r11),%rdimov    0x28(%r11),%r8mov    0x30(%r11),%r9mov    0x38(%r11),%r10mov    (%r11),%raxadd    $0x40,%r11mov    %rdx,0x8(%rbx)mov    %rcx,0x10(%rbx)mov    %rsi,0x18(%rbx)mov    %rdi,0x20(%rbx)mov    %rax,(%rbx)mov    %r8,0x28(%rbx)mov    %r9,0x30(%rbx)mov    %r10,0x38(%rbx)

关于在mov过程中夹杂无关运算代码sub $0x40,%rbp，add $0x40,%r11，可以参考编译器为隐藏内存传输延时而打乱指令顺序的优化资料，在读内存指令后到内存实际被fetch到寄存器，该寄存器可用的过程之间是需要一定的等待周期的，在现代CPU和内存上，此周期为100-200ns之间，在这期间可以执行其它指令，否则必须等待内存读取完成。

关于mov    (%r11),%rax这一句。编译器没有按照实际读取顺序从src+0开始访问，估计跟gcc优化中关于打乱指令顺序以增强寄存器藕合性有关。但是这一举动可能造成cache失效。加上memory barrier之后，编译的结果就是按顺序访问内存了。具体有没有影响请参见后面的测试数据。

4. 不使用中间变量直接赋值。代码同上，只是将COPY64B/COPY32B/COPY16B/COPY8B换成COPY64D/COPY32D/COPY16D/COPY8D，其中COPY64D定义如下：

#define COPY64D(destc, srcc)     \    while (len >= 64) { \        *(unsigned long*)destc = *(unsigned long*)srcc;        \        *(unsigned long*)(destc+8) = *(unsigned long*)(srcc+8);    \        *(unsigned long*)(destc+16) = *(unsigned long*)(srcc+16);   \        *(unsigned long*)(destc+24) = *(unsigned long*)(srcc+24);   \        *(unsigned long*)(destc+32) = *(unsigned long*)(srcc+32);   \        *(unsigned long*)(destc+40) = *(unsigned long*)(srcc+40);   \        *(unsigned long*)(destc+48) = *(unsigned long*)(srcc+48);   \        *(unsigned long*)(destc+56) = *(unsigned long*)(srcc+56);   \        srcc+=64;   \        destc+=64;  \        len-=64;    \    }

实测编译器并不能生成x86上的repz movsq之类的代码，因此这种方式展开之后也是需要借助中间寄存器的。但是区别是读和写交错进行了。具体效果请见后文数据。

函数名定义如下：

 mymemcpy_ 传输字节 _ (d=直接传输 b=加memory barrier)

表头：一次性拷贝的字节数 memcpy(dest, src, N)中的N

数据：每秒钟拷贝字节数(MB/s) 这里MB是Mega BYTE

 81625325064100200256500100010244096163845120001000000sys_memcpy871.061755.353361.044028.173885.786162.046724.5710101.912263.313648.714932.515035.87501.127889.673903.073465.7mymemcpy_naive690.748817.927782.5824.169893.4916.579897.421945.511962.502985.278996.581997.625963.1211003.891004.52982.129mymemcpy_81093.511776.382620.142898.563431.273960.095772.174684.116080.547483.415143.54991.395298.275359.065146.095234.19mymemcpy_8d1076.361684.142294.362444.52730.973009.113940.894293.324495.534977.224923.464903.335265.595349.465137.515230.2mymemcpy_161242.031984.162501.143342.264139.85070.095689.438239.537837.968841.3210146.29234.838045.638053.075710.496204.91mymemcpy_16b1242.681984.722800.193340.884149.635036.355685.048234.777721.368770.9310139.49164.738047.528053.325625.94903.46mymemcpy_16d1242.862018.993154.523286.883975.274969.425771.76985.47717.848761.117201.829201.38040.798055.225666.886200.88mymemcpy_32897.282308.462651.233231.684719.015385.697347.548392.399747.9613096.513617.410656.810582.610573.96189.466284.59mymemcpy_32b897.6592306.732657.883229.034699.635387.467345.728389.519758.6913125.713652138681062310585.16131.786252.79mymemcpy_32d1000.0624862966.073523.384925.876062.828417.9110896.912216.213648.211190.614841.48045.328053.235710.896216.18mymemcpy_64863.2861794.372295.353400.563882.926155.237481.6111199.212606.513463.71475514677.91245310880.53705.593818.43mymemcpy_64b897.591794.842294.513395.984040.516155.34747111195.112610.513645.91482814471.412513122626199.86226.03mymemcpy_64d10021583.032509.213800.174811.316250.398782.9412382.314160.714873.915363.815538.18048.338054.375688.676213.36

结论：

* 不加优化的memcpy仅在拷贝数据较小时速度和其它函数差不多

* 数据量在cache可以完全容纳的大小之内的情况下，传输可以达到超过理论最大值的速度以上(本机内存访问速度理论值为8GB/s)

* 如果不考虑通用性，较大或较小内存的传输可以考虑用自制函数替代系统memory copy

* 指令的乱序可能对内存访问的优化造成一定影响