Microsoft MVP성태의 닷넷 이야기
VC++: 32. VC++에서 bool이 가지는 의미 [링크 복사], [링크+제목 복사]
조회: 20205
글쓴 사람
정성태 (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)
13605정성태4/23/2024203닷넷: 2246. C# - Python.NET을 이용한 파이썬 소스코드 연동파일 다운로드1
13604정성태4/22/2024226오류 유형: 901. Visual Studio - Unable to set the next statement. Set next statement cannot be used in '[Exception]' call stack frames.
13603정성태4/21/2024309닷넷: 2245. C# - IronPython을 이용한 파이썬 소스코드 연동파일 다운로드1
13602정성태4/20/2024660닷넷: 2244. C# - PCM 오디오 데이터를 연속(Streaming) 재생 (Windows Multimedia)파일 다운로드1
13601정성태4/19/2024751닷넷: 2243. C# - PCM 사운드 재생(NAudio)파일 다운로드1
13600정성태4/18/2024760닷넷: 2242. C# - 관리 스레드와 비관리 스레드
13599정성태4/17/2024808닷넷: 2241. C# - WAV 파일의 PCM 사운드 재생(Windows Multimedia)파일 다운로드1
13598정성태4/16/2024835닷넷: 2240. C# - WAV 파일 포맷 + LIST 헤더파일 다운로드2
13597정성태4/15/2024802닷넷: 2239. C# - WAV 파일의 PCM 데이터 생성 및 출력파일 다운로드1
13596정성태4/14/20241038닷넷: 2238. C# - WAV 기본 파일 포맷파일 다운로드1
13595정성태4/13/20241047닷넷: 2237. C# - Audio 장치 열기 (Windows Multimedia, NAudio)파일 다운로드1
13594정성태4/12/20241064닷넷: 2236. C# - Audio 장치 열람 (Windows Multimedia, NAudio)파일 다운로드1
13593정성태4/8/20241074닷넷: 2235. MSBuild - AccelerateBuildsInVisualStudio 옵션
13592정성태4/2/20241215C/C++: 165. CLion으로 만든 Rust Win32 DLL을 C#과 연동
13591정성태4/2/20241187닷넷: 2234. C# - WPF 응용 프로그램에 Blazor App 통합파일 다운로드1
13590정성태3/31/20241078Linux: 70. Python - uwsgi 응용 프로그램이 k8s 환경에서 OOM 발생하는 문제
13589정성태3/29/20241150닷넷: 2233. C# - 프로세스 CPU 사용량을 나타내는 성능 카운터와 Win32 API파일 다운로드1
13588정성태3/28/20241247닷넷: 2232. C# - Unity + 닷넷 App(WinForms/WPF) 간의 Named Pipe 통신 [2]파일 다운로드1
13587정성태3/27/20241168오류 유형: 900. Windows Update 오류 - 8024402C, 80070643
13586정성태3/27/20241320Windows: 263. Windows - 복구 파티션(Recovery Partition) 용량을 늘리는 방법
13585정성태3/26/20241105Windows: 262. PerformanceCounter의 InstanceName에 pid를 추가한 "Process V2"
13584정성태3/26/20241058개발 환경 구성: 708. Unity3D - C# Windows Forms / WPF Application에 통합하는 방법파일 다운로드1
13583정성태3/25/20241175Windows: 261. CPU Utilization이 100% 넘는 경우를 성능 카운터로 확인하는 방법
13582정성태3/19/20241433Windows: 260. CPU 사용률을 나타내는 2가지 수치 - 사용량(Usage)과 활용률(Utilization)파일 다운로드1
13581정성태3/18/20241606개발 환경 구성: 707. 빌드한 Unity3D 프로그램을 C++ Windows Application에 통합하는 방법
[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...