python

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

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

IT Solutions라는 작은 잡지에 쓴 기사입니다. -ㅇ-; 3페이지밖에 안 되니 보고 싶은 분은 서점에서 보고 오세요;; _-_

=> 큰 화면 보기

얼마전 python-dev메일링에 올라온 “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옵션으로 풀어놓고 좀 더 연구를 해 봐야겠습니다. -ㅇ-;

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

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

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

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

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

등등.. 아우성이라서 결국은 빌드방식을 약간 바꿔서 정적빌드를 몽땅 한 다음에, 서브디렉토리에서 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

FreeBSD JKH (Junior Kernel Hackers list)나 GNOME love day처럼 쥬니어 해커들이 입문하기 위한 도움이나 리스트 같은 것은 막 입문하려는 해커들에게 큰 도움을 주는 것 같습니다. GNOME love day 같은 것은 다른 데서도 앞으로 많이 했으면 좋겠네요.

그런 의미에서 한국어를 쓰는 쥬니어 파이썬 해커들이 해 볼만한 파이썬 해킹꺼리를 좀 정리해 봤습니다. 관심 있으신 분들은 한 번 도전을.. 서너개 정도만 말끔히 처리하면 파이썬 소스가 아주 익숙해지면서 금방 커밋 권한도 얻을 수 있을 것입니다~

• 다국어 식별자(internationalized identifier): 1월에 Martin v. Löwis의 메일에서 나온 아이디어인데, 아직 PEP나 구체적인 스펙이 나오지는 않았습니다. Martin의 의견으로는 tp_dict에 아스키로 인코딩 가능한 경우엔 string, 불가능한 경우에는 유니코드 객체를 집어넣어 버리고 그와 그와 관련된 함수들을 추가하자고 하고 있습니다. 그렇지만, 이렇게 되는 경우에는 u’abcd’와 ‘abcd’같이 같은 값이 서로 다른 키로 저장될 수도 있고, 일일이 구분해서 갖고와야 하는 수도 있고 해서 하위호환성 문제가 있는데, UTF-8로 저장하는 방법 등 몇가지 다른 처리 방법이 있을 수 있습니다. 파이썬 전체에 다국어 식별자 패치가 들어가면, 한글로 변수이름과 클래스 이름들을 쓸 수 있게 되기 때문에, 비영어권 사용자의 입문에 큰 도움이 될 것입니다. _ 그냥 단순하게 UTF-8만 되게 만들어 놓은 패치는 http://openlook.org/tmp/i18nidentifier.diff 에 있습니다.

• 크로스 컴파일: 848910 에 패치가 올라와 있기는 한데, 2.2.1기준으로 되어있고 무지 오래된 패치라 제대로 돌아가지 않습니다. 특히 ARM이나 PowerQUICC같은 기종에서 파이썬을 쓰시는 분들에서 유용한데, 크로스 컴파일 지원을 넣기 위해서는 일단 pgen 빌드 과정을 호스트와 타겟을 분리해야하고, setup.py에서 크로스 빌드를 약간 특별하게 취급해서 옵션을 넣어줘야합니다.

• collections와 itertools, statistics: itertools는 2.3에 추가되었고, collections와 statistics는 2.4에 들어갈 모듈인데, 세 모듈은 늘상 쓰는 프로그래밍 패턴을 아주 단순화시켜준다는 면에서 매우 매력적입니다. 지금 들어가 있는 것들도 어느정도는 있지만, 자기가 쓰는 다른 패턴들이 더 있다면 추가해 보는 것도 재미있을 것입니다.

• 순파이썬 로캘 지원: 현재 파이썬에서 지원하는 locale과 관련 모듈들은 모두 시스템 로캘에 의존하고 있어서 요즘 엄청난 이슈가 되고 있는 time.strftime 문제처럼 시스템 독립성에 많은 문제가 되고 있습니다. .NET이나 Java처럼 언어 자체 지원으로 로캘을 지원할 수 있다면 플랫폼 독립성에 큰 도움이 되겠죠. 이 문제에 관심이 있으시다면 IBM의 ICU를 참고로 하시면 됩니다.

• CNS-11643, HKSCS지원: 파이썬에 들어가 있는 CJKCodecs는 지금 널리 쓰이는 CJK 인코딩 중에 EUC-TW, ISO2022-CN같은 CNS-11643을 사용하는 인코딩들과 HKSCS의 지원이 빠져있습니다. 잠재적으로 대만과 홍콩 사용자들에게 문제가 될 수 있어서, 언젠가는 지원을 추가해야합니다. 이쪽 인코딩 정보에 대해서도 ICU 소스에 자세히 나와있습니다.

• SCSU 코덱: 파이썬에서는 아직 표준 유니코드 압축 (Standard Compression Scheme for Unicode)을 지원하지 않습니다. 아무래도 UTF-8나 16보다 용량이 훨씬 적게 나오기 때문에, 쓸모가 많습니다~ SCSU도 ICU에 X11라이선스로 된 C 소스가 있습니다.

• UTF-8 코덱 StreamReader.readline 수정: 현재 파이썬 UTF-8, UTF-7코덱의 StreamReader.readline은 전혀 제대로 동작하지 않는 상태입니다. 그런데, 딱히 깨끗한 해결책이 없기때문에 어쩔 수 없이 그냥 놓인 상태인데, 파이썬 코드로 10줄 내외이기때문에, 한번 뛰어들어볼 만 합니다.

• sre모듈 C로 번역: sre모듈 중 일부는 굉장히 속도가 요구되는 부분임에도 불구하고 현재 파이썬으로 구현되어있어서 C로 번역하자는 여론이 어느정도 조성되어있는 상태입니다. 파이썬 소스 코드가 311줄정도이기 때문에, 이것과 기존에 C로 구현된 _sre를 합쳐서 한개의 모듈로 만들면 속도 상 많은 이익을 얻을 수 있습니다.

• repr, sys.displayhook 국제화: 한/중/일 사람이 파이썬에 입문할 때 가장 헤메는 부분 중의 하나인 “리스트 속에 들어간 한글 제대로 안 보이는 문제”를 해결하는 원초적인 방법입니다. displayhook은 repr에 어느정도 의존하기 때문에, repr만 인코딩을 지원하도록만 수정해주면 됩니다. 그런데, 파이썬 내부의 tp_repr은 인코딩 정보를 전혀 받지 않기 때문에, 하위 호환성을 위해서는 tp_richrepr등의 이름으로 객체에 인코딩을 받아서 인코딩에 맞는 정보를 리턴해 주는 가공이 필요합니다.

• MinGW 지원: 파이썬 2.4부터는 VC 7.1을 기준으로 윈도우 빌드가 바뀝니다. 아직 MinGW에서 파이썬을 빌드하려면 아주 어려운 수동 작업을 몇몇 거쳐야하는데, 이를 깔끔하게 정리해서 메인으로 들여오면 아주 멋지겠죠~

번역하자면,

흐흐 그동안 K&R 인덴트가 아닌 프로젝트에 몇번 참여했던 경험으로는 충분히 10%는 넘는다고 봅니다. 어찌나 신경이 쓰이던지.. ㅠ.ㅠ

최근 ETech 2004에서 Nokia의 CTO가 Nokia의 차세대 핸드폰인 66 시리즈에 파이썬을 플랫폼으로 써서 핸드폰 애플리케이션들을 개발하고 있다고 합니다. 노키아가 작년에 1억대의 핸드폰을 세계적으로 판 것을 생각해 보면, 66 시리즈가 출시되면 파이썬 사용자가 대략 적어도 수천만명은 늘어나는 것인가요?

샘숭전자도 파이썬을 플랫폼으로!! 꺄꺄~~ (꿈만 꾸고 있다;; )

어제 python-dev에 Raymond가 자극적인 제목의 메일 Optimization of the Year을 올렸습니다. 내용은 예전부터 논란이 되어왔던 list.append류의 크기가 변하는 list에서 매번 realloc 을 호출해서 리스트의 성능이 크게 떨어진다는 것이었는데, 이번에 Raymond가 realloc을 안 쓰고 할당된 크기를 구조체에 저장하고 필요한 경우에만 alloc하는 걸로 바꿈으로써 realloc 이 느린 시스템에서 엄청난 성능 향상을 가져오게 되었습니다.

제 기계에서는 전체적으로 15%정도 가속이 되고, list.append는 2배로 최적화가 되었군요! 정말 좋습니다~ 그런데, 원래 Raymond의 구현에서는 list 구조체에서 내용을 저장하는 포인터인 ob_item이 외부에서 변경되는 것을 알아채기 위해서 ob_item을 따로 한벌 더 저장해 두게 되어있는데, Guido와 Tim은 앞으로 객체 추상화는 더욱 더 빡빡하게 될 것이니 외부에서 ob_item을 바꾸는 것은 도저히 용서할 수 없다는 뭐 그런 의견을 얘기하는군요. 그리고, Tim은 Raymond의 구현에서 멤버 변수가 3개나 추가돼서 리스트의 메모리상의 크기가 너무 커지는 것이 아닌가 하는 가이드까지 하며, align때문에 32비트 플랫폼에서는 공짜로 1개까지는 추가할 수 있다는 저같은 초보자는 상상도 못한 얘기를.. 정말 Tim의 무공은 바닥이 보이지 않는 바다입니다. 대단해요~ -.-b

하여간 그래서 제가 약간 고쳐서 1개만 쓰고, tracked를 제거한 패치를 올렸더니 대충 만족하는 분위기라 곧 커밋될 것 같습니다.~ 이제 2.4에서는 2배 빠른 list를! 크크크

지난번에 공약했던 대로(;;;;) CJKCodecs를 드디어 파이썬에 집어넣었습니다! 꺄아~ 파일이 워낙에 많아서 커밋 로그 편집기만 2페이지가 넘고, 그놈터미날 버퍼 사이즈를 넘쳐서;; 뒤로도 못 돌아가는 엽기적인 사태가 흐흐;; 그리고 파이썬 커밋메시지 최초로 160KB짜리 메시지가 갔습니다. _-_

파이썬 속에 들어간 CJKCodecs: http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Modules/cjkcodecs

여하간, 이제 파이썬 2.4에서는 더이상 한글 코덱을 따로 깔 필요가 없으며, 일본어나 중국어도 마찬가지입니다. ~.~; 그러나, 앞으로도 당분간은 파이썬 2.1, 2.2, 2.3을 위한 써드파티 모듈 지원도 계속할 계획이고, 올해 말 안에 HKSCS(홍콩)과 EUC-TW(대만) 지원을 넣을 넣을 계획입니다.

대~~한~민~국! 짝짝짝짝짝;; (새삼 -_-;;;)

CJKCodecs를 파이썬으로 넣기 위한 패치를 올렸습니다. 잇힝. 약간 토론을 거쳐서 넣을 수 있으면 넣을 작정입니다. 아마도 전에 Barry와 Martin이 동조를 해 줬기 때문에, 별로 어렵지 않게 들어갈 수 있을 것 같은데.. 일본어코덱 유저들의 반발이 있을지도 모르니.. 헉헉. 일본 사람들 안 보는 사이에 몰래 넣어놓고 버티면.. 흐흐;

이제 파이썬 2.4부터는 코덱 안 깔고 편하게 씁시다. +_+

http://openlook.org/tmp/node128.html 요건 codecs 모듈 다큐멘트 패치한 것을 빌드한 것인데, 2.4 문서에서는 요걸 볼 수 있었으면 좋겠네요 크크