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

... 61  62  63  64  65  66  67  68  [69]  70  71  72  73  74  75  ...
NoWriterDateCnt.TitleFile(s)
12211정성태4/27/202019260개발 환경 구성: 486. WSL에서 Makefile로 공개된 리눅스 환경의 C/C++ 소스 코드 빌드
12210정성태4/20/202020691.NET Framework: 903. .NET Framework의 Strong-named 어셈블리 바인딩 (1) - app.config을 이용한 바인딩 리디렉션 [1]파일 다운로드1
12209정성태4/13/202017405오류 유형: 614. 리눅스 환경에서 C/C++ 프로그램이 Segmentation fault 에러가 발생한 경우 (2)
12208정성태4/12/202015965Linux: 29. 리눅스 환경에서 C/C++ 프로그램이 Segmentation fault 에러가 발생한 경우
12207정성태4/2/202015802스크립트: 19. Windows PowerShell의 NonInteractive 모드
12206정성태4/2/202018425오류 유형: 613. 파일 잠금이 바로 안 풀린다면? - The process cannot access the file '...' because it is being used by another process.
12205정성태4/2/202015094스크립트: 18. Powershell에서는 cmd.exe의 명령어를 지원하진 않습니다.
12204정성태4/1/202015090스크립트: 17. Powershell 명령어에 ';' (semi-colon) 문자가 포함된 경우
12203정성태3/18/202017937오류 유형: 612. warning: 'C:\ProgramData/Git/config' has a dubious owner: '...'.
12202정성태3/18/202021196개발 환경 구성: 486. .NET Framework 프로젝트를 위한 GitLab CI/CD Runner 구성
12201정성태3/18/202018434오류 유형: 611. git-credential-manager.exe: Using credentials for username "Personal Access Token". [1]
12200정성태3/18/202018523VS.NET IDE: 145. NuGet + Github 라이브러리 디버깅 관련 옵션 3가지 - "Enable Just My Code" / "Enable Source Link support" / "Suppress JIT optimization on module load (Managed only)"
12199정성태3/17/202016167오류 유형: 610. C# - CodeDomProvider 사용 시 Unhandled Exception: System.IO.DirectoryNotFoundException: Could not find a part of the path '...\f2_6uod0.tmp'.
12198정성태3/17/202019528오류 유형: 609. SQL 서버 접속 시 "Cannot open user default database. Login failed."
12197정성태3/17/202018811VS.NET IDE: 144. .NET Core 콘솔 응용 프로그램을 배포(publish) 시 docker image 자동 생성 - 두 번째 이야기 [1]
12196정성태3/17/202015942오류 유형: 608. The ServicedComponent being invoked is not correctly configured (Use regsvcs to re-register).
12195정성태3/16/202018262.NET Framework: 902. C# - 프로세스의 모든 핸들을 열람 - 세 번째 이야기
12194정성태3/16/202020993오류 유형: 607. PostgreSQL - Npgsql.NpgsqlException: sorry, too many clients already
12193정성태3/16/202017903개발 환경 구성: 485. docker - SAP Adaptive Server Enterprise 컨테이너 실행 [1]
12192정성태3/14/202019927개발 환경 구성: 484. docker - Sybase Anywhere 16 컨테이너 실행
12191정성태3/14/202021041개발 환경 구성: 483. docker - OracleXE 컨테이너 실행 [1]
12190정성태3/14/202015622오류 유형: 606. Docker Desktop 업그레이드 시 "The process cannot access the file 'C:\Program Files\Docker\Docker\resources\dockerd.exe' because it is being used by another process."
12189정성태3/13/202021209개발 환경 구성: 482. Facebook OAuth 처리 시 상태 정보 전달 방법과 "유효한 OAuth 리디렉션 URI" 설정 규칙
12188정성태3/13/202026020Windows: 169. 부팅 시점에 실행되는 chkdsk 결과를 확인하는 방법
12187정성태3/12/202015579오류 유형: 605. NtpClient was unable to set a manual peer to use as a time source because of duplicate error on '...'.
12186정성태3/12/202017399오류 유형: 604. The SysVol Permissions for one or more GPOs on this domain controller and not in sync with the permissions for the GPOs on the Baseline domain controller.
... 61  62  63  64  65  66  67  68  [69]  70  71  72  73  74  75  ...