Microsoft MVP성태의 닷넷 이야기
VC++: 32. VC++에서 bool이 가지는 의미 [링크 복사], [링크+제목 복사],
조회: 25682
글쓴 사람
정성태 (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로 얻는 절약은 다른 부하로 다 까먹는 결과일 거라고. ^^
정성태

... 31  32  [33]  34  35  36  37  38  39  40  41  42  43  44  45  ...
NoWriterDateCnt.TitleFile(s)
13114정성태8/2/202217293.NET Framework: 2039. C# - Task와 비교해 본 ValueTask 사용법파일 다운로드1
13113정성태7/31/202216801.NET Framework: 2038. C# 11 - Span 타입에 대한 패턴 매칭 (Pattern matching on ReadOnlySpan<char>)
13112정성태7/30/202217656.NET Framework: 2037. C# 11 - 목록 패턴(List patterns) [1]파일 다운로드1
13111정성태7/29/202217065.NET Framework: 2036. C# 11 - IntPtr/UIntPtr과 nint/nuint의 통합파일 다운로드1
13110정성태7/27/202216792.NET Framework: 2035. C# 11 - 새로운 연산자 ">>>" (Unsigned Right Shift)파일 다운로드1
13109정성태7/27/202218313VS.NET IDE: 177. 비주얼 스튜디오 2022를 이용한 (소스 코드가 없는) 닷넷 모듈 디버깅 - "외부 원본(External Sources)" [1]
13108정성태7/26/202215725Linux: 53. container에 실행 중인 Golang 프로세스를 디버깅하는 방법 [1]
13107정성태7/25/202214548Linux: 52. Debian/Ubuntu 계열의 docker container에서 자주 설치하게 되는 명령어
13106정성태7/24/202214124오류 유형: 819. 닷넷 6 프로젝트의 "Conditional compilation symbols" 기본값 오류
13105정성태7/23/202216542.NET Framework: 2034. .NET Core/5+ 환경에서 (프로젝트가 아닌) C# 코드 파일을 입력으로 컴파일하는 방법 - 두 번째 이야기 [1]
13104정성태7/23/202220264Linux: 51. WSL - init에서 systemd로 전환하는 방법
13103정성태7/22/202215587오류 유형: 818. WSL - systemd-genie와 관련한 2가지(systemd-remount-fs.service, multipathd.socket) 에러
13102정성태7/19/202215462.NET Framework: 2033. .NET Core/5+에서는 구할 수 없는 HttpRuntime.AppDomainAppId
13101정성태7/15/202228596도서: 시작하세요! C# 10 프로그래밍
13100정성태7/15/202217274.NET Framework: 2032. C# 11 - shift 연산자 재정의에 대한 제약 완화 (Relaxing Shift Operator)
13099정성태7/14/202216762.NET Framework: 2031. C# 11 - 사용자 정의 checked 연산자파일 다운로드1
13098정성태7/13/202214401개발 환경 구성: 647. Azure - scale-out 상태의 App Service에서 특정 인스턴스에 요청을 보내는 방법 [1]
13097정성태7/12/202213466오류 유형: 817. Golang - binary.Read: invalid type int32
13096정성태7/8/202217107.NET Framework: 2030. C# 11 - UTF-8 문자열 리터럴
13095정성태7/7/202214552Windows: 208. AD 도메인에 참여하지 않은 컴퓨터에서 Kerberos 인증을 사용하는 방법
13094정성태7/6/202214218오류 유형: 816. Golang - "short write" 오류 원인
13093정성태7/5/202214980.NET Framework: 2029. C# - HttpWebRequest로 localhost 접속 시 2초 이상 지연
13092정성태7/3/202216615.NET Framework: 2028. C# - HttpWebRequest의 POST 동작 방식파일 다운로드1
13091정성태7/3/202215196.NET Framework: 2027. C# - IPv4, IPv6를 모두 지원하는 서버 소켓 생성 방법
13090정성태6/29/202214382오류 유형: 815. PyPI에 업로드한 패키지가 반영이 안 되는 경우
13089정성태6/28/202215068개발 환경 구성: 646. HOSTS 파일 변경 시 Edge 브라우저에 반영하는 방법
... 31  32  [33]  34  35  36  37  38  39  40  41  42  43  44  45  ...