Microsoft MVP성태의 닷넷 이야기
VC++: 32. VC++에서 bool이 가지는 의미 [링크 복사], [링크+제목 복사],
조회: 20233
글쓴 사람
정성태 (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)
13542정성태1/30/20241920오류 유형: 893. Visual Studio - Web Application을 실행하지 못하는 IISExpress - 두 번째 이야기
13541정성태1/29/20241981VS.NET IDE: 188. launchSettings.json의 useSSL 옵션
13540정성태1/29/20242121Linux: 69. 리눅스 - "Docker Desktop for Windows" Container 환경에서 IPv6 Loopback Address 바인딩 오류
13539정성태1/26/20242372개발 환경 구성: 703. Visual Studio - launchSettings.json을 이용한 HTTP/HTTPS 포트 바인딩
13538정성태1/25/20242437닷넷: 2211. C# - NonGC(FOH) 영역에 .NET 개체를 생성파일 다운로드1
13537정성태1/24/20242546닷넷: 2210. C# - Native 메모리에 .NET 개체를 생성파일 다운로드1
13536정성태1/23/20242603닷넷: 2209. .NET 8 - NonGC Heap / FOH (Frozen Object Heap) [1]
13535정성태1/22/20242490닷넷: 2208. C# - GCHandle 구조체의 메모리 분석
13534정성태1/21/20242261닷넷: 2207. C# - SQL Server DB를 bacpac으로 Export/Import파일 다운로드1
13533정성태1/18/20242490닷넷: 2206. C# - TCP KeepAlive의 서버 측 구현파일 다운로드1
13532정성태1/17/20242372닷넷: 2205. C# - SuperSimpleTcp 사용 시 주의할 점파일 다운로드1
13531정성태1/16/20242308닷넷: 2204. C# - TCP KeepAlive에 새로 추가된 Retry 옵션파일 다운로드1
13530정성태1/15/20242215닷넷: 2203. C# - Python과의 AES 암호화 연동파일 다운로드1
13529정성태1/15/20242098닷넷: 2202. C# - PublishAot의 glibc에 대한 정적 링킹하는 방법
13528정성태1/14/20242243Linux: 68. busybox 컨테이너에서 실행 가능한 C++, Go 프로그램 빌드
13527정성태1/14/20242159오류 유형: 892. Visual Studio - Failed to launch debug adapter. Additional information may be available in the output window.
13526정성태1/14/20242248닷넷: 2201. C# - Facebook 연동 / 사용자 탈퇴 처리 방법
13525정성태1/13/20242213오류 유형: 891. Visual Studio - Web Application을 실행하지 못하는 IISExpress
13524정성태1/12/20242300오류 유형: 890. 한국투자증권 KIS Developers OpenAPI - GW라우팅 중 오류가 발생했습니다.
13523정성태1/12/20242100오류 유형: 889. Visual Studio - error : A project with that name is already opened in the solution.
13522정성태1/11/20242242닷넷: 2200. C# - HttpClient.PostAsJsonAsync 호출 시 "Transfer-Encoding: chunked" 대신 "Content-Length" 헤더 처리
13521정성태1/11/20242307닷넷: 2199. C# - 한국투자증권 KIS Developers OpenAPI의 WebSocket Ping, Pong 처리
13520정성태1/10/20242077오류 유형: 888. C# - Unable to resolve service for type 'Microsoft.Extensions.ObjectPool.ObjectPool`....'
13519정성태1/10/20242141닷넷: 2198. C# - Reflection을 이용한 ClientWebSocket의 Ping 호출파일 다운로드1
13518정성태1/9/20242387닷넷: 2197. C# - ClientWebSocket의 Ping, Pong 처리
13517정성태1/8/20242220스크립트: 63. Python - 공개 패키지를 이용한 위성 이미지 생성 (pystac_client, odc.stac)
1  2  3  [4]  5  6  7  8  9  10  11  12  13  14  15  ...