-fPIC와 -fpic

으흐흐. 그동안 같은 플래그인 줄 알고 있었던 -fPIC와 -fpic가 서로 다른 것이었군요. 최근 한 cvs-all 메일에서 David O’Brien씨가 역시 옛날 툴체인 메인테이너답게 이런 구석진 것을 알려주는 군요. 흐흐 [WWW]문제의 메일

대략 요약하면, -fpic는 global offset table (GOT)을 통해 심볼들을 액세스하는데 기계에 따라서 정해진 한계가 있어서 이게 경우에 따라서는 실패할 수도 있다는군요. 그렇지만, 성공하면 -fPIC에 비해 더 적은 속도 저하를 얻을 수 있고, -fPIC는 크기에 상관이 없는 대신 엄청난 속도 저하가~~~ 흐흐 그런데 i386에서는 -fPIC나 -fpic나 똑같아서;;

레이먼드 리스트

올해 초부터 쭉 파이썬 기본 객체들의 최적화 작업을 해오면서 거의 전체적으로 20%정도의 성능을 끌어올리는 전공을 세운 레이먼드 헤팅거씨가 다른 사람들이 시도해 볼 만한 재미있는 해킹꺼리들을 자세히 쓴 [WWW]Raymond’s List를 공개했습니다. (그는 제 멘터이기도 합니다. ^_^;; — 괜히 우쭐 한번 ㅠ.ㅠ)

최근에 서지원님이 많은 해킹을 하고 계시는 컴파일러/VM쪽 외에도 기본 타입/라이브러리 쪽으로도 전체적인 상황을 몰라도 해 볼만한 것들이 많이 있네요. 열정이 넘치는 분들은 다 같이 해 봅시당~ :)

To Me, C is dead.

To Me, C is dead. Except for the JIT!

[WWW]mono 프로젝트의 카리스마 넘치는 이 시대의 리더 Miguel de Icaza씨의 선언! ==> [WWW]O’Reilly 글

그래요. 제가 생각하기에도 사실은 C는 엔드유저/데스크탑/웹/비즈니스 로직 등 숫적으로 대부분을 차지하는 프로그래밍 분야를 이미 잃어버렸다고 사실 생각합니다. 컴퓨터는 갈 수록 빨라지고, 남는게 CPU 파워인데 궁상맞게 C로 열심히 구현해봐야 좀 있으면 고객이 뭐 바꿔달라고 하면 T_T 울면서 싹 갈아엎고.. (잘 짜면야 된다지만.. 잘 짤 시간을 줘야~~ 흐흐..) 아무래도 이제 C는 C#, 파이썬 같은 언어들의 기본 툴킷을 개발하기 위한 언어, JIT를 개발하기 위한 언어, 커널을 개발하기 위한 언어, 아주 일부분의 중요한 부분을 가속하기 위한 언어.. 정도로 일상에서 물러나는 날이 곧 오겠지요. 으흐흑~ 그나마 파이썬을 배워서 얼마나 다행인지~ -ㅇ-;

그나저나, mono에게 얽힐 수 있는 최악의 상황인 .NET MS API부분의 특허 문제는 정말 어떻게 될 지 궁금하군요… 그냥 갈데까지 해보자는 Ximian과 절대 안 된다하는 RedHat의 대결~~ 과연 MS가 .NET API의 특허에 대해 유료화를 선언할 지, 과연 선언한다면 언제쯤 그럴지는.. 으음.. 점쟁이한테 물어봐야..

PowerPC Compiler Writer’s Guide

[ISBN-0964965402] (비매품이라 아마존에 없음)

Larry Wall 할아버지가 한 명언으로 이런 것이 있습니다.

“””A real programmer can write assembly in any languages.”””

므흐므흐. 코드 생산성과 유지보수성, 가독성 등이 퍼포먼스보다는 훨씬 중요한 세상이 온 것은 사실이지만, 여전히 퍼포먼스는 소프트웨어의 가장 중요한 요소 중의 하나입니다. 같은 기계에서 같은 일을 하는데 더 느리게 돌아서 좋을 것은 크게 없으니까요.. 여전히 전체 프로그램의 5%정도는 다른 요소보다 퍼포먼스를 더 중요하게 하여 최적화를 하여야 하는 편이고, 기계에서 내부적으로 어떤 어셈블리를 거쳐서 실행이 되는지, 메모리 레이턴시가 얼마나 작용하는지, 캐쉬 히트가 어느정도 작용되는지를 코드를 작성할 때 생각하면서 작성하는 것은 사실 심각하게 하자면 어렵겠지만, 자주 쓰이는 패턴이 대부분인 것을 생각해 보면, 사실 익혀두면 큰 노력없이 좋은 코드를 짤 수 있는 좋은 요소가 됩니다. +_+ 자바를 짜던 파이썬을 짜던, 핫스팟을 거치면 어떻게 되는지, 파이썬 VM에서 어떤 경우 최적화된 루틴으로 들어가서 실행을 하는지 알고 짜면, 비슷한 코드에서도 훨씬 빠르게 동작할 수 있는 것은 더 말할 나위도 없구요~

헛 잠시 말이 딴데로 빠졌지만, 이 책은 96년에 나온 꽤 오래된 책이지만 여전히 mono나 gcc같은 프로젝트에서 추천서 목록에 빠지지 않고 등장하는 실용적인 명저입니다. 제목대로 PowerPC에서의 C/Fortran 컴파일러를 만들 때 코드 전략에 대해서 논한 책이지만, PowerPC 인스트럭션을 기준으로 설명했다는 것 외에는 근래의 다른 CPU 아키텍처들에서도 통상적으로 적용될만한 교훈들을 많이 담고 있습니다. 예를 들면 if-else를 브랜치 프리딕션 없이 논리식으로 풀어버리는 방법, switch-case 의 개수별/변수타입별/변수범위별 최적화 방법 등 C 코딩을 할 때 사소한 것으로 컴파일러의 최적화를 방해할 수 있는 이슈들을 많이 논하고 있어서 별로 고치지 않고도 컴파일러의 최적화를 많이 도와줄 수 있게 됩니다. PowerPC가 아무래도 컨소시움에서 만들어진 개방표준형 아키텍처이다보니 인텔의 책처럼 자기 구현에 대해서만 최적화를 다루지 않고 여러 구현(모토롤라와 IBM, PowerPC/QUICC 4,5,6,7,8씨리즈)에서 공통되게 잘 돌아가는 방법같이 좋은 예를 C와 Fortran, PowerPC 어셈블리로 다루고 있어서 참 좋았습니다. 그런데, 아무래도 어셈블리 코드가 전부 PowerPC기준으로 되어있다보니 약간 생소하기는 하지만, 모토롤라의 파워피씨 매뉴얼을 놓고 같이 보면 크게 문제는 되지 않는군요~

이 책은 http://www-3.ibm.com/chips/techlib/techlib.nsf/techdocs/852569B20050FF7785256996007558C6 에서 다운로드 받을 수 있습니다.

요리만 못하는 똑똑한 여자들을 위한 요리책.

[ISBN-897365408x] 6년간의 하숙생활을 청산하고 독립생활을 시작한 지 1개월. 슬슬 가사에 재미를 붙이고 있습니다. ^^^;; 요리는 단연 자취생의 로망! 그래서 요리책을 2권 사서 보고 있었는데 처음 산 책들은 정말 맛있어 보이는 사진이 가득한 책으로, 특히 재료 개수가 적어보이는 책들을 샀었습니다. 헉. 그런데, 사고나서 보니.. 이럴수가.. 재료는 냉장고 2개 있는 집에 재료를 항상 가득 채우고 있는 사람이 추가로 사야하는 뭐 그런 것이었습니다. -_-;; 49리터짜리 냉장고에 음료수 몇 개 넣어놓고 사는 자취생에게는 꿈과 같은… 거기 있는 재료 다 사서 요리하고 나면 남는 재료는 다 버려야 .. 흑흑..

그러던 중 괜찮은 책이 있어서 hoya`님께 선물로 받았습니다. “perky님 맛있는 요리하셔서 사랑받는 살림꾼 되세요.”라는 메시지와 함께;; 흐흐. 제목은 “요리만 못하는 똑똑한 여자들을 위한 요리책”라는 상당히 자극적인 제목인데 뭔가 약간 전통적 성역할을 벗어나지 못한 성차별 요소가 담겨있는 책 제목인 듯한 느낌이 있기는 합니다. 므흐. 어쨌던 이 요리책에는 음식 사진이 하나도 없습니다. 두둥! 요리책에 음식사진이 없으면 과연 무엇이 있단 말인가!. 이 책은 논리적이고 간결하게 기술된 책을 선호하는 사람들을 위한 책인 것입니다. 각각의 조리법의 자세한 과학적인 이유와 그에 따라 일어나는 여러가지 분화적인 요소들을 과학적으로 다루고 있습니다. 예를 들면

“””스파게티가 들러붙지 않는 이유는?
스파게티는 삶은 뒤 찬물에 헹구지 않아도 서로 들러붙지 않습니다. 그 점이 일반 국수와 다르지요. 물론 반죽에 기름이 들어갔고 또 삶을 때 기름을 넣고 삶기느 했지만 들러붙지 않거나 불어나지 않는 것은 그 때문만은 아닙니다. 그렇다면 그 이유는 무엇일까요? 그것은 바로 스파게티는 강력분 밀가루로 반죽을 한다는 데 있습니다. 강력분에 다량 함유된 단백질인 글루텐(강력분은 15%이상, 박력분은 10%이하)이 반죽 자체에서 서로 당기는 힘이 강해 다른 국수처럼 서로 들러붙지 않는 것입니다.”””

이렇게 각각의 조리법에서 소금을 더 넣어야 하는 이유, 물을 더 넣어야하는 이유까지 상세하게 모두 설명하고 있고, 관련 역사까지도 다루고 있습니다. :) 사진으로 가득찬 요리책에서는 사진의 위치때문에 감히 시도할 수 없었던 것이었을텐데 이런 책이 나와서 정말 다행입니다~

그리고 요리책을 읽다보면 제일 불편한 것이 아무래도 해요체로 가득차있는 것인데 모든 문장이 모두 해요체로 끝나다보니 신뢰감도 덜하고 문장관계 파악도 힘든 것이 사실입니다. 그럼에도 불구하고 친절한 것이 잘 팔리는지 전부들 싹 해요체를 채택하고 있는데, 이 책은 부분적으로 해요를 쓰기도 하지만 전반적으로 -합니다 로 기술하고 있어서 편하고 신뢰감을 느끼며 읽을 수 있었습니다. :)

밥짓는 방법과 각 단계의 원리, 튀김이 되는 원리와 각 맛의 비결과 그 과학적인 과정같은 것도 모두 설명하고 있는 등 아주 기초에 충실하면서도 흥미를 충분히 돋울만한 소재를 다루고 있어서 재미있게 읽을 수 있었습니다. 또한, 다른 책에서는 대체로 계량 기구를 완벽하게 갖춘 듯이 정량적 단위를 완벽하게 제시하거나, 아니면 또 초보를 위한다고 굉장히 모호한 단위를 전체적으로 써버리기 마련인데, 이 책에서는 정량적인 단위를 제시하면서도 그것을 측량할 수 있는 방법을 여러가지 접근 방법으로 알려주고 있어서 좋았습니다. 예를 들어 계량단위인 “1컵”을 계량하는 방법에 대해서,

“””우리는 “1컵”을 200ml로 치지만, 서양에서는 1컵을 240ml로 칩니다. 그러나 만일 한글로 번역된 요리책을 보며 요리를 하신다면 1컵=200ml로 생각해도 됩니다.

시중에서 파는 작은 우유팩의 용량이 200ml이므로 당장 집에 계량컵이 없다면 우유 한 팩을 컵에 부어 눈금을 표시해서 간이 계량컵으로 써도 됩니다.

순수한 물 200ml의 무게는 200g이지만, 다른 성분이 섞인 액체는 조금씩 무게 차이가 있어 물엿이나 토마토케첩, 고추장처럼 되직한 것들은 부피의 물보다 무게가 더 나가게 마련이므로 부피가 같다고 무게가 같지는 않다는 사실을 유념해야 합니다.”””

으흐흐~~ 하여간 이 책은 제가 요리책을 많이 본 것은 아니지만 요리책 역사에 한 획을 긋는 정말 멋진 책인 것 같습니다. 앞으로 다른 분야에서도 이렇게 논리적으로 기술된 좋은 책들이 많이 나왔으면 합니다.

그렇지만, 책 제목은 좀 바꿨으면 좋겠군요. 분명 마케팅 차원에서 그랬겠지만 -ㅇ-;

프린세스 메이커

1인칭 게임 중 유일하게 할 줄 아는 Rainbow 6가 새로운 확장판 [WWW]Athena Sword가 나왔길래 해보려고 열심히 시도를 해 봤으나.. 원판 Raven Shield CD가 없으면 안 된다는.. 메시지를 보고서는 좌절해서 프린세스 메이커 2004란 것이 있길래 해 봤습니다. +_+

0403-pm1-main-thumb.jpg

큰 화면으로

헛 근데 프린세스 메이커 1을 새로 만든(refined) 버전이었습니다. 전체적으로 음성이 모두 한국어로 더빙되었고, 그래픽도 상당수 수정한 듯 깔끔하군요. 그리고 음악도 미디 외에 PCM도 지원해서 사운드 캔버스 기본 음질 정도의 음악이 나옵니다. +_+ 원판의 기분을 살리기 위해서인지.. 인터페이스도 전혀 바뀌지 않고 효과도 거의 그대로라 옛날 분위기가 물씬 나서 무지 좋았습니다. 헤헤 :)

사실 프린세스 메이커는 2부터만 해 봤는데, 1은 시스템이 2에 비해서 엄청 단순하네요;; ;;; 13살까지만 키우면 별로 할 게 없어서 허송세월만;; 앞으로 YS2 Special이나 천사의 제국, 파워돌스처럼 무지 재미있었던 게임들이 다시 최근 시스템들에 맞춰서 옛날 분위기 그대로 재현을 해 준다면 정말 좋겠네요. 계속 3D쪽으로 발전하면서 크기가 커진 게임들 보다는 아무래도 2D 분위기의 아기자기한 게임들도 계속 나왔으면 하는 바램도 :)

0403-pm1-carn-thumb.jpg

큰 화면으로

그리고, 파르페도 정말 그런대로 괜찮은 게임인데 버그를 좀 잡고 윈도우98에서만 돌아가게 만들어버리는 치명적인 몇몇 메모리 버그들만 좀 고쳐서 팬시상품들과 함께 재 출시를 했으면 하는 소망도 해 봅니다;; 으흐흐

최적화의 양면

얼마전 python-dev메일링에 올라온 [WWW]“Who cares about the performance of these opcodes?”에 대한 amk의 답변에 -O3보다 -Os가 더 빠르다는 글을 보고 몇가지 테스트를 해 봤습니다. 파이썬 바이트 코드를 실행하는 Python/ceval.c는 거의 1000라인에 육박하는 switch-case문으로 구성되어있는데, 요즘 LIST_APPEND같은 특화된 옵코드를 계속 추가하면 전체적으로 switch-case가 느려지지 않겠느냐하는 글에 딸려 나온 것입니다.

오오. 그런데, 테스트를 해 보니 정말로 amk 말 대로 ceval을 -Os로 컴파일한 것이 더 빠른 것이었습니다.

Pentium3 550

Pentium4 Xeon 2.4G

-O3로 전부 (Python 기본 배포 디폴트)

12284

23616

ceval만 -Os

12379

23970

-Os로 전부

11615

18713

-O로 전부 (FreeBSD 포트 디폴트)

11594

이야. 캐쉬 히트나 브랜치 프리딕션 히트 때문인 것인지 궁극의 최적화 옵션 -O3보다 비실비실 -Os가 더 빠른 것입니다! 이건 단순히 1%도 안 되는 성능 향상을 컴파일 옵션으로 얻을 수 있다는 뭐 그런 의미보다는 switch-case문만 잘 줄이면 속도를 더 빨리 만들수 있다는 것을 암시해 주는 것! JIT를 사용하지 않는 파이썬 VM에서는 옵코드 개수가 역시 속도에 큰 영향을 미친다는 것이군요.

요즘 Raymond가 리스트, 딕셔너리, 컴파일러 등등 여러가지 최적화를 해서 정말 파이썬 2.4는 1.5 속도를 따라잡고 멋진 릴리즈가 되지 않을까 하는군요. 기대가 됩니다. :) 그리고, 컴퓨터 아키텍처 책 말고 실전에서도 코드 크기가 영향을 미친다는 것도 신비롭네요. -S옵션으로 풀어놓고 좀 더 연구를 해 봐야겠습니다. -ㅇ-;

흑흑흑 소포질

지난번에도 한번 얘기했듯 소스포지에서 이제 돈낸 사람 이름 옆에 기어를 달아주고 있는데 그 기어 색깔이 기부액마다 달라서 5단계가 있습니다. 흑흑 저는 처음에 기부액 차별 없을 때 기부해서 5달러로 노란색 기어를 달았는데, 차별제도가 생기면서 회색기어로 강등돼버렸… 그래서 트래커에서 검색을 할 때마다 남들은 노란색 번쩍번쩍 기어 달고 있는데 밑에 회색 기어 달고 있으려니 추리해서.. 가슴이 아프다가 결국은 질러버렸습니다. -ㅇ-;

“그래, 사이월드 아바타에 돈내는 사람들 심정이 이해가 간다!. -.-..”

처음엔 10달러면 될 줄 알고 원래 5달러에 5달러 더 기부했는데, 10달러로 안 되더군요.. 그래서 할테면 해보자 하고 10달러를 더 기부해서.. 20달러를 냈더니 영광의 노란기어를.. …

0403-yellowgear.png

… 노란기어를 달게 돼서 한편으로는 폼나지만.. 20달러면 초코파이가 214개인데.. 하는.. 우에엥 -ㅇ-;

파이썬 포트 shared 포함

[FreshPorts]lang/python 포트가 2.3에 처음 올라왔을 때는 멋있게 보이려고 –enable-shared를 디폴트로 짠!하고 넣었다가. [WWW]파이썬 공유 라이브러리의 진실에 대해 깨닫고 다시 static으로 잽싸게 바꾸었는데, static이 단순하고 빠른 면은 아주 좋은데 몇가지 문제점이 최근에 많이 제기 되었습니다. 흐흐

  • 파이썬을 엠베드하는 컨슈머들이 몽땅 정적라이브러리를 링크해버려서, 파이썬 업그레이드할 때 같이 안 딸려 올라가기 때문에 호환성 문제가 생길 수 있고, 파이썬 버전 올라갈 때 마다 고역이다. (대부분의 의견)

  • ia64나 amd64같이 PIC바이너리와 non-PIC바이너리가 전혀 링크조차 안 되는 플랫폼에서 PIC바이너리 링크를 제공해 주기 위해서 결국은 static까지도 PIC로 컴파일해야해서 static으로 하는 득이 많이 줄어든다.

  • 쪼끄만 프로그램에 커다란 파이썬 정적 라이브러리를 붙이려니 괜히 낭비다.

  • 정적 라이브러리는 동적 라이브러리에 대한 의존성이 기록이 안 되기 때문에, [FreshPorts]www/mod_python3 같은 포트에서 동적 라이브러리에 대한 의존성이 무시되는 바람에, pthread라이브러리를 같이 물고 들어올 수가 없다.

등등.. 아우성이라서 결국은 빌드방식을 약간 바꿔서 정적빌드를 몽땅 한 다음에, 서브디렉토리에서 [FreeBSDMan]make 의 VPATH 변수 기능을 이용해서 libpython2.3.so와 python-shared만 빌드하도록 수정했습니다. 그래서 결국은 빌드 시간이 1/3정도 길어졌는데, shared 옹호파와 static 옹호파 양쪽을 모두 만족시키는 방법은 이것밖에 없다싶어서 Y.Y

그래서 이제는 곧 기본 파이썬 포트에서 bin/python 바이너리 외에 bin/python-shared 바이너리도 설치하게 되는데, python-shared는

    파이썬 -> 파이썬 확장모듈 -> 파이썬을 엠베드하는 공유라이브러리 -> 파이썬 공유라이브러리

식으로 붙는 일부 KDE 애플리케이션들을 위해서 넣어두는데 평소에는 별 쓸모는 없을 듯 합니다. 흐흐

메일링에서의 토의는: http://lists.freebsd.org/pipermail/freebsd-python/2004-March/thread.html