성태의 닷넷 이야기
홈 주인
모아 놓은 자료
프로그래밍
질문/답변
사용자 관리
사용자
메뉴
아티클
외부 아티클
유용한 코드
온라인 기능
MathJax 입력기
최근 덧글
[정성태] Roll A Lisp In C - Reading ; https...
[정성태] Java - How to use the Foreign Funct...
[정성태] 제가 큰 실수를 했군요. ^^; Delegate를 통한 Bein...
[정성태] Working with Rust Libraries from C#...
[정성태] Detecting blocking calls using asyn...
[정성태] 아쉽게도, 커뮤니티는 아니고 개인 블로그입니다. ^^
[정성태] 질문이 잘 이해가 안 됩니다. 우선, 해당 소스코드에서 ILis...
[양승조
] var대신 dinamic으로 선언해서 해결은 했습니다. 맞는 해...
[양승조
] 또 막혔습니다. ㅠㅠ var list = props[i].Ge...
[양승조
] 아. 감사합니다. 어제는 안됐던것 같은데....정신을 차려야겠네...
글쓰기
제목
이름
암호
전자우편
HTML
홈페이지
유형
제니퍼 .NET
닷넷
COM 개체 관련
스크립트
VC++
VS.NET IDE
Windows
Team Foundation Server
디버깅 기술
오류 유형
개발 환경 구성
웹
기타
Linux
Java
DDK
Math
Phone
Graphics
사물인터넷
부모글 보이기/감추기
내용
<div style='display: inline'> <br /> <div class='mainCenterTitle'>Orcas - VC++ 다중 소스 동시 컴파일 옵션: /MP</div><br /> <br /> 컴파일 옵션만큼은... VC++이 .NET보다는 앞서 있습니다.<br /> 일례로, 다중 코어(또는 하이퍼쓰레딩)에 따른 다중 프로젝트 동시 컴파일은 VS.NET 2005에서 VC++이 지원을 해주던 것을, .NET 프로젝트는 Orcas에 와서야 해주게 되었지요.<br /> <br /> 그런데, Orcas에서의 VC++는 한 걸음 더 나아가고 있습니다. 이젠 프로젝트 수준이 아닌, "소스 파일" 수준에서 동시 컴파일을 지원합니다. 이에 대해서는 다음에서 설명해 주고 있습니다.<br /> <br /> <pre class='code'> 차세대 Visual C++의 내부 살펴보기 - 사용자 계정 컨트롤을 위한 준비 ; http://msdn.microsoft.com/msdnmag/issues/07/06/Cpp/default.aspx?loc=ko#S8 </pre> <br /> 오... 멋집니다. ^^<br /> 아직은 베타 버전이라서 그런지 VC++ 프로젝트 속성창에서는 "/MP" 스위치에 대한 명시적인 옵션이 제공되지 않고 다음과 같이 직접 지정을 해야 사용이 가능합니다.<br /> <br /> <img alt='cl_new_mp_option_1.png' src='/SysWebRes/bbs/cl_new_mp_option_1.png' /><br /> <br /> <hr style='width: 50%' /><br /> <br /> 기대에 부풀어서, 이제 빌드 명령을 내려 보았습니다. 역시나... 딱 한방에 되진 않는군요. 어쩌겠습니까??? 하나씩 해결해 나가는 수밖에. ^^<br /> <br /> <span class='subLastTitle'>1. /Gm (Enable Minimal Rebuild)</span> <br /> 우선, 첫 번째... "/Gm" 옵션이 문제였습니다. 해당 컴파일러 스위치가 같이 사용되는 경우 다음과 같은 경고가 발생합니다.<br /> <br /> <pre class='code'> cl : Command line warning D9030 : '<b>/Gm</b>' is incompatible with multiprocessing; <b>ignoring /MP</b> switch </pre> <br /> 왠지 아깝지만... 해당 프로젝트의 속성창에서 "C/C++" / "Code Generation" 범주의 "Enable Minimal Rebuild" 옵션을 해제했습니다.<br /> <br /> <span class='subLastTitle'>2. /Yc (Create Precompiled Header File)</span> <br /> /Yc 옵션이 붙은 경우에도 다음과 같은 경고가 발생합니다.<br /> <br /> <pre class='code'> cl : Command line warning D9030 : '<b>/Yc</b>' is incompatible with multiprocessing; <b>ignoring /MP</b> switch </pre> <br /> 이 옵션은 ...? 별도로 설정한 것이 없어서 난감하더군요. 아직 베타 버전이라 그런지 /Yc 옵션에 대한 판단에 버그가 있는 것 같습니다. 어느 경우에는 새로 빌드하면 위와 같은 경고가 발생하다가도, 어느 순간 이후부터는 경고가 사라졌습니다.<br /> <br /> 분명한 것은, /Yc 옵션이 stdafx.cpp 파일 이외에 지정이 되었다면 조정이 되어야 한다는 것.<br /> <br /> <span class='subLastTitle'>3. #import 사용</span> <br /> 보통, 외부 COM 개체를 사용하는 경우, 다음과 같은 식의 #import 구문을 이용해서 참조를 하게 되지요.<br /> <br /> <pre class='code'> #import ".\ExternalCom.dll" </pre> <br /> 그런데, 이 옵션으로 인해 다음과 같은 오류가 발생하게 됩니다.<br /> <br /> <pre class='code'> d:\...\test.h(265) : error C2813: <b>#import</b> is not supported with <b>/MP</b> </pre> <br /> 음... 이건 좀 불편하게 되었군요. 그런데, 가만 보니 모든 #import 구문에서 오류가 나는 것은 아니었습니다. 오호... stdafx.h 파일에서 정의된 #import에서는 오류가 안나고, 그 이외의 파일들에서는 오류가 나는군요. /MP 스위치를 이용해서 빌드를 해보면 알게 되지만, "precompiled-header" 파일을 생성해 내는 stdafx.cpp 파일인 경우에는 다른 C/C++ 파일들과 동시에 빌드되지 않는다는 점을 발견하게 됩니다. 따라서, #import 구문이 stdafx.h 파일에 있는 경우에는 다중 소스 컴파일 기능에 영향을 미치지 않기 때문에 오류가 안 나는 것이었습니다.<br /> <br /> 이 때문에, 각 소스 파일에 흩어져 있던 #import를 이용한 COM 개체 소스 생성 구문을 stdafx.h 파일로 모았습니다.<br /> <br /> <hr style='width: 50%' /><br /> <br /> 일단,,, 제가 만든 프로젝트들에서는 위와 같은 정도의 충돌만 있었을 뿐이었습니다. 모두 수정하고 나니 정상적으로 다중 소스 컴파일이 지원되었습니다. 우와~~~ ^^.<br /> <br /> 자... 이제 결과를 보기 위해. 최대한 환경을 동일하게 하기 위해서 - 디스크 캐쉬라든가 - 우선, "Clean Solution" 메뉴를 이용해서 모든 파일을 제거한 다음에 빌드를 새로 했습니다. 그다음에 다시 "Rebuild Solution" 메뉴를 이용해서 빌드를 할 때 시간을 재보았습니다.<br /> <br /> 각각 Debug 모드로 빌드했고 - 현실적으로 개발시에 가장 빈번히 빌드되는 유형이므로 - 한 번은 /MP 스위치를 주고, 한 번은 주지 않는 식으로 테스트해서 7개의 프로젝트를 가진 솔루션을 대상으로 테스트했습니다.<br /> <br /> <pre class='code'> /MP 스위치 있을 때: <b>1분 42초</b> /MP 스위치 없을 때: <b>2분 11초</b> </pre> <br /> 흠... 29초라... 기대했던 만큼은 많이 차이가 나지 않는 군요. 사실, 생각해 보면 그다지 차이가 나지 않을 법한 이유를 알게 됩니다.<br /> <br /> 왜냐하면, 이미 VS.NET 2005부터 "다중 프로젝트 동시 컴파일"을 지원하고 있었지요. 그래서, "프로젝트 의존성"이 없는 한은 (2개의 CPU 코어가 있는 경우를 가정하면,) 2개의 프로젝트를 동시에 빌드하고 있었습니다. 즉, "/MP" 스위치가 빛을 발하는 시점은, "프로젝트 의존성"으로 인해 빌드가 "직렬"로 단일 프로젝트만 대상이 되어 빌드 수행 시에 C/C++ 파일을 2개씩 동시 컴파일을 하게 되는 경우입니다.<br /> <br /> 그래서, 빌드와 함께 CPU 모니터링을 하면 재미있는 현상을 볼 수 있습니다. /MP 스위치가 있는 경우에는 거의 항상 CPU가 100%를 치고 있는 반면, /MP 스위치가 없는 경우에는 다중 프로젝트 빌드 시에는 100%를 치고 있다가도 의존성으로 인한 단일 프로젝트 빌드로 진입하게 되면 50%로 떨어지게 됩니다.<br /> <br /> 좀 더 확실한 결과를 얻기 위해서 단일 프로젝트를 대상으로만 한정지어서 빌드를 다시 해본 결과는 다음과 같았습니다.<br /> <br /> <pre class='code'> /MP 스위치 있을 때: <b>46초</b> /MP 스위치 없을 때: <b>59초</b> </pre> <br /> 음... ^^; 일단 13초에 만족합시다.<br /> <br /> <hr style='width: 50%' /><br /> <br /> 정리해 볼까요?<br /> <br /> 어찌 보면, /MP 스위치를 모든 프로젝트에 사용할 필요는 없어 보입니다. 왜냐하면 "다중 프로젝트 동시 빌드"가 이뤄지는 시점에는 /MP 스위치가 필요 없기 때문입니다. 따라서, 자신의 VC++ 솔루션을 빌드하면서 의존성으로 인한 단일 프로젝트 빌드만을 찾아내서 /MP 스위치를 적용하는 것도 현명할 수 있습니다.<br /> <br /> 하지만, 언제나 솔루션 단위의 빌드를 하는 것은 아니죠. 대개의 경우 하나의 프로젝트만을 대상으로 하면서 그 프로젝트 하나만을 다시 빌드하는 경우도 많기 때문에. 그것을 생각해 보면 모든 프로젝트에 /MP 스위치를 적용시키는 것도 좋을 것 같습니다.<br /> <br /> 크게 만족스러운 성능 차이는 아니지만. 그래도 VC++ 컴파일러의 이러한 꾸준한 노력이 마음에 듭니다. ^^<br /> <br /><br /><hr /><span style='color: Maroon'>[이 토픽에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]</span> </div>
첨부파일
스팸 방지용 인증 번호
4265
(왼쪽의 숫자를 입력해야 합니다.)