Microsoft MVP성태의 닷넷 이야기
VC++: 32. VC++에서 bool이 가지는 의미 [링크 복사], [링크+제목 복사],
조회: 25646
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 1개 있습니다.)
VC++에서 bool이 가지는 의미.


왠지 재미있는 주제같지요? ^^
다음의 토픽에서 신영진 님이 소개해 주고 있습니다.

VC++에서 bool이 가지는 의미
; http://www.jiniya.net/tt/489

이미 말씀드렸듯이 제 의견은, "크기"와 "형식 안정성"이었는데요. 신영진 님이 실제 bool 변수의 크기만을 고려해서는 안되고 관련 어셈블리 연산 바이트 코드 수까지 고려하게 되면 bool이 결코 효율적이지는 않다고 쓰고 있습니다.

오... ^^ 저는 bool에 대한 비교 연산자에 따른 바이트 코드 수에 대해서는 고려해 볼 생각을 안했지요. 기왕에 나온 거... 이참에 한번 정리해봐야겠습니다. ^^ 우선, 그러기 전에 간단한 테스트 코드를 만들어 볼까요?

콘솔 프로젝트를 만들고. 다음과 같은 준비 코드를 작성합니다.

#include "stdafx.h"

typedef struct tagOnlybool 
{
	bool b1;
	bool b2;
	bool b3;
	bool b4;
} Onlybool;

typedef struct tagOnlyBOOL
{
	BOOL b1;
	BOOL b2;
	BOOL b3;
	BOOL b4;
} OnlyBOOL;

int _tmain(int argc, _TCHAR* argv[])
{
	Onlybool ob1;
	OnlyBOOL ob2;

	int size1 = sizeof( ob1 ); // 4byte
	int size2 = sizeof( ob2 ); // 16byte

	return 0;
}

신영진 님은 다음과 같은 좋은 의견을 내셨습니다.

32비트 컴퓨터에서 int를 0과 비교하는데에는 cmp 명령어 하나로 4바이트가 소모됩니다. 하지만 bool을 false와 비교하는데는 movzx, test를 사용해야 하기 때문에 6바이트가 소모되죠. 즉 bool이 2바이트를 더 사용하는 것 입니다. 한 변수에 대해서 비교가 두 번 발생한다면 본전이고, 세 번 발생한다면 int가 2바이트를 절약하는 셈이 됩니다.



일단, 제가 실제로 VC++ Debug 모드에서 Disassembly 창을 통해 비교해 본 바로는 BOOL 값을 TRUE / FALSE와 비교할 때는 4바이트가 소모되는 것이 맞지만 bool 값을 true/false와 비교할 때는 7바이트가 소모됩니다. bool이 3바이트를 더 쓰게 된 것입니다.

	if ( ob1.b1 == true ) // bool을 true와 비교
004113B7 0F B6 45 F8      movzx       eax,byte ptr [ob1] 
004113BB 83 F8 01         cmp         eax,1 
004113BE 75 07            jne         wmain+47h (4113C7h) 

	if ( ob2.b1 == TRUE ) // BOOL을 TRUE와 비교
004113C7 83 7D E0 01      cmp         dword ptr [ob2],1 
004113CB 75 07            jne         wmain+54h (4113D4h) 

이런... 치명적입니다. bool과 BOOL 변수를 하나만 선언한 경우라면 비교 연산자로 인해서, 변수 자체의 크기로 절약된 3byte를 모두 까먹는 결과가 되어 버렸습니다.




하지만... 바늘 가는 데 실이 따라가듯이. 비교하기 위해서는 우선 해당 변수에 값이 들어있어야 하겠지요. 그래서, ob1.b1과 ob2.b1에 각각 true / TRUE 값을 넣어 보면, 사정이 다시 바뀝니다.

	ob1.b1 = true;
004113AC C6 45 F8 01      mov         byte ptr [ob1],1 
	if ( ob1.b1 == true )
004113B0 0F B6 45 F8      movzx       eax,byte ptr [ob1] 
004113B4 83 F8 01         cmp         eax,1 
004113B7 75 07            jne         wmain+40h (4113C0h) 

	ob2.b1 = TRUE;
004113C0 C7 45 E0 01 00 00 00 mov         dword ptr [ob2],1 
	if ( ob2.b1 == TRUE )
004113C7 83 7D E0 01      cmp         dword ptr [ob2],1 
004113CB 75 07            jne         wmain+54h (4113D4h) 

이렇게 되면 BOOL 형식이 3byte를 더 먹게 되는군요. 그래도 그다지 마음에 들지 않습니다. 명령어 단계가 많다는 것은 성능에 영향을 미치는 것을 의미할 뿐만 아니라, movzx는 "xor eax, eax / mov al, byte ptr"의 조합으로 바꾸라고 할 정도로 그다지 성능이 좋지 않은 것으로 알려져 있습니다. 혹시나 릴리스에서의 최적화 시에는 movzx 명령어를 xor/mov로 풀어주지 않을까 내심 기대해 보았지만, 역시나 마찬가지였습니다.

또한, 비트 연산등을 고려해 보면, 상황은 다시 반전이 됩니다. 불린 형식에서 대표적으로 사용되는 NOT 논리 연산자(!)를 사용하는 경우에는 BOOL 형식이 2바이트 및 명령어 단계 하나가 더 적습니다.




하다 보니, 재미있습니다. ^^; x64에서도 해봤습니다.
적어도 크기 면에서는, x64에서는 bool이 좀 더 어깨를 펼 것 같습니다.

    49:		ob1.b1 = true;
00000001400030D1 C6 44 24 74 01   mov         byte ptr [rsp+74h],1 
    50:		if ( ob1.b1 == true )
00000001400030D6 0F B6 44 24 74   movzx       eax,byte ptr [rsp+74h] 
00000001400030DB 83 F8 01         cmp         eax,1 
00000001400030DE 75 05            jne         wmain+0A5h (1400030E5h) 
    51:		{
    52:			ob1.b1 = false;
00000001400030E0 C6 44 24 74 00   mov         byte ptr [rsp+74h],0 
    53:		}
    54: 
    55:		ob2.b1 = TRUE;
00000001400030E5 C7 84 24 98 00 00 00 01 00 00 00 mov         dword ptr [rsp+98h],1 
    56:		if ( ob2.b1 == TRUE )
00000001400030F0 83 BC 24 98 00 00 00 01 cmp         dword ptr [rsp+98h],1 
00000001400030F8 75 0B            jne         wmain+0C5h (140003105h) 
    57:		{
    58:			ob2.b1 = FALSE;
00000001400030FA C7 84 24 98 00 00 00 00 00 00 00 mov         dword ptr [rsp+98h],0 
    59:		}

그래도... 역시나 명령어 단계는 하나 더 추가가 되니, 그 부분이 좀 아쉽긴 합니다. "!" 연산자도 x64에서는 BOOL에 비교해 바이트가 좀 줄기는 했지만, 명령어 단계는 꼭 한 번씩 더 많은 것을 볼 수 있습니다.

    52:			ob1.b1 = !ob1.b1;
00000001400030E0 0F B6 44 24 74   movzx       eax,byte ptr [rsp+74h] 
00000001400030E5 85 C0            test        eax,eax 
00000001400030E7 75 0D            jne         wmain+0B6h (1400030F6h) 
00000001400030E9 C7 84 24 C8 00 00 00 01 00 00 00 mov         dword ptr [rsp+0C8h],1 
00000001400030F4 EB 0B            jmp         wmain+0C1h (140003101h) 
00000001400030F6 C7 84 24 C8 00 00 00 00 00 00 00 mov         dword ptr [rsp+0C8h],0 
0000000140003101 0F B6 84 24 C8 00 00 00 movzx       eax,byte ptr [rsp+0C8h] 
0000000140003109 88 44 24 74      mov         byte ptr [rsp+74h],al 

    58:			ob2.b1 = !ob2.b1;
0000000140003122 83 BC 24 98 00 00 00 00 cmp         dword ptr [rsp+98h],0 
000000014000312A 75 0D            jne         wmain+0F9h (140003139h) 
000000014000312C C7 84 24 CC 00 00 00 01 00 00 00 mov         dword ptr [rsp+0CCh],1 
0000000140003137 EB 0B            jmp         wmain+104h (140003144h) 
0000000140003139 C7 84 24 CC 00 00 00 00 00 00 00 mov         dword ptr [rsp+0CCh],0 
0000000140003144 8B 84 24 CC 00 00 00 mov         eax,dword ptr [rsp+0CCh] 
000000014000314B 89 84 24 98 00 00 00 mov         dword ptr [rsp+98h],eax 

그건 그렇고... "!" 연산자가 번역된 것을 보면 그다지 마음에 들지는 않는 군요. 차라리 "^=" 연산자가 더 좋은 것 같습니다.

    52:			ob1.b1 ^= ob1.b1;
00000001400030E0 0F B6 44 24 74   movzx       eax,byte ptr [rsp+74h] 
00000001400030E5 0F B6 4C 24 74   movzx       ecx,byte ptr [rsp+74h] 
00000001400030EA 33 C1            xor         eax,ecx 
00000001400030EC 88 44 24 74      mov         byte ptr [rsp+74h],al 

    58:			ob2.b1 ^= ob2.b1;
0000000140003105 8B 84 24 98 00 00 00 mov         eax,dword ptr [rsp+98h] 
000000014000310C 8B 8C 24 98 00 00 00 mov         ecx,dword ptr [rsp+98h] 
0000000140003113 33 C8            xor         ecx,eax 
0000000140003115 8B C1            mov         eax,ecx 
0000000140003117 89 84 24 98 00 00 00 mov         dword ptr [rsp+98h],eax 

다음은 논리 연산자(&&)의 경우입니다.

    51:		if ( ob1.b1 && ob1.b2 ) // || 연산자도 유사한 기계어 코드 생성
00000001400030DB 0F B6 44 24 74   movzx       eax,byte ptr [rsp+74h] 
00000001400030E0 85 C0            test        eax,eax 
00000001400030E2 74 19            je          wmain+0BDh (1400030FDh) 
00000001400030E4 0F B6 44 24 75   movzx       eax,byte ptr [rsp+75h] 
00000001400030E9 85 C0            test        eax,eax 
00000001400030EB 74 10            je          wmain+0BDh (1400030FDh) 

    58:		if ( ob2.b1 && ob2.b2 ) // || 연산자도 유사한 기계어 코드 생성
0000000140003113 83 BC 24 98 00 00 00 00 cmp         dword ptr [rsp+98h],0 
000000014000311B 74 23            je          wmain+100h (140003140h) 
000000014000311D 83 BC 24 9C 00 00 00 00 cmp         dword ptr [rsp+9Ch],0 
0000000140003125 74 19            je          wmain+100h (140003140h) 

정리해 보면... bool 연산자가 미비하게나마 저장 공간은 절약해 줄지언정, 성능면에서는 그다지 좋은 선택은 아니라고 할 수 있겠습니다. 신영진 님 덕분에 고정 관념을 하나 깨게 되었군요. ^^

그나저나... 난 이런 거 별로 안 좋아하는뎅... ^^;



[이 토픽에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]






[최초 등록일: ]
[최종 수정일: 7/8/2021]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 



2007-04-25 08시12분
[신영진] 잘 읽고 갑니다.
제가 미처 생각 못했던 부분이 많이 있네요.
특히 x64 부분은 해볼 엄두도 못냈습니다. ㅋ
저도 사실 이런 거 별로 안 좋아합니다. *^^*
[guest]
2007-04-25 08시38분
^^ 예전에 뉴스그룹에서도 그랬지만. 신영진 님한테서는 재미있는 것을 배우게 되는군요. ^^
kevin25
2011-03-29 10시28분
왜 Windows의 BOOL 타입이 uint가 아닌 int로 정해졌을까요?

Why did Win32 define BOOL as a signed int instead of an unsigned int?
; https://devblogs.microsoft.com/oldnewthing/20110328-00/?p=11113

Windows가 개발되던 당시의 C 표준 문서에 관계 연산자의 결과 타입의 int라고 명시했기 때문이라고. (결국 본래의 이유는 설명되지 않았군요. ^^)

또한, 다음의 문서를 보면,

The cost-benefit analysis of bitfields for a collection of booleans
; https://devblogs.microsoft.com/oldnewthing/20081126-00/?p=20073

The Risk of Micro-optimizations
; https://learn.microsoft.com/en-us/archive/blogs/tonyschr/the-risk-of-micro-optimizations

저장 공간을 절약하기 위해 BOOL을 bit field를 사용해 1비트로 만든 경우의 단점이 나옵니다. 일반적인 BOOL 타입의 대입은 단순히 mov로 끝나지만,

  mov [ebx+01Ch], eax ; m_sliced = sliced

bit field로 지정한 경우라면 이게 좀 복잡해집니다. ^^;

  add eax, eax ; shift “sliced” into the correct position
  xor eax, [ebx+01Ch] ; merge “sliced” with other bits
  and eax, 2
  xor [ebx+01Ch], eax ; store the new bitfield

위에서는 값을 설정한 경우이고 값을 가져오는 경우에도 BOOL 타입은 이렇게 간단하지만,

  push [ebx+01Ch] ; m_sliced
  call _Something@4 ; Something(m_sliced);

bit field라면 이렇게 복잡해집니다.

  mov ecx, [ebx+01Ch] ; load bitfield value
  shl ecx, 30 ; put bit at top
  sar ecx, 31 ; move down and sign extend
  push ecx
  call _Something@4 ; Something(m_sliced);

따라서 가령 4개의 BOOL 변수를 1 bit field로 만들면 3바이트가 절약되지만, 대신 그것을 다루는 기계어 코드는 set에 8바이트, get에 9바이트가 늘어납니다.

따라서, 늘어나는 코드 사이즈와, 복잡해지는 디버깅과 멀티 스레딩에서의 원자성이 깨지는 것을 고려했을 때 bit field 사용은 권장하지 않습니다. 마지막으로 Raymond Chen은, 해당 인스턴스를 수천 번 생성하는 것이라면 bit field로 얻는 절약은 다른 부하로 다 까먹는 결과일 거라고. ^^
정성태

1  2  3  4  [5]  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13818정성태11/15/20245302Windows: 272. Windows 11 24H2 - sudo 추가
13817정성태11/14/20244943Linux: 106. eBPF / bpf2go - (BPF_MAP_TYPE_HASH) Map을 이용한 전역 변수 구현
13816정성태11/14/20245397닷넷: 2312. C#, C++ - Windows / Linux 환경의 Thread Name 설정파일 다운로드1
13815정성태11/13/20244822Linux: 105. eBPF - bpf2go에서 전역 변수 설정 방법
13814정성태11/13/20245290닷넷: 2311. C# - Windows / Linux 환경에서 Native Thread ID 가져오기파일 다운로드1
13813정성태11/12/20245053닷넷: 2310. .NET의 Rune 타입과 emoji 표현파일 다운로드1
13812정성태11/11/20245271오류 유형: 933. Active Directory - The forest functional level is not supported.
13811정성태11/11/20244859Linux: 104. Linux - COLUMNS 환경변수가 언제나 80으로 설정되는 환경
13810정성태11/10/20245390Linux: 103. eBPF (bpf2go) - Tracepoint를 이용한 트레이스 (BPF_PROG_TYPE_TRACEPOINT)
13809정성태11/10/20245264Windows: 271. 윈도우 서버 2025 마이그레이션
13808정성태11/9/20245271오류 유형: 932. Linux - 커널 업그레이드 후 "error: bad shim signature" 오류 발생
13807정성태11/9/20244994Linux: 102. Linux - 커널 이미지 파일 서명 (Ubuntu 환경)
13806정성태11/8/20244917Windows: 270. 어댑터 상세 정보(Network Connection Details) 창의 내용이 비어 있는 경우
13805정성태11/8/20244748오류 유형: 931. Active Directory의 adprep 또는 복제가 안 되는 경우
13804정성태11/7/20245377Linux: 101. eBPF 함수의 인자를 다루는 방법
13803정성태11/7/20245336닷넷: 2309. C# - .NET Core에서 바뀐 DateTime.Ticks의 정밀도
13802정성태11/6/20245707Windows: 269. GetSystemTimeAsFileTime과 GetSystemTimePreciseAsFileTime의 차이점파일 다운로드1
13801정성태11/5/20245493Linux: 100. eBPF의 2가지 방식 - libbcc와 libbpf(CO-RE)
13800정성태11/3/20246339닷넷: 2308. C# - ICU 라이브러리를 활용한 문자열의 대소문자 변환 [2]파일 다운로드1
13799정성태11/2/20244922개발 환경 구성: 732. 모바일 웹 브라우저에서 유니코드 문자가 표시되지 않는 경우
13798정성태11/2/20245524개발 환경 구성: 731. 유니코드 - 출력 예시 및 폰트 찾기
13797정성태11/1/20245514C/C++: 185. C++ - 문자열의 대소문자를 변환하는 transform + std::tolower/toupper 방식의 문제점파일 다운로드1
13796정성태10/31/20245396C/C++: 184. C++ - ICU dll을 이용하는 예제 코드 (Windows)파일 다운로드1
13795정성태10/31/20245179Windows: 268. Windows - 리눅스 환경처럼 공백으로 끝나는 프롬프트 만들기
13794정성태10/30/20245268닷넷: 2307. C# - 윈도우에서 한글(및 유니코드)을 포함한 콘솔 프로그램을 컴파일 및 실행하는 방법
13793정성태10/28/20245149C/C++: 183. C++ - 윈도우에서 한글(및 유니코드)을 포함한 콘솔 프로그램을 컴파일 및 실행하는 방법
1  2  3  4  [5]  6  7  8  9  10  11  12  13  14  15  ...