本文嘗試自己實現記憶體拷貝函式並且對各種大小的拷貝效能進行測試，與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),%rdx
mov    0x10(%r11),%rcx
sub    $0x40,%rbp
mov    0x18(%r11),%rsi
mov    0x20(%r11),%rdi
mov    0x28(%r11),%r8
mov    0x30(%r11),%r9
mov    0x38(%r11),%r10
mov    (%r11),%rax
add    $0x40,%r11
mov    %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

結論：

* 不加優化的memcpy僅在拷貝資料較小時速度和其它函式差不多

* 資料量在cache可以完全容納的大小之內的情況下，傳輸可以達到超過理論最大值的速度以上(本機記憶體訪問速度理論值為8GB/s)

* 如果不考慮通用性，較大或較小記憶體的傳輸可以考慮用自制函式替代系統memory copy

* 指令的亂序可能對記憶體訪問的優化造成一定影響