화요일 저녁에 퇴근하려는데, 옆자리의 개발자 분이 나를 부른다. 내가 개발하는 라이브러리에서,

“Debugger 붙여놓고 띄워보면 First chance exception이 나요. Access violation 이고 0×0000 0000에 뭔가 쓰려고 합니다”

라고.^[1]

일단 해당 자리의 디버거 창에서 살펴본 봐로는, 내가 수 주 전에 추가한 WSASend 호출 횟수 줄이는 코드에서 나온 문제인 듯 했다. Send-Queue에 패킷이 여러개 쌓이면, 이걸 모아서 전송하는 루틴을 추가했는데, 이 안에서 저 first-chance exception이 발생.^[2] 일단 화요일엔 집에 어머니도 와 계시고 해서 바로 퇴근하고 다음 날 오전에 추적하기로 했다.

First chance exception 이 발생했다곤 해도, 프로그램이 실제로 크래시하지 않는 걸로 봐선, 어딘가에선 처리 되고 있단 얘기니 좀 안심하고 다음 날 디버깅 시작. 출근해서 코드를 열심히 들여다 봤다. 대체 어디서 문제가 생길까? 일단 내 머신에선 재현이 안되더라. 그래서 일단 저 문제를 발견한 개발자가 출근할 때 까지 기다렸다. 그리고 얘기해주는 환경을 다 끌어 모아서(플랫폼 + 컴파일러 버젼을 맞춤) 테스트.

발생하지 않는다?!?!?!?!. 해당 개발자 자리에 가서 하면 한 번에 재현된다. 그래서 잘 알려진 WinSock 관련 first-chance exception 문제처럼, 이것도 MS가 포기(?)한 버그인가 싶어서 MS에 있는 모 선배에게 물어볼까 하고 있었다. 그래도 다른 선임분의 말을 듣고 다시 디버깅하는데, 콜 스택 모듈에 보니 수상한 dll 이 하나 있더라.

anywall3.dll 이게 뭘까? 저 네이밍으로 볼 때, 저주받을(…) 삼성 SDS의 인캅스(incops)를 연상케하는데… 여튼 몇 가지 테스트를 더 해본 결과:

Incops3 가 없는 시스템에선 당연히 저 DLL이 콜 스택에 안 보인다. 그리고 저 문제도 없다….

=_=

더욱 씨니어인 다른 개발자 분의 말로는, 정확히 같은 케이스는 아니지만, 인캅스 적용 후 그런 문제를 경험하고 있다고… 나는 계속 서버 쪽 개발만해서 x64 환경만 쓰다보니 — x64에선 인캅스가 안 돈다 – 다행히 안 겪은 것 뿐이었던 듯?

결론: 개발자의 시간과 노고를 갉아먹는, 내 컴퓨터 공학 석사/학사 학위를 걸고 쓸모 없는 프로그램인 삼성 SDS Incops 좀 쓰지 맙시다. 이 회사에서도 사실 상 사용을 포기한 툴이기도 하고 – 존재 의의 중 하나가 USB 로 파일 복사를 막는 기능이 있다. 근데 “전혀 막지 못하는 버그(헛점?)”가 있는데, 리포팅하고 나서 수 개월 후에 패치는 받았다는데, 전사 적용을 못 하더라. 그리고 이젠 다른 툴을 쓴다. 인캅스 자체는 꼭 설치하지 않아도 된다고 하더라…

1. First chance exception에 대해서는 MSDN 블로그의 이 글을 참고 하자.
2. 실제로 구현한 최적화는 이런 내용이다. MS Win32 WinSock 에 존재하는 시스템 콜인 WSASend 는 좀 특이하게(?)도 – 혹은 일부 UNIX 시스템에 익숙한 사람이라면 sendv() 함수를 생각하면 된다 – 하나의 바이트 스트림을 전송하는게 아니라, 일련의 바이트 스트림을 전송하게 해준다. 즉 pointer + length 를 이용하는게 아니라 pointer + length의 배열을 인자로 받아, 이를 전송해 준다. 그래서 Send-Queue에 쌓인게 많으면, 이걸 여러 번 쏘거나(system-call 수가 많다), 하나의 배열로 합치거나(추가적인 메모리 할당 및 복사가 필요하다)하지 않고, 단순히 이 버퍼들에 대한 주소 + 길이 쌍을 배열에 집어넣고 WSASend를 호출하는 것.

Related posts:

1. 멤버 함수 포인터의 크기
2. 당신 역시 초보일 수 있습니다
3. Concurrent Programming and `Linearization’

SF 소설로, 지난 일주일 정도 동안 열심히 봤다. 사실 이건 빌려놓고 제대로 안 읽고 있다가 막상 돌려줘야 할 때가 되서 + Windows Vista->7 업그레이드 때문에 손놓고 있던 두 시간 정도의 여유 때문(???).

‘노인의 전쟁’을 다 읽고나니, 이 후속작도 있다는 소릴 듣고 열심히 읽고, 아마존 검색 결과 그 다음권도 있길래 냉큼 사서 봤음. 처음 두 권을 한글로 보고나니, 마지막 권은 영문으로 봐도 크게 어렵지 않더라.

많은 SF 소설들이,

“이런 상황이 되었을 때, 인간은 어떤 선택을 하느냐; 나중에 이런 문제가 닥쳐올 텐데 어떻게 할까”

라는 식의 얘기를 많이 하는데, 이 씨리즈에선 약간 다른 방향… 좀 더 오락적이랄까? 으로 나간다. 특히 첫 한 권이 그렇다…

이 아래 리뷰 내용에는 낮은 수준의 까발리기가 포함되어 있다. 그렇지만 본다고 저 세 권의 책을 읽는 재미가 줄어들 수준은 아니라고 생각한다.

첫 책에선 거의 세계관 전달에 촛점을 맞춘다. 인류가 우주 개척 시대에 돌입했지만, 지구는 거의 20세기 말 그대로 남아있고, 노인이 되면(75+) 우주 개척 방위군(CDF)에 자원해서 (뭔가 방법을 써서) 젊어지고 우주에서 싸우게 되는 구조가 된 상태를 설명한다. 그리고 이 전쟁(?)의 시대에 주인공이 자원해서 CDF에서 싸우기 시작하기 까지가 책 내용의 거의 절반에 해당한다.

그 와중에 지구의 인류와 우주에 나가 있는 인류(우주 개척 연맹; Colonial Union; CU)에 대한 얘기가 나오고, 앞으로의 씨리즈에 대한(…) 지구인 관점의 설명이 이어진다. 물론 주절주절 설명하는건 아니고 책 전체에 걸쳐 이걸 느끼게 해주는게 좋았음. 오락적으로도 훌륭한 것 같고.

좀 웃겼던 것(그리고 이 책의 이야기가 가능했던 것)은 CU에서 모든 기술을 거의 통제해서 지구의 기술 발전을 늦춘 것이 가능 하다는 것. 근데 정보는 일단 책에서 얘기하는 공간 도약없이는 광속보다 빨리 전달 할 수 없으니 그냥저냥 말이 되서 책은 계속 읽었다 – 궤도 엘리베이터(space elevator?)라거나, 공간 도약, 유전자 조작 병사, 의식(consciousness)의 이식 등등은 CU만 가지고 있는 상태. 우주에 나간 인류는 기타 지성있는 외계인들의 대립 구도(=만인에 대한 만인의 전쟁)에서 열심히 지식을 습득해서 엄한 속도로 발전해버렸다 정도로 설명을 해서 좀…

물론 1권 처럼 오락적인 면(=전쟁 씬이라거나 계략 구도 등등)도 괜찮았다. 다만 1권의 주인공은 3권이 되어야 나오는 건 좀 불만이었지만, 주인공 자체의 매력은 2권에만 나오는 주인공 자신이 꽤 괜찮았음. 시점도 3인칭으로 옮겨가긴 했지만;;

특히나 복제 인간 격인 존재들의 “자기 선택권”에 대해서 얘기하는건 꽤나 흥미로웠다.

그리고 우주 전체의 대립구도를 바꿔놓으면서 이야기 규모를 팍 키워놓고 2권이 끝나버린다. 야!!!!

여튼 1권의 주인공인 존 페리가 재등장하고, 이 존 페리가 새 개척 행성의 행정관(꼴랑 2500명이 이주하는 거긴하지만)이 되서 벌어지는 이야기와, 여기 담긴 음모, 그리고 전우주 규모의 대립이 3권의 내용.

2권 말미에서 잔뜩 벌여놓은 이야기를 잘 수습한다는 점에서 정말 잘 썼다고 생각한다. 사실 2권 읽고나면 벌어진 이야기의 크기 때문에, 3권이 있는걸 알고 안 읽을 수가 없음(…). 내가 1권에서 품었던 기술 격차 문제(CU vs. 지구)도 어떤 의미론 설명해주는게 이 3권이었던 듯 함.

궁굼한건(…) 3권 등장 인물 중에 Jane과 Zane이 있다. 한국어 번역판에선 어떻게 표기하려나?

여튼 이 책을 읽게 된건, 재밌다고 첫 책을 빌려 준 rica 덕분. 이 자리를 빌려 rica 에게 감사를.

PS. 근데 3권까지 봐도 콘수의 존재 의미는 안 밝혀집니다. 난 이게 제일 궁굼한데 Orz.

외전 격인 두 권의 책이 있긴 하지만 제목 자체가 약간의 까발리기이기도 하고 해서 여기선 언급하지 않는다. 다만 아마존 평점이 그닥이라(씨리즈 3권은 모두 4.5/5 수준의 높은 평점인데 이 건 2.5~3 수준) 안 읽을 가능성이 높음; 근데 소개된 줄거리 만으론 콘수 얘기는 없을 것 같다. 흑흑.

Related posts:

1. 빌드 자동화 하기 – CruiseControl.net

Seibel: What is your proces for desiging software? Do you fire up Emacs and start writing code and then move it around until it looks right? Or do you sit down on your couch with a pad of paper?

Bloch: I gave a talk called “How to Design a Good API and Why It Matters” at OOPSLA a couple years ago, and serveral versions of it are floating around the Web. It does a pretty good job explaining how I go about it.

The most important thing is to know what you’re trying to build: what problem you’re trying to solve. The importance of requirements analysis can’t be overstated.

(중략)

Coming up with a good set of use cases is the most important thing you can do at this stage. Once you have that, you have a benchmark against which you can measure any possible solution. (중략)

The worst thing that you can do – and I’ve seen this happen – is you get a bunch of smart guys into a room to work for six months and write a 247-page system specification before they really understand what it is they’re trying to build. (중략)

So get those use cases and then write a skeletal API. It should be really, really short. The whole thing should, usually, fit on a page. (중략)

The whole idea is to stay agile at this stage, to flesh the API out just enough that you can take the use cases and code them up with this nascent API to see if it it’s up to the task. It’s just amazing there are obvious in hindsight but when you’re designing the API, even with the use cases in mind, you get them wrong. (중략)

As your confidence in the API increases, then you flesh it out. But the fundamental rule is, write the code that uses the API before you write the code that implements it. Because otherwise you may be wasting you time writing implmentation code that won’t get used. In fact, write the code that uses the API before you even flesh out the spec, because otherwise you may be wasting your time writing detailed spece for something that’s fundamentally broken. That’s how I go about designing stuff.

간단히 해석+요약 하자면, “뭔가를 디자인 할 때 어떻게 하는가”라는 질문에 대해, Bloch 자신이 2년 전에 했던 강연^[2] 을 보라며 이런 말을 한다.

1. 좋은 디자인을 하려면 요구 사항을 분석해서 use-case 를 만들어야 한다.
2. 이 use-case 를 염두에 둔 채로 간단한 뼈대로 API 명세를 만든다.
3. 그리고 이 초기 API를 코딩한다. 다만 충분히 기민하게 이를 수정한다.
4. 충분히 자신감이 쌓이면 이를 내놓는다.

하지만 가장 중요한 원칙은 “API를 쓰는 코드를 API 보다 먼저 작성하라” 라는 것. 심지어 이 API 명세를 작성하기보다도 먼저…

Bottom line

현실은 시궁창. 6개월 넘게 진행된 명세라는게 1주 구현하면서 내포된 모호성 때문에 상당 수가 뒤집힌 새 명세가 되더라. 그리고 이 명세는 구현 가능할 정도로 안정적인지 난 모르겠다. 명세 내부에서도 서로 모순인게 나오는데… 완성은 언제?

1. 나는 전기 컴퓨터 공학부 대학원에서 이동통신망을 전공했다. 거기에서 PHY 바로 윗부터 MAC 단까지의 여러 가지 프로토콜과 TCP를 다뤘다. 여기서 많은 수의 프로토콜을 분석하고, 향상시킬 수 있는 부분을 제안하거나, 시뮬레이션 하거나 하다 졸업했다
2. 여기서 해당 제목의 PDF나 acm 포탈을 따라가면 볼 수 있다

Related posts:

1. 리뷰: Coders at Work
2. C/C++ on Adobe Flash
3. C++ 0x 새소식 – lambda 와 closure

가상화해서 돌리던 서버 중 1대에 redmine 이 올라가 있었는데, 이 서버가 주기적으로 죽는다. 대략 매 달 4주 차의 토요일 오전에 사망함. 게다가 이건 물리서버를 내가 접근할 수도 없는데, 해당 쪽의 처리도 늦어서 어제는 오전 10시 경에 보고했는데도 실제로 서버가 살아난건 오후 5시 다 되서…

근데 죽는 타이밍이 너무 기가 막히니(…), 저거 누군가 해답을 알려나?

Redmine 사용하는 2개 팀이 그냥 서버 이전하기로 합의 보고, 어제 저녁에 이전 작업을 했다. 일단 예전에 써놓은 대로 작업을 진행했다. 근데 이게 왠걸. 일단 mysql 백업 복구하는 과정에서 막혔다.

잠시 삽질하다 원인을 찾아보니, 해당 서버에 2 개의 mysqld 가 떠 있었고, 나는 내가 설치하지 않은(bitnami-redmine-stack 1.0 설치) mysqld 랑 연결하고 있던 것 Orz. 일단 이렇게 백업은 복구. redmine files 디렉터리도 복사하고, 서버를 띄웠더니 svn 저장소 로그는 보이는데, repository browser 탭이 보이질 않는다.

로그를 뒤져도 딱히 이상한게 없고(이건 log-level 문제인가?), redmine 홈페이지의 트러블슈팅을 따라하다가, 다음 명령에서 문제가 있는 걸 확인.

> rake -f Rakefile redmine:fetch_changesets RAILS_ENV=”production”
svn: Cannot negotiate authentication mechanism
svn: Cannot negotiate authentication mechanism
svn: Cannot negotiate authentication mechanism
…

이런 식으로 대략 연동된 저장소 수 만큼 나오더라. 문제의 원인은 svn 저장소 중 일부가 SASL 인증을 써서 였음. bitnami redmine stack 에 포함된 svn 으론 SASL 인증이 안되더라… Collabnet 에서 나온 svn 클라이언트 설치하고, binary 바꿔치기해서 상황 종료.

Related posts:

1. 개발 머신 설치 기록
2. 프로그래머의 일상: 업그레이드의 때
3. Redmine 설정 중의 뻘짓

매우 간단하게 병렬화 되는 알고리즘인, quicksort를 가지고 성능 테스트를 했다. pivot을 그냥 순열 중간에서 찍어내는 단순 무식한 방법으로 만들었음.

이하에선 대략 배열 길이가 512 보다 작으면 그냥 순차 알고리즘만 동작하게 했음.

Naïve 하게 시작

우선 처음엔 fork-join 하는 형태로 좀 많이 naïve 하게 짜봤다: 정수 400만개 정렬 시켰더니, goroutine 수가 너무 많다고 뻗음. (이건 내 코드의 버그였음). 더 이상 fork하지 않고 도는 threshold를 좀 높게 잡고(8192?) 돌렸더니 대략 1200ms 정도 걸리더라. 단순하게 그냥 짠 알고리즘을 싱글 스레드로 돌리면 약 2000ms. 거의 2 배의 스피드업이 있긴하다.

그래도 이건 좀 아니다 싶어서(…), Work-stealing queue를 짜기 시작.

Work-Stealing Queue

완전히 다 구현한건 아니고, 배열을 둘로 쪼갠 순간 다음과 같이 동작하게 했다.

배열의 앞 부분은 work-stealing queue로 전달하고, 나머지는 그 goroutine이 직접 정렬하게 했다. 물론 이것도 재귀적으로 적용되니까 전부 한 goroutine에선 이루어지지 않는다.

Work-Stealing Queue를 간단하게 구현한다고(…) 좀 가짜로 만들었다. 일단 큐를 스레드 별로 두지 않았다. 다만 자기 자기 큐에서 꺼낼 때의 LIFO 동작을 흉내내려고 전부 큐에 넣는게 아니라 마지막에 분할한 부분 배열은 자기가 직접 정렬한다. 그리고 다른 스레드의 큐에서 꺼내는걸 따라(?)해서 큐에서 꺼내는건 FIFO…

처음에 작업 종료되는걸 감지할 방법을 못찾고 해매다가, Queue에 넣은 작업 갯수 만큼 종료 신호를 받게 했다. 이것도 단순히 빈 슬라이스를 응답으로 보내게 해서 이거 숫자를 셌다(…).

대략 1100ms 정도 걸린다. 총 goroutine 수가 입력에 비례하는게 아니라, 코어 수에 맞춰놔서 naïve 구현처럼 panic() 함수 호출되는 일은 없었음;;;

C++이랑 비교

C++의 <algorithm>에 있는 sort 랑 비교해봤더니 너무 큰 차이가 난다. 대략 700ms 좀 안 걸리게 돌더라. 이건 무려 싱글 스레든데;;; 사실 이건 내 구현이 sort() 함수의 introsort 보다 예상 성능 자체가 낮아서 생기는 일이기도 하지만;;
내가 짠 알고리즘을 싱글 스레드로 돌린 경우 1580ms 정도 걸렸다.  (cf. Go는 2000ms)

intel tbb의 tbb::parallel_sort()를 사용한 경우 대략 350ms 쯤 걸린다. linear-speedup? 이게 가장 빠르긴 하구나.

Go 쪽에 썼던 코드를 그대로 넣고 돌렸더니 대략 1600ms. 그래도 코어 2개 쓰는 쪽이 빠르긴 하지.

요약

Go(single-thread): 2000ms
Go (parallel) : 1100ms

C++(single-thread; same algorithm): 1600 ms
C++(single-thread; std::sort() ) : 700ms
C++(2-threads; tbb::parallel_sort() ):  350ms

간단한 감상: 좀 더 최적화 할 여지가 있어 보인다. 심심풀이로 실제 물리 코어 수 보다 더 많은 MACPROCS를 지정했더니 성능이 꽤 빨리 내려간다. 생각보다 channel 통한 통신의 오버헤드는 크지 않아서 만족스러웠다. fork-join 과 worker-thread 비슷하게 짠 게 큰 차이는 안나는걸 보니… 반대로 goroutine은 아무리 많이 만들어도(한 6만개 만들어도 잘 돈다) 괜찮긴 하더라..

+ naïve 하게 짜면 망한다(???).

Related posts:

1. Google Chrome 확장 기능 만들기
2. Google Go on Android/nacl?
3. C++ style guide – from google, from naver

멋진 장소? 식의 괴악한 한국어를 벗어나 “공유해 주셔서 감사합니다. 정말이야!”라니…

그나마 한국어의 탈을 쓴 듯한 스팸이 오네요. 그래봐야 akismet에 걸린 듯 하지만…

Related posts:

1. 실패할 인터넷 광고 – 테레비 (a.k.a spam)
2. WP를 이용한 서비스형 블로그 서비스 qrobo

art.oriented의 김민장(object)님이 쓴 책이다. 한빛미디어의 Blog2Book 씨리즈 중 하나.

평소에 저 블로그를 구독하고 있다면, object 님이 전반적인 컴퓨터 구조와 최적화에 관해서 얘기하는 걸 여러 번 봤을 거다 – 구독하지 않고 있다면 RSS 리더에 추가하는 걸 추천! 잘 읽히는 블로그 글 솜씨만큼이나 책도 쉽게 읽을 수 있어서 좋았음.

이 책에서는 컴퓨터 구조, 특히 CPU 에서 명령어를 빨리 실행하기 위해 무엇을 하는지를 중심으로 현대 CPU의 여러 부분을 설명하고 있다. 간단히 읊어 보자면,

• 프로세서의 각 부분에 대한 설명
• 컴퓨터 성능 평가와 암달의 법칙
• 고성능 프로세서에 들어간 최적화 부분: 파이프라인, 비순차 실행, 하이퍼 스레딩, 멀티 코어 그리고 데이터 병렬성
• 분기문의 복잡함과 최적화: if 문, virtual function
• 멀티코어 CPU 혹은 SMP 아키텍쳐에서 벌어지는 몇 가지 문제들
• 느려터진 메모리의 최적화: 캐시와 메모리 계층 구조, 메모리 프리펫치

를 비롯해서, 이 포스팅에선 언급 안한 것도 잔뜩 포함해서, 컴퓨터 구조의 여러 내용을 설명하고 있다. 특히 상대적으로 쉬운 내용 – 프로세서의 나 각 실행/제어 단위에 대한 설명, 기본 개념에 대한 설명 – 부터 시작해서,  비순차 실행이라거나 분기 예측, 투기적 실행(speculative execution)처럼 학부 수준의 컴퓨터 구조 시간에는 간단히만 다루는 현대의 복잡한 CPU 구조의 부분부분을 설명해주기 때문에, 좀 어려울 수는 있어도 따라갈 수 없는 내용은 아니다.

물론 이 주제의 상당 부분은 학부 컴퓨터 구조와 컴파일러 시간에 배우는 내용보다 좀 더 최신이고, 상대적으로 좀 더 깊이 들어간 부분이 있기 때문에, 빈말로도 “쉽다”라곤 말 못하겠다. 그렇지만 학부 수업을 차근차근 듣는 기분으로, 찬찬히 살펴본다면 얻을게 정말 많다.

하드웨어 얘기이긴 하지만, 이 하드웨어가 우리가 만드는 소프트웨어와 직접적으로 연관이 있고, 하드웨어의 많은 부분은 소프트웨어 쪽 구현에도 영향을 준다. 책에서도 몇 번 강조하는 얘기지만, 여기서 설명하는 파이프라인의 개념은 여러 멀티스레드 프로그래밍에 나오는 개념이다(Task-parallel pattern; 잘하면 task+data parallel pattern도 됨). 비슷하게 메모리 미리 읽기(pre-fetch)나 캐시 활용 같은게 실제 응용 프로그램에서 쓰이는 사례는 말 안 해도 알 것이다. 그래서 “난 SW에만 관심이 있어!”라고 말하는 사람(=rein)들에게도 좋은 책이라고 생각한다.

비록 오자가 좀(…) 있다곤 하지만, 빠르게 업데이트 되고 있어서, 오자 페이지를 찾아가서 확인하면서 보면 괜찮을 거다;

rein은 이 책을 그레이트 코드 2권 같은 책에 매우 큰 흥미를 보였거나(…), 컴퓨터 구조에 대해서 알고 싶거나, 혹은 더 배우고 싶은 분들에게 매우매우 추천한다. 비슷한 이유로 팀 신입 사원들에게도 읽어보라고 권하고 있다

Related posts:

1. 리뷰: The Design of Design
2. 리뷰: Clean Code
3. 리뷰: The Design of the UNIX Operating System

현대 과학에 새로 생겨난(?) 분야 중 하나가 복잡계 과학이란 분야다. 이 책에서 얘기하는 것처럼 명확히 정의되지 않고, 그 경계도 모호한 분야지만 여러 분야 – 생물학, 물리학, 컴퓨터 과학, 수학, 기상학, … – 에서 나타나는 “복잡계” 때문에 많은 사람들에게 친숙(?)한 용어이긴 하다.

이미 번역된 책으로 이머전스, 딥 심플리시티, 링크(linked), 동시성의 과학 싱크(sync) 같은 많은 책이 나와있긴 한데, 좀 묶어서 나온 책이 없다고 생각해서, 추가로 읽게 된 책이다.

책 초반부에 이런 얘기가 나온다:

복잡성에 관한 “하나의 과학”은 아직 없다. 복잡성에 대해 서로 다른 정의를 갖는 몇 개의 서로 다른 과학이 있을 뿐이다. 이 정의(notion)은 일부분에선 매우 수학적(formal)이고, 일부에선 그렇지 않다. 만약 여러 복잡성의 과학이 “하나의” 복잡성의 과학이 된다면, 이 서로 다른 정의가 어떤 관계인지 알게 될 것이다.

즉, 아직 “충분히 연구되지 않아서” 명확히 정의 내리긴 어렵고, 각각의 분야에서 서로 다른 생각을 하고 있다는 것. 그리고 이런 분야에 관해 저자가 하나하나 설명하는 식으로 책이 진행된다(…).

책 전반에서는 “복잡성”의 의미를 저자가 생각하는 몇 가지 카테고리로 나누고, 이에 대한 예를 굉장히 많이 든다. 링크에서 얘기했던 스케일 없는 네트워크 비슷한 내용이라거나, 여러 분야에서 공통으로 반복되는 상수라거나 구조 등등. 일단 복잡성 자체를 “계산”이라는 (그래도 불명확하지만) 의미로 묶고, 이에 대해서 잘 쪼개서 설명하고 있다.

책 자체는 굉장히 쉬운 문체로 쓰여 있어서 술술 잘 읽힌다. 내가 컴퓨터 공학 전공이라 그런지 “복잡계”의 특성으로 “계산”을 가지고 얘기하는 게 꽤나 편하게 들렸다. “파인만의 엉뚱 발랄한 컴퓨터 강의”에서 얘기하는 “계산”의 특성에 관한 내용과 열역학 제 2법칙에 관한 내용도 다루는데, 이 책은 설명이 좀 부실하다. 파인만의 ~~~ 책 쪽이 훨씬 설명이 나음. 더불어, 몇 가지 컴퓨터 공학의 경계(frontier)에 해당할 “유전 알고리즘”이라거나 “셀룰러 오토마타; 세포 자동자”에 관한 얘기도 많이 다룬다. 매스매티카의 울프람 씨 얘기도 많이 나오고, 유전 알고리즘으로 최적화된 셀룰러 오토마톤을 찾는 얘기도 나온다.

다만 저자 자신의 박사 논문에 해당하는 copycat 프로그램을 다루는 절은 좀 지루했다. 스킵해도 뒤에선 별 차이 없더라…

책 자체가 복잡성 과학이 적용된 몇 가지 분야에 대해서 예를 많이 든다는 점은 매우 큰 장점인 듯 하다. . 전산학(계산; 자기복제; 셀룰러 오토마타; 유전알고리즘…), 생물학(유전; 발생; 신경계; …) 등등이 이에 해당. 그래서 상대적으로 저자의 말을 이해 하는 게 쉬웠다. 이런 류의 책의 주 독자층은 적어도 한 두 분야는 약간씩 접해보았거나, 자기 전공과 관련이 있을 테니 꽤나 보기 쉽게 만들어줄 듯 하다.

덤으로 마지막 장에서 저자가 “이 복잡성 과학이 쓸모 없다는 반론이 있지만 나는 그렇지 않을 거라 믿는다”라 말하고 있는데, 나는 대략 반반의 의견. 세부 분야가 정말 쪼개져버리거나 – 각 분야의 이해가 깊어지면서, 그 분야에 맞는 이론으로 고착화 되기 – 아니면 저자 말대로 하나의 과학 분야가 생겨나거나..

Related posts:

1. 리뷰: 이중나선
2. 리뷰: 무지개를 풀며
3. 리뷰: 사이비 사이언스 – 과학과 비과학의 경계에 관한 지침서

The Myhtical Man-Month 의 저자 Frederick Brooks 의 신작이다.^[1]

일단 이 책은 부제인 “Essay from a Computer Scientist”에 나와 있듯, 일종의 에세이다. 저자의 사고를 일정한 순서로 풀어놓고, 이를 묶어서 책으로 만든 느낌이다.

이 책에서는 “디자인”을 어떻게 하는가 – 그러니까 디자인(설계)을 어떻게 설계해야 하는가 – 를 다룬다. 좀 불명확하긴 하지만, 디자인이 뭔지, 그리고 여기에 들어가는 사람들이 어떻게 사고하며 (이를 위한 SW는 어떤지, 이걸 써본 결과는 어땠는지), 그리고 어떻게 상호작용하는 지도 다룬다. 더불어, 디자인에 영향을 주는 요소들 – 자원(예산), 제약 사항 등등 – 도 다룬다.

물론 이 디자인을 하기 위해 뭘 어떻게 배워야 하는지. 우리가 배울 수 있는 예제들은 어떤지, 그리고 그걸 배우곤 있는 지라거나 등등에 관해서도 열심히 얘기한다. 마지막으로 이 내용들을 몇 가지 사례(컴퓨터 관련, 건축 관련, 책 관련…)를 들어 설명한다.

저자인 브룩스가 IBM의 통합된 형식(프로그래밍 모델이라거나, OS라거나 …)의 컴퓨터 군으론 최초로, 거대한 성공을 이룬 IBM System 360 을 설계 책임자여서인지는 모르겠지만, 여기서 얻은 경험을 예제로 여러 번 들고 있으며, 컴퓨터 구조 및 OS 설계 과정을 케이스 스터디로 각각 다루고 있다.

개인적으로 가장 의미심장 했던 대목을 다루자면,

성공적인 디자인은 공통적으로 이런 패턴을 갖는다: 물리적으로 격리; 작은 팀; 극도의 집중; 한 명의 리더십. 특히 (특정 설계의) 후속 디자인에 비해 어떤 획기적인 디자인에서 이게 반복적으로 나타난다. 예로, Joe Mitchell의 스핏파이어 팀이나, U-2와 F-117을 만든 켈리 존슨의 스컹크 웍스(Skunk Works), 애플에 대항하기 위해 PC를 설계했던 IBM의 격리된 lab이 있다.

이거랑 직접적인 대응은 아니지만, 중간에 다룬 내용으로, system 360 의 아키텍처를 정하기 위해 13 개의 서브 팀으로 쪼갠 후 경쟁 시켰다는 대목이 나온다. 즉, 작은 팀(1~3명)으로 / 격리 시키고 / 단기에 집중 시켜서 얻어낸 결과로 결론을 내렸다는 것. 가장 좋았던 두 개의 후보의 차이는 나머지는 거의 차이가 없고, 6bit 바이트일지 8bit 바이트일지 였다고…

그리고 보론처럼 들어간 게,

저자가 본 모든 팀 프로젝트에서, 디자인의 각 부분은 매 순간 한 사람만 다룬다. 그 한 사람이 그 부분에 대한 제안서를 준비한다. 그리고 동료들과 어떤 부분이 영향을 받는지 아주 작은 세션(micro-session)의 디자인 리뷰를 한다. 그리고 협력해서 내린 각 결정과 방향에 따라 세부 사항을 작업한다.

몇몇 개발 방법론에서 얘기하는 것 처럼, 코드 소유자가 있고, 그 부분을 각자 진행하는 시간이 있다는 것. Coders at Work에 나왔던 Erlang 개발 얘기도 이거랑 비슷한 느낌이 좀 있다.^[2]

덧. 책 내용 자체가 에세이라고 생각하면 상당히 가벼워지긴 하지만, 저자 자체가 갖는 이름값도 굉장하고 해서 좀 무겁게 읽었다. 왠지 이 책과 비교해서 번역서로 읽었던 Mythical Man-Month는 좀 거칠거칠했다는 느낌도 받게 되었음 – 그러니까 번역 후에 어조가 바뀐 느낌; 어쩌면 그 사이에 흘러버린 시간 때문일 수도 있지만.

덧2. 얼마 전에 이 책을 읽다 부끄러워졌다고 썼는데, 이 책에선 디자이너를 어떻게 하면 잘 키워낼까를 얘기하면서 많은 예제들을 보라고 한다. 그래서 나 지금은 좀 하고 있나?(..)

1. 사실 4개월이나 지났지만…
2. 다만 이건 브룩스가 말하는 특별한 케이스 – 2 인 팀 – 이긴 하다

Related posts:

1. The Design of design 읽던 중에
2. 리뷰: The Design of the UNIX Operating System

Introduction to Go Programming Language #2

거의 일주일 전에 한거지만 업로드는 이제야…

지난 번에 받은 느낌은 C버젼의 Erlang 비슷한 언어였는데, 좀 더 쓰다보니 대략 Python 을 연상케한다.

• Syntactic sugar라거나, http 모듈 구현 방식이라거나, duck-typing이나 다름 없는 interface 구조라거나
• 하지만 python 을 컴파일 언어로 만들긴 힘드니, 상당한 제약이 들어가 있다
• 그럼에도 불구하고 꽤나 편하게 만질 수 있었다 (System Programming 언어를 표방하는 애들 중엔 제일…)
• C 랑 매우 잘 붙는 것도 거의(…)
• C 와의 인터페이스로 쓰는 C pseudo-package 도 왠지 ctypes가 생각 나는 것이…

…이런 느낌?

이번엔 지난 번(4주 전)에 이어 간단한 웹 서버 모듈 짜고, 이걸로 뭔가 보여주려고 했는데, 예제 짜고나서 이걸 설명하려니 지난 번에 설명하지 못했던 개념들이 이거저거 나와서(…) 그것들과 C 언어 링킹, Goroutine 과 그 구현의 현재 문제점들, 그리고 간단한 웹 서버 모듈을 설명하는 걸로 마쳤다.

일단 웹 서버 모듈(http 팩키지)만 놓고 보면, python 의 BasicHTTPServer 처럼 http 팩키지의 핸들러를 적당히 등록하는 방식으로 만들 수 있어서 꽤나 편했다. python이랑 달리 아예 URI 별로 핸들러를 등록시키는 방식이라, 상대적으로 모듈 쪼개기가 쉬워보임. C랑 잘붙어서 기존 라이브러리 가져다 쓰기도 매우 편한 것 같고… C랑 붙이기 위해서 “C” 란 가짜 패키지를 (만드는 척해서) 사용하는데, C.struct_name, C.function_name 만으로 접근되는게 꽤 편했음. (다만 이를 위해 SWIG 처럼 cgo 란 툴로 팩키지 빌드를 하긴 해야함)

여튼 C 연결을 쓰는 sqlite 래퍼를 찾고(…), 여기에 http 팩키지로 만든 웹서버를 띄워서 간단한 북마크 저장소를 시연하고 이번 치 세미나는 끝. 다음 번 주제를 좀 고민하고 있는데, 웹 서버처럼 상대적으로 full-swing 하는게 쉽게 보이는 걸 좀 더 해볼지, 아니면 게임 서버처럼 서로 얽히고 섥힌(…) 녀석을 만들어 볼지 고민 중이다.

Related posts:

1. 팀 세미나: Go Programming Language #1
2. Programming Erlang 을 읽다 든 생각
3. Concurrent Programming and `Linearization’

Google Chrome 확장 기능은 개념적으로 매우 단순한 구조를 가지고 있다. 다만 보안 상의 이유로 몇 가지 제약 사항이 있어서 짜는데 삽질을 해야 했지만;;

전체적으로는 몇 개의 파일을 묶어서 플러그 인이 되게 한다. manifest.json라는 파일을 포함해야 하는데, 여기에 구글에서 정의한 기능 단위로 어느 파일이 어떤 기능을 하는지 정의 한다. 예를 들어, 이 아이콘을 쓰고, 옵션 페이지는 이 html 을, “~~한 URI”에는 이 javascript 를 … 하는 식으로 정의 한다.

내가 짠 스크립트는 이글루스 밸리에서 특정 블로그를 차단하면 되는 거라, 특정 URI에 해당하는^[1] 페이지를 만나면, 여기에 동작하는 content_scripts를 짜는 걸로 했다. 일단 시작 자체는 튜토리얼만 따라 해도 돼서 편하게 갔음.

옵션을 표현하는 페이지를 manifest에 options_page 로 주고, 여기에서 localStorage^[2] 에 어느 블로그를 차단할지 저장하게 했다.

다만 작성하는 동안 최대 문제는, 내가 사용한 content_scripts 가 “페이지를 변환”하는 기능을 하기 때문에, 당연히 XSS 위험이 있을 수 밖에 없고, 이거 때문에 chrome 확장 API 들을 거의 접근할 수 없었다. 그래서 localStorage 도 직접 접근할 수 없었고, background.html 이라고 플러그 인을 위해 계속 떠 있는 페이지^[3] 를 이용해서 데이터를 읽으려 해도, 역시 보안 상의 이유로 실패 Orz.

좀 더 API 문서를 읽어보니, background.html 에 asynchronous query 하는 건 되더라. 그래서 여기에 옵션 값 내놓으라는 요청을 보내고(…), 이걸 받는 후에야 특정 블로그 내용이 나올지 말지 결정하게 했다. 그랬더니 어찌 어찌 동작하게 되더라; 그리고 플러그 인 페이지에 한 번 낚였는데 –_-.

구글 크롬 자체의 플러그 인 페이지에 개발 중이 플러그 인을 배포용으로 묶어 주는 기능이 있는데, 구글의 공식 확장 기능 페이지에는 이 파일을 업로드 하는 게 아니었음. 개인키로 서명까지 하게 해 놓고 이게 무슨 삽질인지 –_-; 사실 구글 계정과 플러그 인 업로드가 묶이기 때문에 그런 거 같긴 하지만;

Mozilla FireFox 플러그 인은 XUL 배우기가 귀찮아서 전혀 손도 안 대보고 있었는데, 나중에 기회가 나면 그쪽으로 포팅하는 걸 고려 중이다. 아내가 주로 쓰는 브라우저가 그거라서…

여하튼 감상:

• json, javascript, html + 약간의 데이터(이미지 등등)를 통해 금방 플러그 인을 작성할 수 있더라
• 특정 기능(content_script) 사용의 경우 Java Applet이나 Adobe ActionScript 처럼 상당한 제약이 걸린다. 우회해야 하는 게 한 무더기.
• 특정 시나리오, 예를 들어 플리커에서 사진을 가져온다거나 하는 일은 매우 쉽다. 로컬 연결이 아닌 웹의 각 open API를 쓰긴 쉬워 보였다. 기본 예제도 그렇고.
• npapi도 지원하긴 하더라. 별로 쓰고 싶진 않지만(…)

1. valley.egloos.com/* 그리고 www.egloos.com/* 및 비슷한 페이지들
2. 5MiB 까지 데이터를 저장할 수 있는 공간이 있다; 그리고 여기에 의존하다 피 봤음
3. 각 플러그인마다 존재하고 이것도 manifest 에 기술하고 html 파일을 플러그 인에 추가하면 끝.

Related posts:

1. C++ style guide – from google, from naver
2. 주말 코딩: Google test 용 GUI runner
3. Google Chart 다국어 문자열 지원 시작?

Signal vs. Noise 라는 이름으로 37signals^[1] 에서 운영하는 블로그가 있다. 여 튼 이 블로그에 글을 쓰는 사람 중 두 명이, 상당 부분 블로그 내용에 가깝게 책을 썼고, 이게 3월에 발매되었다. 이 책을 산 이유 중 하나는 광고 문구로, “각 종 사업을 시작해보려는 사람, 사업 중인 사람, 혹은 전혀 그럴 생각이 없는 사람들을 대상으로 썼다” 라고 되어 있길래 대체 무슨 소린가 해서. Jeff Atwood라거나 Joel Spolsky 가 추천하는 것도 있었고 …

간단히 요약하자면, 책 저자들이 작은 회사 – 요새 유행하는 용어를 쓰자면 강소 기업? – 를 잘 운영하고 있어서 그런지, 그런 방향으로 “이걸 이렇게 생각해서 성공적이었다”는 식으로 강조하는 게 꽤 많고, 상당히 납득할만한 방식으로 서술해서 재미있게 봤다. 그리고 이걸 잘 돌려서 생각하면, 그냥 고용인 입장에서 봐도 납득할 만한 + 스스로 실천해볼만한 사항이 많다. 그래서 이 책의 권장(혹은 광고 대상?) 독자 층이 저렇게 잡히는 거 같지만.

책은 별로 길지 않다. 본문을 인용하자면,

Lots of things get better as the get shorter. Directors cut good scenes to make a great movie. (중략) We cut this book in half between the next-to-last and final draft. From 57,000 words to about 27,000 words. Trust us, it’s better for it.

더 짧게 만들면 더 좋아지는 것들이 많다. 감독은 명작을 만들어내기 위해 좋은 씬들을 잘라 낸다. (중략). 이 책의 최종 원고와 그 직전 원고 사이에 거의 절반의 양을 잘라 냈다. 대략 5.7만 단어에서 2.7만 단어 수준으로 줄였다. 믿어보자, 이게 더 낫다.

(REWORK 의 Progress – Build half a product, not a half-assed product 에서 발췌; 모든 저작권은 REWORK 의 저자들에게 있다)

즉, 더 나은 책을 쓰려고 양을 반으로 줄여서 그리 길지 않은 – 종이 책 기준으로 약 280 페이지 – 책이 된 것. 덕분에 읽는데 일주일도 안 걸렸다(…). 그리고 많은 내용이 이들의 블로그에서 말한 내용이다. 완전히 같지는 않을지라도, 저 블로그 구독하고 있다면 많이 본 얘기들이 나온다. 뭐 이 책에서 말하는 “문화”란게 저런 거 겠지만;;

책 자체는 중 주제 몇 개를 소주제로 쪼개서 간결한 그림 한 장 + 설명 한 페이지 ~ 세 페이지 정도? 로 설명하고 있다. 여기서 이들의 경험을 기반으로 “어떻게 살아야(?)하는지” 얘기한다. 특히나 벤처, 특히 IT 벤처업계의 상식이(???) 된 얘기들에 반하는 내용을 꽤나 직설적으로 말한다.

처음부터 이익을 낼 수 있어야 한다거나, 몇 년 짜리 계획(혹은 사업 계획서)은 무의미하다거나. 상품만 파는 게 아니라 상품을 만들기 위한 지식도 팔고, 상품에 덤으로 나오는 것도 잘 팔면 된다거나.

벤처 캐피털의 도움을 받는 건 절대 하지 말아야 할 일(Plan Z)라고 부르고 있고, “작은 회사가 좋은 점”에 대해서도 꽤나 길게 몇 개 소주제로 역설한다. 그리고 역시 자신들의 경험에 빗대어 사람을 어떻게 뽑을지, 그리고 지리적으로 넓게 분산되어 있는 팀은 어떤 지도 얘기한다.

맘에 드는 대목을 몇 개 꼽자면,

아이디어는 매우 값싸고 많다. 맨 처음 아이디어 자체는 비즈니스 전체에서는 매우 작은 부분만 차지할 뿐이고, 거의 무시할 수준이다. 정말 중요한 것은 “얼마나 잘 실행하느냐”다.

Go – Start making something,

더 작은 질량을 갖고 간다고 생각하자. 지금 당장이 가장 작고, 군살을 뺀, 가장 빠른 상태며, 앞으론 점점 살이 붙게 된다. 그리고 점점 더 변화하기 힘들게 된다.

Go – Less mass

경쟁자보다 더 쓰고, 더 팔고, 혹은 더 후원하는 것보다 더 “가르치려고” 하라. 경쟁자는 생각조차 하지 않을 일이고, 이건 일반적인 마케팅 방법으론 얻을 수 없는 “유대감(bond)”을 만들어 줄 것이다.

Promotion – Out-teach your competition

사업가는 왜 더 크게 보이려고, 딱딱한 언어, 공식 발표, 만들어낸 친밀감, 법적인 것들 등등을 왜 쓰는가? 마치 로봇 같다. 즉, 당신과 대화 하려는 게 아니라, 당신에게 설교하려 든다.

읽을 만한 글을 쓰자. 쓰기 위한 글을 쓰면 안 된다. 뭔가 쓰고 난 후엔 크게 소리 내서 읽어라. 대화하는 것처럼 들리는가? 그렇지 않다면 더 대화문같이 수정하자.

Culture – Sound like you

역시 인용된 모든 문구의 저작권은 REWORK의 저자들에게 있다. 이 책 꽤 재미있게 읽었다. 갑자기 찾아온 여름이 덥기도 하니, 약간은 가볍게 읽고 싶은 책이 필요한 사람에게 추천한다.

1. Ruby on Rails 를 만든 회사이기도 하고, 몇 개의 사용하기 쉽고 간결한 툴들을 만든다. 사실 저 프레임웍 자체도 이 툴들 중 하나를 만들다 나온 것.

No related posts.

Google Go 의 타겟 플랫폼으로 알고 있던 게, linux x86/x64, darwin(MacOSX) x86/x64, arm 이었는데, 몇 가지가 더 보이더라. 그 중 주목(?)할 만한 게 있었음.

일단 linux-arm-android 가 있고, 추가로 nacl 386 이 있다. 좀 놀란 이유는 며칠 전 구글 I/O 에서,

Android 지원은 가능하지만(arm 에서 빌드가 되니), 아직 높은 우선 순위는 아니다

라고 답한 거였는데 … (정확히는 FAQ 목록이지만) 그리고 이 빌드가 한참된거라서 (올해 1월부터 있다; Fail이 좀 많긴 하지만)

뭐 일단 Android 도 어느 정도 테스트되고 있는 듯(golang.org 에도 사용가능한 플랫폼으로 그에 대한 언급이 있다). 덤으로 WebApp 용 native client(nacl) 지원도 있는 듯 함. 다만 벤치 마크 페이지에는 darwin x86/x64, linux x86/x64 만 있는 걸로 보아 아직 불안정한 상태인 듯도. (그리고 Google I/O 발언대로라면 아직 그렇게 높은 우선 순위가 아니라는 정도?)

PS. 근데 내가 Go 를 정말로 쓰기 위한 최우선 과제(?) I/O 성능 개선인데, 이건 언제쯤? 사실 이건 밑 단 라이브러리만 잘 되면 좋겠는데. 하다 못해 Java 보다야 I/O 성능이 좋아야할 거 아닌가;;

이 글을 쓰는 사이에 스리슬쩍 FAQ관련된 비디오가 업데이트 되었다. 이건 집에가서 봐야하나.

Related posts:

1. Google Chrome 확장 기능 만들기
2. C++ style guide – from google, from naver
3. Google Chart 다국어 문자열 지원 시작?

그리고는, 책장에 꽂힌 내 책(사진의 예쁘장한 파란색 하드커버 책)을 뽑으려고 한다. 김명수 교수님의 모 수업을 들었던 분들은 무슨 책인지 잘 아실 듯(…)

아들이 관심을 갖는 건, 학부 4학년 때? 던가 그 학기에 처음 개설된(…) 3학년 과목의 교재였던 Gilbert Strang 교수의 "Introduction to Applied Mathematics"란 책. 무광 파란색에 하얀 테두리가 맘에 드는 모양(?).

학부 4학년 봄 학기에 가장 많이 뒤져본 책이 아닐까 싶은데, 무겁고(…), 비쌌고!(한 달 생활비 1/4넘게 날아감), 심지어 거의 절판된(지금은 절판) 책이었는데, ‘수학 그게 뭔가요’하는 무지한 공대생들에게, 선형대수학…이라기보단 그 응용을 적절히 다뤄준 책.

심지어 첫 학기라고, 그 랩 박사과정 형님 + 석사과정 누님 한 분이 주말마다 연습문제 풀이도 해주셨음(하지만 토요일 오전 9시던가 10시의 압박은 실로 -ㅁ-)

덕분에 그 이후에 들었던 컴퓨터 애니메이션(…의 탈을 쓴 컴퓨터 그래픽스 + 선형대수학)은 쉽게 쉽게 들었다는 훈훈한 얘기가(???).

근데 아들은 파란색이 맘에 드는지 저 책을 뽑고 + 핥고 + 꾸깃꾸깃(그래 봐야 하드커버!) 하고 싶어한다.  아들아, 추억의 책은 좀 남겨주지 않으련? 절판돼서 아마존에서도 못 구한단다 Orz.

ps. 근데 Gilbert Strang으로 아마존 검색해보니 3년 전에 나온 Computational Science and Engineering 도 있다. 이것도 사서 연습문제 따라 천천히 읽어보고 싶어지네…

Related posts:

1. 수업 교재를 읽다 짜증나는 순간
2. 서점에서 겪은 일
3. 4주간 하고싶었던 일들

나는 이 시간에 Google 에서 만드는 오픈 소스 프로그래밍 언어인 Go 에 대해 하기로 했다. 요즘 심심풀이로 만지는 언어가 Go라서…

여기 그 때 썼던 자료를 게시한다. export를 잘못했는지 슬라이드 노트들은 없다(…).

Introduction to Go Programming Language

사용한지 기껏해야 한달 좀 넘었지만, 기본적인 구조는 C를 따르고, 여기에 몇 가지 제약을 가하고 기본 타입과 concurrency primitive 를 더해서,^[1] Erlang 비슷한 언어가 되었다는 느낌.

그래서 이런 느낌을 가지고 Go 가 가지는 강점과 약점이라고 생각되는걸 간단히 요약하자면,

• 굉장히 빠른 시스템 빌드 시간 – 대부분의 의존성(type, import,…)을 명시적으로 해결하기 때문에 빌드가 정말 빠르다
• 간단하고 어느 정도 duck-typing이 돼서 조작하기 쉽다
• 메시지 패싱에 기반하는 병행/병렬 프로그래밍에 특화되어 있다 – Erlang 과 유사함
• C 와 달리 내장 타입이 좀 더 다양하다
• UTF-8 내장 + range() 문을 사용하면 문자열을 byte 단위와 문자 단위(variable-length)로 모두 순회하기 쉽다
• 문자열은 상수고, 배열도 그냥 복사된다. 이건 Erlang 에 대해 내가 쓴 글에서도 말했듯이, 변하지 않는 데이터가 병렬성에선 정말 중요하다.^[2]

단점도 몇 가지,

• 아직 툴 체인이 완성되지 않았다 – gccgo(gcc를 백엔드로 씀), 8g(x86 용), 6g(x64 용), 5g(arm 용) 등이 따로 논다. 특히 전자와 뒤의 3가지는 정말 따로 놈. 내장 기능의 수행방식도 약간 다른 수준이라.
• 라이브러리가 아직 정말 빈약하다 –_-;
• 툴 체인이 완성되지 않았다?랑 비슷한 얘기지만, 아직 충분히 최적화된 코드가 아닌 느낌. 몇몇 벤치 마크 결과가 그리 좋지 않다. (Java 보다도 느리다니…)

뭐 그래도 Erlang 보다는 많은 수의 (예비) 프로그래머가 있으니(C/C++/Java) 상대적으로 병렬 프로그래밍 작성할 때 쓰기엔 나은 듯도 하다. 다만 얼마나 빨리 성숙한 상태에 도달하느냐가 문제지만;

덧. (MacOSX 의) Exposé 의 Spaces를 이용해서 Keynote 프레젠테이션과 코드를 실행하는 터미널을 번갈아 가며 쓰려고 했다. 그런데 프레젠테이션 중엔 Ctrl + 화살표^[3] 로 다른 스페이스로 못 넘어 가더라. 그래도 Command + Tab 으로 프로그램 선택이 바뀌면 스페이스 바뀌니 어찌 되긴 하더라.

1. 물론 GC도 제약이라면 제약이지만 추가사항으로 치자
2. 물론 배열을 복사하지 않고, 배열 전체 혹은 일부를 참조하는 slice란 문법을 지원한다
3. Fn +인가? 손이 기억하는 거라 잘 모르겠다

Related posts:

1. 팀 세미나: Go Programming Language #2
2. Programming Erlang 을 읽다 든 생각
3. Concurrent Programming and `Linearization’

여기서 사용하신 듀나의 영화게시판의 valentine30 님이 작성한 것임을 밝혀둡니다.

Related posts:

1. 2010년 새해 목표
2. GPGStudy 포럼의 대안에 관해

이런 클래스의 객체 so가 있고. 이 so의 Increment() 멤버 함수를 인자로 지역 변수 x를 넣어, 미래의 특정 시점에 호출하려고 Closure로 만든다고 치자. 우선 기존 구현체를 쓴다면 다음과 같은 코드가 필요하다.

MakeClosure(so, &SomeObject::Increment, x);

이번엔 lambda를 이용해서 만든다고 치자.

MakeLambdaClosure([&so, x](){ so.Increment(x); });

인자가 하나 뿐이기에 큰 차이는 나지 않는다.

하지만 인자가 많아지고, 인자 중 일부는 복사하는 경우 비용이 매우 큰 경우라고 가정하자. 그러면 MakeClosure() 구현을 효율적으로 만드는 게 별로 쉬워지지 않는다.

그리고 좀 더 생각을 바꿔서(?) Increment() 함수를 노출시키고 싶지 않은 경우, lambda 를 사용하는 경우엔 MakeLambdaClosure를 SomeObject 내부의 스코프에서 호출하기만 하면 되지만, 전자는 이게 불가능하다. Closure 템플릿에서 해당 함수를 호출할 수 있어야만 템플릿 인스턴스가 만들어지기 때문이다.

그리고 Increment()를 1번 호출하는 게 아니라 k번 호출하는 경우를 생각해보자. 전자는 SomeObject의 멤버 함수를 새로 만들어야 한다. 반면에 후자는 다음과 같이 수정하면 끝이다.

MakeLambdaClosure([&so, x, k](){ for(int i = 0; i < k, ; ++i) so.Increment(x); });

C++ 0x에 추가된 lambda 문법이 access control, 기존 변수 접근하는 법(capture rule이라 부름), 함수를 직접 “만들어낸다”는 점에서 이것 저것 제어할 수 있어서 상당한 편의를 주게된다. 물론 다른 방법으로도 이 구현은 할 수 있기에 표현력이 증가하지는 않는다.

Related posts:

1. C++0x를 써서 Closure 다시 만들기
2. C++ 0x 새소식 – lambda 와 closure
3. C++ template 함수의 타입 추론

• 함수의 타입을 인식해야 하기 때문에 가변 인자 템플릿을 만들어야 했고, 이를 위해 boost::preprocessor 의존성이 생겼다
• 인자의 생명 주기를 추정할 수 없기에, 간단한 가정을 하고 모든 참조형 인자(T& 타입)를 강제로 원래 타입으로 지정(T 타입)해서 저장하도록 했다.
• 함수를 ‘저장’하기 위해 boost::function 을 사용했다. (std::tr1::function 과 동일함)

C++ 0x 에는 lambda function 문법이 있다. 이를 이용해서 위의 세 가지를 간단히(?)해결할 수 있게 되었다.

원래 다음 템플릿에 해당하는 걸 썼다.^[1] 

하지만 익명 함수 문법인 lambda function을 사용하면 다음 한 가지 형태로 내가 이전 구현에 생각했던 모든 함수 형을 다룰 수 있다.

우선 함수의 타입 인식 문제. 어차피 타입 이름을 알 수 없지만(익명 함수니까), 이건 템플릿 함수의 타입 추론이 해결해준다. 즉, 단순히 아래 함수를 만들면 해결.

함수 자체의 타입이야 있겠지만, 이걸 굳이 boost::function 혹은 std::(tr1::)function 에 넣지 않고도 가볍게(?) 저장할 수 있다.

그리고 인자의 생명 주기 자체는 내가 작성하는 Closure 코드에서 전부 알아서 할 게 아니라, lambda function의 argument capture 문법에서 원하는 데로(?) 참조인지 복사인지 각 인자 별로, 혹은 적당히(?) 지정하면 끝.

마지막으로 추가 라이브러리 사용이 없다는 건 장점. 게다가 lambda function은 선언하는 scope 에서 friend 함수로 간주되기에, 이전에는 어쩔 수 없이 public 으로 노출해야 하던 함수들이 굳이 노출될 필요가 없어진다.

그리고 기나긴(?) template instantiation 된 함수 호출들이 단순히(?) 호출 한 번으로 끝나기 때문에 함수 호출 오버헤드도 약간 감소한다. (아주 간단하게 객체 내부 변수를 1씩 더하는걸 이전 구현과 새 구현 기준으로 비교했더니 Core2Duo 6750 에서 597ms vs. 181ms 정도의 차이가 있었다; 실행 횟수는 8천만번 호출하는걸 256회 반복해서 낸 평균; 그러니까 어느 쪽도 충분히 큰 오버헤드는 아니다.)

덤으로, 예전대로라면 별도의 함수를 작성해야 하는데, 그 부분이 없어지고, 실제로 의미를 따라가기 쉽게(혹은 어렵게?) “Closure를 생성하는 위치”에 함수 본문(body)이 온다는 것도 꽤 편하다…

일단 MS VisualStudio 2010 과 GCC 4.5 에는 이 익명함수가 존재하고 있고, draft 단계를 지나고 나면 아마 더 많은 컴파일러 들도 지원할 것으로 보인다.^[2]  그리고 내가 예전에 생각한 것처럼, 미래(?)가 되어 일이 좀 편해지는 듯 하다.

1. 실제로는 BOOST_PP가 이걸 생성해 낸다.
2. intel cc도 지원하긴 하는데 정확한 버전을 모르겠다.

Related posts:

1. 밑 글에 이어, C++ 0x lambda를 사용한 closure 예제
2. C++ 0x 새소식 – lambda 와 closure
3. Flash ActionScript 사용기 – 두번째 삽질

Mythical Man Month 의 Freidric Brooks 의 신작(작년에 나왔지만) The Design of design 을 요즘 읽고 있다.^[1] 반 쯤 읽은 상탠데, 반복해서 강조하는 내용 중 하나가,

디자이너는 자기 분야의 “모범적인 예제(exemplar)”들을 탐구하고, 연구하고, 그 안에 담긴 원리(rationale)를 이해하고 상황에 맞게 해석해야 한다.

의 내용이다.

좀 더 자세히 쓰자면, 해당 분야의 이론이 되는 근거들(컴퓨터 공학이라면 수학/논리학/전기 공학 …)를 충분히 배우는 것도 중요하고 실무의 내용도 알아야 하며, 이를 이해하기 위해 역사적인 모범 예제들을 탐구하라는 것. 그리고 이런 게 정규 교육 과정의 일부가 되어야 한다라는 건데.

학부시절을 생각해보면 이런 걸 제대로 접해본 적이 있나 싶어서 좀 부끄러워 졌음. 작게는 컴퓨터 프로그래밍으로, 조금 넓게는 어떤 서버의 구조를 생각하고 이걸 구현하는 일을 직업으로 삼고 있는데, 나는 얼마나 이 분야의 역사적인 사례(exemplar)에 대해 탐구해왔나 생각해보니 Orz.

학부 내내 코드를 자세히 읽어본 건 거의 최초 버전의 UNIX 운영체제^[2] , linux kernel^[3] 정도 뿐이다. 회사 와서는 이전에 작성된 서버코드를 여러 개(대략 4개?) 쯤 읽긴 했지만, 이건 빨리빨리 보느라 대충 봤으니…

뻔한 소리지만, 컴퓨터 공학 / 전산학 (Computer Engineering, Computer Science) 는 그렇게 역사가 오래된 분야가 아니다. 그런데도 나는 이 분야의 일부에 국한한 부분을 전문(?)으로 하면서도, 역사, 그리고 그 역사에 담긴 모범 예제들, 그리고 그 안에 담긴 생각들에 대해 너무나도 무지하다. 아직 젊다고 자위할 게 아니라, 좀 더 정진해서 배워야 할 필요가 매우 많다.

1. 다만 요즘 출근 시간을 앗싸리 땡겨 버려서, 차가 안막히다 보니(…) 진도가 좀 늦다
2. 수업기간의 1/3 기간 정도를 Lion’s code 라는 책을 가지고 소스 코드를 읽으면서 진행한 수업이 있다; 덤으로 동아리 스터디 + 자체 공부로 약간의 UNIX 내부(system V r4) 약간 공부한 수준이니
3. 2.4.x; 이것도 절반은 자의로 스터디하고, 나머지는 소스 코드 분석해서 문서화하는 알바 하면서 얻은 것

Related posts:

1. 리뷰: The Design of Design
2. 리뷰: Coders at Work
3. Peter Norvig 이 생각하는 TDD

나 자신이 주 개발을 C++/Python으로 하는지라, 이 이하의 내용은 C++ 프로그래머 관점이 주다.

C++ 변경 사항(C++ TR1/C++ 0x) 반영에 따른 변화

lambda 구문 추가. 예전에 썼듯이, C++ 은 효과적인 익명 함수 문법이 없기 때문에, 굉장히 괴악한 삽질을 하고서야 closure 비슷한 구문을 만들 수 있었다. 하지만 이런 게 지원 되면 (어차피 functional 에 해당 기능도 추가되고 해서) 상대적으로 쉽게 이를 만들 수 있게 된다.

rvalue reference 및 이를 사용한 STL 구현 변경. “값”에 해당하는 (의미론적으로 위치가 없는) rvalue 참조자가 생겼다 (type&& 문법으로 표기). C++ 의 철학 중 하나가, “사용하지 않는 것의 대가를 치르지 말아라” 인 게 괜한 게 아님. (특히) STL 컨테이너에서 임시 객체 할당하는 경우, 복사 연산이 상당히 줄어들게 된다. (move semantics / perfect forwarding)

rvalue/lvalue 자체가 좀 헷갈리시는 분들은 Visual C++ 팀 블로그의 Rvalue references 란 글을 읽어 보자.

nullptr 지원, auto 타입 지정자 설정 등으로 상대적으로 코드를 쓰기 간편해짐. 엄청 복잡한 템플릿 기반 컨테이너(…)의 iterator 같은걸 생각하면 정말 머리가 아픈데 – 대부분 typedef 땜 빵을 하기야 하지만 – 이런걸 상대적으로 쉽게 넘어가게 해준다.

대부분의 TR1 헤더 및 일부 C++ 0x 기능이 헤더에 추가됨. 문제는 이런 헤더 파일들의 변화로, boost 라이브러리를 사용하는 라이브러리 중 일부가 컴파일 되지 않는다. google-test 1.4.0 릴리즈도 tuple 을 내부적으로 정의해서 쓰고 있어서 이름 충돌 –_- 을 겪게 된다. 내가 짠 라이브러리 중엔 identity functor 를 정의해 쓰던 게 충돌하고 / type_traits 를 사용한 코드도 충돌하고 / boost::function 을 쓰는 코드도 충돌했다(바로 그 closure 코드 –_-).

문제는 내가 작성하는 라이브러리를 몇 가지 VS 버전에서 컴파일 되도록 해야 해서, 정말 하기 싫었던(…), _MSC_VER 값 가지고 조건부 컴파일을 몇 개 추가 했다.

빌드 관련 변경 사항

Native multi-targeting 이란 기능이 추가. VS 2010 솔루션 파일 하나 가지고, VS 2008 혹은 VS 2005 의 툴 체인을 사용해서 빌드 할 수 있게 수정되었다. 다만 이전 버전이 설치되어 있어야 하고, VS 2005는 공식 지원이 아님. 근데 VC++ 팀 블로그에 해당 프로퍼티 파일들이 올라와 있어서 그냥 하니까 되더라;

다만 일부 post-build / pre-build 이벤트에서 msbuild 로 빌드하게 했는데, 이 설정들은 자동으로 컨버팅 되질 않아서, 좀 괴로웠음. 게다가 이건 버전 별로 어떻게 나눠야 할지 좀 갑갑함…

MSBuild 버전이 올라가고, 좀 더 툴 자체가 리파인 되었음. 로그 출력도 좀 더 정갈(?)해지고…

빌드 속도 자체는 광고하던 링크 속도 향상은 미미했던 것 같고, 일부 테스트에선 오히려 느려지기도 하던데 (5% 미만 수준이긴 했지만…).

그리고 컴파일 과정에서 사용하는 플랫폼 SDK 버전이 낮으면(같이 포함된 7.0A 이상을 써야 함) rc 가 이상한 에러를 내뱉는다. 그리고 (기본) include, lib, exe .. path 에 해당하는 설정이 다른 곳으로 이전됨…

컴파일러에서 정의하는 상수들 중 일부가 변경됨. 이건 별도 빌드 파일인 경우엔 신경 쓰지 않으면 곤란해질지도 모르지만, 일단 테스트하는 동안엔 별 문제 안 생겼음.

IDE 에서 눈에 띄는 것들

제대로 된 다중 모니터 지원. 이젠 모니터 세 개를 개발 머신에 물려도 될 것 같다. 일부 출력/watch/… 창만 IDE 프레임 밖으로 꺼낼 수 있었는데, 이젠 개별 편집 창을 꺼낼 수 있게 변경. 게다가 “창 별로” 확대 기능을 지원한다. 이건 시연용?

인텔리센스는 조금 나아진 듯도 하지만, 이건 오래 안 써보면 모르겠고. WPF를 써서인지 메모리 사용량은 좀 늘었지만(약 50~150MiB쯤?), 이 정도는 램 가격 내려간걸 생각하면 별거 아니고.

Related posts:

1. 근황 – 2010/04/05
2. 근황 – 2010/02/18
3. VisualStudio + UnitTest++에서 abort() 처리하기