从几个版本的memcpy的测速过程学习一点底层的东西

以下有三个版本的memcpy，对于版本3，很多人都很熟悉，它很经典，很多人面试都写这个，可是我不得不说一句，对于类似的问题，最好的回答有两个：一是调用c库，二是使用汇编。用这一类的问题来考察应聘者的c语言能力，真的很菜！如果真的要考察c语言能力，还不如给几个if，switch-case，for语句呢。

版本1.linux内核中的实现，其实glibc也是如此实现的，省略了不少内容，真正的实现很巧妙，将n个字节分为了三部分(前导字节-对齐到页面+页面+后续字节-页面对齐后的游离字节)进行分块拷贝(linux内核是绝对不会卖弄c语言的，基本的底层函数最终为了高效大多数都用汇编)：

char *memcpy1(char *to, char *from, size_t n)

{

long esi, edi;

int ecx;

esi = (long)from;

edi = (long)to;

asm volatile("rep ; movsl"

: "=&c" (ecx), "=&D" (edi), "=&S" (esi)

: "0" (n / 4), "1" (edi), "2" (esi)

: "memory"

);

return to;

}

版本2.memcpy2为经典的C面试者写法：

char *memcpy2(char *dest, char *src, size_t n)

{

int i = 0;

while (i < n)

{

dest[i] = src[i];

i ++;

}

return dest;

}

版本3.glibc的写法：

...

仅仅这几个memcpy版本，如何确定哪个更高效呢？以下是一个测试的例子，请看例子1。

例子1：

#include <stdlib.h>

#include <stdio.h>

#include <time.h>

#define COUNTS 6000000

long long getcyclenow()

{

unsigned int h, l;

long long bs, cc;

asm("rdtsc /n/t");

asm("movl %%eax, %0/n/t":"=g"(l));

asm("movl %%edx, %0/n/t":"=g"(h));

bs = h;

cc = (bs << 32)|l;

return cc;

}

int main(int argc, char **argv)

{

time_t st0, st1, st2, st3;

long long l0, l1, l2, l3;

int i = 0;

char *src = (char *)calloc(1, 109);

strcpy(src, "iiiiabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz");

char *dest0 = (char *)calloc(1, 109);

char *dest1 = (char *)calloc(1, 109);

char *dest2 = (char *)calloc(1, 109);

l0 = getcyclenow();

dest0 = memcpy(dest0, src, 108);

l1 = getcyclenow();

dest2 = memcpy2(dest2, src, 108);

l2 = getcyclenow();

dest1 = memcpy1(dest1, src, 108);

l3 = getcyclenow();

printf("%X/t%X/t%X/n", l1-l0, l2-l1, l3-l2);



memset(dest0, 0, 109);

memset(dest1, 0, 109);

memset(dest2, 0, 109);

st0 = time(NULL);

for (i = 0; i < COUNTS; i++)

dest0 = memcpy(dest0, src, 108);

st1 = time(NULL);

for (i = 0; i < COUNTS; i++)

dest2 = memcpy2(dest2, src, 108);

st2 = time(NULL);

for (i = 0; i < COUNTS; i++)

dest1 = memcpy1(dest1, src, 108);

st3 = time(NULL);

printf("t0:%f, t1:%f, %f/n", difftime(st1, st0), difftime(st2, st1), difftime(st3, st2));

/*

memset(dest0, 0, 109);

memset(dest1, 0, 109);

memset(dest2, 0, 109);



l0 = getcyclenow();

dest0 = memcpy(dest0, src, 108);

l1 = getcyclenow();

dest2 = memcpy2(dest2, src, 108);

l2 = getcyclenow();

dest1 = memcpy1(dest1, src, 108);

l3 = getcyclenow();

printf("%X/t%X/t%X/n", l1-l0, l2-l1, l3-l2);

*/

return 0;

}

执行这个程序，看第一个printf输出，发现memcpy是最慢的，而汇编写的memcpy1是最快的，而经典的面试写法memcpy2位居中间，可是看c库的memcpy源码或者其反汇编代码，它也是使用了rep ; movsX指令，那为什么它慢呢？考虑到了数据缓存问题，将memcpy和memcpy1以及memcpy2的调用互换了位置，仍然是c库的memcpy最慢，这就给了很多涉业不久的毕业生十足的理由继续往笔试卷上写memcpy2之类的。附带一句，后面的for循环的COUNTS次测速为了得到一个统计值，这次发现memcpy2最慢，memcpy比memcpy1慢一点点，但是都比memcpy2快很多，这名显与通过rdtsc测试出来的结果不对应，于是肯定哪里出了问题。

实际上这是cpu指令预取和指令cache以及缺页引起的，而和c库以及c库实现的memcpy没有关系，要知道c库大家都在用，不会有如此明显的性能问题的，再者说，随便懂点cpu知识和汇编的人都知道memcpy2是最不可取的，因为它里面有大量的条件判断和条件跳转，这对于cpu的流水线是很不利的，并且通过c语言语义上语句实现拷贝增加了指令数，从而也就是增加了执行时间，x86处理器猛就猛在其是从cisc演变过来的，包含了大量的指令，于是movsX加repeat前缀肯定是不二的选择啦。当第一次调用memcpy的时候，cpu不得不从其所在的“地址”处将指令取到cpu，然后就cache到那里了，除非越来越多的别的指令将它冲掉(flush)，它就一直在那里。

另外tlb也是一个重要的因素，tlb缓存了虚拟地址和物理地址的映射，在cpu用虚拟地址访存时，需要通过mmu得到物理地址，tlb可以缓存这个映射从而以后不再需要查询页表，直接从tlb中得到物理地址。对于指令的寻址，cpu也是按照虚拟地址来的，第一次访问时要完全查找页表，并且还可能缺页，接下来从最慢的磁盘将数据读到次慢的内存，然后将物理地址-虚拟地址的映射读入tlb，指令进入icache，因此接下来的调用就会很快了。有个问题需要解释，c库的函数不是一直cache在内存中的吗？是的，但是第一它没有cache在处理器中，第二它虽然缓存在了内存，但是对于当前task却不一定建立了页表项，而处理器dcache/icache(数据缓存/指令缓存)是通过物理地址寻址的(而tlb是虚拟地址寻址的)，因此会导致两个不命中：cpu cache(icache/dcache/tlb)不命中和页表项不命中，然后发生缺页，内核准备读磁盘之前首先要看一下它是否在内存中，如果在的话直接建立页表项映射就可以了，对于c库的函数，一般是在内存的(前提是内存足够大)，因此第一次调用c库函数只会有缺页-建立页表项的开销，而大多数情况下不会有读磁盘的开销。

下面通过例子2分析问题到底出在哪里！

例子2：

#include <stdlib.h>

#include <stdio.h>

#define ALIGN 0X800

int test()

{

return 1;

}

void __attribute__ ((aligned (ALIGN))) stub()

{

return;

}

long long getcycle()

{

unsigned int h, l;

long long bs, cc;

asm("rdtsc /n/t");

asm("movl %%eax, %0/n/t":"=g"(l));

asm("movl %%edx, %0/n/t":"=g"(h));

bs = h;

cc = (bs << 32)|l;

return cc;

}

int main(int argc, char **argv)

{

long long t1, t2, t3, t4;

printf("%p/t%p/t%p/n", test, stub, main);

t1 = getcycle();

test();

t2 = getcycle();

test();

t3 = getcycle();

test();

t4 = getcycle();

printf("%X/t%X/t%X/n", t2-t1, t3-t2, t4-t3);

printf("%p/t%p/t%p/n", getcycle, test, main);

return 0;

}

stub函数设置了aligned这个attribute，为了在test函数和main之间制造一点“距离”(用nop指令填充)，这样的话，第一，cpu的指令预取(instruction prefetch)就取不到了，毕竟cpu的指令缓存是有限的；第二，执行main之前main函数一定要映射进页表项，由于mmu按页大小(4096字节)映射，拉开一定距离就不会让test也映射进入，在下一个例子中我们会调整这个距离来表明缺页对执行性能的影响。控制ALIGN的值，使得test函数和main的距离变化，当ALIGN很小的时候，test和main离的很近(小于一个页面且在同一页面)，cpu可能会根据局部性原理加载main的时候将test的指令取入cache，并且由于test和main在一个页面，test也会进入内存且建立页表映射，从而tlb中也会有test的物理地址，然而如果ALIGN很大，比如是0x10000，这样test和main很远，cpu既取不到test的指令，又不会建立页表映射，在第一次执行test的时候，会缺页，会花费很多时间，以下讨论不再考虑cpu预取，仅考虑缺页和cpu的icache，也不再考虑tlb，因为在访问一组连续地址(页面)的第一个字节时，地址映射信息就会进入tlb，以下一个页面内的连续访问几乎都会命中，1个字节带来的优势对比一个页面字节来讲，效果不容易表现出来(测试不容易)。因此在ALIGN为0x10000的时候，执行结果如下：

b36 3f 38

0x450017 0x420006 0x450045

第一次和第二次调用test足有40多倍的延迟。由于指令已经cache了，第二次和第三次执行就很快了。为了证明是缺页的的影响很大，把getcycle的定义放到test之前：

long long getcycle()

{

...

}

int test()

{

return 1;

}

void __attribute__ ((aligned (ALIGN))) stub()

{

return;

}

在执行test之前要先执行一个t1 = getcycle();，该调用会触发getcycle缺页，由于getcycle和test在同一页面，也就是说会建立test的页表映射，执行结果如下：

3f 38 3f

0x420000 0x420034 0x450017

虽然main和test离的仍然很远，然而getcycle和test很近，在调用getcycle的时候会建立页表项，因此速度加快很多，以后就从指令缓存icache中取指令，为了再次证实这个事情且不影响getcycle的执行，将getcycle放回原位，然后在test之前放一个stub0，然后在第一个调用getcycle之前调用stub0，然后看结果，三次执行test的时间仍然很接近。看一下linux的do_page_fault的代码，的确很多，这些都要算在t2-t1中，怪不得缺页情形下多了那么多的时间。

因此前一个例子中c库的memcpy慢的原因就找到了，将例子1中main函数最后的注释放开，再次编译执行(-O0参数，不优化，前面的例子2也要这样编译)，发现memcpy1仍然是最快的，而c库的memcpy位居第二，和memcpy1相差不多，而面试版本的memcpy2最慢。接下来看例子3，展示缺页的影响。

例子3：

#include <stdlib.h>

#include <stdio.h>

#include <string.h>

#define ALIGN_test 0X800

#define ALIGN_main 0X800

long long getcycle()

{

unsigned int h, l;

long long bs, cc;

asm("rdtsc /n/t");

asm("movl %%eax, %0/n/t":"=g"(l));

asm("movl %%edx, %0/n/t":"=g"(h));

bs = h;

cc = (bs << 32)|l;

return cc;

}

void __attribute__ ((aligned (0x10000))) stub0() //为了让test和main分布在两个页面中

{

return;

}

int __attribute__ ((aligned (ALIGN_test))) test(char *buf)

{ //增加一些代码，让它像真正的函数。要使用-O0编译

int i = 2, j=3;

if (buf[0] < i)

j += 3;

for (j; j < 10; i += j+buf[i])

j = buf[j];

if (buf[0] < i)

j += 3;

for (j; j < 10; i += j+buf[i])

j = buf[j];

if (buf[0] < i)

j += 3;

for (j; j < 10; i += j+buf[i])

j = buf[j];

return i*j;

};

int __attribute__ ((aligned (ALIGN_main))) main(int argc, char **argv)

{

long long t1, t2, t3, t4;

char b[25] = {0};

t1 = getcycle();

memcpy(b, "ddddd", 5);

t2 = getcycle();

memcpy(b, "ddddd", 5);

t3 = getcycle();

memcpy(b, "ddddd", 5);

t4 = getcycle();

printf("%llx/t%llx/t%llx/n", t2-t1, t3-t2, t4-t3);

t1 = getcycle();

test("ddddd/n");

t2 = getcycle();

test("ddddd/n");

t3 = getcycle();

test("ddddd/n");

t4 = getcycle();

printf("%llx/t%llx/t%llx/n", t2-t1, t3-t2, t4-t3);

printf("%p/t%p/t%p/n", getcycle, printf2, main);

}

ALIGN_main和ALIGN_test均为0x800的情况下，上述的代码将把test和main分布在两个页面中，间隔0x800，执行main时并不会为test建立映射，因此第一次执行test函数时将会慢很多，如果将ALIGN_main和ALIGN_test分别调整为0x800和0x1000，那么test和main就会分布在同一个页面，第一次执行test明显会快很多，这就是缺页带来的影响，可见页面调入实在太耗时了。在结束rdtsc指令的第一个影响因素之前再看一个例子，理解一下共享库的作用。

例子4：

share.h:

int test1();

share.c

int test1()

{

return 3;

}

test1.c:

#include <stdlib.h>

#include <stdio.h>

#include "share.h"

long long getcycle()

{

unsigned int h, l;

long long bs, cc;

long long interval, start, end;

asm("rdtsc /n/t");

asm("movl %%eax, %0/n/t":"=g"(l));

asm("movl %%edx, %0/n/t":"=g"(h));

bs = h;

cc = (bs << 32)|l;

return cc;

}

int main(int argc, char **argv)

{

time_t st0, st1, st2, st3;

long long l0, l1, l2, l3;

l0 = getcycle();

test1();

l1 = getcycle();

test1();

l2 = getcycle();

test1();

l3 = getcycle();

printf("%llx/t%llx/t%llx/n", l1-l0, l2-l1, l3-l2);

}

test2.c:

#include <stdlib.h>

#include <stdio.h>

#include "shar.h"

int main(int argc, char **argv)

{

while(1) {

test1();

}

}

编译：

gcc -fPIC -shared share.c -o libshare.so -O0

gcc test1.c -o test1 -L. -lshare

gcc test2.c -o test2 -L. -lshare

1.连续执行test1：

28b 46 3f

2.执行sysctl -w vm.drop_caches=3后执行一次test1：

391 54 46

3.在另一tty上执行test2，然后执行test1：

29a 46 38

4.在另一tty上执行test2，执行sysctl -w vm.drop_caches=3后执行test1：

2c8 46 38

测试1说明第一次执行test1函数时缺页，建立页表映射消耗大量时间，连续执行后即使test1退出linux也可能将so缓存在了内存，不再需要读磁盘，因此得到了一个大致0x28b的数值，测试2由于刷新了文件缓存，缺页时需要读磁盘，时间消耗明显增加，测试3和测试1不相上下，测试4并没有重现测试2的噩梦，因此test2在循环执行中，即使刷新了磁盘缓存，test2也会将libshare.so读入磁盘，由于libshare.so是共享的，因此test1在第一次执行test1函数时只需要建立页面映射即可，不必再读磁盘了，这就是共享库的好处。

知道了cache和缺页带来的影响，rdtsc就可以无忧得使用了吗？不是这样的！如果getcycle包围的待测试代码本身执行时间过长或者导致了进程调度，那么两个getcycle调用的差值并不是真正的执行时间，比如：

t1 = getcycle();

test() //很长，可能会sleep

t2 = getcycle();

如此一来t2-t1可能会把其它进程执行的时间都算上，因为rdtsc获得的是cpu全局的嘀嗒信息，而我们需要测试的执行时间是基于本进程的统计时间。因此实际上我们是不能信任rdtsc测试出来的结果的。哪一次在test()执行过程中发生调度几乎是用户态决定不了的(除非设置实时进程优先级并且没有IO)。

总结：

1.编写代码时，主要的调用函数要尽量紧凑的放在一个页面中，注意向物理页面起始地址对齐，不要离的太远，这样可以提高执行效率。

2.使用共享库，虽然可能因此增加几条指令(比如got机制的代价)，然而却省去了很多缺页时读磁盘的开销。

3.测量长函数执行一次的时间，不要相信rdtsc，因此中间如果发生调度，别的进程时间也会计算进去，rdtsc是全局的。

4.挖掘机器的特性，在指令级别寻找办法，不要太迷恋c语言。