CLR Via C# 2nd Edition 을 읽는 도중 흥미로운 부분이 있어 기록해 놓는다.

요지는 관리 코드인 경우 IL -> JIT -> Native Code 단계로서 최종적으로 C++과 같은 Native 코드를 생산해 내지만, 중간 단계인 JIT 에서 속도의 저하가 일어난다 라고 사람들은 알고 있다. 하지만, JIT 의 경우 Native 코드로 컴파일할때 현재 실행환경(CPU, 32, 64비트 환경 여부 등)을 정확하게 파악하고 있으므로, 항상 해당 환경에 최적화된 Native Code 를 생산해준다..... 라는것! 일리 있어 보이는데?

믿기 힘들겠지만 필자를 포함한 많은 사람들은 비관리 어플리케이션보다 관리되는 어플리게이션이 더 빠르다고 생각한다. 이에 대한 근거는 많이 있다. 예를 들면, JIT 컴파일러는 IL코드를 네이티브 코드로 컴파일할 때 어플리케이션의 실행 관경에 대해서 비관리 컴파일러보다 훨씬 더 자세하고 정확하게 알고 있다. 다음은 관리 코드가 비관리 코드보다 성능이 우수할 수 있는 몇 가지 근거이다.

• 컴파일 시에 JIT 컴파일러는 실행 환경이 펜티엄4 CPU 라는 것을 알 수 있고 또 펜티엄4 CPU라는 것이 확인되면 이에 최적화된 지시어를 이용해서 네이티브 코드를 생성함으로써 성능을 향상시킬 수 있다.

• JIT 컴파일러는 특정 상황의 테스트 값 혹은 논리 연산의 결과를 실행 전에 이미 정확히 알 수 있다. 다음의 코드가 이런 예이다.
  
  if(numberOfCPUs > 1) {
  //...
  }
  
  이 경우 JIT 컴파일러를 호스팅하고 있는 시스템의 CPU가 하나라면 KIT 컴파일러는 해당 if 블록이 할상 실행되지 않을 것을 알 것이며, 따라서 전체 if 문을 네이티브 코드로 변황하지 않을 것이다. 이 경우 어플리케이션의 실행 코드는 호스팅하는 운영체계에 최적화된 코드이며 좀 더 작고 좀 더 빠른 네이티브 코드를 생성하게 된다.

• CLR은 어플리케이션의 실행 패턴을 프로파일(profile)할 수 있으며 이에 따라서 어플리케이션 실행중에 IL 코드를 네이티브 코드로 다시 컴파일할 수 있다. 재컴파일된 네이티브 코드는 프로파일된 실행 패턴을 바탕으로 코드의 분기를 최적화하기 위해서 재정열된다.