OpenLook

예전에 libgcrypt에 대한 SEED패치 작업이 진행되면서, FSF에 저작권을 전달하기 위해 메일을 보냈었는데, 지난 주말에 거의 3주만에 드디어 동의서가 도착했습니다. 목빠지겠어요;

내용물로 △ 동의서 1장 △ 회신용 봉투 1장 △ GNU 소 모양 (스티커커 아님) 2장 △ FSF 멤버가 되세요 광고지 1장 이렇게 들어있습니다. 기왕 주는 걸 스티커를 줬으면 더 좋았을텐데 아쉽네요.

이 문서에 싸인을 하면, 제가 올린 부분에 패치에 대한 저작권을 FSF에 할당하게 돼서, 저작권 방어를 FSF에서 대신 맡게 됩니다. 대략 20줄 내외가 넘는 패치들은 이렇게 한다는데.. 다른 프로젝트에서 다 이런식으로 항상 저작권 할당 작업을 한다면 굉장히 난감할 것 같군요; 좀 더 간단하게 자기가 스스로 인터넷에 간단한 라이선스로 릴리스하고 그걸 받아가게 하는 방법도 있긴 한데, 왠지 한 번 해 보고 싶어서 제일 복잡한 방법으로 한 번 둘러가 봤습니다. ^^;

그러나, 정작 싸인을 하려고 보니까 두둥..

과연 어디에 싸인을 해야 할 것인가! 우리나라에서 늘 쓰는 양식에는 (인) 위에 싸인을 하면 간단한데, 여기는 도대체 어디에 싸인을 해야할 지 애매하더군요; 아흐아흐.. 혹시 외국인들도 우리나라에 와서 싸인할 일이 생기면 (인) 뒤에 공간이 너무 적어서 도대체 여기다가 어떻게 싸인을 하느냐 하고 고민하지 않을까 생각을 해 봤습니다;

왠지 ①아니면 ③ 자리가 맞을 것 같았는데, 인터넷에 찾아보니 대체로 활자로 인쇄된 이름 위에 싸인을 하는 걸 봐서는 ②번 자리에 줄 위에다가 글자를 쓰라는 뜻으로 밑줄을 그어 놓은 것 같아서 거기에 싸인을 했습니다. (혹시 싸인해 보신 분은 정답을 알려주세요 -ㅇ-)

이제 회신을 보내면 저작권 작업이 끝나서, gnupg에서 SEED를 쓸 수 있을 것 같습니다. ^.^

9월에 두 행사에서 발표를 맡았습니다. 혹시 직접 만나서 물어보실 것이 있으시거나, 전해주시고 싶은 선물-ㅇ- 이 있으시면 오시면 좋을 것 같습니다. ^o^

9월 1일~3일: 대안언어축제에서 Io언어 튜토리얼을 1시간 30분 정도 진행합니다. Io 언어는 문법이 안 독특한 듯 하면서도, 독특하고 자유도가 별로인 것 같으면서도 굉장히 자유로운 재미있는 성질이 있는데요, 혼자 공부하기 귀찮으시면 오셔서 같이~ 물론, 대안언어축제의 다른 행사들도 ∑n=0,∞{정말정말} 재미있습니다. 요즘 참가신청을 받고 있으니 일정을 확인해 보시고 등록하세요~ (마감임박!)

9월 17일: KLDP 10주년 기념 컨퍼런스에서 “오픈소스 프로젝트에 참여하기”라는 제목으로 발표할 예정입니다. 그냥 사용자로써 종종 불편한 점을 패치해서 개발자들에게 보내주는 방법부터 개발자가 되기 위한 중간 과정, 개발자가 되고 나서 있는 여러 인간관계까지 다양한 상황에 대한 소개를 조금씩 해드리려고 합니다. 구글의 Greg Stein도 온다고 하니, 구글에 관심 있는 분들도 오시면 재미있을 것 같네요~ — 아마 Greg Stein의 발표는 그동안의 발표 내용으로 미루어보아 Python과 MySQL에 대한 내용이 주가 되지 않을까 생각합니다.

애자일 블로그에 올라온 프로그래머와 수학을 읽고 전에 경험했던 것을 짧게 써 봅니다.

프로그램을 하다보면, 뭔가 하고 있는 것이 비효율적인 것 같은 느낌이 약간은 들지만, 최적화가 충분히 되어있다고 느낄 때가 많습니다. 더 속도가 필요하다면, 더 빠른 언어와 여러 트릭을 동원해서 빠르게 하곤 합니다. 극단적인 경우를 예를 들어서, 항상 예제로 많이 쓰이는 피보나치 수열을 한 번 보겠습니다. 실제 프로그래밍이 피보나치 수열처럼 간단한 루틴일 리도 없고 그렇게 반복적으로 호출될 일은 없겠지만, 그래도 극단적인 예를 보면, 그 특징을 다른 곳에서 활용할 수 있을테니까요~

일반적으로 피보나치 수열 n번째를 구하는 루틴은 파이썬으로 이렇게 합니다.

만약 피보나치 수열의 200005번째 수 “주변”의 것이 정확할 필요는 없고 대충의 값이 필요해서 호출한다면, 제 컴퓨터에서는 대충 2.82초 정도가 걸립니다. 그런데, 이런 루틴이 적어도 초당 100번 이상은 호출되어야 하는 상황이 왔다고 치면 보통 이런 대안을 생각합니다.

• 파이썬이 느리니까 C로 하자!
• a, b는 터플이 묶였다가 풀리면서 메모리 할당을 하니까 따로 따로 하게 2줄로 분리해 보자.
• 내가 요새 어셈블리에 재미를 붙였는데, 어셈블리로 하면 레지스터도 충분히 활용하고 빠르지 않을까?
• 루프를 매번 돌리는 것은 비효율적이니까, 16번에 한번씩 돌게 풀어쓰면(unroll) 빨라질거야!

자.. 그런데, C로 하면 과연 얼마나 빨라질까요. 200005번째 피보나치 수는 64비트로 커버가 안 되는 수이기 때문에, 빅넘버 라이브러리를 쓰다보면 결국 시간이 제법 걸리고, 속도도 생각보다는 별로 빠르지 않습니다. 어셈블리로 하면? 과연 오늘 퇴근 할 수 있을까요..

여기서 경험많은 프로그래머는 알고리즘을 휙 보고, 이런 코드로 최적화를 합니다.

200005번째 수를 주는데 걸리는 시간이 눈깜짝할 새 입니다. 아이 그런데, 또 주변의 수가 더 필요해졌습니다. 그래서, 좀 더 많은 범위에서 캐시를 할 수 있게 데코레이터도 쓰고 해서 멋있는 캐시를 넣어서 정말 더 빨라졌습니다. 그랬더니 이제는 메모리를 너무 많이 먹습니다! 결국에는 캐시 관리 기능에 메모리가 얼마인지 보게도 만들어서, 이 프로그래머는 주변의 존경을 받습니다.

그러나, 이때 옆에서 보던 한 수학자가 종이에 뭘 끄적거리더니, 이렇게 하면 안 되겠냐고 조심스럽게 코드를 한손가락으로 톡톡 쳐줍니다.

아! 아.. 프로그래머는 뭔가 속은 기분이 들었습니다. 그래서 유심히 보니까, 실행해 보면 정확한 값이 나오지는 않았습니다. 그래서 따져보고 싶었지만 필요한 것은 그냥 대충 화면 좌표를 잡는 것이라 유효숫자 6개 정도만 하면 넘칠정도라는 사실에 슬펐습니다.

컴퓨터 전공 학생들은 대부분 4학년 되면, 적분기호를 까먹을 정도로 수학을 쓸 일이 없습니다. 그런데, 간단한 프로그래밍의 수준을 지나면 생각보다 훨씬 수학을 활용할 수 있는 일이 늘어나는 것 같습니다. 물론 굳이 수학 뿐만 아니라, 넓게 봐서 논리의 흐름과 여러가지 알고리즘적인 방법, 패턴 등이 있겠죠.

모니터 가까이에서 코드를 보고 있으면, 앞에서 본 C로 하면 무조건 제일 빠를거야!, 터플 때문에 괜히 메모리 할당하는 것을 줄이면 정말 빠를거야! 라는 생각을 늘 하게 되기에 마련이지만, 가끔은 좀 멀리서 최적화에 조바심을 내지 않으면서 코드를 볼 기회도 가져봄 직 할 것 같습니다.

“Real efficiency comes from elegant solutions, not optimized programs.
Optimization is always just a few correctness-preserving transformations
away.” – Jonathan Sobel, 《Is Scheme Faster than C?》에서

붙임: 중간에 든 예가 좀 과장이 심해서 죄송 -ㅇ-; 글의 원래의도가 피보나치 수열을 최적화하자는 것은 아닙니다. ^^;