2010. 4. 4. 16:11

구조체의 크기가 예상과 다른 이유는?

이것도 예전에 데브피아에서 어떤 유저가 기고하였던 질문에 대한 저의 답변입니다.

------------------------------------------------------------------------------

구조체에서..
 
char a;
int b;
float c;

이것은 아는 대로 12바이트가 할당 됩니다.

char a;
int b;
double c;


이것은 16바이트가 할당이 되구요..

헌데, 

char a;
double b;
float c;

는 24바이트가 할당이 되네요.

구조체는 시스템의 메모리의 한 워드 단위로 할당이 되는거 아닌가요?

그러면 4바이트 단위니깐 16바이트가 맞는것 같은데..

답변 부탁드리겠습니다.

------------------------------------------------------------------------------

Structure Alignment는 시스템 cpu에 따라 의존적입니다.

이러한 구조체 정렬을 하는 근본적인 이유는 데이터 타입을

버스의 크기만큼 처리하는 것이 가장 효율적이기 때문이죠.

그러니까 예를 들면, 32Bit CPU에서는 데이터 버스도 32Bit의

크기를 가지는데, 한번에 처리할 수 있는 크기 단위로 처리하는

것이 성능면에서 당연히 효율적일 겁니다. 보다 작으면 데이터를

처리하기 위해서는 쉬프트 연산으로 인한 오버헤드가 크다는 겁니다.

차라리 몇 바이트를 낭비하는 대신, 성능상의 이점을 충분히 얻겠다는 의도입니다.

VC 컴파일러는 기본적으로 8Byte 정렬을 하는데요..

컴파일러 옵션으로 정렬 단위를 바꿔 줄 수 있습니다.

Structure Alignment는 그 구조체 멤버에서 가장 큰 데이터

타입을 기준으로 정렬하게 됩니다.

그럼 님께서 예를 들었던 구조체들을 다시 한번 살펴 보도록 하겠습니다.
 

char a;
int b;
float c;
 

1) 위의 구조체에서 가장 큰 멤버의 크기는 4Byte입니다.
 

■■■
■■■■
■■■■

그렇기 때문에 4 바이트를 기준으로 정렬하게 되며,

첫번째 멤버 char a는 3byte의 Empty Block이 생기게 되겠죠.
 

///////////////////////////////////////////////////////////////

 
char a;
int b;
double c;
 

2) 위의 구조체에서 가장 큰 멤버의 크기는 8Byte입니다.

 
■■■■■■■
■■■■■■■■
 

char a와 int b는 둘다 8Byte 블럭안에 포함될 수 있습니다.
 
단, 두번째 멤버 int b는 4Byte기 때문에, 앞의 공간을 사용한
 
char a에 의해서 3Byte 공간만 남아 정렬될 수 없기 때문에

int b 자신의 데이터 크기만큼 띄워 나머지 공간에 padding되게 됩니다.
 

///////////////////////////////////////////////////////////////

char a;
double b;
float c;

3) 위의 구조체에서 가장 큰 멤버의 크기는 마찬가지로 8Byte입니다.

■■■■■■■
■■■■■■■■
■■■■■■■■

첫번째 멤버 char a가 위치한 후에 8Byte에서 나머지 7Byte 공간에

double b가 들어갈 수 없기 때문에, 자신의 블럭 크기로 padding되게 됩니다.

마찬가지입니다. float c도 위의 8Byte(double b의 공간)이 모두 채워졌기

때문에 다시 8Byte만큼 정렬한 공간에서 나머지 4Byte크기로 padding되게 됩니다.

 
 

※ 메모리 위치가 수시로 변할 수 있는 근본적인 이유는 Allocation Segment Alignment 때문입니다.

    그러니까 힙 영역을 할당할 때, os에서 heap allocation을 처리하는 알고리즘에서 새로이 할당되는

    메모리 영역을 순차적으로 검색하다가 충분히 할당할 수 있는 공간이라고 판단되면, 이전에 할당된

    메모리 공간을 보다 앞으로 위치시킬 수 있는 그러한 이유가 있기 때문이죠.


Written By Sim-Hyeon, Choe