| OSXDEV.ORG Mac OS X 개발자 포럼 |
|
사실은 이렇다애플의 제스츄어가 가끔은 좀 과장된 경향이 있지만 그렇다고 거짓말을 일삼는 회사는 아니다. 애플은 매우 공개적인 자리는 아니지만 공식 인터뷰 같은 자리에서 분명히 팬서가 64비트 OS가 아니라고 언급했다. 그리고 어떤 공식 문서에서도 팬서가 64비트라고 언급한 적도 없다.단지 몇몇 문서에서 (특히 G5 옵티마이징 문서) 64비트 옵티마이징이란 표현을 쓰기는 하지만 이것이 팬서가 64비트라는 증거가 될 수는 없다. 무엇을 64비트 OS라고 볼 것인가64비트 OS에 대한 이야기를 하기 전에 무엇을 64비트 OS라고 볼 것인가 하는 기준이 중요할 것이라 생각한다. 필자가 참고 하고자 하는 것은 Opengroup에서 구분한 방식으로 그 프로그래밍 모델에 대한 분류 방법은 아래 표와 같다.Datatype LP64 ILP64 LLP64 ILP32 LP32 char 8 8 8 8 8 short 16 16 16 16 _int32 32 int 32 64 32 32 16 long 64 64 32 32 32 long long 64 pointer 64 64 64 32 32 이 표에서 64비트 모드 프로그래밍 모델이라고 볼 수 있는 것은 LP64, ILP64, LLP64라는 것을 알 수 있다. int으 크기가 항상 64비트가 아님에 유의할 필요가 있다. 즉, 개발사의 의도에 따라서 int를 32비트로 남기고 있는 상태로 64비트를 지원 할 수 있다는 이야기이다. 현재 이 세가지 모델 중에서 가장 좋다고 인정받는 모델은 LP64로 이것 역시 int를 32비트로 하고 있다. (여기에 대한 상세한 정보를 보고자 한다면 http://www.opengroup.org/public/tech/aspen/lp64_wp.htm을 참고하기 바란다.) 팬서와 64비트팬서는 64비트 아키텍쳐를 지원하기 위해서 몇 가지 바꾼 부분이 있다. 그러나 이것은 OS 내부에만 해당하기 때문에 개발자는 64비트 컴퓨터에서 작동되는 디바이스 드라이버에 한해서 그 장점을 얻을 수 있다. 즉 커널 모드에서 64비트 어드레싱을 사용 할 수 있다.그러나 팬서에서 애플리케이션들은 ILP32로 된 라이브러리를 링크한다. 즉, 커널 모드에서 약간의 64비트 어드레싱을 지원하는 것과 뒤에 gcc를 소개하면서 이야기 할 몇 개의 새로운 인스트럭션, 그리고 64비트 파일시스템 이 외에는 64비트라고 볼만한 부분이 없다는 것이다. 비록 현재 최고 사양의 G5 머쉰이 8GB의 물리적 메모리를 지원하지만 이것은 다른 OS를 이용하는 시스템들도 모두 가능한 것이다. 이것은 결국 팬서는 반쪽 64비트 OS라는 것이고(사실 반쪽도 안 된다고 생각한다.) 이것은 한동안 고쳐지지 않을 것 같다. 이것은 기술적인 문제라기 보다 정책적인 문제에 기인한 것이라 생각되는데 아마도 10.4에 가서 64비트 OS라 부를 수 있는 것이 나오면 다행이라 생각하고 어쩌면 더 오래 걸릴지도 모른다고 생각된다. GCC 3.3애플의 개발 툴은 현재 gcc 3.3을 사용하고 있다. 여기에는 몇 개의 G5 튜닝에 관련된 플래그가 있는데 G5에서만 사용 할 수 있는 인스트럭션을 사용 가능하게 해주는 옵션과 G5에 맞게 튜닝 해주는 옵션이 있다.자주 사용하는 몇 개의 플래그는 아래 표와 같다. -mcpu=970 G5에서만 사용 가능한 인스트럭션 셋을 사용한다. -mtune=970 G5에 맞춰서 튜닝은 하되 코드는 호환성을 가지게 한다. -mpowerpc64 G5의 네이티브 long long(64비트) 타입을 사용하게 하는데 long long타입으로 연산할 때 성능이 많이 향상된다. -mpowerpc-gpopt G5의 네이티브 실수 스퀘어루트를 사용 가능하게 한다. -force_cpusubtype_ALL 컴파일러가 코드에 이 코드가 G5전용이라고 마크하지 못하게 한다. 즉, G5전용 인스트럭션을 사용하지만 OS는 그런데 관여치 않고 모든 PPC CPU에서 작동되게 해버리기 때문에 잘못하면 애플리케이션이 크래쉬 할 수 있다.
#include <mach/mach.h>
#include <mach/mach_host.h>
#include <mach/host_info.h>
#include <mach/machine.h>
#ifndef CPU_SUBTYPE_POWERPC_970
#define CPU_SUBTYPE_POWERPC_970 ((cpu_subtype_t) 100)
#endif
boolean_t IsG5()
{
host_basic_info_data_t hostInfo;
mach_msg_type_number_t infoCount;
infoCount = HOST_BASIC_INFO_COUNT;
host_info(mach_host_self(), HOST_BASIC_INFO, (host_info_t)&hostInfo, &infoCount);
return ((hostInfo.cpu_type == CPU_TYPE_POWERPC) && (hostInfo.cpu_subtype == CPU_SUBTYPE_POWERPC_970));
}
문제는 맥 개발자들에게 gcc가 그렇게 절대적인 지지를 받고 있다고 말할 수 없다는 것이다. 흔히 맥 개발자들 사이에 gcc를 PPC에 최적화된 코드를 만들어내지 못하는 조금은 부족한 컴파일러로 인식되곤 한다. 어차피 gcc가 다양한 플랫폼에서 돌아가는 컴파일러이지만 남의 떡이 커 보인다고 하지 않았던가. x86에서 더 완벽한 코드를 만들어내는 것을 마냥 부러워하고 있어야 할 뿐이다. 정확하지 않은, 그냥 경험적인 말들에 의하면 POWER4에서 최적화된 컴파일러보다 gcc가 20% 정도 성능 저하를 일으킨다고 한다. 아직 이것에 대해 정확한 근거를 가지고 테스트를 한 자료를 구하지는 못했다. 그래서 많은 맥 개발자들이 은근히 기다리던 것이 있었는데 그것이 바로 IBM의 컴파일러다. IBM XL C++IBM의 XL C++이 PowerPC 970에 최적화 되어서 나와있다. 이것은 C/C++을 지원하는 컴파일러로 성능면에서 gcc보다 매우 뛰어날 것이라 예상되고 있다.XL C++은 gcc 3.3을 필요로 하는데 헤더파일과 런타임 라이브러리를 gcc의 것을 그대로 이용한다. 사실 필자가 XL C++을 눈 여겨 본 가장 큰 이유는 64비트 코드의 생성이 어떨까 싶어서였는데 매뉴얼 첫 장을 채 넘기기도 전에 32비트 애플리케이션을 위한 컴파일러라는 말을 보고 무척 실망했었다. 자, 그렇다면 그토록 기대했던 최적화면에서는 어떨까? 그에 대한 답은, '별로 기대하지 않는다.'이다. 가장 큰 이유는 런타임 라이브러리를 gcc의 것을 그대로 쓴다는 것 때문인데 실제 코드 실행에 있어서 많은 부분이 런타임 라이브러리에 의해 이루어 진다고 봤을 때 최적화 된 런타임 라이브러리를 함께 제공했으면 어땠을까 하는 아쉬움이 남는다. 또한, 또 한번 기대를 저버린 것은 이 컴파일러가 오브젝티브-C를 지원하지 않는다는 것이다. Mac OS X의 가장 중요한 프래임웍인 코코아를 사용할 방법이 없는 것이다. 결국 코코아를 사용한다면 아직 XL C++은 답이 아니라는 결론을 내릴 수 밖에 없었다. Link to this Page
Since 2001, OSXDEV.ORG |