28 Mar 07 개발자와 사용자의 ‘속도’차이
개발자들은 소프트웨어의 ‘속도’라고 하면 흔히 여러 벤치마크를 생각한다. 사람들이 Java가 느리다고 할 때, Java 개발자들은 HotSpot과 같은 기술로 Java를 빠르게 만들었다. 정말 최근의 JVM은 빠르다. 대용량 서버용 소프트웨어에 Java가 많이 쓰이는 이유 중 하나이다. 그런데도 applet은 거의 사용되지 않고 사용자들도 좋아하지 않는다.
사용자들이 느끼는 속도는 개발자들이 생각하는 속도와 다르다. 사용자들은 virtual function call이 어떻게 사용중에 profile되고 inlining되어 C++의 virtual function보다 빨라질 수 있는지에 대해선 관심 없다. 다만 그들은 Java 로고가 보일 때는 웹페이지가 늦게 뜬다는 것을 알 뿐이다.
사용자들의 PC는 개발자들의 PC와 다르다. CPU의 GHz만 높고 메모리는 부족한 대기업 PC에 시작 프로그램은 20개쯤 등록되어 있고 지금 보고 있는 웹페이지에서도 온갖 그림과 플래시 때문에 하드 디스크는 이미 한참 swapping하고 있는 중이다. 더군다나 그 하드 디스크는 defrag한지가 몇년쯤 되었고 90% 이상 용량이 차있어서 기본 defrag tool은 쓰지도 않지만, 쓸 수도 없다. 이런 PC에서 JVM이 뜨면서 수십 MB를 새로 확보하려면 수십초가 걸려도 이상하지 않다.
아무리 PC 사양이 좋아졌다고 해도, 보통 사용자들의 PC는 느리다. CPU가 느리다기 보다는 메모리가 부족하고 fragment된 하드 디스크가 느리다. 따라서 메모리 footprint를 줄이는 것이 무엇보다도 중요하다. 매크로미디어는 이런 점을 잘 알고 있었고 Sun은 그렇지 못했다.
최근 FLEX2를 써보기 시작했다. Java와 비교할 때 장점도 있고 단점도 있다. ActionScript의 실행속도가 아무리 빨라졌다고 해도 JVM에 비교할 수는 없다. 하지만 사용자가 느끼는 속도 차이는 그게 아니라 큰 부담없이 뜨는 플래시와 이미 ‘느리다’는 느낌으로 조건학습되어버린 Java 로고의 차이이다.
20 Mar 07 직장인 연간근로시간과 오픈소스 활동의 관계
직장인 연간근로시간과 오픈소스 활동의 관계에서 국가별 평균 근무 시간과 오픈소스 활동량의 상관관계가 있음을 알 수 있다. 의외로 우리 못지않게 영어 못하는 일본의 경우 인구를 감안하더라도 우리보다 훨씬 오픈소스에 적극적임을 알 수 있다. 하지만 상관관계가 항상 가정했던 대로의 인과관계를 의미하진 않는다. 과연 우리나라에서 직장에 다니는 프로그래머들이 시간이 적어서 오픈소스 활동에 기여하지 않는 것일까? 술마시는 시간은 그래도 꽤 되는데? 그다지 시간이 적다고 할 수 없는 대학생들은?
우리나라 사람들이 별로 이타적이지 않은 것은 아닐까? 다들 자기 잘 살기 위해 열심이다보니 경쟁이 치열하여 평균 근로시간도 길고, 오픈소스 활동도 저조한 것은 아닐까.
29 Oct 06 Defragmentation
NTFS는 FAT[32]보다 fragmentation이 덜 생기는 것으로 알고 있었고, 요즘엔 어차피 하드 디스크의 속도도 빠르고 캐시도 크기 때문에 fragmentation에 대해 그다지 신경쓰지 않고 살고 있었다. 나온지 10년이 꽤 넘었으니, 이젠 특별히 디스크를 여유없게 쓰거나 tmp 파일을 많이 만들거나 하지만 않으면 NT 커널이 어느 정도는 defrag를 알아서 해 줄 것으로 생각하고 있었다. 컴퓨터를 사용하려면 config.sys 정도는 알아서 관리할 수 있어야 했던 20세기가 아니지 않은가!
I was wrong.
나는 회사 노트북과 집의 PC간에 unison file synchronizer를 이용하여 몇 GB 정도의 데이터를 동기화하고 있었는데, 지난 주 출장 다녀온 후 그동안 밀린 동기화를 집의 네트웍 내에서 하면 금방 할 수 있을 것으로 생각했다. 그런데 내부 IP 주소로 연결했는데도 시간이 꽤 걸리는 것 아닌가? 더군다나 집 PC의 하드디스크가 엄청나게 버벅이는 소리를 냈다. 180GB 중 절반 가까이가 남아있는 파티션이었기 때문에 defrag를 할 필요가 없으리라고 생각하고 있었지만 그래도 한번 해보았더니, 웬 걸, 많은 파일들이 수백, 많으면 천개 이상으로 fragmentation 되어 있었다. 디스크가 여유가 많은데도 왜 이렇게 fragmentation이 심할까 하고 봤더니 대충 다음의 프로그램들에 의해 생성된 파일들이었다.
공통점은 네트웍 혹은 인코딩 속도 때문에 긴 시간 동안 크기가 큰 파일을 write하는 프로그램이라는 점이었다. NTFS가 copy처럼 미리 파일 사이즈를 알 수 있는 경우에는 fragmentation을 여간하면 발생시키지 않지만 최종 크기를 모르는채로 파일을 생성하여 긴 시간 동안 write하면서 동시에 다른 파일을 write하면 fragmentation이 많이 발생하는 것 같았다.
XP에 기본으로 포함되어 있는 “조각 모음”을 사용하니 defrag 하는데 시간이 너무 많이 걸려서 중간에 중지하고 diskeeper의 trial 버전을 사용해봤다. diskeeper 로도 꽤 시간이 걸리기는 했으나, 일단 defrag 되고나니 하드 디스크에서 발생하는 소리가 훨씬 줄어들었다는 것을 금새 알 수 있었다. 예전의 명성만 믿고 별 생각없이 구입했던 시게이트 바라쿠다 하드가 너무 소음이 크다고 생각하고 있었는데, defrag를 하는 것 만으로도 이많큼 소리가 줄어들 줄은 몰랐다.
Diskeeper 덕에 문제를 해결하긴 했는데, 이걸 계속 사용하기 위해 구입을 할까 고민하다가 (home version은 그다지 비싸진 않지만, XP의 “조각 모음”과 기능이 많이 달라보이지도 않았다. 하지만 “조각 모음”은 가끔씩 수동으로 돌려줘야 했다) 좀 찾아보니 defrag.exe라는 같은 기능의 command line version이 XP에 포함되어 있다는 것을 알았다. 결국 아래와 같은 batch 파일을 “예약된 작업”에 등록해두고 몇 주 후 다시 증상을 볼 예정이다.
@echo off echo Defragmentation Starting... > autodefrag.log defrag c: >> autodefrag.log 2>&1 defrag d: >> autodefrag.log 2>&1 defrag e: >> autodefrag.log 2>&1
26 Apr 06 Code Monkey
Code Monkey: (Wikipedia)
- A person only capable of grinding out code, but unable to perform the higher-primate tasks of software architecture, analysis, and design. Mildly insulting. Often applied to the most junior people on a programming team.
- Anyone who writes code for a living; a programmer.
- A self-deprecating way of denying responsibility for a management decision, or of complaining about having to live with such decisions. As in “Don’t ask me why we need to write a compiler in COBOL, I’m just a code monkey.”
Code Monkey란 대략 “단순히 코딩만 할 수 있는 프로그래머”라는 좀 프로그래머를 비하하는 은어. Code Monkey라는 노래를 (링크된 글의 본문 바로 아래에 MP3 파일이 링크되어 있음) 소개한다. 아래는 가사인데 아마 한번이라도 프로그래머로 일해본 사람, 특히 젊은 남자라면 노래 들으면서 가사 읽으면 (리스닝이 되면 읽을 필요 없겠지만^^) 가슴이 뭉클할 듯.
(more…)
26 Apr 06 Windows Powershell… Untrusted Publisher
마이크로소프트의 .NET 기반 OO shell인 Power Shell (구 Monad)의 RC1 버전이 나왔다길래 받아서 설치해봤는데, 처음 실행했을 때 나오는 메시지를 보니… (클릭하면 크게 보임)
마이크로소프트는 스스로를 신뢰할 수 없는 회사라고 생각하는 모양이다. 
23 Oct 05 C#에 대한 Hejlsberg의 인터뷰
O’Reilly 사이트에 올라온 C#에 대한 Hejlsberg와의 인터뷰. Hejlsberg(어떻게 읽는거지?)는 물론 C#의 chief architect이고 그 유명한 터보 파스칼과 델파이을 개발했으며 .NET에서도 중추적인 역할을 한 인물. Channel 9에 올라온 LINQ에 대한 최근 인터뷰 비디오를 보면 선입견을 갖고 있어서인지는 몰라도 인상에서부터 천재성이 배어나오는 듯 하다.
C#에 대한 인터뷰를 보면 프로그래밍 언어에 대한 그의 철학을 대충 볼 수 있는데, 나는 아직 C#으로 본격적인 프로그래밍을 해본 적은 없지만 Java를 써본 경험에서 알고 있는 문제점들을 C#에서 해결하는 것을 보면, 또 C# 2.0에서 도입된 강력한 기능들이 LINQ에서 어떻게 활용되는지를 보면 역시 그의 철학에 고개가 끄덕여지지 않을 수 없다.
Java가 그동안 라이브러리를 많이 확장하면서도 VM이나 바이트코드 레벨의 호환성을 놀라울 정도로 안정적으로 유지해온 것이 Java의 가장 큰 장점 중 하나이긴 하지만, delegation에 대한 Sun의 주장을 읽다보면 C#/.NET이 아니었다면 지금쯤 Java도 delegation이 도입되었을 것을 근거가 약한 논리로 고집부리고 있는 것 아닌가 하는 생각이 든다.
C#과 .NET은 Hejlsberg가 MS JVM과 WFC를 개발한 경험을 바탕으로 했기에 Java의 단점과 한계를 너무나도 잘 알고 이를 모두 매우 clever한 방법으로 보완하고 있는 것으로 보인다. 물론 후발주자가 이런 면에서 유리할 수 밖에 없지만 MS의 숙명적 한계인 업계의 반감과 불신, 그리고 아직 충분히 숙성되지 않은 VM의 완성도를 보면 C#/.NET이 지금 시점에서 꼭 유리한 것만은 아닌 듯하다. 그렇기는 해도 10년 전 MS가 낡아빠진 Win32와 x86 호환성에 묶여 있을 때 Sun에서 Java로 치고 나온 것처럼, Sun이 Java의 호환성과 WORA (Write Once, Run Anywhere)에 묶여 있을 때 MS에서 .NET, Avalon등의 강력한 기술을 포함하는 WinFX을 내놓는 것을 보면 입장만 서로 바뀐 역사의 반복이 아닐 수 없다.
08 Feb 05 Eclipse와 Firefox의 Swapping 문제
몇주 전 회사의 동료가 추천한 Eclipse의 plug-in을 이제야 써봤다.
예전부터 Eclipse를 minimize해두었다가 사용하려고 할 때 많이 버벅거리는 것이 Windows NT/2K/XP의 가상 메모리 관리 방식 및 Java의 메모리 관리 방식과 관계가 있는 줄 알고 있었지만, 그걸 plug-in으로 해결하는 방법이 있는 줄은 몰랐었다. 이 plug-in의 저자에 따르면
The performance of Eclipse (and other large Java applications) has long suffered due to the Windows virtual memory manager. Windows has a tendency to preemptively swap Java processes out of physical memory, even when there is still plenty of physical memory available. This interacts very poorly with Java processes, which do not have good locality and touch a lot of memory. The problem is exacerbated when Java performs garbage collection, which causes the Java process to touch lots of memory that has been paged out to disk. Ever had Eclipse randomly hang for 15-20 seconds? This is most likely the culprit.
Kernel과 GUI가 분리되어 있는 UNIX와는 달리, Win32 계열의 커널에서는 프로그램이 minimize될 때 이 프로그램의 working set을 OS가 알아서 최소화시켜 버리기 때문에 약간의 파일 I/O만으로도 이 프로그램이 사용하던 메모리가 모두 discard되어 버리고, 이 때문에 프로그램이 다시 restore/maximize될 때 버벅거리는 것이다. Java의 경우엔 더군다나 클래스 파일, JIT된 네이티브 코드 및 오브젝트가 메모리에 여기 저기 흩어져 있고 특히 garbage collection이라도 하게 되면 전체 virtual memory를 다 랜덤 액세스하게 되므로 demand loading의 performance가 매우 나쁘게 되어 차라리 다시 띄우는 것이 더 나은 경우도 많게 되는 것이다.
Windows의 작업 관리자에서 “최고 메모리 사용률”을 보이게 하고 Eclipse의 javaw를 선택한 후 Eclipse를 minimize해보면, “최고 메모리 사용률”은 그대로 있지만 “메모리 사용”은 많이 줄어드는 것을 볼 수 있는데, 위의 plug-in을 설치하고 나면 “최고 메모리 사용률”이 유지되는 것을 볼 수 있고, 충분히 체감도 할 수 있다. 하지만 working set을 유지하기 위해 VirtualLock()을 사용하는 것은 메모리가 충분하지 않은 컴퓨터에서는 전체 시스템의 성능에 많은 영향을 줄 수 있으므로 주의해서 사용해야 할 것 같다.
NT 커널의 virtual memory가 swapping하는데 FIFO 알고리즘을 사용하기 때문에 성능이 좋지 않다는 얘기는 예전에도 들은 적이 있지만, 다른 대부분의 애플리케이션에서는 큰 문제가 안되기 때문에 꼭 OS만의 문제라고 치부하기는 어렵다. 마이크로소프트의 관련 설명을 보면 이를 피해가는 방법이 있는데 Sun에서는 Java 5.0에 와서야 선택적으로 이 방법을 사용할 수 있게 했다(System property sun.awt.keepWorkingSetOnMinimize=”true”. AWT가 아닌 SWT를 사용하는 Eclipse에는 적용 안됨). Eclipse나 다른 Java 기반의 프로그램 외에 Mozilla/Firefox의 경우에도 비슷한 문제가 있는데, 관심있는 사람들은 좀 길긴 하지만 이 bugzilla entry를 보면 많은 걸 배울 수 있다. 해결책에만 관심있는 사람은
- Mozilla/Firefox의 주소 필드에 about:config를 입력하고,
- 이 창에서 마우스 우측 버튼을 누른 후 “New”를 선택
- “Boolean” 타입을 선택하고
- Preference 이름으로 config.trim_on_minimize를 입력한 후 값을 false로 지정
- 브라우저를 재시작
하고 Eclipse의 경우와 마찬가지로 작업 관리자에서 메모리 사용량을 확인해보면 차이를 볼 수 있다.
MS에서 비록 선택적으로 피해가는 방법을 제공하고 있기는 하지만, 이러한 문제의 원인과 해결책을 별로 열심히 알리고 있는 것 같지는 않고 또 OS 레벨에서 이런 문제를 해결하기 위한 대책을 적극적으로 강구하는 것 같지도 않다. 이 문제의 가장 많은 영향을 받는 애플리케이션이 Java와 Mozilla/Firefox라는 것은 단순히 우연일까? 하인라인이 “Never attribute to malice which can be explained by stupidity.”라고 했다지만 그게 Microsoft에도 적용되는 얘기일까? 사회 생활을 하다보니 오히려 “무지를 가장한 악의”도 많이 눈에 띄는 것 같다.
추가: 이상하게 이 글에만 자꾸 스팸 덧글이 붙어서 덧글 막습니다.
18 Dec 04 Google Suggest의 분석
Google Suggest Dissected… Gmail과 더불어 JavaScript/XMLHTTP 기술의 극한을 보여주는 Google Suggest의 메카니즘을 분석한 글이다. 조금이라도 더 빠른 응답시간을 얻기 위해 Google의 엔지니어들이 얼마나 머리를 쥐어짰는지 대충이나마 알 수 있다. 너무 일찍 브로드밴드 인터넷이 일반화되어 버리고 quick & dirty 웹사이트가 판을 치는 우리나라에선 이런 기술을 추구할 이유도 없고 그럴 여건도 안되지만, 기질이 있는 엔지니어라면 항상 어디까지 갈 수 있는지 추구해보고 싶기 마련이다 (월급만 나오면!).
이런 기술을 보다 보니 몇 해 전, N사의 WAP 브라우저를 포팅하는 프로젝트에서 비슷한 일을 하려했던 것이 기억난다. 그 때 경쟁 브라우저와 차별화 포인트의 하나로 tree 태그를 추가 구현한 후 XMLHTTP와 비슷한 방법에 의해 페이지 전체를 reloading하지 않으면서 subtree가 더해질 수 있도록 하려 했었는데 N사의 브라우저가 너무 작은 메모리에 최적화되어있어 DOM을 제대로 지원하지 않는 바람에 포기했었다. 그 프로젝트는 결국 여러가지 이유로 상용화되지 못했지만, 이런 류의 기술은 bandwidth가 제한된 무선 인터넷 브라우저에서 더 쓸모가 많을 것임에도 불구하고 ECMAScript를 지원하는 브라우저가 속속 실용화되고 있는 지금에도 아직 무선 인터넷쪽에선 사용되지 않고 있다.
브라우저의 bookmark, back & forward, reload등의 기능이 항상 기대하는 대로 동작하던 시절은 frame과 cookie가 등장할 때부터 이미 지나갔지만, JavaScript와 XMLHTTP의 적극적인 사용은 그런 경향을 더욱 가속화할 것이다. XAML에 의한 사이트는 로컬 애플리케이션과 사실상 구분이 되지 않을 것이다. 보다 나은 usability를 추구하는 노력들이 웹을 그토록 빨리 확산시키는데 일조했던 단순함과 일관성을 해치게 되지는 않을까?
24 Nov 04 Language Oriented Programming
Language Oriented Programming: Java IDE로 유명한 IntelliJ의 Sergey Dmitriev가 메타프로그래밍에 대한 자신의 생각과 현재 개발중인 툴에 대해 쓴 글. LISP이래로 메타프로그래밍에 대해 많은 시도가 있었으나 아직까지 메인스트림에서 성공한 경우는 없었다. 이 글에 대한 Martin Fowler의 Bliki에서도 앞으로 몇년동안 지켜봐야 할 분야라고 말하고 있지만, 과연 몇년 내에 큰 변화가 있을까. 90년대 말이었던 것 같은데, 메타프로그래밍이 뭔지 모르는 선배에게 한참 개념을 설명한 후 10년 후면 그 당시의 OOP만큼이나 중요한 개념이 될 것이라고 얘기했던 기억이 나지만 지금은 정말 그렇게 될 지 자신이 없다. 사실 industry에서 보면 OOP조차도 제대로 쓰는 사람이 많지 않은데 이들에게 하나의 dimension을 더 이해하라고 하는 것이 무리라는 생각도 든다. 하지만 J2SE 5.0에 annotation processing을 위한 툴이 표준적으로 포함되어 있고 Eclipse 프로젝트에서도 AspectJ가 진행되고 있으며 IntelliJ와 같이 많이 사용되는 툴 메이커에서도 메타 프로그래밍을 도와주는 툴을 내놓는다면, 예상하지 못했던 방식으로라도 메타프로그래밍이 실용화될 수도 있지 않을까? 구체적으로 예상하긴 어렵지만, 예를 들어
- LaTeX의 경우처럼 Domain Specific Language package를 전문가들이 만들면 일반 프로그래머들은 사용만 하는 시스템
- OO 개념을 visual tool에서 쉽게 사용하게 해주는 것처럼 MP를 제한적이지만 쉽게 사용하게 해주는 툴
등이 나올 수도 있지 않을까.
21 Nov 04 Avalon CTP, Java Mustang SR
Microsoft Avalon의 CTP(Community Technology Preview)와 Java “Mustang” (J2SE 6.0)의 Snapshot Release가 발표되었다. Avalon CTP는 XP에 설치할 수 있다고 해서 한번 깔아보고 싶었는데, 관련 기사의 끝부분을 보고 관두기로 했다.
… the company warns customers not to use it even on a primary development computer, with there being every likelihood of bugs and a pretty good chance developers will want to reinstall their system once they’re done using the Avalon preview.
Mustang은 Tiger만큼 많은 기능이 더해지진 않을 듯 하다. JSR-121이 포함되는지 궁금했는데, 아마 이번에도 어려울 듯 하다. Mustang과 JSR-121을 Google에서 함께 검색하니 재밌는 페이지가 나온다. JSR-121의 Isolation API가 CDC/CLDC도 타겟하고 있다는 얘긴데, 아직 J2SE에도 언제 포함될 지 모르는 기능이 CLDC도 함께 타겟하고 있다는 것이 의외일 수도 있지만, SavaJe에서 볼 수 있듯이 Isolation 기능이 서버보단 오히려 휴대폰에서 더 필요할 수 있다는 점에서 예상할 수 있었던 일이기도 하다.
