Skip to main content

Low-Level Envy

Paul Graham이 쓴 Hackers and Painters라는 글을 보면 math envy라는 말이 나옵니다. 과학계에 있는 사람들은 속으로 수학자들이 자신들보다 똑똑하다고 믿는 것을 두고 나온 말입니다. 이런 생각의 결과로 자신의 작업을 되도록이면 수학적으로 보이려고 애쓰게 되는데 물리학같은 과학에선 이런 현상이 별 해가 없지만 자연과학에서 멀어질수록 문제를 발생시킬 수 있습니다. 정말 중요한 문제보단 수학적으로 보일 수 있는 문제를 풀려는 유혹이 강해진다는 것이죠.

제 생각에 개발자들에게 또 하나의 envy가 있다면 low-level envy가 아닐까 합니다. C++를 알다보면 컴파일러의 구현 방법에 대해 알고 싶어집니다. 표준 라이브러리를 사용하다보면 이 함수는 어떤 시스템 콜을 사용하는지 궁금해지고요. 다음으론 그 시스템 콜은 커널에서 어떻게 동작하는지, 커널이나 디바이스 드라이버는 어떻게 구현되는지, 하드웨어와는 어떻게 인터페이스하는지, CPU는 한 명령어를 어떻게 처리하는지, 캐시는 어떻게 사용되는지 등등.

사실 이런 low-level envy는 math envy와는 달리 실제 프로그래밍 작업에 많은 도움이 됩니다. 실제 지난 글에서 살펴봤던 pure virtual function called와 같은 에러는 컴파일러가 vtbl과 vptr를 어떻게 구현하는지를 몰랐다면 원인을 찾기가 어려웠을 것입니다. 다른 예로 시스템의 메모리는 남아 있는데 왜 더 이상 쓰레드 생성이 안되는지와 같은 에러의 원인을 알려면 커널이 어떻게 쓰레드를 구현하고 있는지를 알고 있어야 할 것입니다. C++ and the Perils of Double-Checked Locking과 같은 문제점을 찾으려면 sequence point라는 개념과 컴파일러와 CPU에 의한 최적화 방법들까지 어느 정도 알고 있어야 합니다.

이런 low-level의 지식들은 날마다 필요한 것들은 아닙니다. 하지만 진짜 어려운 문제를 만났을 때 그것을 해결할 수 있느냐 없느냐의 차이를 가져옵니다.

이런 문제가 가장 많이 발생하는 곳이 바로 multi-threading쪽이 아닐까 합니다.

이 문제가 어려운 이유는 재현이 어렵다는 것이죠. 따라서 일반적인 디버깅과 같이 trial and error 방법을 써서 문제를 풀기가 어렵습니다. 이런 문제는 꼼꼼한 code inspection과 알고 있는 지식을 가지고 정확히 문제가 되는 코드를 찾아야 합니다. 주로 lock이 있어야 할 곳에 없거나 locking의 범위에 몇 라인이 빠졌다거나 하는 문제입니다만 multi-threading의 원리를 이해하지 못하고 있으면 원인을 찾지 못하거나 "printf를 한 줄 넣었더니 잘 되요"나 "debugging 옵션으로 컴파일하니 문제가 없어져요"와 같은 엉뚱한 결론을 내리게 됩니다.

저 역시 항상 좀 더 low-level을 알고자 하는 욕심이 있어서 리눅스 커널 관련 서적을 몇권 읽었습니다. 하드웨어에 관해선 학교 다닐때 수업시간에 들은게 다입니다만 항상 관심을 가지고 있고요. ((art.oriented사이트에서 가끔 재밌는 글을 읽게 됩니다. 얼마전에도 false sharing에 대한 글이 올라 왔었죠. Monaca사이트도 등록해 놓고 읽고 있습니다. 여긴 가끔 프로그래밍 이외의 강한 어조의 글들이 올라옵니다. :-| ))

얼마전에 회사에서 시켜주는 교육중에 임베디드 리눅스 프로그래밍이란 것이 있길래 냉큼 신청해서 들었습니다. 여태까진 임베디드 시스템이라고 해도 거의 PC 수준의 시스템이었기 때문에 항상 진짜 임베디드 시스템 프로그래밍이란 어떤 것인지 궁금했는데 (몰라서 불안했는데) 부트로더나 커널 포팅에 대해 배우고 나니 많은 도움이 되었습니다. (좀 안심이 되더군요.) 일단 커널 포팅이 되고 나니 다음은 거의 하드웨어 스펙 보기나 애플리케이션 레벨의 프로그래밍이 되어 좀 지루해지긴 했습니다만... :-)

훌륭한 개발자의 조건은 무엇보다 호기심인 것 같습니다. 모르는 것이 생겼을 때 궁금해서 못 견디는 그런 호기심 말이죠. :-)

.

덧) 한가지 문제는 low-level envy뿐 아니라 high-level envy도 있다는 것입니다. 코딩만 하다보면 설계 방법도 배워야 되고, 디자인 패턴, 리팩토링, UML에 각종 methodology까지... 제가 요새 읽고 있는 책은 Fit for Developing Software. :-|

Comments

  1. low-level envy, 멋진 표현입니다. 호기심이 중요하다는 말이 무척 와닿습니다. 호기심이 많을수록 low-level envy가 많이 생기는 것 같더라구요.

    ReplyDelete

Post a Comment

Popular posts from this blog

1의 개수 세기

저도 간단한 알고리즘 문제 하나... :-)

어떤 수 n이 주어졌을때 1~n까지의 수를 쭈욱 썼을때 나오는 1의 개수를 구하는 문제입니다.

예를 들어 13이라는 수가 주어지면 1~13까지의 수 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13에서 1은 1, 10, 11, 12, 13에 나오며 그 개수는 6이 됩니다. 즉, f(13)=6.

원래 문제는 f(n)=n이 되는 1이 아닌 가장 작은 수를 구하는 문제인데 이 문제의 경우에는 처음부터 쭈욱 세어나가면 되기 때문에 간단히 다음과 같이 구현을 하면 됩니다. ((한가지 주의할 점은 이전에 찾았던 n-1값을 사용하지 않고 다시 처음부터 n까지 값을 계산하면 시간이 너무 많이 걸린다는 점입니다. 위의 코드에서는 static 변수를 사용하여 이전 값에 계속 더해나가는 방법을 사용했습니다.))


#include

int count1(int n)
{
static int cnt = 1; // not 0 because n starts from 2. see main.

while (n > 0) {
if ((n % 10) == 1) ++cnt;
n /= 10;
}

return cnt;
}

int main()
{
using namespace std;

int n = 2;

while (count1(n) != n) ++n;
cout << n << endl;
}


좀 재미가 없죠? 그래서 이번 문제는 어떤 수 n에 대해서 f(n)을 O(1)시간에 구하는 알고리즘을 만드는 것입니다. 관심있으신 분들은 한번 풀어보세요. 제가 만든 코드는 내일 올려보겠습니다.

C++ of the Day #9 - Boost.Python 사용하기 #1

Python은 가장 인기있는 interpret 언어중의 하나입니다. Python의 장점 중 하나는 C/C++ 모듈과 쉽게 연동할 수 있다는 점입니다. 물론 손으로 일일히 wrapper를 만드는 것은 손이 많이 가고 에러를 만들수 있는 작업이나 SWIG등과 같은 도구를 사용하면 쉽게 python 모듈을 만들 수 있습니다.

Boost.Python은 이런 SWIG와 같이 python 모듈을 쉽게 만들 수 있도록 도와주는 라이브러리로 순수 C++만을 사용한다는 점이 SWIG와 다른 점입니다. 그리고 개인적으로는 Boost 라이브러리에 포함되어 있는 것들이 왠지 좀 더 믿음직스러워서... :-)

이번 글에서는 Boost.Python 문서에 나와 있는 예제를 가지고 간단하게 python 모듈을 만드는 방법에 대해서 알아보겠습니다.

Requirements리눅스
이 글에서는 리눅스 환경에서의 사용 방법을 설명한다.Boost.Python 라이브러리 (1.33.1)
Boost 라이브러리를 다운로드받아 아래와 유사한 명령으로 라이브러리를 빌드한다.
bjam -sTOOLS=gcc -with-python install

bjam의 --prefix 옵션으로 라이브러리가 설치될 위치를 변경할 수 있다.Python 라이브러리 (2.4.3)
Python을 다운로드 받아 빌드하여 설치한다.
위의 경우와 유사하게 configure의 --prefix 옵션으로 설치될 위치를 변경할 수 있다.

Write C++ Code다음과 같이 코드를 작성한다.

// greet.cpp #include <stdexcept> char const* greet(unsigned x) { static char const* const msgs[] = { "hello", "Boost.Python", "world!" }; if (x > 2) throw std::range_error("greet: index out of range"…

Hello Wordpress, again.

한 두주일 정도 Textpattern을 사용해봤는데 다시 Wordpress로 돌아오기로 결정했습니다. 무엇보다 스킨 변경이 너무 복잡하고 사용자층이 Wordpress에 비해 너무 앏네요. 원하는 plugin도 찾기 어렵고... :-|

그동안 Textpattern에 썼던 글들은 모두 Wordpress로 옮겼습니다. 2개 있던 댓글도 옮겼는데 그중의 하난 제가 쓴... ;-)

애초에 wp-dokuwiki plugin이 무거워서 옮겼던 것이라 이 plugin은 설치를 안할 예정인데 몇가지 아쉬운 점이 있네요.

첫째는 code highlighting 기능인데 이 기능은 예전에 만들어 놨던 것을 조금 수정해서 쓰려고 준비중입니다. 두번째는 Footnote 기능인데 찾아보니 Footnotes 0.9 Plugin for WordPress 2.0.x라는게 있네요.

이정도면 비록 wiki syntax에 비할바는 아니지만 쓸만할 것 같습니다. :-)