Software Development

GCC 4.0: A Review for AMD and Intel Processors

-O3 옵션을 사용한 벤치마크. amd64에서는 컴파일 속도가 기존 버전에 비해서 느리게 나오고 P4에서는 빠르게 나온다.

GCC 4.0 C++ Compilation Speed

-O0 옵션을 사용한 KDE 코드에 대한 벤치마크. 상당한 개선을 볼 수 있다.

Introduction

어떤 practice가 보편화되어있고 그것을 보조하는 툴이나 생각의 장치들이 잘 만들어져있다면, 오히려 그 practice의 장점이 무엇인지 파악하는 데에는 방해가 되기도 한다. 어떻게 보면, 생산성을 높히고자 하는 우리의 노력이 때로는, 각 개인의 능력을 키우는 데에는 방해가 될 수도 있는 것이다.

예를 들어, 잘 만들어진 소프트웨어 프로세스 환경에만 익숙한 개발자는, 그러한 프로세스가필요없다고 주장하는 사람에게, 그것이 왜 필요한지 제대로 설명하지 못할 것이다.현대의 특정 프로그래밍 언어에만 익숙한 사람은, 자신이 활용하고 있는 수많은 언어적 장치들의 이점을 제대로 이해하고 있지 못할 가능성이 높다.

마찬가지로, 잘 만들어진 Model-View-Controller(이하 MVC) 프레임워크에만 익숙한 사람이라면, 그 패턴이 가지고 있는 유용성이나 의미를 발견하지 못할 가능성이 높다. 대부분의 웹어플리케이션 개발자들은, 프리젠테이션과 로직이 뒤섞인 기존의 웹어플리케이션에만 익숙하거나, MVC 프레임워크 웹어플리케이션에만 익숙하다. 기존의 웹어플리케이션이 MVC를 사용함으로써 어떤 점에서 좋아질 수 있는지는 전자나 후자의 프로그래머들 모두 알지못할 가능성이 높다.

이 글의 목적은 기존의 웹어플리케이션에 MVC 패턴을 적용하면서 리팩토링하는 과정을 보임으로써, MVC 패턴의 유용성을 재발견하는데 있다.

…

Refactoring Galaxy to MVC Design (Part 1)더 보기 »

Galaxy(http://rubyforge.org/projects/galaxy/)의 public release를 위해서, lastmind-specific한 design에서 좀 더 generic한 design으로 손봤습니다. (네, 네, Word Press 스타일입니다. 그렇게 안보이는 분들도 계시겠지만…) 색상이나 형태 등은 가능한 한 CSS로 분리했습니다. (완벽하지는 않습니다.) 게다가 아직도 view/filter 변경 인터페이스나, admin 인터페이스 쪽은 멀었습니다.

제가 혼자 사용하기에는 별로 문제없었는데, product로 release 하려니, 상당히 손이 많이 가는군요. Brooks의 Programming Product에 관한 이야기를 실감합니다.

boost-devel 메일링 리스트에서 최근에 제 관심을 끄는 이슈들입니다.

[Ann] Proposed Boost.TR1 library: first complete version now available.

http://article.gmane.org/gmane.comp.lib.boost.devel/121123/match=proposed+boost+tr1

John Maddock이 작업 중이던, TR1의 (거의) 완전한 첫번째 구현이 나왔습니다. 언제쯤 boost에서 그리고, g++에서 볼 수 있을까요? 기대됩니다.

Network library: What we have until now

http://lists.boost.org/boost/2005/04/24164.php

Boost.Net library에 관한 논의는 아주 오래전부터 있어왔지만, 구현을 하시던 분이 실종되기도 하고 (?), 우여곡절 끝에 최근에 다시 논의가 뜨거워지고 있습니다. C++에 아직 보편적으로 쓸만한 network library가 없다는 것은 C++ 개발자로서는 괴로운 일일 수 밖에 없죠. 간단한 작업을 위해서도 reinvent wheel을 해야하니까요. 최근에 개발된 언어들은 대부분 기본적인 socket으로부터, http와 같은 상위 layer protocol 까지 모두 지원하고 있는데 말입니다. 어서 C++ 개발자들도 자유롭게 개발할 수 있었으면 합니다. 전에도 적었듯이 reactor + fsm 을 구현해보고 싶은 생각이 있는데, boost에서도 multiplexor에 대한 논의는 계속 진행중입니다. (fsm은 이미 있긴 한데, 상당히 generic한 디자인이다보니 좀 복잡해서, multiplexor와 함께 잘 쓰일 수 있는지는 의문입니다.)

예전부터 다음 위키 페이지에 잘 정리되고 있으니 관심있는 분은 참고하시길.

http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostNet

더불어 Async I/O를 어떻게 제공해야하는가, platform neutral해야하는가, thread와 독립적이어야 하는가 등의 이슈에 대한 논의도 활발하게 진행중입니다.

http://lists.boost.org/boost/2005/04/24098.php

Regression testing and BuildBot discussions

http://lists.boost.org/boost/2005/04/24559.php

Boost에는 원래부터 automated regression testing을 하고 있었습니다만, 아마 개발자가 build를 하고 그 결과를 자동적으로 집계하는 식이었을 겁니다. 최근에 BuildBot(http://buildbot.sourceforge.net/)을 Boost의 regression testing에 도입하기로 결정된 것 같습니다. BuildBot은 분산 환경에서 주기적으로 build를 해주는 소프트웨어로 보입니다.

제가 회사에 있을 때, 팀에서 개발 중인 라이브러리의 regression testing을 담당하고 있었고, Boost를 모델로 했지만, 그 당시에도 차후에는 BuildBot과 같은 것이 필요하다는 생각을 했었습니다. 그 때는 BuildBot과 같은 기능은 차후로 미루고 단순히 cron을 사용했는데요. 굳이 새로이 개발하기보다는 BuildBot을 가져다 쓰는 것도 괜찮을 것 같군요. 주기적으로 build를 trigger하는 것뿐만 아니라, 분산 환경에서 on-demand build도 가능한지가 궁금하군요.

참, Regression Testing에 대해서 알고 싶으신 분은 Regression Testing에 대한 Wikipedia 항목을 참고하시기 바랍니다. (혹, 나중에 블로깅할 일이 생길지도 모르겠네요.) Automated regression testing의 이익에 대해서 알고 싶으신 분들은 Joel Spolsky의 Daily Builds Are Your Friend를 읽어보시기 바랍니다. Daily Build는 Joel의 유명한 The Joel Test에도 들어있는 항목이지요.

TR2와 C++0x의 스케줄이 잡혔다는군요. boost의 threads, filesystem, signals가 제안될 계획이라는 군요. (물론 TR2로 겠죠.) thread를 사용하기 위해서 boost 전체를 설치해야한다는 게 부담스러워서, 따로 thread library를 만들기도 했었는데요. 표준화가 된다면 얘기가 달라질 것 같군요. boost의 위상이 점점 높아만 가는군요. production에서 boost를 쓰는 것도 별 무리가 없지 않을까요?

h3. What is websvn?
p. websvn(http://websvn.tigris.org/)은 cvsweb이나 viewcvs와 같은 svn의 web frontend다.

…

Installing websvn on gentoo-amd64 platform더 보기 »

요즘, 주변 사람들에게 썰을 풀고 있는 프로그래머의 (가까운; 10년내) 미래에 관한 나의 생각. 지식노동자에 관한 허름한 대화는 무시하거나 조언을 해주시길. 좀 시간이 지난 후에 정리해볼께요.

2005년 04월 12일 오후 4:10:10 부터 2005년 04월 12일 오후 4:34:28 까지 한 윤묵형과의 MSN 대화입니다.

네오위즈에 근무하던, 2004년 정도에 이른바 “비용절감” 바람이 불었었다. 직접적인 원인은 아마도 budget의 감소였을 것이다. 하지만, 그동안 성능이나 비용에 크게 신경써오지 않았던 이유도 있으리라고 본다. “필요하다면, 더 많은 기계를 투입하면 된다”는 정책이기 때문인데, 이는 물론 맞는 말이다. 기본적으로 하드웨어는 싸고, time-to-market은 비싸기 때문이다.

어쨌거나 사실 시스템 프로그래머의 입장에서는 자신의 기술이 유용하게 쓰일 수 있다는 점에서, 그런 바람은 달가운 것이었다. 여러 부문에서의 기술적인 검토가 이루어지고, 또 실제로 여러가지 개선이 이루어지게 되었다.

내가 휴직을 위해 인수인계를 시작할 즈음 궁금해 하던 것 중의 하나는, 왜 apache를 대체하는 안은 고려되지 않는가였다. 그도 그럴 것이 네오위즈의 주 서비스인 세이클럽은 웹 어플리케이션이고, 따라서, 웹서버가 PC 서버들 중 상당 부분을 차지하고 있었기 때문이다. 물론 비용의 가장 커다란 부분은 DB 부문이었을테고, PC 서버들이 성능 개선의 요구에서 낮은 priority를 차지하는 것은 당연해보이긴 했지만 말이다.

당시에 내가 작업중이던 reactor framework을 테스트할 target으로 web server로 하면 어떨까 하는 생각도 있었기 때문에, 이러한 요구에 대해서 좀 더 심각하게 고려하게 되었다. 그러다가 같은 팀의 senior 멤버인 윤묵형과 이 주제에 대한 대화를 하게되었다.

윤묵형과 대화하면서 결론 내린 것은, 어느 웹서버를 사용하느냐는 별로 중요하지 않다는 것이었다. 그 이유는, 웹서버 머신 리소스의 대부분을 차지하는 것은 php (알다시피 세이클럽은 php를 사용한다)의 컴파일 및 실행 비용이고, 웹서버의 종류, 즉 apache와 비용은 상관관계가 상대적으로 작을 것이란 것이었다.

그런데, 최근 IRC 채널을 통해서, lighttpd와 php via fastcgi의 조합이 apache와 mod_php의 조합을 능가한다는 고무적인 벤치마크를 발견하게 되었다.

http://www.lighttpd.net/benchmark/

물론 이 벤치마크만으로, 세이클럽에서도 lighttpd + fastcgi의 조합이 apache + mod_php에 비해서 우세하리라고 단정지을 수는 없다. 이 벤치마크에 사용된 php application과 세이클럽에서 사용하는 php application은 다르기 때문이다. 뿐만 아니라, 세이클럽에서 사용하고 있는 apache의 기능이 lighttpd에서도 충분히 구현이 되어있는지, 또 그 기능이 벤치마크에 미칠 영향이 있을 것인지도 중요한 변수가 될 수 있다.

하지만, 이제 나는 회사라는 특정 비즈니스 요구에 한정되는 틀에서 벗어났기 때문에, apache에 비해 성능이 좋은 웹서버를 만드는 것 자체에는 더이상의 설득력 있는 이유가 필요한 것 같지는 않다. 내가 제일 처음 맡았던 job이 고성능 네트워크 서버를 만드는 것이었고, 그 때문인지, reactor + fsm 기반의 네트워크 서버를 위한 library/framework를 만들어야겠다는 조그만 야망을 계속 품어왔었다. 당장은 시간이 나지않지만, 앞으로 시간이 나는대로 작업해보고 싶다.

http://code.google.com/