字节对齐详解
来自:
Minico's Blog
一.什么是字节对齐,为什么要对齐?
二.字节对齐对程序的影响:
设结构体如下定义: struct A { }; struct B { }; 现在已知 32 位机器上各种数据类型的长度如下 : char:1( 有符号无符号同 ) short:2( 有符号无符号同 ) int:4( 有符号无符号同 ) long:4( 有符号无符号同 ) float:4 那么上面两个结构大小如何呢 ? 结果是 : sizeof(strcut A) 值为 8 sizeof(struct B) 的值却是 12
结构体
A
中包含了
4
字节长度的
int
一个,
1
字节长度的
char
一个和
2
字节长度的
short
型数据一个
,B
也一样
;
按理说
A,B
大小应该都是
7
字节。
之所以出现上面的结果是因为编译器要对数据成员在空间上进行对齐。上面是按照编译器的默认设置进行对齐的结果 , 那么我们是不是可以改变编译器的这种默认对齐设置呢 , 当然可以 . 例如 : #pragma pack (2) struct C { }; #pragma pack () sizeof(struct C) 值是 8 。 修改对齐值为 1 : #pragma pack (1) struct D { }; #pragma pack () sizeof(struct D) 值为 7 。 后面我们再讲解 #pragma pack() 的作用 .
三.编译器是按照什么样的原则进行对齐的?
先让我们看四个重要的基本概念:
1. 数据类型自身的对齐值: 2. 结构体或者类的自身对齐值: 其成员中自身对齐值最大的那个值。 3. 指定对齐值 : #pragma pack (value) 时的指定对齐值 value 。 4. 数据成员、结构体和类的有效对齐值: 自身对齐值和指定对齐值中小的那个值。 有了这些值,我们就可以很方便的来讨论具体数据结构的成员和其自身的对齐方式。有效对齐值 N 是最终用来决定数据存放地址方式的值,最重要。有效对齐 N ,就是表示 “ 对齐在 N 上 ” ,也就是说该数据的 " 存放起始地址 %N=0". 而数据结构中的数据变量都是按定义的先后顺序来排放的。第一个数据变量的起始地址就是数据结构的起始地址。结构体的成员变量要对齐排放,结构体本身也要根据自身的有效对齐值圆整 ( 就是结构体成员变量占用总长度需要是对结构体有效对齐值的整数倍,结合下面例子理解 ) 。这样就不能理解上面的几个例子的值了。 例子分析: 分析例子 B ; struct B { }; 假设 B 从地址空间 0x0000 开始排放。该例子中没有定义指定对齐值,在笔者环境下,该值默认为 4 。第一个成员变量 b 的自身对齐值是 1 ,比指定或者默认指定对齐值 4 小,所以其有效对齐值为 1 ,所以其存放地址 0x0000 符合 0x0000%1=0. 第二个成员变量 a ,其自身对齐值为 4 ,所以有效对齐值也为 4 ,所以只能存放在起始地址为 0x0004 到 0x0007 这四个连续的字节空间中,复核 0x0004%4=0, 且紧靠第一个变量。第三个变量 c, 自身对齐值为 2 ,所以有效对齐值也是 2 ,可以存放在 0x0008 到 0x0009 这两个字节空间中,符合 0x0008%2=0 。所以从 0x0000 到 0x0009 存放的都是 B 内容。再看数据结构 B 的自身对齐值为其变量中最大对齐值 ( 这里是 b )所以就是 4 ,所以结构体的有效对齐值也是 4 。根据结构体圆整的要求, 0x0009 到 0x0000=10 字节,( 10 + 2 )% 4 = 0 。所以 0x0000A 到 0x000B 也为结构体 B 所占用。故 B 从 0x0000 到 0x000B 共有 12 个字节 ,sizeof(struct B)=12; 其实如果就这一个来说它已经满足字节对齐了 , 因为它的起始地址是 0, 因此肯定是对齐的 , 之所以在后面补充 2 个字节 , 是因为编译器为了实现结构数组的存取效率 , 试想如果我们定义了一个结构 B 的数组 , 那么第一个结构起始地址是 0 没有问题 , 但是第二个结构呢 ? 按照数组的定义 , 数组中所有元素都是紧挨着的 , 如果我们不把结构的大小补充为 4 的整数倍 , 那么下一个结构的起始地址将是 0x0000A, 这显然不能满足结构的地址对齐了 , 因此我们要把结构补充成有效对齐大小的整数倍 . 其实诸如 : 对于 char 型数据,其自身对齐值为 1 ,对于 short 型为 2 ,对于 int,float,double 类型,其自身对齐值为 4 ,这些已有类型的自身对齐值也是基于数组考虑的 , 只是因为这些类型的长度已知了 , 所以他们的自身对齐值也就已知了 . 同理 , 分析上面例子 C : #pragma pack (2) struct C { }; #pragma pack () 第一个变量 b 的自身对齐值为 1 ,指定对齐值为 2 ,所以,其有效对齐值为 1 ,假设 C 从 0x0000 开始,那么 b 存放在 0x0000 ,符合 0x0000%1= 0; 第二个变量,自身对齐值为 4 ,指定对齐值为 2 ,所以有效对齐值为 2 ,所以顺序存放在 0x0002 、 0x0003 、 0x0004 、 0x0005 四个连续字节中,符合 0x0002%2=0 。第三个变量 c 的自身对齐值为 2 ,所以有效对齐值为 2 ,顺序存放 在 0x0006 、 0x0007 中,符合 0x0006%2=0 。所以从 0x0000 到 0x00007 共八字节存放的是 C 的变量。又 C 的自身对齐值为 4 ,所以 C 的有效对齐值为 2 。又 8%2=0,C 只占用 0x0000 到 0x0007 的八个字节。所以 sizeof(struct C)=8.
四.如何修改编译器的默认对齐值?
1.
在
VC IDE
中,可以这样修改:
[Project]|[Settings],c/c++
选项卡
Category
的
Code Generation
选项的
Struct Member Alignment
中修改,默认是
8
字节。
2. 在编码时,可以这样动态修改: #pragma pack . 注意 : 是 pragma 而不是 progma.
五.针对字节对齐,我们在编程中如何考虑?
} reserved 成员对我们的程序没有什么意义 , 它只是起到填补空间以达到字节对齐的目的 , 当然即使不加这个成员通常编译器也会给我们自动填补对齐 , 我们自己加上它只是起到显式的提醒作用 .
六.字节对齐可能带来的隐患:
unsigned int i = 0x12345678; unsigned char *p=NULL; unsigned short *p1=NULL;
p=&i;
*p=0x00; p1=(unsigned short *)(p+1); *p1=0x0000; 最后两句代码,从奇数边界去访问 unsignedshort 型变量,显然不符合对齐的规定。 在 x86 上,类似的操作只会影响效率,但是在 MIPS 或者 sparc 上,可能就是一个 error, 因为它们要求必须字节对齐 .
七.如何查找与字节对齐方面的问题:
如果出现对齐或者赋值问题首先查看
1. 编译器的 big little 端设置 2. 看这种体系本身是否支持非对齐访问 3. 如果支持,看设置了对齐与否 , 如果没有则看访问时需要加某些特殊的修饰来标志其特殊访问操作。 from DUI0067D_ADS1_2_CompLib
3.13 type
有部分摘自
ARM
编译器文档对齐部分
对齐的使用
:
1.__align(num) 2.__packed // 将下面变量定义成全局静态不在栈上 static char* p; static struct STRUCT_TEST a; void Main() {
//
这样可以很清楚的看到非对齐访问是如何产生错误的
// 以及如何消除非对齐访问带来问题 // 也可以看到非对齐访问和对齐访问的指令差异导致效率问题 } |
前言:
《***软件编程规范》中提到:“在定义结构数据类型时,为了提高系统效率,要注意4字节对齐原则……”。本文解释x86上字节对齐的机制,其他架构读者可自行试验。同时,本文对C/C++的函数调用方式进行了讨论。
1
.
先看下面的例子:
struct A{
}a;
struct B{
}b;
结构A没有遵守字节对齐原则(为了区分,我将它叫做对齐声明原则),结构B遵守了。我们来看看在x86上会出现什么结果。先打印出a和b的各个成员的地址。会看到a中,各个成员间的间距是4个字节。b中,i和j,j和s都间距4个字节,但是s和c1间距2个字节。所以:
sizeof(a) = 16
sizeof(b) = 12
为什么会有这样的结果呢?这就是x86上字节对齐的作用。为了加快程序执行的速度,一些体系结构以对齐的方式设计,通常以字长作为对齐边界。对于一些结构体变量,整个结构要对齐在内部成员变量最大的对齐边界,如B,整个结构以4为对齐边界,所以sizeof(b)为12,而不是11。
对于A来讲,虽然声明的时候没有对齐,但是根据打印出的地址来看,编译器已经自动为其对齐了,所以每个成员的间距是4。在x86下,声明A与B唯一的差别,仅在于A多浪费了4个字节内存。(是不是某些特定情况下,B比A执行更快,这个还需要讨论。比如紧挨的两条分别取s和c1的指令)
如果体系结构是不对齐的,A中的成员将会一个挨一个存储,从而sizeof(a)为11。显然对齐更浪费了空间。那么为什么要使用对齐呢?
体系结构的对齐和不对齐,是在时间和空间上的一个权衡。对齐节省了时间。假设一个体系结构的字长为w,那么它同时就假设了在这种体系结构上对宽度为w的数据的处理最频繁也是最重要的。它的设计也是从优先提高对w位数据操作的效率来考虑的。比如说读写时,大多数情况下需要读写w位数据,那么数据通道就会是w位。如果所有的数据访问都以w位对齐,那么访问还可以进一步加快,因为需要传输的地址位减少,寻址可以加快。大多数体系结构都是按照字长来对齐访问数据的。不对齐的时候,有的会出错,比如MIPS上会产生bus error,而x86则会进行多次访问来拼接得到的结果,从而降低执行效率。
有些体系结构是必须要求对齐的,如sparc,MIPS。它们在硬件的设计上就强制性的要求对齐。不是因为它们作不到对齐的访问,而是它们认为这样没有意义。它们追求的是速度。
上面讲了体系结构的对齐。在IA-32上面,sizeof(a)为16,就是对齐的结果。下面我们来看,为什么变量声明的时候也要尽量对齐。
我们看到,结构A的声明并不对齐,但是它的成员地址仍是以4为边界对齐的(成员间距为4)。这是编译器的功劳。因为我所用的编译器gcc,默认是对齐的。而x86可以处理不对齐的数据访问,所以这样声明程序并不会出错。但是对于其他结构,只能访问对齐的数据,而编译器又不小心设置了不对齐的选项,则代码就不能执行了。如果按照B的方式声明,则不管编译器是否设置了对齐选项,都能够正确的访问数据。
目前的开发普遍比较重视性能,所以对齐的问题,有三种不同的处理方法:
1
) 采用B的方式声明
2
) 对于逻辑上相关的成员变量希望放在靠近的位置,就写成A的方式。有一种做法是显式的插入reserved成员:
}a;
3
) 随便怎么写,一切交给编译器自动对齐。
代码中关于对齐的隐患,很多是隐式的。比如在强制类型转换的时候。下面举个例子:
unsigned int ui_1=0x12345678;
unsigned char *p=NULL;
unsigned short *us_1=NULL;
p=&ui_1;
*p=0x00;
us_1=(unsigned short *)(p+1);
*us_1=0x0000;
最后两句代码,从奇数边界去访问unsigned short型变量,显然不符合对齐的规定。在x86上,类似的操作只会影响效率,但是在MIPS或者sparc上,可能就是一个bus error(我没有试)。
有些人喜欢通过移动指针来操作结构中的成员(比如在linux操作struct sk_buff的成员),但是我们看到,A中(&c1+1) 决不等于&i。不过B中(&s+2)就是 &c1了。所以,我们清楚了结构中成员的存放位置,才能编写无错的代码。同时切记,不管对于结构,数组,或者普通的变量,在作强制类型转换时一定要多看看:)不过为了不那么累,还是遵守声明对齐原则吧!(这个原则是说变量尽量声明在它的对齐边界上,而且在节省空间的基础上)
2
.C/C++函数调用方式
我们当然早就知道,C/C++中的函数调用,都是以值传递的方式,而不是参数传递。那么,值传递是如何实现的呢?
函数调用前的典型汇编码如下:
push �x
call 0x401394
add $0x10,%esp
首先,入栈的是实参的地址。由于被调函数都是对地址进行操作,所以就能够理解值传递的原理和参数是引用时的情况了。
Call ***
, 是要调用函数了,后面的地址,就是函数的入口地址。Call指令等价于:
首先把当前的执行地址IP压栈,然后跳转到函数执行。
执行完后,被调函数要返回,就要执行RET指令。RET等价于POP IP,恢复CALL之前的执行地址。所以一旦使用CALL指令,堆栈指针SP就会自动减2,因为IP的值进栈了。
函数的参数进栈的顺序是从右到左,这是C与其它语言如pascal的不同之处。函数调用都以以下语句开始:
push �p
mov %esp,�p
首先保存BP的值,然后将当前的堆栈指针传递给BP。那么现在BP+2就是IP的值(16位register的情况),BP+4放第一个参数的值,BP+6放第二个参数……。函数在结束前,要执行POP BP。
C/C++
语言默认的函数调用方式,都是由主调用函数进行参数压栈并且恢复堆栈,实参的压栈顺序是从右到左,最后由主调函数进行堆栈恢复。由于主调用函数管理堆栈,所以可以实现变参函数。
对于WINAPI和CALLBACK函数,在主调用函数中负责压栈,在被调用函数中负责弹出堆栈中的参数,并且负责恢复堆栈。因此不能实现变参函数。
(哪位对编译原理和编译器比较了解的,可以将这个部分写完善,谢谢。可以加入编译时的处理。不然只有等偶继续学习了)字节对齐或内存对齐
转载出处:http://www.blogbus.com/blogbus/blog/archive.php?id=1807
Alignment, Pack and Bit Field . . .
2)关于字节对齐Alignment 的问题现在写出来与大家分享与讨论欢迎指正。
1.
为什么要对齐?
1 8 16 24 32
-------- ------- ------- --------
| long1 | long1 | long1 | long1 |
-------- ------- ------- --------
| | | | long2 |
-------- ------- ------- --------
| long2 | long2 | long2 | |
-------- ------- ------- --------
| ....
2.
一般编译器实现对齐的方法
#pragma pack(8) //
指定Align为 8
struct STest1
{
} test1;
#pragma pack()
现在 Align of STest1 = 4 , sizeof STest1 = 12 ( 4 * 3 )
test1
在内存中的排列如下 FF 为 padding
00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --
01 FF FF FF 01 01 01 01 01 FF FF FF
ch1 -- lo1 -- ch2
#pragma pack(2) //
指定Align为 2
struct STest2
{
} test2;
#pragma pack()
现在 Align of STest1 = 2, Align of STest2 = 2 ,sizeof STest2 = 14 ( 7 * 2 )
test2
在内存中的排列如下
00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --
02 FF 01 FF FF FF 01 01 01 01 01 FF FF FF
ch3 ch1 -- lo1 -- ch2
从以上可以看出用户可以在任何需要的地方定义不同的align值
3.
不同编译器实现用户指定align 值的方法:
4.
使用 #pragma pack 或其他开关需注意的问题
VC
中提供了一种安全使用pack的方法
#pragma pack( [ push | pop ], n )
#pragma pack( push, n)
将当前的align值压入编译器的一个内部堆栈并使用 ,n作为当前的align值,而#pragma pack(pop)则将内部堆栈中的栈顶值作为当前的align值,这样就保证了嵌套pack时的正确。
5.
关于位域 Bit Field
C
中没有进行规定所以如果涉及到位域问题一定要查看手册。
6.
附例
例中定义了如下几个结构
typedef struct tagSLong
{
char chMem1;
char chMem2;
char chMem3;
unsigned short wMem4;
unsigned long dwMem5;
unsigned short wMem6;
char chMem7;
}SLong;
typedef struct tagSShort
{
char chMem1;
unsigned short wMem2;
char chMem3;
}SShort;
typedef union tagun
{
char uChar;
unsigned short uWord;
}un;
typedef struct tagComplex
{
char chItem1;
SLong struItem2;
unsigned long dwItem3;
char chItem4;
un unItem5;
}Complex;
测试时对每个结构的成员按 1 2 3 ... 依次进行赋值FF 为Padding
下面列出了每个结构的size Align的大小及其空间分配
1. Now the Align(Pack) size is 8
sizeof(SLong) = 16 Alignment of (SLong) = 4
00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --
01 02 03 FF 04 00 FF FF 05 00 00 00 06 00 07 FF
sizeof(SShort) = 6 Alignment of (SShort) = 2
00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --
01 FF 02 00 03 FF
sizeof(Complex) = 28 Alignment of (Complex) = 4
[Notice the alignment of (SLong) = 4 and (un)=2 ]
00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --
01 FF FF FF 01 02 03 FF 04 00 FF FF 05 00 00 00
06 00 07 FF 08 00 00 00 09 FF 0A 00
sizeof(SLong[2]) = 32 Alignment of (SLong[2]) = 4
[Notice the alignment of (SLong) = 4 ]
00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --
01 02 03 FF 04 00 FF FF 05 00 00 00 06 00 07 FF
01 02 03 FF 04 00 FF FF 05 00 00 00 06 00 07 FF
sizeof(un) = 2 Alignment of (un) = 2
00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --
02 00
2. Now the Align(Pack) size is 4
sizeof(SLong) = 16 Alignment of (SLong) = 4
00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --
01 02 03 FF 04 00 FF FF 05 00 00 00 06 00 07 FF
sizeof(SShort) = 6 Alignment of (SShort) = 2
00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --
01 FF 02 00 03 FF
sizeof(Complex) = 28 Alignment of (Complex) = 4
00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --
01 FF FF FF 01 02 03 FF 04 00 FF FF 05 00 00 00
06 00 07 FF 08 00 00 00 09 FF 0A 00
sizeof(SLong[2]) = 32 Alignment of (SLong[2]) = 4
00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --
01 02 03 FF 04 00 FF FF 05 00 00 00 06 00 07 FF
01 02 03 FF 04 00 FF FF 05 00 00 00 06 00 07 FF
sizeof(un) = 2 Alignment of (un) = 2
00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --
02 00
3. Now the Align(Pack) size is 2
sizeof(SLong) = 14 Alignment of (SLong) = 2
00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --
01 02 03 FF 04 00 05 00 00 00 06 00 07 FF
sizeof(SShort) = 6 Alignment of (SShort) = 2
00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --
01 FF 02 00 03 FF
sizeof(Complex) = 24 Alignment of (Complex) = 2
[Notice the alignment of (SLong) = 2 and (un) = 2
00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --
01 FF 01 02 03 FF 04 00 05 00 00 00 06 00 07 FF
08 00 00 00 09 FF 0A 00
sizeof(SLong[2]) = 28 Alignment of (SLong[2]) = 2
00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --
01 02 03 FF 04 00 05 00 00 00 06 00 07 FF 01 02
03 FF 04 00 05 00 00 00 06 00 07 FF
sizeof(un) = 2 Alignment of (un) = 2
00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --
02 00
4. Now the Align(Pack) size is 1
sizeof(SLong) = 12 Alignment of (SLong) = 1
00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --
01 02 03 04 00 05 00 00 00 06 00 07
sizeof(SShort) = 4 Alignment of (SShort) = 1
00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --
01 02 00 03
sizeof(Complex) = 20 Alignment of (Complex) = 1
[Notice the alignment of (SLong) = 1 and (un) = 1]
00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --
01 01 02 03 04 00 05 00 00 00 06 00 07 08 00 00
00 09 0A 00
sizeof(SLong[2]) = 24 Alignment of (SLong[2]) = 1
[Notice the alignment of (SLong) = 1 ]
00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --
01 02 03 04 00 05 00 00 00 06 00 07 01 02 03 04
00 05 00 00 00 06 00 07
sizeof(un) = 2 Alignment of (un) = 1
00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --
02 00
关于pack 使用的几点建议及需注意的问题
0.
由于各种编译器对pack的实现各不相同建议定义几个头文件(参照microsoft的做法)
poppack.h, pshpack1.h, pshpack2.h ...
其中poppack.h用于恢复编译器的缺省pack值其大略定义如下
#if _HA_WIN32 //for Visual C++
#pragma pack()
#elif _HA_GNU //for gcc960
#pragma pack
#pragma align 0
#elif ... for any more
pshpack1(n).h
用于指定编译器的pack值为 n , 其大略定义如下
#if _HA_WIN32 //for Visual C++
#pragma pack(1)//n
#elif _HA_GNU //for gcc960
#pragma pack 1//n
#pragma align 1//n
#elif ... //for any more
使用时在需要pack的地方加上 #include "pshpack1.h" ,
在需要恢复pack的地方加上 #include "poppack.h" .
使用这种头文件的方式有如下几点好处:
1.
为了保证执行速度在没有必要的地方不要使用#pragma pack 不要只为了节省空间而使用BYTE等类型,其实数据的空间是减少了但代码的空间却变大了,如本来只需一条指令的地方可能需三四条指令,既影响了执行速度又增加了空间,得不偿失。如果必须使用BYTE等类型,尽可能将其在结构中排成自然对齐。
2.
不同的编译器生成的代码极有可能不同,一定要查看相应手册并做实验。
如对于如下结构定义
struct SLanDest
{
WORD wTag;
MACADDR addr;
};
该结构在VC下是不加padding的但在pRism下就加了padding
3.
需要加pack的地方一定要在定义结构的头文件中加,不要依赖命令行选项。因为如果很多人使用该头文件,并不是每个人都知道应该pack 特别是为别人开发库文件时如果一个库函数使用了struct作为其参数,当调用者与库文件开发者使用不同的pack时,就会造成错误,而且该类错误很不好查。在VC及BC提供的头文件中除了能正好对齐在四字节上的结构外都加了pack, 否则我们编的Windows程序哪一个也不会正常运行。
4.
在 #include "pshpack1.h"后一定不要include其他头文件,若包含的头文件中改变了align值,如包含了#include "poppack.h" 将产生非预期结果。
5.
不要多人同时定义一个数据结构,在多人合作开发一个软件模块时,为了保持自己的编程风格,每个人都要对同一结构定义一份符合自己风格的数据类型。当两个人之间需要传递该数据结构时如果两个人的 pack值不一样就会产生错误,该类错误也很难查。所以为了安全起见我们还是舍弃一些自己的风格吧。
6.
何时需要加pack?
在编写通信协议时通信协议的帧结构对于所有跨CPU的协议都应理解为通信协议。如邮箱通信主机与主机通过通信线路进行通信等编写硬件驱动程序时,寄存器的结构这两个地方都需要加pack1 即使看起来本来就自然对齐的也要加pack 以免不同的编译器生成的代码不一样。如 2.中的例子对于运行时只与一个CPU有关的结构为了提高执行速度请不要加pack。
3)VC中字节对齐问题
1
、 sizeof应用在结构上的情况
gcc
的字节对齐扩展
在阅读ffmpeg代码时经常看到类似下面的语句:
#pragma pack(n)
#pragma pack()
和
__attribute((aligned (8)))
__attribute__ ((packed));
例如:
# ifdef __GNUC__
static inline uint32_t unaligned32(const void *v)
{
}
struct FieldTest
{
}__attribute__((packed)) ft;
//
取消编译器优化对齐,取实际长度
//----------------------------------------------------
这两种方式是gcc的c扩展,用来对齐的,包括栈对齐,变量地址对齐,内存分配对齐和结构体对齐方式.
Note:
在设置新的#pragma pack(n)之前,应该先取消以前的对齐,也就是说要调用一下#pragma pack().
#pragma pack(n)
n
的取值可以为1、2、4、8,在编译过程中按照n个字结对齐
#pragma pack()
取消对齐,按照编译器的优化对齐方式对齐
__attribute__ ((packed));
是说取消结构在编译过程中的优化对齐。
__attribute__ ((aligned (n)));
让所作用的成员对齐在n字节自然边界上,如果结构中有成员的长度大于n,则按照机器字长来对齐
gcc
手册中说了不建议使用 #pragma,而且#pragma最多只能支持8字节的对齐.
由于不同编译器可能对对齐的实现有区别,在不同编译器编译的程序间进行数据传递就有可能要用到这些东西了.
struct abc {
u32 sid;
u8 p;
union {
int digest[4];
char ctldta[10];
} data;
char dummy[0] __attribute__ ((aligned (64)));
} __attribute__ ((packed));
//__attribute__ ((packed));
是说取消结构在编译过程中的优化对齐。
//__attribute__ ((aligned (64)));
是说让dummy成员对齐在64-bit自然边界上。
#include
struct FieldTest
{
} __attribute__((aligned(16))) ft; //Aligned by 128 bit
int main(int argc,char** argv)
{
}
//---------------------------------------------------------
g++ packed_test.cpp -o test.exe -Wno-deprecated
./test.exe
the size of FieldTest is 16
人为对齐就是保证每组数据都是4字节的。
例如:
{
char s1[3] ;
long l ;
char s2 ;
}
应改为
{
char s1[3] ;
char s2 ;
long l ;
}
同理,
{
short a ;
long l ;
short b ;
}
应改为
{
short a ;
short b ;
long l ;
}
就是保证每个数据的起始位置符合4字节对齐要求。
若是有奇数个short, 如:
{
short s1;
short s2;
short s3;
long l ;
}
那么要想对齐, 就得手工补足:
{
short s1;
short s2;
short s3;
short temp ;
long l ;
}
这样就不用编译器帮你对齐了。它的最大好处其实是不论1,2,4字节对齐,
编译器生成的结构都是一样的。 这在通信和文件保存方面有莫大的好处。
char
也一样, 全应补足为4字节。
更改C编译器的缺省字节对齐方式
• 使用伪指令#pragma pack (n),C编译器将按照n个字节对齐。
以上的n = 1, 2, 4, 8, 16... 第一种方式较为常见。
应用实例
在网络协议编程中,经常会处理不同协议的数据报文。一种方法是通过指针偏移的方法来得到各种信息,但这样做不仅编程复杂,而且一旦协议有变化,程序修改起来也比较麻烦。在了解了编译器对结构空间的分配原则之后,我们完全可以利用这一特性定义自己的协议结构,通过访问结构的成员来获取各种信息。这样做,不仅简化了编程,而且即使协议发生变化,我们也只需修改协议结构的定义即可,其它程序无需修改,省时省力。下面以TCP协议首部为例,说明如何定义协议结构。其协议结构定义如下:
#pragma pack(1) //
按照1字节方式进行对齐
struct TCPHEADER
{
};
#pragma pack() //
取消1字节对齐方式
4)C++ 代码优化
谈到优化,很多人都会直接想到汇编。难道优化只能在汇编层次吗?当然不是,C++层次一样可以作代码优化,其中有些常常是意想不到的。在C++层次进行优化,比在汇编层次优化具有更好的移植性,应该是优化中的首选做法。
确定浮点型变量和表达式是 float 型
为了让编译器产生更好的代码(比如说产生3DNow! 或SSE指令的代码),必须确定浮点型变量和表达式是 float 型的。要特别注意的是,以 ";F"; 或 ";f"; 为后缀(比如:3.14f)的浮点常量才是 float 型,否则默认是 double 型。为了避免 float 型参数自动转化为 double,请在函数声明时使用 float。
使用32位的数据类型
编译器有很多种,但它们都包含的典型的32位类型是:int,signed,signed int,unsigned,unsigned int,long,signed long,long int,signed long int,unsigned long,unsigned long int。尽量使用32位的数据类型,因为它们比16位的数据甚至8位的数据更有效率。
明智使用有符号整型变量
在很多情况下,你需要考虑整型变量是有符号还是无符号类型的。比如,保存一个人的体重数据时不可能出现负数,所以不需要使用有符号类型。但是,如果是要保存温度数据,就必须使用到有符号的变量。
在许多地方,考虑是否使用有符号的变量是必要的。在一些情况下,有符号的运算比较快;但在一些情况下却相反。
比如:整型到浮点转化时,使用大于16位的有符号整型比较快。因为x86构架中提供了从有符号整型转化到浮点型的指令,但没有提供从无符号整型转化到浮点的指令。看看编译器产生的汇编代码:
不好的代码:
编译前 编译后
double x
; mov [foo + 4], 0
unsigned int i
; mov eax, i
x = i
; mov [foo], eax
flid qword ptr [foo]
fstp qword ptr [x]
上面的代码比较慢。不仅因为指令数目比较多,而且由于指令不能配对造成的FLID指令被延迟执行。最好用以下代码代替:
推荐的代码:
编译前 编译后
double x
; fild dword ptr [i]
int i
; fstp qword ptr [x]
x = i
;
在整数运算中计算商和余数时,使用无符号类型比较快。以下这段典型的代码是编译器产生的32位整型数除以4的代码:
不好的代码 推荐的代码
编译前 编译后
int i
; mov eax, i
i = i / 4
; cdq
and edx, 3
add eax, edx
sar eax, 2
mov i, eax
编译前 编译后
unsigned int i
; shr i, 2
i = i / 4
;
总结:
无符号类型用于:
除法和余数
循环计数
数组下标
有符号类型用于:
整型到浮点的转化
while VS. for
在编程中,我们常常需要用到无限循环,常用的两种方法是while (1) 和 for (;;)。这两种方法效果完全一样,但那一种更好呢?然我们看看它们编译后的代码:
编译前 编译后
while (1)
; mov eax,1
test eax,eax
je foo+23h
jmp foo+18h
编译前 编译后
for (
;;); jmp foo+23h
一目了然,for (;;)指令少,不占用寄存器,而且没有判断跳转,比while (1)好。
使用数组型代替指针型
使用指针会使编译器很难优化它。因为缺乏有效的指针代码优化的方法,编译器总是假设指针可以访问内存的任意地方,包括分配给其他变量的储存空间。所以为了编译器产生优化得更好的代码,要避免在不必要的地方使用指针。一个典型的例子是访问存放在数组中的数据。C++ 允许使用操作符 [] 或指针来访问数组,使用数组型代码会让优化器减少产生不安全代码的可能性。比如,x[0] 和x[2] 不可能是同一个内存地址,但 *p 和 *q 可能。强烈建议使用数组型,因为这样可能会有意料之外的性能提升。
不好的代码 推荐的代码
typedef struct
{
float x,y,z,w;
} VERTEX
;
typedef struct
{
float m[4][4];
} MATRIX
;
void XForm(float* res, const float* v, const float* m, int nNumVerts)
{
float dp;
int i;
const VERTEX* vv = (VERTEX *)v;
for (i = 0; i <; nNumVerts; i++)
{
dp = vv->;x * *m ++;
dp += vv->;y * *m ++;
dp += vv->;z * *m ++;
dp += vv->;w * *m ++;
*res ++ = dp; // 写入转换了的 x
dp = vv->;x * *m ++;
dp += vv->;y * *m ++;
dp += vv->;z * *m ++;
dp += vv->;w * *m ++;
*res ++ = dp; // 写入转换了的 y
dp = vv->;x * *m ++;
dp += vv->;y * *m ++;
dp += vv->;z * *m ++;
dp += vv->;w * *m ++;
*res ++ = dp; // 写入转换了的 z
dp = vv->;x * *m ++;
dp += vv->;y * *m ++;
dp += vv->;z * *m ++;
dp += vv->;w * *m ++;
*res ++ = dp; // 写入转换了的 w
vv ++; // 下一个矢量
m -= 16;
}
}
typedef struct
{
float x,y,z,w;
} VERTEX
;
typedef struct
{
float m[4][4];
} MATRIX
;
void XForm (float* res, const float* v, const float* m, int nNumVerts)
{
int i;
const VERTEX* vv = (VERTEX*)v;
const MATRIX* mm = (MATRIX*)m;
VERTEX* rr = (VERTEX*)res;
for (i = 0; i <; nNumVerts; i++)
{
rr->;x = vv->;x * mm->;m[0][0] + vv->;y * mm->;m[0][1]
+ vv->;z * mm->;m[0][2] + vv->;w * mm->;m[0][3];
rr->;y = vv->;x * mm->;m[1][0] + vv->;y * mm->;m[1][1]
+ vv->;z * mm->;m[1][2] + vv->;w * mm->;m[1][3];
rr->;z = vv->;x * mm->;m[2][0] + vv->;y * mm->;m[2][1]
+ vv->;z * mm->;m[2][2] + vv->;w * mm->;m[2][3];
rr->;w = vv->;x * mm->;m[3][0] + vv->;y * mm->;m[3][1]
+ vv->;z * mm->;m[3][2] + vv->;w * mm->;m[3][3];
}
}
注意: 源代码的转化是与编译器的代码发生器相结合的。从源代码层次很难控制产生的机器码。依靠编译器和特殊的源代码,有可能指针型代码编译成的机器码比同等条件下的数组型代码运行速度更快。明智的做法是在源代码转化后检查性能是否真正提高了,再选择使用指针型还是数组型。
充分分解小的循环
要充分利用CPU的指令缓存,就要充分分解小的循环。特别是当循环体本身很小的时候,分解循环可以提高性能。BTW:很多编译器并不能自动分解循环。
不好的代码 推荐的代码
// 3D
转化:把矢量 V 和 4x4 矩阵 M 相乘
for (i = 0
; i <; 4; i ++)
{
r[i] = 0;
for (j = 0; j <; 4; j ++)
{
r[i] += M[j][i]*V[j];
}
}
r[0] = M[0][0]*V[0] + M[1][0]*V[1] + M[2][0]*V[2] + M[3][0]*V[3]
;
r[1] = M[0][1]*V[0] + M[1][1]*V[1] + M[2][1]*V[2] + M[3][1]*V[3]
;
r[2] = M[0][2]*V[0] + M[1][2]*V[1] + M[2][2]*V[2] + M[3][2]*V[3]
;
r[3] = M[0][3]*V[0] + M[1][3]*V[1] + M[2][3]*V[2] + M[3][3]*v[3]
;
避免没有必要的读写依赖
当数据保存到内存时存在读写依赖,即数据必须在正确写入后才能再次读取。虽然AMD Athlon等CPU有加速读写依赖延迟的硬件,允许在要保存的数据被写入内存前读取出来,但是,如果避免了读写依赖并把数据保存在内部寄存器中,速度会更快。在一段很长的又互相依赖的代码链中,避免读写依赖显得尤其重要。如果读写依赖发生在操作数组时,许多编译器不能自动优化代码以避免读写依赖。所以推荐程序员手动去消除读写依赖,举例来说,引进一个可以保存在寄存器中的临时变量。这样可以有很大的性能提升。下面一段代码是一个例子:
不好的代码 推荐的代码
float x[VECLEN], y[VECLEN], z[VECLEN]
;
......
for (unsigned int k = 1
; k <; VECLEN; k ++)
{
x[k] = x[k-1] + y[k];
}
for (k = 1
; k <; VECLEN; k++)
{
x[k] = z[k] * (y[k] - x[k-1]);
}
float x[VECLEN], y[VECLEN], z[VECLEN]
;
......
float t(x[0])
;
for (unsigned int k = 1
; k <; VECLEN; k ++)
{
t = t + y[k];
x[k] = t;
}
t = x[0]
;
for (k = 1
; k <; VECLEN; k ++)
{
t = z[k] * (y[k] - t);
x[k] = t;
}
Switch 的用法
Switch 可能转化成多种不同算法的代码。其中最常见的是跳转表和比较链/树。推荐对case的值依照发生的可能性进行排序,把最有可能的放在第一个,当switch用比较链的方式转化时,这样可以提高性能。此外,在case中推荐使用小的连续的整数,因为在这种情况下,所有的编译器都可以把switch 转化成跳转表。
不好的代码 推荐的代码
int days_in_month, short_months, normal_months, long_months
;
......
switch (days_in_month)
{
case 28:
case 29:
short_months ++;
break;
case 30:
normal_months ++;
break;
case 31:
long_months ++;
break;
default:
cout <;<; ";month has fewer than 28 or more than 31 days"; <;<; endl;
break;
}
int days_in_month, short_months, normal_months, long_months
;
......
switch (days_in_month)
{
case 31:
long_months ++;
break;
case 30:
normal_months ++;
break;
case 28:
case 29:
short_months ++;
break;
default:
cout <;<; ";month has fewer than 28 or more than 31 days"; <;<; endl;
break;
}
所有函数都应该有原型定义
一般来说,所有函数都应该有原型定义。原型定义可以传达给编译器更多的可能用于优化的信息。
尽可能使用常量(const)
尽可能使用常量(const)。C++ 标准规定,如果一个const声明的对象的地址不被获取,允许编译器不对它分配储存空间。这样可以使代码更有效率,而且可以生成更好的代码。
提升循环的性能
要提升循环的性能,减少多余的常量计算非常有用(比如,不随循环变化的计算)。
不好的代码(在for()中包含不变的if()) 推荐的代码
for( i ... )
{
if( CONSTANT0 )
{
DoWork0( i ); // 假设这里不改变CONSTANT0的值
}
else
{
DoWork1( i ); // 假设这里不改变CONSTANT0的值
}
}
if( CONSTANT0 )
{
for( i ... )
{
DoWork0( i );
}
}
else
{
for( i ... )
{
DoWork1( i );
}
}
如果已经知道if()的值,这样可以避免重复计算。虽然不好的代码中的分支可以简单地预测,但是由于推荐的代码在进入循环前分支已经确定,就可以减少对分支预测的依赖。 把本地函数声明为静态的(static)
如果一个函数在实现它的文件外未被使用的话,把它声明为静态的(static)以强制使用内部连接。否则,默认的情况下会把函数定义为外部连接。这样可能会影响某些编译器的优化——比如,自动内联。
考虑动态内存分配
动态内存分配(C++中的";new";)可能总是为长的基本类型(四字对齐)返回一个已经对齐的指针。但是如果不能保证对齐,使用以下代码来实现四字对齐。这段代码假设指针可以映射到 long 型。
例子
double* p = (double*)new BYTE[sizeof(double) * number_of_doubles+7L];
double* np = (double*)((long(p) + 7L) &
; –8L);
现在,你可以使用 np 代替 p 来访问数据。注意:释放储存空间时仍然应该用delete p。
使用显式的并行代码
尽可能把长的有依赖的代码链分解成几个可以在流水线执行单元中并行执行的没有依赖的代码链。因为浮点操作有很长的潜伏期,所以不管它被映射成 x87 或 3DNow! 指令,这都很重要。很多高级语言,包括C++,并不对产生的浮点表达式重新排序,因为那是一个相当复杂的过程。需要注意的是,重排序的代码和原来的代码在代数上一致并不等价于计算结果一致,因为浮点操作缺乏精确度。在一些情况下,这些优化可能导致意料之外的结果。幸运的是,在大部分情况下,最后结果可能只有最不重要的位(即最低位)是错误的。
不好的代码 推荐的代码
double a[100], sum
;
int i
;
sum = 0.0f
;
for (i=0
; i<;100; i++)
sum += a[i];
double a[100], sum1, sum2, sum3, sum4, sum
;
int i
;
sum1 = sum2 = sum3 = sum4 = 0.0
;
for (i = 0
; i <; 100; i += 4)
{
sum1 += a[i];
sum2 += a[i+1];
sum3 += a[i+2];
sum4 += a[i+3];
}
sum = (sum4+sum3)+(sum1+sum2)
;
要注意的是:使用4 路分解是因为这样使用了4阶段流水线浮点加法,浮点加法的每一个阶段占用一个时钟周期,保证了最大的资源利用率。
提出公共子表达式
在某些情况下,C++编译器不能从浮点表达式中提出公共的子表达式,因为这意味着相当于对表达式重新排序。需要特别指出的是,编译器在提取公共子表达式前不能按照代数的等价关系重新安排表达式。这时,程序员要手动地提出公共的子表达式(在VC.net里有一项“全局优化”选项可以完成此工作,但效果就不得而知了)。
推荐的代码
float a, b, c, d, e, f
;
...
e = b * c / d
;
f = b / d * a
;
float a, b, c, d, e, f
;
...
const float t(b / d)
;
e = c * t
;
f = a * t
;
推荐的代码
float a, b, c, e, f
;
...
e = a / c
;
f = b / c
;
float a, b, c, e, f
;
...
const float t(1.0f / c)
;
e = a * t
;
f = b * t
;
结构体成员的布局
很多编译器有“使结构体字,双字或四字对齐”的选项。但是,还是需要改善结构体成员的对齐,有些编译器可能分配给结构体成员空间的顺序与他们声明的不同。但是,有些编译器并不提供这些功能,或者效果不好。所以,要在付出最少代价的情况下实现最好的结构体和结构体成员对齐,建议采取这些方法:
按类型长度排序
把结构体的成员按照它们的类型长度排序,声明成员时把长的类型放在短的前面。
把结构体填充成最长类型长度的整倍数
把结构体填充成最长类型长度的整倍数。照这样,如果结构体的第一个成员对齐了,所有整个结构体自然也就对齐了。下面的例子演示了如何对结构体成员进行重新排序:
不好的代码,普通顺序 推荐的代码,新的顺序并手动填充了几个字节
struct
{
char a[5];
long k;
double x;
} baz
;
struct
{
double x;
long k;
char a[5];
char pad[7]
;
} baz
;
这个规则同样适用于类的成员的布局。
按数据类型的长度排序本地变量
当编译器分配给本地变量空间时,它们的顺序和它们在源代码中声明的顺序一样,和上一条规则一样,应该把长的变量放在短的变量前面。如果第一个变量对齐了,其它变量就会连续的存放,而且不用填充字节自然就会对齐。有些编译器在分配变量时不会自动改变变量顺序,有些编译器不能产生4字节对齐的栈,所以4字节可能不对齐。下面这个例子演示了本地变量声明的重新排序:
不好的代码,普通顺序 推荐的代码,改进的顺序
short ga, gu, gi
;
long foo, bar
;
double x, y, z[3]
;
char a, b
;
float baz
;
double z[3]
;
double x, y
;
long foo, bar
;
float baz
;
short ga, gu, gi
;
避免不必要的整数除法
整数除法是整数运算中最慢的,所以应该尽可能避免。一种可能减少整数除法的地方是连除,这里除法可以由乘法代替。这个替换的副作用是有可能在算乘积时会溢出,所以只能在一定范围的除法中使用。
不好的代码 推荐的代码
int i, j, k, m
;
m = i / j / k
;
int i, j, k, m
;
m = i / (j * k)
;
把频繁使用的指针型参数拷贝到本地变量
避免在函数中频繁使用指针型参数指向的值。因为编译器不知道指针之间是否存在冲突,所以指针型参数往往不能被编译器优化。这样是数据不能被存放在寄存器中,而且明显地占用了内存带宽。注意,很多编译器有“假设不冲突”优化开关(在VC里必须手动添加编译器命令行/Oa或/Ow),这允许编译器假设两个不同的指针总是有不同的内容,这样就不用把指针型参数保存到本地变量。否则,请在函数一开始把指针指向的数据保存到本地变量。如果需要的话,在函数结束前拷贝回去。 不好的代码 推荐的代码
?/
假设 q != r
void isqrt(unsigned long a, unsigned long* q, unsigned long* r)
{
*q = a;
if (a >; 0)
{
while (*q >; (*r = a / *q))
{
*q = (*q + *r) >;>; 1;
}
}
*r = a - *q * *q;
}
//
假设 q != r
void isqrt(unsigned long a, unsigned long* q, unsigned long* r)
{
unsigned long qq, rr;
qq = a;
if (a >; 0)
{
while (qq >; (rr = a / qq))
{
qq = (qq + rr) >;>; 1;
}
}
rr = a - qq * qq;
*q = qq;
*r = rr;
}
赋值与初始化
先看看以下代码:
class CInt
{
int m_i;
public:
CInt(int a = 0):m_i(a) { cout <;<; ";CInt"; <;<; endl; }
~CInt() { cout <;<; ";~CInt"; <;<; endl; }
CInt operator + (const CInt&; a) { return CInt(m_i + a.GetInt()); }
void SetInt(const int i) { m_i = i; }
int GetInt() const { return m_i; }
}
;
不好的代码 推荐的代码
void main()
{
CInt a, b, c;
a.SetInt(1);
b.SetInt(2);
c = a + b;
}
void main()
{
CInt a(1), b(2);
CInt c(a + b);
}
这两段代码所作的事都一样,但那一个更好呢?看看输出结果就会发现,不好的代码输出了四个";CInt";和四个";~CInt";,而推荐的代码只输出三个。也就是说,第二个例子比第一个例子少生成一次临时对象。Why? 请注意,第一个中的c用的是先声明再赋值的方法,第二个用的是初始化的方法,它们有本质的区别。第一个例子的";c = a + b";先生成一个临时对象用来保存a + b的值,再把该临时对象用位拷贝的方法给c赋值,然后临时对象被销毁。这个临时对象就是那个多出来的对象。第二个例子直接用拷贝构造函数的方法对c初始化,不产生临时对象。所以,尽量在需要使用一个对象时才声明,并用初始化的方法赋初值。
尽量使用成员初始化列表
在初始化类的成员时,尽量使用成员初始化列表而不是传统的赋值方式。
不好的代码 推荐的代码
籧lass CMyClass
{
string strName;
public:
CMyClass(const string&; str);
}
;
CMyClass::CMyClass(const string&
; str)
{
strName = str;
}
class CMyClass
{
string strName;
int i;
public:
CMyClass(const string&; str);
}
;
CMyClass::CMyClass(const string&
;str)
: strName(str)
{
}
不好的例子用的是赋值的方式。这样,strName会先被建立(调用了string的默认构造函数),再由参数str赋值。而推荐的例子用的是成员初始化列表,strName直接构造为str,少调用一次默认构造函数,还少了一些安全隐患。