- 浏览: 40990 次
- 性别:
- 来自: 北京
最新评论
一 内存读取粒度 Memory access granularity
Programmers are conditioned to think of memory as a simple array of bytes. Among C and its descendants, char*
is ubiquitous as meaning "a block of memory", and even Java? has its byte[]
type to represent raw memory.
Figure 1. How programmers see memory
However, your computer's processor does not read from and write to memory in byte-sized chunks. Instead, it accesses memory in two-, four-, eight- 16- or even 32-byte chunks. We'll call the size in which a processor accesses memory its memory access granularity.
Figure 2. How processors see memory
The difference between how high-level programmers think of memory and how modern processors actually work with memory raises interesting issues that this article explores.
If you don't understand and address alignment issues in your software, the following scenarios, in increasing order of severity, are all possible:
- Your software will run slower.
- Your application will lock up.
- Your operating system will crash.
- Your software will silently fail, yielding incorrect results.
To illustrate the principles behind alignment, examine a constant task, and how it's affected by a processor's memory access granularity. The task is simple: first read four bytes from address 0 into the processor's register. Then read four bytes from address 1 into the same register.
First examine what would happen on a processor with a one-byte memory access granularity:
Figure 3. Single-byte memory access granularity
This fits in with the naive programmer's model of how memory works: it takes the same four memory accesses to read from address 0 as it does from address 1. Now see what would happen on a processor with two-byte granularity, like the original 68000:
Figure 4. Double-byte memory access granularity
When reading from address 0, a processor with two-byte granularity takes half the number of memory accesses as a processor with one-byte granularity. Because each memory access entails a fixed amount overhead, minimizing the number of accesses can really help performance.
However, notice what happens when reading from address 1. Because the address doesn't fall evenly on the processor's memory access boundary, the processor has extra work to do. Such an address is known as an unaligned address. Because address 1 is unaligned, a processor with two-byte granularity must perform an extra memory access, slowing down the operation.
Finally, examine what would happen on a processor with four-byte memory access granularity, like the 68030 or PowerPC? 601:
Figure 5. Quad-byte memory access granularity
A processor with four-byte granularity can slurp up four bytes from an aligned address with one read. Also note that reading from an unaligned address doubles the access count.
Now that you understand the fundamentals behind aligned data access, you can explore some of the issues related to alignment.
A processor has to perform some tricks when instructed to access an unaligned address. Going back to the example of reading four bytes from address 1 on a processor with four-byte granularity, you can work out exactly what needs to be done:
Figure 6. How processors handle unaligned memory access
The processor needs to read the first chunk of the unaligned address and shift out the "unwanted" bytes from the first chunk. Then it needs to read the second chunk of the unaligned address and shift out some of its information. Finally, the two are merged together for placement in the register. It's a lot of work.
Some processors just aren't willing to do all of that work for you.
The original 68000 was a processor with two-byte granularity and lacked the circuitry to cope with unaligned addresses. When presented with such an address, the processor would throw an exception. The original Mac OS didn't take very kindly to this exception, and would usually demand the user restart the machine. Ouch.
Later processors in the 680x0 series, such as the 68020, lifted this restriction and performed the necessary work for you. This explains why some old software that works on the 68020 crashes on the 68000. It also explains why, way back when, some old Mac coders initialized pointers with odd addresses. On the original Mac, if the pointer was accessed without being reassigned to a valid address, the Mac would immediately drop into the debugger. Often they could then examine the calling chain stack and figure out where the mistake was.
All processors have a finite number of transistors to get work done. Adding unaligned address access support cuts into this "transistor budget." These transistors could otherwise be used to make other portions of the processor work faster, or add new functionality altogether.
An example of a processor that sacrifices unaligned address access support in the name of speed is MIPS. MIPS is a great example of a processor that does away with almost all frivolity in the name of getting real work done faster.
The PowerPC takes a hybrid approach. Every PowerPC processor to date has hardware support for unaligned 32-bit integer access. While you still pay a performance penalty for unaligned access, it tends to be small.
On the other hand, modern PowerPC processors lack hardware support for unaligned 64-bit floating-point access. When asked to load an unaligned floating-point number from memory, modern PowerPC processors will throw an exception and have the operating system perform the alignment chores in software. Performing alignment in software is much slower than performing it in hardware.
内存对齐有一个好处是提高访问内存的速度,因为在许多数据结构中都需要占用内存,在很多系统中,要求内存分配的时候要对齐.下面是对为什么可以提高内存速度通过代码做了解释!
代码解释Writing some tests illustrates the performance penalties of unaligned memory access. The test is simple: you read, negate, and write back the numbers in a ten-megabyte buffer. These tests have two variables:
- The size, in bytes, in which you process the buffer. First you'll process the buffer one byte at a time. Then you'll move onto two-, four- and eight-bytes at a time.
- The alignment of the buffer. You'll stagger the alignment of the buffer by incrementing the pointer to the buffer and running each test again.
These tests were performed on a 800 MHz PowerBook G4. To help normalize performance fluctuations from interrupt processing, each test was run ten times, keeping the average of the runs. First up is the test that operates on a single byte at a time:
Listing 1. Munging data one byte at a timevoid Munge8( void *data, uint32_t size ) {
uint8_t *data8 = (uint8_t*) data;
uint8_t *data8End = data8 + size;
while( data8 != data8End ) {
*data8++ = -*data8;
}
}
It took an average of 67,364 microseconds to execute this function. Now modify it to work on two bytes at a time instead of one byte at a time -- which will halve the number of memory accesses:
Listing 2. Munging data two bytes at a time
void Munge16( void *data, uint32_t size ) { uint16_t *data16 = (uint16_t*) data; uint16_t *data16End = data16 + (size >> 1); /* Divide size by 2. */ uint8_t *data8 = (uint8_t*) data16End; uint8_t *data8End = data8 + (size & 0x00000001); /* Strip upper 31 bits. */ while( data16 != data16End ) { *data16++ = -*data16; } while( data8 != data8End ) { *data8++ = -*data8; } }
This function took 48,765 microseconds to process the same ten-megabyte buffer -- 38% faster than Munge8. However, that buffer was aligned. If the buffer is unaligned, the time required increases to 66,385 microseconds -- about a 27% speed penalty. The following chart illustrates the performance pattern of aligned memory accesses versus unaligned accesses:
Figure 7. Single-byte access versus double-byte access
The first thing you notice is that accessing memory one byte at a time is uniformly slow. The second item of interest is that when accessing memory two bytes at a time, whenever the address is not evenly divisible by two, that 27% speed penalty rears its ugly head.
Now up the ante, and process the buffer four bytes at a time:
Listing 3. Munging data four bytes at a time
void Munge16( void *data, uint32_t size ) { uint16_t *data16 = (uint16_t*) data; uint16_t *data16End = data16 + (size >> 1); /* Divide size by 2. */ uint8_t *data8 = (uint8_t*) data16End; uint8_t *data8End = data8 + (size & 0x00000001); /* Strip upper 31 bits. */ while( data16 != data16End ) { *data16++ = -*data16; } while( data8 != data8End ) { *data8++ = -*data8; } }
This function processes an aligned buffer in 43,043 microseconds and an unaligned buffer in 55,775 microseconds, respectively. Thus, on this test machine, accessing unaligned memory four bytes at a time is slower than accessing aligned memory two bytes at a time:
Figure 8. Single- versus double- versus quad-byte access
Now for the horror story: processing the buffer eight bytes at a time.
Listing 4. Munging data eight bytes at a time
void Munge32( void *data, uint32_t size ) {
uint32_t *data32 = (uint32_t*) data;
uint32_t *data32End = data32 + (size >> 2); /* Divide size by 4. */
uint8_t *data8 = (uint8_t*) data32End;
uint8_t *data8End = data8 + (size & 0x00000003); /* Strip upper 30 bits. */
while( data32 != data32End ) {
*data32++ = -*data32;
}
while( data8 != data8End ) {
*data8++ = -*data8;
}
}
Munge64
processes
an aligned buffer in 39,085 microseconds -- about 10% faster than
processing the buffer four bytes at a time. However, processing an
unaligned buffer takes an amazing 1,841,155 microseconds -- two orders
of magnitude slower than aligned access, an outstanding 4,610%
performance penalty!
What happened? Because modern PowerPC processors lack hardware support for unaligned floating-point access, the processor throws an exception for each unaligned access. The operating system catches this exception and performs the alignment in software. Here's a chart illustrating the penalty, and when it occurs:
Figure 9. Multiple-byte access comparison
The penalties for one-, two- and four-byte unaligned access are dwarfed by the horrendous unaligned eight-byte penalty. Maybe this chart, removing the top (and thus the tremendous gulf between the two numbers), will be clearer:
Figure 10. Multiple-byte access comparison #2
There's another subtle insight hidden in this data. Compare eight-byte access speeds on four-byte boundaries:
Figure 11. Multiple-byte access comparison #3
Notice accessing memory eight bytes at a time on four- and twelve- byte boundaries is slower than reading the same memory four or even two bytes at a time. While PowerPCs have hardware support for four-byte aligned eight-byte doubles, you still pay a performance penalty if you use that support. Granted, it's no where near the 4,610% penalty, but it's certainly noticeable. Moral of the story: accessing memory in large chunks can be slower than accessing memory in small chunks, if that access is not aligned.
All modern processors offer atomic instructions. These special instructions are crucial for synchronizing two or more concurrent tasks. As the name implies, atomic instructions must be indivisible -- that's why they're so handy for synchronization: they can't be preempted.
It turns out that in order for atomic instructions to perform correctly, the addresses you pass them must be at least four-byte aligned. This is because of a subtle interaction between atomic instructions and virtual memory.
If an address is unaligned, it requires at least two memory accesses. But what happens if the desired data spans two pages of virtual memory? This could lead to a situation where the first page is resident while the last page is not. Upon access, in the middle of the instruction, a page fault would be generated, executing the virtual memory management swap-in code, destroying the atomicity of the instruction. To keep things simple and correct, both the 68K and PowerPC require that atomically manipulated addresses always be at least four-byte aligned.
Unfortunately, the PowerPC does not throw an exception when atomically storing to an unaligned address. Instead, the store simply always fails. This is bad because most atomic functions are written to retry upon a failed store, under the assumption they were preempted. These two circumstances combine to where your program will go into an infinite loop if you attempt to atomically store to an unaligned address. Oops.
Altivec is all about speed. Unaligned memory access slows down the processor and costs precious transistors. Thus, the Altivec engineers took a page from the MIPS playbook and simply don't support unaligned memory access. Because Altivec works with sixteen-byte chunks at a time, all addresses passed to Altivec must be sixteen-byte aligned. What's scary is what happens if your address is not aligned.
Altivec won't throw an exception to warn you about the unaligned address. Instead, Altivec simply ignores the lower four bits of the address and charges ahead, operating on the wrong address. This means your program may silently corrupt memory or return incorrect results if you don't explicitly make sure all your data is aligned.
There is an advantage to Altivec's bit-stripping ways. Because you don't need to explicitly truncate (align-down) an address, this behavior can save you an instruction or two when handing addresses to the processor.
This is not to say Altivec can't process unaligned memory. You can find detailed instructions how to do so on the Altivec Programming Environments Manual (see Resources). It requires more work, but because memory is so slow compared to the processor, the overhead for such shenanigans is surprisingly low.
Examine the following structure:
Listing 5. An innocent structure
void Munge64( void *data, uint32_t size ) {
typedef struct {
char a;
long b;
char c;
} Struct;What is the size of this structure in bytes? Many programmers will answer "6 bytes." It makes sense: one byte for a
, four bytes forb
and another byte for c
. 1 + 4 + 1 equals 6. Here's how it would lay out in memory:
Field Type | Field Name | Field Offset | Field Size | Field End |
char |
a |
0 | 1 | 1 |
long |
b |
1 | 4 | 5 |
char |
c |
5 | 1 | 6 |
Total Size in Bytes: | 6 |
However, if you were to ask your compiler to sizeof( Struct )
,
chances are the answer you'd get back would be greater than six,
perhaps eight or even twenty-four. There's two reasons for this:
backwards compatibility and efficiency.
First,
backwards compatibility. Remember the 68000 was a processor with
two-byte memory access granularity, and would throw an exception upon
encountering an odd address. If you were to read from or write to field b
,
you'd attempt to access an odd address. If a debugger weren't
installed, the old Mac OS would throw up a System Error dialog box with
one button: Restart. Yikes!
So, instead of laying out your fields just the way you wrote them, the compiler padded the structure so that b
and c
would reside at even addresses:
Field Type | Field Name | Field Offset | Field Size | Field End |
char |
a |
0 | 1 | 1 |
padding | 1 | 1 | 2 | |
long |
b |
2 | 4 | 6 |
char |
c |
6 | 1 | 7 |
padding | 7 | 1 | 8 | |
Total Size in Bytes: | 8 |
Padding is the act of adding otherwise unused space to a structure to make fields line up in a desired way. Now, when the 68020 came out with built-in hardware support for unaligned memory access, this padding was unnecessary. However, it didn't hurt anything, and it even helped a little in performance.
The
second reason is efficiency. Nowadays, on PowerPC machines, two-byte
alignment is nice, but four-byte or eight-byte is better. You probably
don't care anymore that the original 68000 choked on unaligned
structures, but you probably care about potential 4,610% performance
penalties, which can happen if a double
field doesn't sit aligned in a structure of your devising.
内存对齐关键是需要画图!在下面的中文有说明例子
Examine the following structure:
What is the size of this structure in bytes? Many programmers will answer "6 bytes." It makes sense: one byte for a
, four bytes forb
and another byte for c
. 1 + 4 + 1 equals 6. Here's how it would lay out in memory:
Field Type | Field Name | Field Offset | Field Size | Field End |
char |
a |
0 | 1 | 1 |
long |
b |
1 | 4 | 5 |
char |
c |
5 | 1 | 6 |
Total Size in Bytes: | 6 |
However, if you were to ask your compiler to sizeof( Struct )
,
chances are the answer you'd get back would be greater than six,
perhaps eight or even twenty-four. There's two reasons for this:
backwards compatibility and efficiency.
First,
backwards compatibility. Remember the 68000 was a processor with
two-byte memory access granularity, and would throw an exception upon
encountering an odd address. If you were to read from or write to field b
,
you'd attempt to access an odd address. If a debugger weren't
installed, the old Mac OS would throw up a System Error dialog box with
one button: Restart. Yikes!
So, instead of laying out your fields just the way you wrote them, the compiler padded the structure so that b
and c
would reside at even addresses:
Field Type | Field Name | Field Offset | Field Size | Field End |
char |
a |
0 | 1 | 1 |
padding | 1 | 1 | 2 | |
long |
b |
2 | 4 | 6 |
char |
c |
6 | 1 | 7 |
padding | 7 | 1 | 8 | |
Total Size in Bytes: | 8 |
Padding is the act of adding otherwise unused space to a structure to make fields line up in a desired way. Now, when the 68020 came out with built-in hardware support for unaligned memory access, this padding was unnecessary. However, it didn't hurt anything, and it even helped a little in performance.
The
second reason is efficiency. Nowadays, on PowerPC machines, two-byte
alignment is nice, but four-byte or eight-byte is better. You probably
don't care anymore that the original 68000 choked on unaligned
structures, but you probably care about potential 4,610% performance
penalties, which can happen if a double
field doesn't sit aligned in a structure of your devising.
很多人都知道是内存对齐所造成的原因,却鲜有人告诉你内存对齐的基本原理!上面作者就做了解释!
- Your software may hit performance-killing unaligned memory access exceptions, which invoke very expensive alignment exception handlers.
- Your application may attempt to atomically store to an unaligned address, causing your application to lock up.
- Your application may attempt to pass an unaligned address to Altivec, resulting in Altivec reading from and/or writing to the wrong part of memory, silently corrupting data or yielding incorrect results.
-
一、内存对齐的原因 - 大部分的参考资料都是如是说的:
1、平台原因(移植原因):不是所有的硬件平台都能访问任意地址上的任意数据的;某些硬件平台只能在某些地址处取某些特定类型的数据,否则抛出硬件异常。
2、性能原因:数据结构(尤其是栈)应该尽可能地在自然边界上对齐。原因在于,为了访问未对齐的内存,处理器需要作两次内存访问;而对齐的内存访问仅需要一次访问。
二、对齐规则
每个特定平台上的编译器都有自己的默认“对齐系数”(也叫对齐模数)。程序员可以通过预编译命令#pragma pack(n),n=1,2,4,8,16来改变这一系数,其中的n就是你要指定的“对齐系数”。
规则:
1、数据成员对齐规则:结构(struct)(或联合(union))的数据成员,第一个数据成员放在offset为0的地方,以后每个数据成员的对齐按照#pragma pack指定的数值和这个数据成员
自身长度中,比较小的那个进行。
2、结构(或联合)的整体对齐规则:在数据成员完成各自对齐之后,结构(或联合)本身也要进行对齐,对齐将按照#pragma pack指定的数值和结构(或联合)最大数据成员长度中,比较小的那个进行。
3、结合1、2可推断:当#pragma pack的n值等于或超过所有数据成员长度的时候,这个n值的大小将不产生任何效果。
三、试验
下面我们通过一系列例子的详细说明来证明这个规则
编译器:GCC 3.4.2、VC6.0
平台:Windows XP
典型的struct对齐
struct定义:
#pragma pack(n) /* n = 1, 2, 4, 8, 16 */
struct test_t {
int a;
char b;
short c;
char d;
};
#pragma pack(n)
首先确认在试验平台上的各个类型的size,经验证两个编译器的输出均为:
sizeof(char) = 1
sizeof(short) = 2
sizeof(int) = 4
试验过程如下:通过#pragma pack(n)改变“对齐系数”,然后察看sizeof(struct test_t)的值。
1、1字节对齐(#pragma pack(1))
输出结果:sizeof(struct test_t) = 8 [两个编译器输出一致]
分析过程:
1) 成员数据对齐
#pragma pack(1)
struct test_t {
int a; /* 长度4 > 1 按1对齐;起始offset=0 0%1=0;存放位置区间[0,3] */
char b; /* 长度1 = 1 按1对齐;起始offset=4 4%1=0;存放位置区间[4] */
short c; /* 长度2 > 1 按1对齐;起始offset=5 5%1=0;存放位置区间[5,6] */
char d; /* 长度1 = 1 按1对齐;起始offset=7 7%1=0;存放位置区间[7] */
};
#pragma pack()
成员总大小=8
2) 整体对齐
整体对齐系数 = min((max(int,short,char), 1) = 1
整体大小(size)=$(成员总大小) 按 $(整体对齐系数) 圆整 = 8 /* 8%1=0 */ [注1]
2、2字节对齐(#pragma pack(2))
输出结果:sizeof(struct test_t) = 10 [两个编译器输出一致]
分析过程:
1) 成员数据对齐
#pragma pack(2)
struct test_t {
int a; /* 长度4 > 2 按2对齐;起始offset=0 0%2=0;存放位置区间[0,3] */
char b; /* 长度1 < 2 按1对齐;起始offset=4 4%1=0;存放位置区间[4] */
short c; /* 长度2 = 2 按2对齐;起始offset=6 6%2=0;存放位置区间[6,7] */
char d; /* 长度1 < 2 按1对齐;起始offset=8 8%1=0;存放位置区间[8] */
};
#pragma pack()
成员总大小=9
2) 整体对齐
整体对齐系数 = min((max(int,short,char), 2) = 2
整体大小(size)=$(成员总大小) 按 $(整体对齐系数) 圆整 = 10 /* 10%2=0 */
3、4字节对齐(#pragma pack(4))
输出结果:sizeof(struct test_t) = 12 [两个编译器输出一致]
分析过程:
1) 成员数据对齐
#pragma pack(4)
struct test_t {
int a; /* 长度4 = 4 按4对齐;起始offset=0 0%4=0;存放位置区间[0,3] */
char b; /* 长度1 < 4 按1对齐;起始offset=4 4%1=0;存放位置区间[4] */
short c; /* 长度2 < 4 按2对齐;起始offset=6 6%2=0;存放位置区间[6,7] */
char d; /* 长度1 < 4 按1对齐;起始offset=8 8%1=0;存放位置区间[8] */
};
#pragma pack()
成员总大小=9
2) 整体对齐
整体对齐系数 = min((max(int,short,char), 4) = 4
整体大小(size)=$(成员总大小) 按 $(整体对齐系数) 圆整 = 12 /* 12%4=0 */
4、8字节对齐(#pragma pack(8))
输出结果:sizeof(struct test_t) = 12 [两个编译器输出一致]
分析过程:
1) 成员数据对齐
#pragma pack(8)
struct test_t {
int a; /* 长度4 < 8 按4对齐;起始offset=0 0%4=0;存放位置区间[0,3] */
char b; /* 长度1 < 8 按1对齐;起始offset=4 4%1=0;存放位置区间[4] */
short c; /* 长度2 < 8 按2对齐;起始offset=6 6%2=0;存放位置区间[6,7] */
char d; /* 长度1 < 8 按1对齐;起始offset=8 8%1=0;存放位置区间[8] */
};
#pragma pack()
成员总大小=9
2) 整体对齐
整体对齐系数 = min((max(int,short,char), 8) = 4
整体大小(size)=$(成员总大小) 按 $(整体对齐系数) 圆整 = 12 /* 12%4=0 */
5、16字节对齐(#pragma pack(16))
输出结果:sizeof(struct test_t) = 12 [两个编译器输出一致]
分析过程:
1) 成员数据对齐
#pragma pack(16)
struct test_t {
int a; /* 长度4 < 16 按4对齐;起始offset=0 0%4=0;存放位置区间[0,3] */
char b; /* 长度1 < 16 按1对齐;起始offset=4 4%1=0;存放位置区间[4] */
short c; /* 长度2 < 16 按2对齐;起始offset=6 6%2=0;存放位置区间[6,7] */
char d; /* 长度1 < 16 按1对齐;起始offset=8 8%1=0;存放位置区间[8] */
};
#pragma pack()
成员总大小=9
2) 整体对齐
整体对齐系数 = min((max(int,short,char), 16) = 4
整体大小(size)=$(成员总大小) 按 $(整体对齐系数) 圆整 = 12 /* 12%4=0 */
8字节和16字节对齐试验证明了“规则”的第3点:“当#pragma pack的n值等于或超过所有数据成员长度的时候,这个n值的大小将不产生任何效果”。
内 存分配与内存对齐是个很复杂的东西,不但与具体实现密切相关,而且在不同的操作系统,编译器或硬件平台上规则也不尽相同,虽然目前大多数系统/语言都具有 自动管理、分配并隐藏低层操作的功能,使得应用程序编写大为简单,程序员不在需要考虑详细的内存分配问题。但是,在系统或驱动级以至于高实时,高保密性的 程序开发过程中,程序内存分配问题仍旧是保证整个程序稳定,安全,高效的基础。 -
[注1]
什么是“圆整”?
举例说明:如上面的8字节对齐中的“整体对齐”,整体大小=9 按 4 圆整 = 12
圆整的过程:从9开始每次加一,看是否能被4整除,这里9,10,11均不能被4整除,到12时可以,则圆整结束。
相关推荐
sizeof(结构体)和内存对齐 sizeof(结构体)和内存对齐 sizeof(结构体)和内存对齐 sizeof(结构体)和内存对齐
该文件详细介绍了用sizeof求取struct结构体内存大小的各种情况
该文档提供了详细解决结构体sizeof问题,从结构体内变量所占空间大小,默认内存对齐大小,强制内存对齐方法,变量在内存中布局的详细分析,语言言简意赅,绝无废话,为读者解决了大量寻找书籍的烦恼,读者可以花费几分钟的...
sizeof与结构体和共同体.PDF 特别特别难找的一本书,不下会后悔的
sizeof进行结构体大小的判断.sizeof进行结构体大小的判断.sizeof进行结构体大小的判断.
这些问题在平时编程的时候也确实不怎么用到,但在一些笔试面试题目中出是常常出现,对sizeof我们将在另一篇文章中总结,这篇文章我们只总结结构体的sizeof,报着不到黄河心不死的决心,终于完成了总结,也算是小有...
写出一个struct,然后sizeof,你会不会经常对结果感到奇怪?sizeof的结果往往都比你声明的变量总长度要大,这是怎么回事呢?讲讲字节对齐吧.
sizeof作用于基本数据类型,在特定的平台和特定的编译器中,结果是确定的,如果使用sizeof计算构造类型:结构体、联合体和类的大小时,情况稍微复杂一些。 1.sizeof计算结构体 考察如下代码: struct S1 { char c; ...
先自定义一个结构体,比如: struct Table{short int a;long b;short intc;long d;};struct Table Tab[10]; 以下的函数即是用于清空结构体的,需要传入的两个参数分别为结构体的起始地址和结构体的长度。 ...
结构体内存布局2.1 offsetof 定位某成员在结构体中的「 偏移量」2.2 为保证内存对齐,填充了什么值3. 内存对齐3.1 结构体成员默认内存对齐3.2 不同架构内存对齐方式3.3 小试牛刀3.3.1 前置填充3.3.2 中间填充3.3.3 ...
结构体的sizeof 先看一个结构体: struct S1 { char c; int i; }; sizeof(s1)在VC6中按默认设置得到的结果为8。 我们先看看sizeof的定义——sizeof的结果等于对象或者类型所占的内存字节数...
C 语言结构体对齐也是老生常谈的话题了。基本上是面试题的必考题。内容 虽然很基础,但一不小心就会弄错。写出一个 struct,然后 sizeof,你会不会经 常对结果感到奇怪? sizeof的结果往往都比你声明的变量总长度要...
Q:关于结构体的对齐,到底遵循什么原则? A:首先先不讨论结构体按多少字节对齐,先看看只以1字节对齐的情况: #include #include #define PRINT_D(intValue) printf(#intValue is %d\n, (intValue)); #define ...
为了优化CPU访问和优化内存,减少内存碎片,编译器对内存对齐制定了一些规则。但是,不同的编译器可能有不同的实现,本文只针对VC++编译器,这里使用的IDE是VS2012。 #pragma pack()是一个预处理,表示内存对齐。...
内存对齐一般讲就是cpu access memory的效率(提高运行速度)和准确性(在一些条件下,如果没有对齐会导致数据不同步现象).依赖cpu,平台和编译器的不同.一些cpu要求较高(这句话说的不准确,但是确实依赖cpu的不同),而有些...
学习结构体排序查找以及链表的使用#include #include #include struct student { int num; double score; char name[100]; struct student *next; }; int cmp(const void *a,const void *b) { struct student *...
默认情况下,在32位cpu里,gcc对于结构体的对齐方式是按照四个字节来对齐的。
为了提高CPU的存储速度,VC对一些变量的起始地址做了“对齐”处理。在默认情况下,VC规定各成员变量存放的起始地址相对于结构的起始地址的偏移量必须为该变量的类型所占用的字节数的倍数。下面列出常用类型的对齐...
而sizeof计算数据(包括数组、变量、类型、结构体等)所占内存空间,用字节数表示。 2.指针与静态数组的sizeof操作 指针均可看为变量类型的一种。所有指针变量的sizeof 操作结果均为4。 注意:int *p; sizeof(p)=4...