Month: March 2004

브랜치 확률로 최적화하기

by

얼마전에 파이썬을 이리저리 컴파일하고 놀다가, 얻은 팁을 하나 씁니다. :)

일반적으로 뻔히 나오는 NULL 포인터 체크나, 범위 검사 같은 조건절 같은 경우에 한쪽으로 가는 확률은 극도로 적습니다. 따라서, 이런 경우에는 분기가 많이 되는 쪽이 더 빨리 실행되도록 최적화를 하는 편이 좋은데, C 언어에서 뭔가 이런 걸 정해주는 문법적인 도구가 없기때매 컴파일러가 제 멋대로 판단을 하죠. 그런데, 언제 생겼는지 (아마 꽤 됐겠지만;;) gcc에도 브랜치 통계를 기반으로 한 최적화가 있더군요. 아주 간단합니다. -fprofile-arcs를 주고 컴파일을 한번 해서 실행하고, 그 옵션을 빼고 -fbranch-probabilities 를 주고 다시 컴파일하면 됩니다. 먼저 한번 실행하는 건 통계 자료를 모으기 위한건데 .da 확장자를 가진 파일들이 우두두둑 생성됩니다.

파이썬을 컴파일할 때에는 OPT=”-fprofile-arcs -O3″ ./configure 해서 한번 컴파일하고 pystone을 한번 실행한 다음에, OPT=”-fbranch-probabilities -O3″ ./configure 해서 또 컴파일하면 대충 모듈 빼고는 그냥 다 됩니다. 므흐흐 그래서, 이렇게 컴파일한 결과! pystone이 17210에서 21057로 올라갔습니다. 공짜로 22% 향상! 꺄아. 히히

아무래도 OpenSSL이나 아파치 같은 것들도 브랜치 확률 정보를 줘서 컴파일을 하면 좀 더 빨라질 것 같은 예감이 듭니다.. 근데 이건 아무래도 컴파일도 두번 해야 하고, .da 다루기가 까다로워서 바이너리 패키지 같은 데 쓰기는 좀 어렵지 않을까 하는 생각이 드는군요. ^_^

UTF-8 로캘 베이스로!

by

NetBSD에는 진작에 오래 전에 들어간 [FreshPorts]misc/utf8locale 가 드디어 베이스에 들어갔습니다. 캭캭. 그동안 포트에서 2년간 설움의 세월을 보냈던 보람이.. ㅠ.ㅠ -CURRENT에 들어갔기 때문에 5.3부터 적용이 될 예정입니다. 원래는 6에 적용될 예정이었는데 그래도 다행이네요~ 이제 포트를 설치하지 않아도 UTF-8 로캘을 쓸 수 있습니다. :) utf8locale포트를 위해서 버전도 범프돼서 [WWW]502110을 받았습니다. :)

Prothon

by

작년 Miguel의 MS메일링에서의 Jim Hugunin의 메일 인용 공개를 시작으로 PyCon까지 엄청난 파장을 일으키고 있는 IronPython, 올해 OSCON에서 100달러 내기를 겨루게 되는 Parrot Pie-Thon, 혼자 만들었다고는 믿기지가 않는 8bit CPU를 위한 pymite 등등 정말 재미있는 파이썬 구현들이 많아지고 있습니다. +_+

그러는 와중 이제는, esoteric 계열 언어까지 하나 등장했습니다. 사실 완전히 escoteric 계열은 아니고 그쪽에서 놀던 사람들이 -.-;; 이름은 Prothon, Prototype Python을 줄여쓴 것이라는군요. 특징은 그동안 파이썬을 조금만 쓴 사람이면 다 불평하는, 완전한 쓰레드 지원 (fine-grained locking, object locking)이 들어갔고, lua 5에서도 도입하고 요즘 한창 인기인 스택리스 시스템으로 구현되었으며, 가비지 콜렉션이 CPython처럼 부가적인 마크-앤-스윕 이 아니라 바닥부터 마크-앤-스윕 으로 쓰레드마다 돌아갈 수 있도록 되어있다고 합니다. 사실 pymite에서도 그랬고, 파이썬을 새로 만들겠다 하는 사람들이 다 쓰는 특성이 아닐까 합니다. 크흐;

또한, Prototype Python 이름에서 풍기듯, Prototype-based Language를 표방하고 있다는 점에서 클래스 기반인 Python과는 좀 다르다고 하기는 하는데, prototype-based랑 class-based의 차이가 뭔지 아직 잘 모르겠습니다. -ㅇ-; (전에 들었는데 까먹었다 ㅠ.ㅠ) 그리고, 인덴트 제한이라던지, int형이 이터러블하고, /* */ 주석이 추가되고 등등 엄청나게 많은 문법 수정이 가해졌는데, 이건 참신한 시도이긴 하군요. ;) 실험적인 독자 문법이 시장에 나와서 실제 사용자들의 반응을 볼 수 있는 좋은 기회인 듯 합니다.

그리고 독특한 특징 하나는 포터빌러티 레이어를 위해서 아파치의 APR을 썼다는 것입니다. 기존에 공개된 오픈소스 포터빌러티 레이어라면 glib이나 모질라의 nspr같은 것도 있긴 하겠는데 아무래도 라이선스 문제상 apr이 좋긴 하겠지요.. 그런데 apr은 영 거시기 한 것이 약간 거부감이 들기는 합니다. ;;

아직 프리알파 상태라서 지원 모듈이 극소수만 있다고 하는군요. 있다가 퇴근하고 해봐야겠습니다. :)

파이썬, 이슈에서 벗어나 대세로

by

전의 블로그에서 언급한 기사가 OSS에 등록이 됐습니다. 흐흐 출판된지 1달도 안 됐는데, 막 올려도 되나 모르겠네요. 뭐 원고료도 없는 것이니 딱히 저작권 주장은 안 하겠지만서도 –;

http://developer.oss.or.kr/developissue/view.html?num=18&page=1

요즘 뜨는 언어들은 언급을 안 하고, 옛날 언어들만 언급함으로써 독자의 시야를 약간 가려서 설득시키려고 시도했습니다. (…)

아 근데 뭐 생각해보면 사실 파이썬이 젤 좋지 않아요? =3 =33 (ㅠ.ㅠ)

영어로 된 책을 읽을 때의 애로사항

by

그동안 영어 책이라고는 컴퓨터 관련된 책만 읽다보니 한국어 책에서도 늘 보던 그 단어들이 주루룩 있어서 어려운 줄을 모르고 살아왔으나.. 한 해에 영어로된 책을 포함하여 80권을 읽으신다는 [WWW]Jania님의 말씀을 듣고 아 나도 이제 열심히 공부해야겠구나 하는 충격을 받아서 으흐흐.. 얼마 전에 이것저것 충동구매를 했었더랬습니다.

처음 읽기를 시도한 것은 Richard Dawkins의 The Blind Watchmaker [ISBN-0393315703] 이었습니다. 헉 그런데 이 책은 페이퍼백에 글자가 빼곡한데다 문장이 걸핏하면 5~6줄씩 넘어가고 아 역시 한국어로 읽어도 어렵더니 장난이 아니구나 하는 것을 느끼고 4일동안 30페이지 읽고서는 나중으로~ ;;

그 다음 시도는 퍼키가 열렬한 팬인 Matt Ridley의 Nature via Nurture [ISBN-0060006781]! 역시 글자도 크고 표지도 예쁘고 하길래;; 이야 역시 좀 더 대중적인 책 답게, 문장도 대체로 짧고 줄간격도 넓고 읽기도 쉬웠습니다. 문장 자체는 거의 컴퓨터 책 못지 않게 쉬워서 그냥 쓱쓱 읽을 수가 있었는데.. 흐흑 결정적인… “모르는 단어가 너무 많다!” tenticle, polygamy, paucity, copula 등등.. 역시 고등학교 때 공부를 열심히 안 한 것이 들통나는 것인가!;;

그래서.. “하하하 그래그래 그런 뜻이겠지.. ^^;;”하고 넘어가는 단어가 1페이지에 10개 정도 -O-; 이래서야;;

그래서 생각해 본 해결책은

  • 그냥 몰라도 계속 읽는다. 나중에 사전 찾아본다.

  • 전자사전을 사서 들고 다니며 읽는다.

  • 단어공부를 더 하고 다시 읽는다.

일단은.. 전자사전 찾으면 뭔가 공부를 하는 느낌이 들어서 지루해질 것 같아서 제외.. 단어공부도.. 공부하는 것을 아주 죽기보다 싫어하므로 제외.. 하고 -ㅇ-; 그냥 읽기로 했습니다.. 흐.. 과연 얼마나 더 읽을 수 있을지!

5차원 영어학습법의 원동연박사께서 한 말을 생각하며 더 읽어봐야겠습니다. 크흣~

“”” 전 세계의 쓸모 있는 지식 중에 한국어를 통해 얻을 수 있는 것이 30%라면, 영어로 얻을 수 있는 것은 60%정도는 된다고 볼 수 있다. 따라서, 영어도 할 수 있다는 것은 곧 더 큰 시야를 확보할 수 있다는 뜻이고, 더 큰 물에서 놀 수 있다는 뜻이다.”””

500일 남았다!

by

이히히 제가 병역 특례를 시작한 것이 2002년 9월 19일, 끝나는 날은 단축의 효과로 2005년 8월 1일. 드디어 500일 남았습니다! 캬아아~

그동안 500일 남을 때까지 600여일동안 돌보아 주신 여러분께 감사드립니다. -ㅇ-; 앞으로 더욱 훌륭한 병역특례가.. (..)

으흐흐. 그런데 학교를 안 다닌지 너무 오래돼서 그런지, 복학해서 숙제하고 시험볼 생각하니 깜깜해요. ㅠ.ㅠ 흑흑~

-fPIC와 -fpic

by

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

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

레이먼드 리스트

by

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

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

To Me, C is dead.

by

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

by

[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 에서 다운로드 받을 수 있습니다.