|
Microsoft .NET Framework 에 의해 개발자의 생산성이 향상하는 것에 의문의 여지는 없습니다. 그러나 그 한편으로 매니지 코드의 퍼포먼스에 대해 염려를 안고 있는 사람들이
많이 있습니다. 신 버젼의 Visual C++ 에 의해 이러한 염려는 불식 됩니다. Visual
Studio 2005 에서는 보다 신속한 어플리케이션 작성을 목적으로 하여 C++ 의
구문 자체가 큰폭으로 개량되고 있습니다. 그리고 유연한
언어 체제가 준비되어 있어 공통 언어 런타임 (CLR) 과 제휴시키는 것에 의해 퍼포먼스의 높은 프로그램을 작성할 수 있습니다.
C++ 은 네이티브 코드를 생성하기 때문에 퍼포먼스가 좋다고 생각하는 프로그래머가 다수 있습니다. 그러나
완전한 매니지 코드에서도 뛰어난 퍼포먼스를 얻을
수 있습니다. C++에서는
유연한 프로그래밍 모델이 채용되고 있기 때문에 , 절차형 프로그래밍, 객체
지향 프로그래밍, 생성적 프로그래밍, 메타 프로그래밍
등에 유저가 속박될 것은 없습니다.
프로그래머가 가지고 있는 1개의 공통의 오해는 .NET Framework 가 뛰어난 퍼포먼스는 사용하는 언어에
영향을 받지 않는다고 하는 것입니다. 즉 프로그래머는 다양한 컴파일러에 의해 생성되는 Microsoft 중간 언어 (MSIL) 가 본질적으로 같다라고
보고 있습니다. Visual
Studio .NET 2003 에서 조차 이러한 생각은 올바르지는 않습니다. 한층 더 Visual Studio 2005 에 있어서는 C++ 컴파일러
팀이 수년에 걸치는 네이티브 코드의 최적화로부터 얻을 수 있던 지식을 매니지 코드의 최적화에 확실히 적용할 수 있도록 다대한 노력을 소비했습니다. C++ 에서는 고 퍼포먼스 마샬링등의 세세한 조정을 행하기 위한 유연성이 제공되고
있습니다. 다른 언어에서는 이러한 유연성은 실현될 수 없습니다. 게다가Visual C++ 컴파일러는 다른 .NET 언어와 비교해 보다
최적화된 MSIL를 생성합니다. 그 결과 가장 최적화된
.NET 의 코드를
생성하는 것은 Visual C++ 컴파일러라는 것이 됩니다.
최적화된 MSIL
.NET 환경의 컴파일은 2 개의 부분으로 나눌 수가 있습니다. 1 개는 프로그래머가 언어 컴파일러 (C#,Visual Basic, 또는 Visual
C++) 을 사용해 컴파일과 최적화를 실시해 MSIL 를 생성하는 부분입니다. 또 하나는 져스트인타임(JIT) 컴파일러 또는 NGEN이 MSIL를 받아 그것을 읽어들여 최적화된 네이티브인 기계어 코드를 생성하는 부분입니다. 언어 컴파일러와 JIT 가 밀접하게 결합되고 있는 것은 분명합니다. 즉 뛰어난 코드를 작성하려면
양 컴퍼넌트의 제휴가 필요하게 됩니다.
Visual C++ 은 어느 컴파일러보다 고도의 최적화를 항상 제공해 왔습니다. 이것은 매니지 코드에 대해서도 같습니다. 네이티브 컴파일러에 의한
MSIL 코드 생성의 최적화는 Visual C++ .NET 2003 에서 처음으로 도입되었습니다만
이 시점에서 이미 고도의 기능이 준비되어 있었습니다.
Visual C++ 2005 의 컴파일러에서는 표준적인 네이티브
코드의 최적화의 대부분을 MSIL 코드에 실행할 수 있습니다. 이러한
최적화에는 데이터 플로우 베이스의 최적화로부터 루프 전개의 식의 최적화까지 모든 종류가 포함됩니다. 다른 어느 .NET 플랫폼상의 언어도 이 레벨의 최적화는 갖추고
있지 않습니다. Visual
C++ .NET 2003 에서 /clr 스윗치를 사용한 빌드에 대한 프로그램 전체의 최적화 (WPO) 의 서포트는 행해지고 있지 않았습니다만 Visual C++ 2005 에서 이 기능을 매니지 코드에 적용할
수 있습니다. 이 기능을 사용하면 크로스 모듈의 최적화가 실행 가능하게 됩니다. 이 점에 대해서는 이 기사의 후반에 설명합니다.
Visual C++ 2005 의 매니지 코드에 적용할 수 없는
유일한 최적화 클래스는 Profile Guided Optimization 입니다. 하지만 장래의 버젼에서는 이 기능을 이용할 수 있게 되겠지요. 상세한 것에 대하여는 「Write Faster Code with the Modern Language Features of Visual
C++ 2005」(영어) 를 참조해 주세요.
JIT 과 컴파일러 최적화의 상호작용
JIT 또는 NGEN 은
Visual C++ 이 생성하는 최적화 코드로부터 native
code를 생성합니다. Visual C++ 컴파일러에 의해 생성된 코드가 MSIL인가 언 매니지 코드(비관리 코드)인가에 관계없이 코드의 생성에는 10 년 이상에 걸쳐서 개발 및 조정을 해 온 옵티마이저가
사용됩니다.
MSIL 코드에 적용되는 최적화는 언 매니지 코드에
적용되는 최적화와 거의 같습니다. 컴파일러가 검증 가능한 코드
(/clr:safe) 와 검증 불능인
코드의 어느 쪽을 생성할까에 의해 정당한 최적화 클래스가 다르다고 하는 점은 지적해 두는 가치가 있습니다. 메타데이타 또는
검증 가능성 제약을 위해서 컴파일러를 실행할 수 없는 최적화의 예로서는 강도의 삭감(곱셈을 포인터
가산에 변환)이나 어느 클래스의 private 멤버 액세스를
다른 클래스의 메소드 본체에 인 라인화하는 것등이
있습니다.
Visual C++ 컴파일러에 의해 생성된 MSIL 코드는 그
후 JIT 에 의해 이용됩니다. JIT 은 MSIL 을
읽어들여 최적화를 실행합니다만 이 최적화는 MSIL 의
차이에 매우 민감합니다. 즉 MSIL 가 있는 명령 순서가 최적화의 영향을 매우 받기 쉬운 한편 다른 (의미적으로
같은) 순서는 최적화에 의해 거의 영향을 받지 않는다고 하는 일이 있습니다. 예를 들면 레지스터 할당이라는 불리는 최적화에서는 JIT 옵티마이저가 변수를 레지스터에 할당합니다. 실제의 하드웨어는 이 레지스터를 오퍼랜드로서 사용해 산술 연산이나 논리 연산을 실행합니다. 의미적으로 등가인 코드에서도 기술 방법이 다르다면 옵티마이저가
레지스터 할당이라는 것을 적절히 실시할 수 없는 경우가 있습니다. 루프 전개 등의 코드 변환은 JIT 이 레지스터 할당에 지장을 초래하는 원인으로도 될 수 있습니다.
C++ 컴파일러가 실행하는 루프 전개는 명령 레벨의 병렬성을
향상시켜 동시에 보다 많은 생존 변수를 작성합니다. 옵티마이저는
이러한 변수를 레지스터에 할당할 필요가 있습니다. CLR JIT 에서는 추적 가능한 레지스터 할당을
위한 변수의 수는 고정되고 있습니다. 이 정수를 넘는 변수를 추적할 필요가 있는 경우 JIT 는 레지스터의 내용을 메모리로 옮깁니다.
이러한 이유이기 때문에 최적인 코드의 생성에는
Visual C++ 컴파일러와 JIT 를
제휴해 조정할 필요가 있습니다. Visual C++ 컴파일러가 실행하는 것은 JIT 이 실행하려면 시간이 너무 걸리는 최적화나 C++ 소스로부터 MSIL 에 컴파일 하는 과정에서 매우 많은 정보가 없어지는 최적화입니다.
다음에 매니지 코드에
대한 Visual C++ 의 최적화에 대해 몇 개인가를 봐 가기로 합시다.
공통 부분식의
삭제와 연산의 간단화
공통
부분식의 삭제(CSE) 와 연산의 간단화는 강력한
최적화입니다. 컴파일러는
이러한 수법을 사용해 식 레벨의 기본적인 최적화를 실행합니다. 그 결과 개발자는 알고리즘과 아키텍쳐에 집중할 수 있습니다.
이하는 C# 및 C++ 으로서 컴파일 된 코드 스니펫을 나타내고 있습니다. 어느쪽이나 Release 구성으로
컴파일 되고 있습니다. 변수 a,b,c 는 코드를 포함한 함수에 파라미터로서
건네받은 배열로부터 카피된 것입니다.
int d =
a + b * c;
int e =
(c * b) * 12 + a + (a + b * c);
그림 1 은 최적화를 유효하게 한 C# 컴파일러와 C++ 컴파일러에
의해 이 코드로부터 생성된 MSIL를 나타내고 있습니다. C# 에서는 19 의
명령이 필요합니다만 C++ 에 필요한 명령은 13 뿐
입니다. 그리고 이해와 같이 C++ 코드에서는
식 b*C 에 대해서 CSE 가 실행되고 있습니다. 옵티마이저는 연산의 단순화를 실행해 a+a 대신에 2*a 를 또 (c*b)*12 + c*b 대신에 (c*b)*13 를 각각 생성하고 있습니다. 후자의 CSE 은 특별히 우수하다고 생각합니다. 프로그래머가 이러한 연산의
단순화에 실패하고 있는 것을 실제로 본 적이 있기 때문입니다. "C# 컴파일러의 최적화"
를 참조해 주세요.
프로그램 전체의 최적화
Visual C++ .NET 에서는 WPO 이 언 매니지 코드에 대해서 추가되었습니다. Visual C++ 2005 에서 이 기능이 매니지 코드에도
확장되고 있습니다. 소스 파일의 컴파일과 최적화를 1 파일씩
실행할 필요는 없고 복수의
소스 파일과 헤더 파일을 정리해 한 번에 컴파일 및 최적화할 수 있습니다.
컴파일러는 복수의 파일을 대상으로 분석과 최적화를 실행할 수 있게 되었습니다. 예를 들면 WPO 이 없으면 컴파일러는 1 개의 컴파일 가능 파일 내에서 밖에 함수를 인 라인화할 수 없습니다.
WPO를 사용하면 프로그램내의 어느 소스 파일의 함수에서도 인 라인화할 수 있습니다.
이하의 예에서는 컴파일러는 인 라인화나 정수 전파 등의 최적화를 복수의 컴파일 가능 파일에 실행할 수 있습니다. 게다가 그 외의 프로시저간 최적화를 실행할 수도 있습니다.
// Main.cpp
...
MSDNClass ^MSDNObj = gcnew MSDNClass;
int x = MSDNObj->Square(42);
return x;
...
// MSDNClass.cpp
int MSDNClass::Square(int x)
{
return x*x;
}
이 예에서는 Main.cpp 가 다른 소스 파일에 포함되는 MSDNClass
의 Square 메소드를 호출하고 있습니다. /O2 최적화를 사용해여 프로그램 전체의 최적화를 사용하지 않고 컴파일 하면 이하와 같은
MSIL 이 Main.cpp 에 생성됩니다.
ldc.i4.s
42
call instance
int32 MSDNClass::Square(int32)
42 가 스택에
읽혀 다음에 Square 함수가 호출 되고 있는 것을 알 수 있습니다.
한편 프로그램 전체의 최적화를 유효하게 해 같은
프로그램을 컴파일 하면 생성되는 MSIL 은 이하와 같이 됩니다.
ldc.i4 0x6e4
42 를 읽어들일 것도 없고 또 Square 함수를
호출하는 일도 없습니다. 프로그램 전체의 최적화를 사용하는 것으로 컴파일러는 MSDNClass.cpp 의 함수의 인 라인화와 정수 전파를
실행할 수 있었습니다. 그 결과 42*42 의 연산 결과 즉 16 진수의 0x6e4 을 읽어들이는 명령만이 생성되었습니다.
Visual C++ 컴파일러가 실행하는 분석이나 최적화의 일부는 JIT 컴파일러가
실행하는 일도 이론상은 가능합니다만 JIT 컴파일러에 부과되고 있는 시간적인 제약을 위해 여기서
접하고 있는 최적화의 상당수는 현시점에서는 구현 할 수 없습니다. 일반론으로 말하면 NGEN 가 JIT 보다 먼저 이러한 최적화를 구현 한다고 생각됩니다. JIT 과는 달리 NGEN 에는 응답 시간의 제약이 부과되지 않기 때문입니다.
64 비트 NGEN 의 최적화
기사의
형편상 지금까지는 JIT NGEN 의 양쪽 모두를 정리해 JIT 로서 취급해 왔습니다. 32 비트의 CLR 에서는
JIT 컴파일러와 NGEN 는 어느쪽이나 같은 최적화를 실행합니다. 그러나 64 비트의 CLR 에서는 NGEN
은 JIT 보다 꽤 많은 최적화를 실행할 수 있습니다.
64 비트 NGEN 는 JIT 와
비교하여 훨씬 많은 시간을 컴파일에 소비할 수가 있습니다. 이것은 JIT 의 throughput가 어플리케이션의 응답 속도에 직접
영향을 주기 때문입니다. 이 기사에서는 주로 64 비트 NGEN 에 대해 설명합니다. 그 이유는 64 비트 NGEN 에서는 C++
스타일의 코드에 맞춘 조정을 하고 있어 또 Double Thunk
Elimination 등 다른 JIT 이나 NGEN 에는
없다 C++ 에 있어 매우 유효한 최적화가 준비되어 있기 때문입니다. 32 비트 JIT 및 64 비트 JIT 는 각각 마이크로소프트가 다른 팀에 의해 다른 코드 베이스를 이용해
구현 되었습니다. 32 비트 JIT 의 개발은 CLR 팀이 담당했습니다만 64 비트 JIT 는 Visual
C++ 팀이 Visual C++ 코드 베이스를 기초로서 개발했습니다. 64 비트 JIT 는
Visual C++ 팀에 의해 개발되었기 때문에 C++ 와 관계되는 문제를 보다 의식한
것이 되고 있습니다.
Double Thunk
Elimination
64 비트 NGEN 의
가장 중요한 최적화의 1 개는 Double Thunk Elimination 으로 불리는
것입니다. /clr 스윗치를 사용해 컴파일 된 C++ 코드의 경우 매니지 코드가
함수 포인터 또는 가상 호출을 개입시켜 매니지 엔트리
포인트를 호출하면 천이(遷移)가 발생합니다만 (/clr:pure 또는 /clr:safe 을 사용해 컴파일 된 코드에서는 이 천이는
발생하지 않습니다) Double Thunk
Elimination 는 이 천이를 처리합니다. 이 천이가 발생하는 이유는 함수 포인터와
가상 호출이 콜 사이트의 충분한 정보를 갖추지 않기 때문에 호출처가 매니지 엔트리 포인트 (MEP) 인가 언 매니지 엔트리 포인트
(UEP) 인가 를 판단할 수 없는 것에 있습니다.
하위 호환성을 유지하기 위해 UEP 가 항상 선택됩니다. 그러나 매니지 콜 사이트가
실제로 매니지 메소드를 호출했을 경우는 어떻게
되는 것일까요. 이 경우 매니지 콜 사이트로부터 UEP에의 최초의 썽크에 더해져 UEP 로부터 목적의 매니지
메소드에의 셩크가 발생합니다. 이 매니지 코드로부터 매니지
코드에의 셩크 프로세스는 일반적으로 더블 셩크로
불리고 있습니다.
64 비트 NGEN 는 "언
매니지 코드로부터 매니지 코드" 에의 호출을 매니지
코드에 셩크 백 하는 호출이라고 인식하는 것에 의해 이 더블 셩크를 최적화합니다. 64 비트 NGEN 는 셩크 백이 발생하고 있는지 어떤지를 확인해 발생하고
있는 경우는 그림 2 에 나타나듯이 양쪽 모두의 셩크를
스킵 해 매니지 코드에 직접 점프 합니다. 이 기능에 의해 다수의 명령을 생략 할 수가 있습니다. 실제로
사용되고 있는 코드를 모델로 한 벤치마크에서는 퍼포먼스가 5 ~ 10% 향상했음 (인공적인 테스트에서는 100% 을 넘은 적도 있습니다).
그림 2. Double
Thunk Elimination
다만
주의가 필요한 것은 이 최적화는 기정(既定)의 어플리케이션 도메인 내에서만 실행 가능이라고 하는 것입니다.
기정의 AppDomain 을 이용하면 퍼포먼스가 향상한다고 하는 원칙을 기억해 둬 주세요.
C++ 상호 운용 기능
C++ 상호 운용 기능은 매니지 코드와 네이티브 코드의 상호 운용을 관리하는 테크놀러지입니다. 이 테크놀러지에 의해 /clr
스윗치를 사용해 컴파일 된 표준의 C++ 코드로부터
네이티브 함수를 직접 호출할 수가 있게 됩니다. 그
때에 프로그래머가 코드를 추가할 필요는 없습니다. /clr 스윗치를 사용해 생성된 코드는 MSIL 됩니다 (일부 예외도 있습니다). 데이터는 매니지
데이터에도 언 매니지 데이터로도 될 수 있는 (유저가
지정합니다). C++ 상호
운용 기능은 가장 중요한 .NET 기능입니다만 완전히라고 말해도
좋을 정도 알려져 있지 않습니다. C++ 상호 운용 기능은 혁신적이라고 할 수 있을 정도의 기능을
제공합니다만 그것이 올바르게 인식 될 때까지는 당분간 시간이 필요한 것 같습니다.
.NET 에 준거한 다른 언어로 네이티브 코드와의 상호 운용을 실현하려면 DLL 에 native code를 배치해 dllimport (또는 동등의 것. 사용하는 언어에 따라서 다릅니다) 를 사용해 P/Invoke
로 명시적으로 함수를 호출합니다. 그
이외의 방법을 사용하는 경우는 처리의 무거운 COM 상호 운용 기능을 사용해 native code에 액세스 할 필요가 있습니다. 이것은 분명하게
불편한 방법이며 많은 경우 C++ 와 비교해 퍼포먼스가
크게 뒤떨어집니다.
C++ 상호 운용 기능은 C++ 언어의 퍼포먼스 향상 기능으로서 통상은 보여지고 있지 않습니다. 그러나
C++ 상호 운용 기능이 제공하는 유연성과 편리성에 의해 CLR 를 타겟으로 하는 것으로 퍼포먼스를 향상시킬 수가 있습니다.
단일 이미지내의 네이티브
코드와 매니지 코드
Visual C++ 에서는 매니지 코드로 하는 함수와
네이티브 코드로 하는 함수를 프로그래머가 개개에 선택할 수 있습니다. 이 선택을 실시하려면 #pragma
managed 라는 #pragma
unmanaged 를 사용합니다. 예를
그림 3에
나타냅니다. 어려운 컴퓨터 태스크를 실행하는 경우 코어 함수를 네이티브 컴파일 해 다른 코드를 매니지 컴파일 하는 것이
바람직한 일이 있습니다. C++ 에서는 단일의 이미지 내에 매니지 코드와 네이티브 코드를 혼재시킬 수가 있습니다. 네이티브 함수로부터 매니지
함수를 호출하는 경우(또는 그 역의 경우) 특별한 구문을
기술할 필요는 없습니다. C++ 에서 이러한 섬세함에 의해 매니지 코드로부터 네이티브 코드에의 천이 , 및 네이티브 코드로부터 매니지 코드에의 천이를 용이하게 제어할 수 있습니다.
매니지 코드로부터 네이티브
코드에 천이 하는 경우(또는 그 역의 경우) 컴파일러
및 링커에 의한 셩크의 생성이 실행 플로우에 포함되게 됩니다. 당연한 일입니다만 프로그래머는 이러한
셩크의 생성에 의한 코스트를 회피하고 싶다고 생각합니다. CLR 과 컴파일러는 천이의 코스트를 최소한으로 억제하기 위해
다수의 처리를 실행합니다만 개발자의 쪽에서 천이의 발생 빈도를 최소화할 수도 있습니다.
그림 4의 파트 A 에
나타내는 C++ 어플리케이션은 일부의 코드 (Z.cpp) 가 (/clr
를 사용해) MSIL 그리고 다른 코드 (X.cpp 와 Y.cpp)
가 네이티브 코드에 컴파일 되고 있습니다. 이
프로그램의 Y.cpp 과 Z.cpp 에는
복수의 함수가 포함되어 있어 서로 다수의 호출을 실행하고 있습니다. 그 결과 매니지 코드와 네이티브 코드의 천이가 다수 발생하고
있어 프로그램의 실행 속도를 저하시키고 있습니다.
그림 4. Changing
Managed Boundaries
그림 4. 의 파트 B 는
이 프로그램을 최적화해 매니지 코드와 네이티브
코드의 천이를 최소화하는 방법을 나타내고 있습니다. 이것은 상호 호출이 다수 발생하고 있는 인터페이스를
특정해 이것들을 매니지 영역 또는 네이티브 영역의
어느 쪽인가에 정리해 이동하는 것으로 인터페이스간에 빈번하게 발생하는 천이를 제거한다고 하는 생각에 근거하고 있습니다. Visual C++ 의 상호
운용 기능을 사용하면 이
태스크를 간단하게 실행할 수 있습니다.
예를 들면 ,그림 4. 의 A 으로부터 B 로 구성을 변경하려면 /clr 스윗치를 사용해 Y.cpp 를
재컴파일 할 뿐입니다. Y.cpp
은 매니지 코드에 컴파일 되어 Z.cpp 로부터
의 호출에 수반하는 매니지 코드와 네이티브 코드의
천이의 코스트는 없어집니다. 물론
Y.cpp 이 MSIL 가 되는 것의 퍼포먼스 코스트도 고려해 이러한 구성 변경이
어플리케이션에 있어 타당한 트레이드 오프인 것을 확인할 필요가 있습니다.
고 퍼포먼스
마샬링
매니지 코드와 네이티브
코드의 상호 운용과 관계되는 처리 중에서 가장 코스트의 비싼 처리의 1 개가 마샬링입니다. C# 이나 Visual
Basic .NET 등의 언어의 경우 마샬링은 (기정의 마샤러 또는 ICustomMarshaler 을 구현하는 경우에는 커스텀
마샬링 코드를 사용해) P/Invoke 가 불려 갔을
때에 CLR 에 의해 암묵적으로 실행됩니다. C++ 상호 운용 기능을 사용하면
프로그래머가 필요에 따라서 코드내의 데이터를 명시적으로
마셜 할 수 있습니다. 이 방법의 장점은 프로그래머가 데이터를 네이티브
데이터에 한 번 마셜 하는 것만으로 이 마샬링 데이터의 결과를 복수의 호출로 재 이용할 수 있게 되기 때문에 마샬링의 코스트를 메울 수가 있다고 하는 점에 있습니다.
그림 5 은 /clr 스윗치를
사용해 컴파일 된 스니펫을 나타내고 있습니다. 이
코드에는 for 루프가 1 개 포함되어 있어 그 내부에서
네이티브 함수 (GetChar)
가 불려 가고 있습니다. 그림 6 에서는
같은 코드가 C# 로 실장되고 있습니다. 그곳에서는 이하에 나타내듯이 GetChar 의
호출에 의해 CSharpType 클래스가 NativeType 에 마셜 되고 있습니다.
class NATIVECODE_API NativeType
{
public:
NativeType();
int pos;
int length;
char *theString;
};
C++ 에서 유저가 명시적으로 네이티브형을 사용할 수 있기 때문에 암묵적인 마샬링은 필요 없습니다. 이 최적화에 의해 코스트를 큰 폭으로
삭감할 수 있습니다. 이 예에서는 C++ 의 구현은 C# 의 구현과 비교해 18 배 고속으로 실행됩니다.
.NET 형태를 사용한 템플릿과 STL
Visual C++ 2005 에 새롭게 도입된 퍼포먼스 기능
중에서도 특히 흥미로운 것으로서 매니지형을 사용한 템플릿
(STL/CLI 을 포함한) 매니지 코드에
의한 프로그램 전체의 최적화 지연 읽어들여기 Deterministic Finalization 가
있습니다. Visual C++ .NET 2003 에서는 네이티브형
템플릿의 MSIL 을 생성할 수 있습니다만 매니지형을 템플릿의
파라미터형으로서 사용할 수 없습니다. Visual C++
2005 에서 이 점에 대해 수정을 하고 있어 템플릿에 매니지형 또는 언 매니지형을 파라미터로서 포함할 수가 있습니다. 현재는 템플릿에 의해 제공되는 훌륭한 기능을 .NET 안에서
기술된 코드로부터 이용할 수 있게 되어 있습니다 (Blitz++ 나 Boost 라이브러리에 의해 된 실적에 대해서도 대충 훑어보는 것을 잊지 말아 주세요).
C++ 의 STL (Standard Template Library) 는 라이브러리 설계에 있어서의
가장 중요한 이노베이션(innovation)의 1 개입니다. STL이 제공하는 다수의
컨테이너나 알고리즘이 뛰어난 추상화를 퍼포먼스에 영향을
주는 일 없이 이용할 수 있습니다. Visual C++ .NET 2003에서 템플릿에 있어서의
제약을 위해 매니지형에 대해서는 STL 동등의 라이브러리는 없었습니다. Visual C++ 2005 에서는
이 제약이 제거되어STL/CLI 로 불리는 라이브러리가
도입되고 있습니다. 이것은 STL 의 검증 가능한 버젼이며 매니지형을 취급할
수가 있습니다. .NET 에 처음으로 컨테이너를 제공한 것은 기본 클래스 라이브러리(BCL) 입니다만 Visual C++ 그룹은 STL/CLI 의 퍼포먼스가 우수하다고 생각하고 있습니다. STL/CLI 의 상세한
것에 대하여는 Visual C++ Developer Center 에 게재되고 있는 Stan Lippman 의 훌륭한 기사 「STL.NET Primer」(영어) 를 참조해 주세요.
STL/CLI 를 이용하면 STL
의 vector,list,deque,map,set,hash
map,hash set 등 을 자유롭게 구현할 수 있습니다. 그리고 소트 , 검색 , 집합 조작 , 내적 , 전
요소 가산 등의 알고리즘도 이용할 수 있습니다. STL/CLI 의 알고리즘에 관해서 하나 놀라게 하는 것은 네이티브 버젼과 STL/CLI 버젼으로 같은 구현이 채용되고 있는 것입니다. STL 이 뛰어난 설계에
의해 이식성이 높고 파워풀한 코드를 작성할 수 있다고
하는 형태로 모든 프로그래머가 혜택을 받습니다.
결정론에 의한 퍼포먼스의
향상
C++ 이 뛰어난 라이브러리에는 다양한 패턴이나 관용어를 가지고
있어 이것들을 자유롭게 사용하는 것으로 효율적인 코드를 용이하게 작성할 수 있습니다. RAII (Resource Acquisition Is
Initialization)를 포함해 이러한 패턴이나 관용어의 상당수는 Deterministic
Finalization 으로 불리는 C++ 언어의
기능을 사용하고 있습니다. Deterministic Finalization 의 기본 기능은 오브젝트가 delete 연산자에 의해 삭제되었을 때 (heap에 배치된 오브젝트의
경우) 또는 오브젝트가 스코프의 밖에 나왔을 때 (스택에 배치된 오브젝트의 경우)에 오브젝트의 소멸자를 기동하는 것입니다. Deterministic
Finalization 은 퍼포먼스의 향상에 도움이 됩니다. 오브젝트가 (절대적으로 필요한 범위를 넘어) 자원을 길게 보관 유지하면 할수록 다른 오브젝트가 같은 자원을 취득하려고 했을 때의 퍼포먼스 저하가 격렬해지기 때문입니다.
CLR 파이널리저를 사용하면 오브젝트가 스코프의 밖에 나온 후가 있는 시점에서 파이널리저 코드가
실행됩니다 (락을 해방하는 코드가 파이널리저라고 가정하고 있습니다). 다만 파이날제레이션 thread가 오브젝트의 파이널리저에 대해서 기동되기 전에 실행될 것은 없습니다. 이것은
분명하게 최적인 동작이라고는 말할 수 없습니다. 프로그래머가 예기 한 타이밍에 파이날제레이션 thread가 실행된다고는 할 수 없기 때문입니다. 게다가 파이널리저가 실행되기 전에 오브젝트의 보관 유지하고
있던 메모리가 가베지 컬렉트 될 것은 없습니다. 이것은 프로그램이 사용하는 메모리의 증가로 연결됩니다.
.NET 베이스의 코드로 이 문제를 회피하는 일반적인 관용어의
하나로 Dispose 패턴이
있습니다. Dispose 패턴을 사용하려면 클래스에 Dispose 메소드를 실장해 오브젝트가 불필요하게 되었을 때에 그 메소드를 호출할 필요가 있습니다. 이 메소드가 불려 가는 코드내의 장소는 C++ 프로그래머가 오브젝트의
삭제를 실행하는 장소와 같습니다. 그러나 C++ 에 있었어
조차 이러한 처리는 에러의 발생으로 연결되기 쉽고 , 코드가 매우 장황하게 됩니다. C# 등의 언어에서는
"using" 컨스트래트가 추가되고 있어 에러의 발생이나 장황한
기술의 회피에 도움이 됩니다. 다만 중요한 케이스에서는 역시 기술이 복잡이 되어 에러의 원인으로도 됩니다.
이러한 방법과는 달라 C++ 의
RAII 관용어는 자원의 취득과 해방을 자동적으로 실시합니다. 그리고 프로그래머가 코드를
추가할 필요가 없기 때문에 에러가 발생할 가능성도 낮아집니다. Visual C++ .NET 2003
에서는 스택에 배치된 .NET 오브젝트의
Deterministic Finalization 은 서포트되고
있지 않았습니다만 Visual C++ 2005 에서는 이 기능이 서포트되고 있습니다.
그림 7의
전반의 코드로 Socket_t 형태의 오브젝트가 스택 베이스의 구문을 사용해 그리고 스택 베이스의 클린 업 시멘틱스를 갖추는 것에 주의해 주세요. 3 행째에서 예외가 슬로우
되었을 경우는 어떻게 되는 것일까요. 스택 베이스의
시멘틱스가 사용되고 있기 때문에 mainSock 의 소멸자가 확정적으로 실행됩니다. 다만 ,backupSock 이 아직 스택상에 작성되어 있지 않기 때문에 파기되는 오브젝트는 존재하지 않습니다.
이 예와 의미적으로 등가인 코드를 C# 로 작성하면 그림 7 의
후반에 가리키듯이 기술이 약간 복잡이 되어 에러로 연결되기 쉬워집니다.
이것은 사소한 예에 지나지 않습니다만 태스크가 복잡하게 되는 것에 따라 실수를 범할 가능성이 높아집니다.
지연 읽기
.NET Framework 에서는 퍼포먼스의 조정을 하고 있습니다만 CLR 이 읽히는 기동시에 약간의 지연이 발생합니다. 어플리케이션이 많게는 매니지 코드가 없는 코드 패스나 시나리오가 포함되어 있습니다. 이
경향은 기존의 레가시 프로그램에 .NET 기능을 짜넣는 경우에 특히 현저합니다. 이러한 환경에서는 CLR 의 읽어들여에 관련하는 어플리케이션 기동시의 지연을 회피할
필요가 있습니다. DLL 의
지연 읽기로 불리는 Visual C++ 의 기존의 기능을 사용하는 것으로 이 문제를 해결할 수
있습니다.
이것은 실제로 사용할 경우에 처음 DLL 을 읽어들인다고 하는 생각에 근거하고 있습니다. .NET 어셈블리의 DLL 을 읽어들이는 경우에도 같은 개념을 적용할 수 있습니다. 링커 옵션 /DELAYLOAD:dll 에 지연 읽는 .NET 어셈블리를
지정하면 지정한 .NET 어셈블리 뿐만이 아니라 CLR 의
읽기도 지연 시킬 수가 있습니다 (모든 .NET 어셈블리가
지연 읽어들이게 되는 경우). 그 결과 네이티브 어플리케이션과 동일한 정도의 속도로 기동할 수 있게 되어 매니지 어플리케이션에 관한
가장 일반적인 불만의 1 개가 해소되게 됩니다.
dllexport 가 항상 유리한 계책이라고는 할 수 없는 이유
__declspec(dllexport)
를 사용하는 것에는 몇개의 결점이
있습니다. dllexport 에 관한 문제가 발생하는 것은 매니지 코드로
작성된 2 개의 이미지 (DLL 또는 exe) 이 #using 이 아닌 dllexport
를 개입시켜 기능을 공개하고 있는 경우입니다. dllexport 는 네이티브 컨스트랙트이기 때문에 __declspec(dllexport)
를 개입시켜 DLL 의 경계를 넘은 호출이
발생할 때마다 우선 매니지 코드로부터 네이티브
코드에의 천이가 계속되어 네이티브 코드로부터 매니지
코드에의 천이가 생깁니다. 이것은 퍼포먼스의 악화로
연결됩니다.
이 퍼포먼스의 문제를 해결하는 옵션은 한정되어 있습니다. __declspec(dllexport) 를 단순한 "스윗치" 로 돌연 바꾸어
매니지
코드에의 셩크를 발생시키지 않는 컨스트랙트로 변환하는
일은 할 수 없습니다. 추천 되는 해결책은 export 되는 기능을 매니지형 (참조형의 class 또는 값 형의 struct)
으로 랩 하는 것입니다. 이것에 의해 임포터는 "#using" 을 개입시켜 export DLL 에 액세스 해 직접 DLL 의 기능을 이용할
수 있게 됩니다. 이와 같이 변경하는 것으로 매니지
클라이언트가 매니지 코드를 호출해도 천이가 발생하지 않게 됩니다. 이 구조를 그림 8 에 나타냅니다. 파트 A 는 __declspec(dllexport) 의 사용에
수반하는 코스트를 나타내고 있어 파트 B 는 .NET 형태에
의한 함수의 랩핑과 #using 를 사용한 최적화의 결과를 나타내고 있습니다. 다만 이 방법에는 export DLL 의 언 매니지 임포터가 DLL 의
기능을 __declspec(dllimport)
할 수 없다고 하는 잠재적인 문제가 수반합니다. 변경을 실시하는 경우에는 이 점에 대해 고려할
필요가 있습니다.
그림 8. 셩크 코스트의 삭감
그림 8. 의 파트 A 는
__declspec(dllexport)
을 사용해 매니지 함수를 매니지 코드에
공개하는 경우의 천이 패스를 나타내고 있습니다. 파트 B 는
함수에의 액세스를 나타내고 있어 그곳에서는 매니지형에 의한 함수의 랩과 #using 이 사용되고 있습니다. 그 결과 파트 A 의 프로세스와는 달라 코스트의
비싼 산크가 제거되고 있습니다.
통계
Visual Studio .NET 2002 C++ 에 도입된
이래 Visual C++ 에 의한 .NET Framework 은
크게 진화해 왔습니다. C++
이 제공하는 지금까지 없을 만큼의 유연성에 의해 C++ 프로그래머는 퍼포먼스의 높은 매니지 코드를 익숙해진 방법으로 기술할 수가
있습니다. .NET 프로그래밍이 가능한 언어는 많이
있습니다만 퍼포먼스의
최대화에 관심이 있다면 Visual C++ 을 선택해야 합니다.
|