字节对齐效率的疑惑

lyjdamzwf

平时大家一直都在说字节对齐会影响效率如何如何, 最近突然想自己测一下这个问题.
首先我想到了glibc中的memset中对于字节对齐的处理,代码如下:

1. void *
   
2. memset (dstpp, c, len)
   
3.      void *dstpp;
   
4.      int c;
   
5.      size_t len;
   
6. {
   
7.   long int dstp = (long int) dstpp;
   
8. 
   
9.   if (len >= 8)
   
10.     {
    
11.       size_t xlen;
    
12.       op_t cccc;
    
13. 
    
14.       cccc = (unsigned char) c;
    
15.       cccc |= cccc << 8;
    
16.       cccc |= cccc << 16;
    
17.       if (OPSIZ > 4)
    
18.     /* Do the shift in two steps to avoid warning if long has 32 bits.  */
    
19.     cccc |= (cccc << 16) << 16;
    
20. 
    
21.       [color=Red]/* There are at least some bytes to set.
    
22.      No need to test for LEN == 0 in this alignment loop.  */
    
23.       while (dstp % OPSIZ != 0)
    
24.     {
    
25.       ((byte *) dstp)[0] = c;
    
26.       dstp += 1;
    
27.       len -= 1;
    
28.     }[/color]
    
29. 
    
30.       /* Write 8 `op_t' per iteration until less than 8 `op_t' remain.  */
    
31.       xlen = len / (OPSIZ * 8);
    
32.       while (xlen > 0)
    
33.     {
    
34.       ((op_t *) dstp)[0] = cccc;
    
35.       ((op_t *) dstp)[1] = cccc;
    
36.       ((op_t *) dstp)[2] = cccc;
    
37.       ((op_t *) dstp)[3] = cccc;
    
38.       ((op_t *) dstp)[4] = cccc;
    
39.       ((op_t *) dstp)[5] = cccc;
    
40.       ((op_t *) dstp)[6] = cccc;
    
41.       ((op_t *) dstp)[7] = cccc;
    
42.       dstp += 8 * OPSIZ;
    
43.       xlen -= 1;
    
44.     }
    
45. 
    
46. len %= OPSIZ * 8;
    
47. 
    
48.       /* Write 1 `op_t' per iteration until less than OPSIZ bytes remain.  */
    
49.       xlen = len / OPSIZ;
    
50.       while (xlen > 0)
    
51.     {
    
52.       ((op_t *) dstp)[0] = cccc;
    
53.       dstp += OPSIZ;
    
54.       xlen -= 1;
    
55.     }
    
56.       len %= OPSIZ;
    
57.     }
    
58. 
    
59.   /* Write the last few bytes.  */
    
60.   while (len > 0)
    
61.     {
    
62.       ((byte *) dstp)[0] = c;
    
63.       dstp += 1;
    
64.       len -= 1;
    
65.     }
    
66. 
    
67.   return dstpp;
    
68. }

复制代码

我们可以看到红色部分,memset进行了按4字节或8字节对齐地字节赋值(OPSIZ为4或8, 在地址对齐之后, 才开始按效率较高的4bytes/8bytes 赋值.
在我以前的理解是, 如果地址没有按某标准类型大小对齐时, 我们在取某标准类型值的时候, 总线会花费更多的指令来读取"两块"地址, 然后合并取值, 导致效率降低.
带着这样的猜测, 我编写了如下测试程序:

1. #include <sys/time.h>
   
2. #include <stdlib.h>
   
3. #include <stdint.h>
   
4. #include <stdio.h>
   
5. #include <string.h>
   
6. #include <iostream>
   
7. using namespace std;
   
8. 
   
9. #define EXEC_COUNT      (1000 * 1000 * 1000)
   
10. 
    
11. typedef long int        op_t;
    
12. 
    
13. int main(int argc_, char* argv_[])
    
14. {
    
15.     void* ori_mem_ptr = malloc(50);
    
16.     memset(ori_mem_ptr, 0, sizeof(ori_mem_ptr));
    
17. 
    
18.     timeval begin_tv;
    
19.     timeval end_tv;
    
20.     for (int offset = 0; offset < 20; ++offset)
    
21.     {
    
22.         char* mem_ptr = (char*)ori_mem_ptr + offset;
    
23.         long int ptr_val = (long int)mem_ptr;
    
24. 
    
25.         printf("ori_mem_ptr:[%p] mem_ptr:[%p] offset:[%d]\n", ori_mem_ptr, mem_ptr, offset);
    
26.         gettimeofday(&begin_tv, NULL);
    
27. 
    
28.         for (uint32_t i = 0; i < EXEC_COUNT; ++i)
    
29.         {
    
30.             *(uint32_t*)mem_ptr = i;
    
31.             //! uint32_t tmp_val = *(uint32_t*)mem_ptr;
    
32.         }
    
33. 
    
34.         gettimeofday(&end_tv, NULL);
    
35.         printf("perf:[%lu]us\n\n", (end_tv.tv_sec * 1000 * 1000 + end_tv.tv_usec) - (begin_tv.tv_sec * 1000 * 1000 + begin_tv.tv_usec));
    
36.     }
    
37. 
    
38.     free(ori_mem_ptr);
    
39. 
    
40.     return 0;
    
41. }
    

复制代码

这样一个简单的程序, 分配了一个内存块, 然后分配偏移指针指向其内部不同的地址, 本意是想测出没有按字节对齐的话, 取值效率会慢, 但是测试结果让我感到疑惑.ori_mem_ptr:[0x18af010] mem_ptr:[0x18af010] offset:[0]
perf:[2736881]us

ori_mem_ptr:[0x18af010] mem_ptr:[0x18af011] offset:[1]
perf:[2730324]us

ori_mem_ptr:[0x18af010] mem_ptr:[0x18af012] offset:[2]
perf:[2728421]us

ori_mem_ptr:[0x18af010] mem_ptr:[0x18af013] offset:[3]
perf:[2704567]us

ori_mem_ptr:[0x18af010] mem_ptr:[0x18af014] offset:[4]
perf:[2711222]us

ori_mem_ptr:[0x18af010] mem_ptr:[0x18af015] offset:[5]
perf:[2710743]us

ori_mem_ptr:[0x18af010] mem_ptr:[0x18af016] offset:[6]
perf:[2715045]us

ori_mem_ptr:[0x18af010] mem_ptr:[0x18af017] offset:[7]
perf:[2720721]us

ori_mem_ptr:[0x18af010] mem_ptr:[0x18af018] offset:[8]
perf:[2707865]us

ori_mem_ptr:[0x18af010] mem_ptr:[0x18af019] offset:[9]
perf:[2750098]us

ori_mem_ptr:[0x18af010] mem_ptr:[0x18af01a] offset:[10]
perf:[2745997]us

ori_mem_ptr:[0x18af010] mem_ptr:[0x18af01b] offset:[11]
perf:[2686419]us

ori_mem_ptr:[0x18af010] mem_ptr:[0x18af01c] offset:[12]
perf:[2686714]us

ori_mem_ptr:[0x18af010] mem_ptr:[0x18af01d] offset:[13]
perf:[3304225]us

ori_mem_ptr:[0x18af010] mem_ptr:[0x18af01e] offset:[14]
perf:[3299947]us

ori_mem_ptr:[0x18af010] mem_ptr:[0x18af01f] offset:[15]
perf:[3303989]us

ori_mem_ptr:[0x18af010] mem_ptr:[0x18af020] offset:[16]
perf:[2747328]us

ori_mem_ptr:[0x18af010] mem_ptr:[0x18af021] offset:[17]
perf:[2687445]us

ori_mem_ptr:[0x18af010] mem_ptr:[0x18af022] offset:[18]
perf:[2703295]us

ori_mem_ptr:[0x18af010] mem_ptr:[0x18af023] offset:[19]
perf:[2688810]us


可以看到输出结果的分界点不是按我所想的那样, 我怀疑是不是虚拟地址是如此, 但是实际的物理地址可以不连续导致, 那如果这样memset这些库函数的做法又让我疑惑了. 对底层不是很懂.
希望CU各位大神能帮我解惑.

zylthinking

编译器优化或gettimeofday的不准确性？

hellioncu

应该是对齐与否赋值的开销差别远比循环的开销小，再加上系统调度的差别，看不出来差别

zhaohongjian000

访存指令地址对齐与否，在支持非对齐访存的CPU上一条指令也就是差几个到几十个周期，这么测可能测不出来。

safedead

你直接用汇编写，循环1亿次
用time ./a.out测试
对齐不对齐差2倍速度最少的

狗气球

和CPU架构的关系大不大？
对RISC和x86的影响程度是否一样？

yulihua49

lyjdamzwf 发表于 2012-01-15 09:20
平时大家一直都在说字节对齐会影响效率如何如何, 最近突然想自己测一下这个问题.
首先我想到了glibc中的me ...

不必太在意这个效率。
不过，这种程序移植到其它CPU可能会崩溃，尽量不要这么用。

egmkang

狗气球 发表于 2012-01-16 10:39
和CPU架构的关系大不大？
对RISC和x86的影响程度是否一样？

有些RISC如果不对齐,直接会中断的

lyjdamzwf

多谢各位的评论, 之后我又测试了不同的类型长度的访存操作, 不同的cpu型, 测试结果均比较无规律化, 有的性能上没有明显的差别, 有的会出现比较奇怪的"分界", 个人觉得可能glibc的用意主要还是如LS几位所说, 为了防止其他一些硬件架构不对齐会中断的问题.

狗气球

回复 9# lyjdamzwf


    建议看一下反汇编。这会儿没空不然我也编两个看看了