C++ PIMPL 패턴.. 별로임 -_-;

생각해보니 개인적으로 PIMPL 패턴을 직접 구현해본적이 없다. 이런 패턴이 있다는걸 예전에 읽어본적은 있지만.. 그냥 '그닥 쓰고 싶은 생각이 안나는 놈?' 정도로 생각했다고 할까...

음 근데.. 지금 다루고 있는 코드베이스 안에는 PIMPL패턴이 아주 넘친다... 그래서 사용해본 뒤 소감이 어떻냐고? 안.좋.다. 게임 프로그래밍에서 이 패턴을 씀으로써 얻는 장점이 별로 없다고 생각한다. PIMPL 패턴의 장점이 뭘까? 다음 두가지 장점 정도가 아닐까?

1. API 설계와 구현의 확연한 구분: 소프트웨어 아키텍트 마스터가 API를 멋지게 설계해두면 쫄개 프로그래머/코드 몽키들을 와라락 달려들어 잘 숨겨진 파일안에 구현을 함
2. 헤더파일간의 의존성(dependency)가 적음 = 컴파일 시간이 빠름

일단 장점 1번이 게임 프로그래밍 업계에서 큰 의미가 있다고 생각하지 않는다. 어느 엔터테인먼트 업계에서도 그러듯이 게임의 요구사항은 끊임없이 변하며 그에따라 API도 수도없이 바뀐다. 즉, 마스터가 API를 멋지게 설계하는 일 자체가 별로 없단 이야기. 그리고 다른 프로그래머들로부터 구현파일을 숨긴다는거 자체도... 좀 웃기지 않나? 게임 프로그래머들은 전체 소스코드를 보는 걸 좋아한다. 라이브러리를 만들어서 파는 3rd party업체가 아닌이상... 정말 별 의미가 없음...

게임 프로그래머들이 PIMPL 패턴을 왜 쓰는 주 이유는 사실 2번이라고 생각한다. C++ 의 컴파일 속도는 매우 구려요 -_-;;; 하지만 PIMPL 패턴 보다 컴파일 속도를 향상시킬 수 있는 다른 방법이 존재한다. 물론 조홀라 비싼 incredibuild를 말하는 건 아니다. 여태까지 써본 방법중에 가장 빠른 건 이미 10년전부터 널리 애용되고 있는 유니티 빌드였다.. 물론 공짜 -_-v... 이에 대한 제대로된 한국말 설명은 다음의 슬라이드를 참고...

따라서 PIMPL의 장점이 그닥 중요하가 와닿지 않는 반면.. 단점은 아주 절절히 느껴지는게 문제....

1. 코드 읽기가 더 귀찮아진다. 파일 여러개를 뛰어다녀야만 겨우 구현코드를 볼 수 있다는 단점....매조키스트 아닌 다음에야 이걸 좋아할리가...
2. 듬성듬성한 메모리 할당: pimpl 개체를 만들기 위해 따로 new를 호출해줘야 한다. 메모리 파편화, cache 관리 등의 이유로 개인적으로 클래스의 모든 멤버가 한번에 메모리할당되는 걸 좋아하고, 그 외에도 어떤 개체의 크기를 쉽게 알아오기에도 한번에 할당되는게 좋다.
3. 추가적인 포인터 참조 연산 = 아주 조금 더 느림.... 이정도 포인터 점프 한번 더 하는게 성능에 아주 큰 영향을 미치지는 않는다. 하지만 엔진쪽 프로그래밍 하는 사람으로써 이런 필요없는 포인터연산이 성능을 10프로 이상 떨어뜨리는 걸 수도없이 봤기에... 매우 까탈스러울수밖에 없다... 아마 실제로 이 포인터 참조에 걸리는건 CPU 사이클 4사이클 정도일 테지만... pimpl 개체의 메모리 위치가 떨어져 있을 수도 있으니 cache 관리까지 들어가면 더 느릴수 있다는 것.... 물론 메모리 할당 순서를 손수 잘 컨트롤 해주면 이런 문제를 피할수도 있겠지만... pimpl 패턴의 장점이 크게 없는 이상 왜 이런 쓸데없는 짓을 해야하나 생각까지 든다.

결론... 핌플 맘에 안듬.... -_- 아니면 내가 뭔가 놓치고 있는게 있나?

참고로 영어로 pimple은 뾰드락지를 말함 -_- 이런거...

PHP의 정수형에 대한 불만

몇년전에 PHP를 상당히 많이 썼었다. 물론 게임 렌더링 엔진의 코어에... 초당 120프레임까지 뽑아내려면 PHP가 최고다..... 는 농담이고.... ^^ 그냥 이런 저런 웹 사이트를 만드는데 많이 사용했었다.

최근에 PHP를 다시 접할 일이 있었다. 32비트 정수 값으로 표현하기엔 너무 큰 랜덤 수를 만들어 이것을 MySQL 데이터베이스에 저장하려고 했는데.. 아뿔사....

MySQL은 64비트 정수형인 BIGINT 변수형을 지원한다... 따라서 별 문제 없음... 진짜 문제는 PHP... PHP의 int는 32비트가 될 수도 있고, 64비트가 될수도 있다... 꺼억... 꼭 C같군 -_-; PHP가 설치된 컴퓨터의 비트수에 따라 달라진단다.. (또 64비트 정수를 사용하려면 64비트 PHP 버전을 따로 설치해야 할거라고 추측만 하고 있음)

이런 어이없는 짓은 C에서는 용납이 가능하다. 그냥 32비트/64비트 용으로 따로 실행파일을 만들어 배포하면 되니까.... 하지만 PHP는 웹기반이라서 이건 정말 개소리다 -_-;;; 이런 상황을 고려해보자.. PHP에서 64비트 정수를 사용하는 웹사이트를 만들어서 64비트 웹 서버에 호스팅했다고 치자.. 근데 이 호스팅 서비스가 맘에 안들어서 다른 웹호스팅 서비스로 옮기기로 맘을 먹었는데 새 호스팅 회사가 32비트 PHP를 쓴다면?..... 한마디로 왕짜증 -_-; 코드 전부다 리팩터하거나... 아예 64비트 정수를 지원하는 클래스를 스스로 짜는게 훨 낫다는 결론..... 써글 -_-?

PHP에서 64비트 정수를 사용하는 것의 또다른 문제 중 하나는 Random() 함수이다. 랜던 시드(seed)의 인자와 Random() 함수의 반환값이 모두 int이다. 따라서 64비트 정수 클래스를 커스텀하게 만든다면 이 함수를 그대로 쓸 수 있는 방법이 없다. 그 대신 이 64비트 클래스의 값을 2개의 32비트 정수값으로 바꿔서 이리저리 짜맞춰야 한다는 게지... -_-

뭐 PHP에서 정수대신에 부동소수점(floating-point) 수를 쓰면 32비트가 넘는 정수의 값을 표현할 수 있다... 하지만 정밀도(precision)의 문제가 또 있다는 게 문제.. 역시 내 입맛엔 별로 맞지 않음... -_-

오해는 하지 마시길... 난 사실 PHP를 매우 선호한다. 웹프로그래밍을 할 때 다른 언어 다 제쳐두고 언제나 찾게되는 언어가 PHP니까.. 하지만 MySQL처럼 PHP도 BIGINT형을 자체적으로 지원해야 한다고 생각한다...