“‘Planning’ as the term is commonly understood is actually incompatible with an entrepreneurial society and economy….innovation , almost by definition, has to be decentralized, ad hoc, autonomous, specific and microeconomic.”
Drucker가 1985년에 그의 책인 ‘Innovation and Entrepreneurship’에서 얘기한 것. 여기서 말하는 entrepreneurial sociery and economy는 현재의 사회와 경제, 즉, 지식 근로자 사회/경제를 얘기하는 거라고 봐도 무방할 듯 하다. 지식 사회에서는 decentralized, ad hoc, autonomous, specific, microeconomic한 innovation을 해야한다는 것이다. XP나 FDD 등과 같은 Agile(Light-weight) Software Development가 바로 이러한 철학을 가지고 있지 않은가!
gcc(+stlport) 환경에서 C++ Standard Library container들과 ncl::Array에 대한 성능 측정을 해보았습니다. 다만, int형에 대한 insert at end/push_back operation에 대해서만 측정을 해보았습니다. 참고로, ncl::Array는 C Standard Library의 realloc을 활용하여 copy를 줄이는 container입니다. 즉, C++ Standard Library의 container들과는 semantic이 좀 다른 셈이지요.
1. insert at end
첫번째는 (Sheet 1) container.insert(container.end(), obj) operation을 사용한 테스트입니다. stlport가 들어가있는 결과물은 gcc의 기본 library 구현 대신 stlport를 사용한 결과이고, reserve란 단어가 들어가 있는 결과물은 vector::reserve나 Array::Array(int size)를 사용한 구현의 결과입니다. (deque, list는 reserve를 위한 mechanism이 없습니다.)
결과를 요약해보면, vector (reserving) < vector < deque(stlport) =~ deque < list < list (stlport) 입니다. code는 다음과 유사합니다.
#include
int main(int argc, char * argv[])
{
if (argc != 3)
{
printf("usage: %s count sizen", argv[0]);
return 0;
}
int count = atoi(argv[1]);
int size = atoi(argv[2]);
for (int i = 0; i != count; ++i)
{
std::vector v;
#ifdef VECTOR_RESERVE
v.reserve(size);
#endif
for (int j = 0; j != size; ++j)
v.insert(v.end(), j);
}
}
2. push_back test
두번째는 (Sheet 2) container.push_back(obj) operation을 사용한 테스트입니다. vector의 경우에 위의 insert(container.end(), …)와 성능 차이가 2배정도 나는 것이 신기하군요.
결과를 요약해보면, Array (reserving) < vector (reserving) < deque < Array =~ vector << list 입니다. container들에 대한 코드는 다음과 유사합니다.
#include
int main(int argc, char * argv[])
{
if (argc != 3)
{
printf("usage: %s count sizen", argv[0]);
return 0;
}
int count = atoi(argv[1]);
int size = atoi(argv[2]);
for (int i = 0; i != count; ++i)
{
#ifndef VECTOR_RESERVE
std::vector v;
#else
std::vector v;
v.reserve(size);
#endif
for (int j = 0; j != size; ++j)
v.push_back(j);
}
}
ARRAY의 테스트 코드는 다음과 같습니다.
#include
#include "ncl/array.h"
int main(int argc, char * argv[])
{
if (argc != 3)
{
printf("usage: %s count sizen", argv[0]);
return 0;
}
int count = atoi(argv[1]);
int size = atoi(argv[2]);
for (int i = 0; i != count; ++i)
{
#ifndef ARRAY_RESERVE
ncl::Array v;
for (int j = 0; j != size; ++j)
//v.insert(v.size(), j);
v.add(j);
#else
ncl::Array v(size);
for (int j = 0; j != size; ++j)
v.item(j) = j;
#endif
}
}
3. Conclusion
신기하게도, insert at end의 경우에는 vector가 제일 빠르고, deque, list의 순입니다. push_back의 경우에는 deque, vector, list의 순이었습니다.
두 경우 모두 list는 매우 느렸습니다. link를 위한 pointer의 overhead와 entry 별 allocation이 큰 것 같습니다. (아마도 allocator 수준에서 pooling을 하게 되면 개선할 수 있을까요?)
reserve를 하지 않는 경우 vector와 Array는 거의 유사한 performance를 보여줍니다. 10만건이 되면 좀 차이가 납니다. item 수가 적은 경우 (10000건 이하인 경우) vector의 alloc/copy와 Array의 realloc이 별로 차이나지 않는 것을 알 수 있습니다. (copy cost외에도 pre-allocation의 전략이 다르기 때문일 수도 있을 것 같습니다.) int형이 아니라 좀 더 큰 size의 (따라서 copy cost가 더 큰) object를 사용할 경우에는, vector와 Array의 차이가 더 커질 수도 있을 것 같습니다. (테스트가 필요합니다)
그리고 deque가 vector와 Array보다 더 빠른 것을 알 수 있습니다. gcc의 구현을 조금 보니, deque는 memory chunk 단위로 alloc하고 이에 대한 index(map)를 유지하는 data structure더군요. push_back의 경우에 추가적인 메모리만 할당하고, index의 size만 조절해주면 되기 때문에 당연히 더 좋을 수 밖에 없는 것 같습니다.
또한, reserve하는 것이 단연 reserve 하지 않는 경우보다 빠른 것을 알 수 있습니다. reserve할 경우에는 ncl::Array가 std::vector보다 훨씬 빠릅니다. Array의 경우에는 생성자를 통하지만, vector의 경우에는 reserve() op를 통하기 때문일까요?
C# Programming Language에 관한 책이다. 사실 .Net Framework에 대한 내용도 상당히 포함되어있기 때문에, Language를 배우기에 좋은 책은 아니다. 그럼에도 불구하고, C#의 여러 언어적인 요소와 CIL(Common Intermediate Langauge; aka MSIL)을 비교하면서 작동원리를 설명해주기 때문에 C# Programming Language의 구현 방식을 약간이나마 들여다볼 수 있는 점은 이 책의 미덕이다. 번역은 엉망인 편이다. (10점 만점에, 초반은 4점 중반은 0점, 후반은 5점 정도?) 아르바이트 생들에게 시키고 한번도 제대로 읽어보지 않은 정도의 퀄리티. 읽어보면서 내가 직접 수정하면서 읽어간 곳만도 한 스무군데 정도 되는 것 같다. 요즘에 번역서를 몇권 보면서 신뢰를 약간 얻어가는 중이었는데, 이 책을 보고 다시 실망해버렸다. 따라서 이 책을 읽고자 하는 사람은 차라리 원서를 보기를 추천한다.
현재 읽고 있는 책이다. 현재 Chapter 6를 읽고 있는데, 이번 달 안에 끝낼 생각. 번역은 C++ In-Depth 시리즈를 통틀어서 그렇듯이, 만족스러운 편이다. Template parameter를 Strategy로 사용하는 idiom을 Chapter 1에서 소개하고, Template을 사용하는 자잘한 techniqueue을 Chapter 2에 모아두었다. 이어서 Template을 이용해서 구현하는 굵직굵직한 주제들이 나온다. Typelists, SmallObjAllocator, Generalized functor, Singleton, Smart pointer, Object Factory, Abstract Factory, Visitor, Multi Method가 그것들인데, 잘 알려진 패턴이거나 현재 Library TR에서 adopting 중인 것이기 때문에 어쩌면 이미 잘 알고 있는 사람도 있을 것 같다. (저자인 Andrei Alexandrescu가 CUJ의 고정 칼럼 필자이기 때문에, CUJ에서도 이미 다루어졌던 주제들이 많다.) 어떤 것들은 이것이 쓸모가 있는가 싶을 정도인 것도 있고, 어떤 것들은 당장 내 코드에 반영할만한 것들도 있고, 또 내가 직접 구현해보고 싶은 것들도 있다. 확실히 template을 잘 쓰고 싶은 사람이라면 한번쯤은 거쳐가야할 책인 듯 싶다.
소프트웨어 개발자가 선택하는 언어는 개발 패러다임이 변화함에 따라, 어플리케이션 도메인이 변화함에 따라, 또는 외부적인 기술 변화에 따라 계속 변해왔다. 현대의 프로그래밍 언어에서는 이러한 변화가 비단 언어간의 선택에만 반영되는 것이 아니라, 이미 존재하는 언어에도 변화를 요구하는 것이 사실이다.
이 사실은 C++ Programming Language에 있어서도 예외가 아니다. 1998년에 처음으로 C++ Programming Language의 공식적인 표준 (ISO/IEC 14882:1988 International Standard. C++98)이 제정된 이후로 꾸준히 bug fix들이 – 이러한 bug fix 가운데 하나는 std::vector의 internal storage가 contiguous해야한다는 requirement가 추가되어야 한다는 것이다. 그래야만, 프로그래머는 vector 내의 한 element로의 pointer를 얻은 후 array처럼 pointer 연산을 통해 traverse할 수 있다 – 이루어져와서 작년(2003년)에 TC1을 포함한 새로운 표준 (ISO/IEC 14882:2003 International Standard. C++03)이 발표되었다.
현재 C++ Standards committee는 C++0x 표준안에 노력을 기울이고 있는데, 여기에는 기존과는 달리 C++의 언어 자체상의 변화와 표준 라이브러리 (흔히 STL이라고 불리는.. 이는 잘못된 이름이다) 상의 변화를 수반하고 있다. C++ Programming Language를 사용해서 개발하는 프로그래머라면, 이러한 변화에 대해서 미리 알고 있다면, 그동안, C++에서 부족했던 feature에 대해서 보완할 때, 미래의 C++을 미리 고려해서 결정할 수 있을 뿐만 아니라, C++이라는 언어가 현재까지 가져왔던 철학뿐만 아니라 앞으로 가질 철학에 대해서도 더욱 잘 이해할 수 있으리라고 믿는다.
이를 위해서 ISO C++ Standards committee의 의장(convener)이자 Exceptional C++/More Exceptional C++의 저자이면서 Micorosoft에서 Visual C++ architect로 일하고 있는 Herb Sutter가 CUJ에 기고한 The New C++ 칼럼을 이해하기 쉽도록 정리해서 적어보고자 한다.
ISO C++ Standard Committee
ISO C++ Standard Committee에서 하고 있는 일들의 진행상황은 여기에서 볼 수 있다. 언어 자체상의 issue들 (The C++ Standard Core Issues List)이나 표준 라이브러리상의 issue들 (The C++ Standard Library Issues List), 또는 TR1에 들어갈 표준 라이브러리 extension의 draft 등을 해당 사이트에서 찾아볼 수 있다.
Issues List를 참고할 때, Issue들의 종류에는 크게 세가지가 있다.
Defect Reports: committee가 표준안 상에서 수정이 필요하다고 동의한 것들이다.
Active Issues: 현재 고려중인 issue들이다. 저번 meeting에서 제기된 새로운 issue들과 논의되고 있던 issue들뿐만 아니라, commit하기 전에 더 많은 작업을 필요로 하는 issue들도 필요로 한다.
Closed Issues: 더이상의 작업(표준상의 변화)이 필요없는 issue들이다.
The C++ Standards meeting에서 주로 작업하는 것들에는 다음과 같은 것들이 있다.
Defect Reports (DRs): 전체 미팅 시간의 반 정도를 현재의 표준안에 대한 질의에 대답하고 버그를 찾는데에 할당한다. TC1 (Technical Corrigendum 1) 이후의 bug fix들은 TC2 또는 C++ 표준안의 다음 revision인 C++0x에 들어가게 될 것이다.
Performance Technical Report (Performance TR): 하드웨어나 embedded system을 물론 C++ implementability (예를 들어 exception을 어떻게 좋은 성능으로 구현 및 사용할 것인가)에 초점을 맞추고 있다. 이 TR은 C++0x에 들어갈 예정이다.
Library Technical Report (Library TR): 표준 라이브러리에 새로운 기능을 추가하는 것에 대해서 다룬다. 특히, 언어 자체에 추가사항을 필요로 하지 않는 것에 대해서만 다루고 있다. 이 TR은 C++0x에 들어갈 예정이다. Library TR에서 다루는 대부분의 기능은 Boost에 구현되어있다. (그렇다고 해서 Boost의 구현이 표준이 되리라고 보장할 수는 없다는 점을 유의)
Evolution Working Group (Evolution WG): Library TR이 다루지 않는, 즉 언어 자체에 추가사항을 필요로 하는 것들을 다룬다.
이번에는 소개와 C++ Standards committee에 대해서 소개하는 내용밖에 없었지만 다음부터는 C++0x에 들어갈 내용 중, 프로그래머에게 가장 관심이 있을 부분인 Library TR와 Evolution WG에 approve된 내용들을 다루려고 한다. 일단 Part II에서는 현재 Libary TR과 Evolution WG에서 다루고 있는, 다음 내용들에 대한 간단한 설명부터 시작하고, 이후에 각각의 issue에 대해서 자세한 article을 써보는 것도 괜찮을 것 같다. C++에 관심있는 개발자라면, 간단히 적어놓은 아래의 리스트만 보아도 누구나 눈에 띄이는 내용들일 것이다.
p. Web 기반의 Messenger 서비스인 [“MSN Web Messenger”:http://webmessenger.msn.com/]가 beta-testing 중이다. h2. First Impression p. 약간 사용해 본 느낌은 메신저 창이나 대화 창이 초기화되는데 좀 오래걸리는 것 같고, 상대방의 메시지가 도착할 때, 메시지가 기록되는 창으로 focus가 가서 내 typing이 방해받는 것이 신경쓰였다. 그리고 메시지를 보내고 난 후, form이 다시 loading되는데에 걸리는 시간도 불편한 점. p. 웹브라우저 외에 다른 소프트웨어를 설치 불가능한 곳이라든가… MSN Messenger 서비스를 사용 불가능한 platform이라든가… (요즘엔 gaim이 파일 전송도 된다는 모양입니다만.. ㅋ) 그런 곳에서는 쓸모가 있을 수는 있겠다. h2. Technical overview p. 기술적으로는 이미 존재하기도 했기 때문에 그다지 신기한 것은 아니다. server-side something + HTTP (periodical refresh) + Javascript 정도인 듯. applet이나 ActiveX 기술을 사용하지 않는덕분에 많은 Javascript를 지원하는 웹브라우저에서는 대부분 사용가능하다. (Windows의 IE, Mozilla, Firefox는 물론 OS-X의 Camino나 Linux의 Firefox에서도 동작가능할 것이라고 한다. 실제로 가능한지는 not confirmed.) 다만 인상적인 것은 push에 사용하는 방법이 주기적인 HTTP refresh일 뿐이었는데도, realtime messaging이라는 서비스의 usability에는 그리 치명적이지는 않았다는 것. client-side 및 server-side의 performance가 문제가 될 수는 있겠지만, realtime requirement가 critical하게 중요하지 않은/부차적인 서비스에서는 connection-oriented 기술이 필수적이지 않다는 생각도 해볼 수 있을 것 같다. (예를 들어, 채팅 같이 messaging이 빈번하고 realtime-ness가 중요한 서비스에서는 connection-oriented 기술이 사용자의 experience를 개선하는데에 중요하겠지만, 메시지 전달이 빈번하지 않은 게임 초대 같은 서비스 등에서는 별로 중요하지 않을 수도 있다는 것이다. (물론 user exprience에서의 최선은 connection-oriented이다.) h2. Inside the MSN Web Messenger 기본적으로 MSN Web Messenger의 UI는 HTML과 Javascript에 기초한다고 보면 된다. 다음은 MSN Web Messenger의 중심이 되는 javascript file을 indentation을 위해 약간 수정한 것이니 참조해보라. (License쪽을 뒤져봐야겠군. ;;) [“webmessenger.js”:http://www.lastmind.net/archives/20040809/webmessenger.js] 세션의 유지는 server-side에서 이루어진다고 생각된다. client는 어떤 형태로든 session ID를 유지하리라고 추측된다. Javascript에서 connection을 해서 세션을 유지한다거나 하는 것 절대 아니다. ;;; 서버로부터 클라이언트로 push되는 정보는 위에서 언급했듯이 HTTP refresh를 통해 이루어진다. Fiddler같은 HTTP 분석 tool을 사용해보면 5-7초 간격으로 driver.ashx라는 URL을 refresh하는 것을 알 수 있다. 그리고 이 page 내에는 WebMessenger javascript 객체의 method를 통해 상대방이 보낸 메시지나, 친구들의 상태 변경 정보들을 WebMessenger object instance에 update하고 이를 통해 UI에도 반영시키게 된다. 다음은 상대방이 메시지를 보내왔을 때, 이 page의 예이다.
h2. Links * [” What is MSN Web Messenger?”:http://www.mess.be/msnmessengerfaq/article.php?id=083&action=print] * [“eMessenger”:http://e-messenger.net/]: MSN Web Messenger와 거의 똑같은 서비스를 하는 web application. h2. Screenshots !http://www.lastmind.net/archives/20040809/MSN_Web_Messenger_01.JPG! !http://www.lastmind.net/archives/20040809/MSN_Web_Messenger_02.JPG!
얼마전 OSCON에서, 지난 3월 “PyCon 2004”:http://www.python.org/pycon/dc2004/papers/9 에 소개되었던 “IronPython”:http://ironpython.com/ 에 관한 발표가 있었다. IronPython은 Microsoft의 open source license인 CPL로 release되었고, pystone benchmark에서 Python-2.3에 비해 1.7배 정도까지 좋은 performance를 보여주었다고 한다. 반면, “Edd Dumbill’s blog”:http://usefulinc.com/edd/blog/2004/7/29#00:28 에 의하면 좀 더 현실적인 benchmark인 parrotbench는 IronPython이 Python-2.3에 비해 4% 정도 더 느린 결과를 보여주었다고 한다. 또한 “oreillynet의 slides”:http://conferences.oreillynet.com/presentations/os2004/hugunin_jim_up.ppt 에 따르면 좀 더 다른 결과를 보여주고 있다. 확실히, 성능에 관한 benchmark는 한가지 결과를 가지고 모든 것을 판단할 수 없겠지만, 적어도 Python에 국한해서는 .Net 환경이 그렇지 않은 환경에 비해 느리다는 억측은 피할 수 있게된 것 같다. 한편, IronPython의 제작자인 Jim Hugunin은 dynamic language에 대한 지원을 위해 CLR team에 합류하였다고 한다. More Links:
p. Gentoo package에 대한 query tool인 equery를 사용하면 USE flag의 의미를 쉽게 알 수 있습니다. equery는 gentoolkit package 내에 들어있습니다. “http://www.gentoo.or.kr/wiki/moin.cgi/UseFlag”:http://www.gentoo.or.kr/wiki/moin.cgi/UseFlag
# equery uses sendmail
[ Colour Code : set unset ]
[ Legend : (U) Col 1 - Current USE flags ]
[ : (I) Col 2 - Installed With USE flags ]
U I [ Found these USE variables in : mail-mta/sendmail-8.12.11-r3 ]
+ + ssl : Adds support for Secure Socket Layer connections
+ + ldap : Adds LDAP support (Lightweight Directory Access Protocol)
- - sasl : Adds support for the Simple Authentication and Security Layer
+ + tcpd : Adds support for TCP wrappers
- - mbox : Adds support for mbox (/var/spool/mail) style mail spools
- - milter : Build sendmail mail filter (milter) support
- - mailwrapper : Adds mailwrapper support to allow multiple MTAs to be installed
