OpenLook

요새 IRC의 jiwon님이 VM 관련 수업을 들으시면서 이것 저것 많이 알려주셔서 VM 관련 논문을 여럿 읽고 있습니다. 어제는 퇴근길(일요일!)에 뭐 볼 만한 것 없을까 찾다가 Are CLI-based Virtual Machines Suitable for High Performance Computing？이라는 논문을 읽었습니다.

이 논문은 주로 대규모 수치연산이나 데이터 처리에 사용되는 환경으로 직접 C나 Fortran처럼 네이티브 코드를 생산하는 컴파일러를 사용하지 않고, Java나 CLI같은 가상 기계 환경을 사용하는 경우도 쓸만한가에 대해 논하고 있습니다. 사실 그런데, 이 얘기를 듣기 전까지는 그 비싼 기계를 네이티브 코드로 안 돌리고 VM 코드로 돌릴 사람이 있을까 생각하긴 했는데, 진지하게 Java로 돌리고 그러는 커뮤니티도 있고 그렇군요 -ㅇ-;

처음 몇 섹션에서는 CLI와 CLI구현들에 대한 소개를 하고 있는데 상당히 일반적인 소개라서, HPC에 관심이 없는 사람이라도 읽어볼 만합니다. 그 다음에는 본격적으로 Java, CLR, SSCLI, Mono 넷을 벤치마크 하고 있습니다. 주요 수치 연산들과 알고리즘, SciMark등을 선보이고 있는데, 이 논문이 쓰여질 당시 (작년)에는 아직 mono가 최적화가 완전히 진행되지 않아서인지, 정수 연산, 기본 수학 연산에서 Sun JVM과 CLR에 한참 뒤져 있고, CLR이 대체로 Sun JVM을 약간씩 앞서는 퍼포먼스를 내고 있군요. SSCLI은 예상외로 선전을(..;)해서 mono하고 비슷하군요. 흐흐 사실 SSCLI는 그렇게 느려서 쓸 사람이 있을까 생각을 했는데..; 성능을 테스트할 수 있는 여러가지 수학적 알고리즘을 수행하는 SciMark에서는 IBM JVM이 제일 앞서고 근소한 차이로 MS CLR이 간혹 몇군데에서는 앞서기도 하고 있습니다. Sun JVM은 많이 차이나는 것도 있고 비슷한 것도 있고 그러고 있고, mono는 마냥 느리군요. -ㅇ-; 그런데, 상당히 놀라운 것은, SciMark의 FFT 시험같은 경우에는 IBM JVM, MS CLR은 C로 구현된 것보다 더 빠르기도 하고, 상당수의 알고리즘들이 70%정도는 유지하고 있다는 것입니다. VM이라고 엄청나게 느린 것은 아니군요..

글쓴이의 평가에서 Mono가 MS CLR에 비해 이렇게 느린 결과가 나온 것은 IL 코드와 생성된 x86 어셈블리 코드를 비교해 보면 Mono는 거의 1:1로 변환되어 최적화된 흔적이 아주 적은 반면에 MS CLR 코드는 상당히 많이 최적화되어 있어서 IL코드와 x86 어셈블리 코드가 1:1로 매칭이 잘 안 되는 정도라고 합니다. 그래서, 결론적으로는 과학 계산에 결정적인 영향을 미치는 것은 C# -> IL 사이의 최적화라기 보다는 IL -> native 사이의 최적화가 결정적인 영향을 미친다는 얘기인 듯 합니다. native 코드로 JIT 번역은 사실 parrot이나 DotGNU의 libjit, GNU lightning같은 경우만 보더라도 그냥 바이트 코드 읽어서 1:1 emit 하는 경우가 대부분이라, 사실상 최적화를 안 하고 있는 것이나 마찬가지인데 앞으로 JIT 디자인에서 좀 더 도전해 볼만한 요소인 듯 합니다.

며칠 전 블로그에서 김창준님의 추천으로 Enforcing Strict Model-View Separation in Template Engines이라는 논문을 봤습니다. 이거 웹 프로그래밍으로 논문까지 쓰고.. 역시 연구하는 사람은 어디든 있군요~

그동안 써본 템플릿 엔진 albatross, DTML, HTML::Template::Sigma, Quixote PTL 이 다섯은 처음 쓸 때는 아주 신세계가 열린 듯한 기분이 들었다가도 쓰다보면 금방 답답함을 느꼈습니다. 그 이유를 대충 정리해 보자면,

• albatross: HTML 태그 형태로 명령을 지원하는데 태그와 본문 간의 간격을 줄이기 위해서 어트리뷰트를 더 쓴다던지 하는 아주 지저분한 트윅이 필요하고, 특히 루프 돌릴 때 루프 변수를 조작하기가 매우 까다로워서 템플릿에 코딩까지 해야할 정도.

• DTML: 알바트로스보다는 훨씬 깔끔한 루프 변수를 지원하고, 여러모로 디자인이 잘 된 HTML 태그 모양의 템플릿이긴 하지만, 템플릿 쪽에서 제어 코드를 넣어야지만 처리가 가능한 경우가 너무 많다.

• HTML::Template::Sigma: 아주 단순한 블럭, 인클루드를 만을 지원하는 언어라, 진짜로 템플릿에는 데이터만 들어갈 수 있도록 만들어 주기는 했지만, 너무 단순해서 에러 보고가 제대로 안 되는 바람에 에러가 나면 제대로 잡기가 거의 불가능. -O- 일일이 하나하나 다 바꿔가며 디버깅을.. ㅠ.ㅠ

• Quixote PTL: 템플릿 언어계의 반항아! 다른 템플릿 언어들과는 완전히 다른 위젯 개념으로 코드가 템플릿을 감싸 안는 방식을 채택했다. 굉장히 혁신적이고 신선하긴 하지만, 아무래도 템플릿에 코드가 덕지덕지 붙은 이상은 디자이너들한테 쓰라고 하는 것은 불가능한터라, 개발자가 만들어서 개발자들만 보는 관리 프로그램등에나 쓸 수 있을 듯.

흐흐~ 그래 웹 프로그래밍은 다 이런거야 하고 좌절을 하고 있었는데, 이 논문을 보고 원래 다 그런 건 아니구나 하고 실낱같은 희망을 얻게 되었습니다. 이 논문에서는 템플릿에서 완전히 로직을 제거하는 게 단지 이상향으로만 존재하는 게 아니라는 것을 여러가지 증명으로 보여주고 있는데, 실제로 템플릿에 마구 로직이 섞여서 결국은 디자이너들이 감히 템플릿에 손을 못 대도록 만드는 문제의 원인이 템플릿 언어들이 파워를 잃어버릴까봐 템플릿 언어 안에 코드를 섞어 쓰는 것을 허용하는 것 때문이라고 합니다. 실제로 대부분의 템플릿 언어에서는 테일러 급수로 sin(x)를 전개하는 것이 가능하다는군요. (-ㅇ-;) 그래서 머피의 법칙 “if it can be done wrong, it will be done wrong,”에 의해 결국은 마감에 쫓기는 코더들은 임시 방편으로 코드를 마구 복사해서 여기저기 템플릿에 붙여서, 다음 개발자가 로직을 고칠때 여기저기 흩어져 있는 것을 일부 고치다가 뻑나서 다같이 망하거나, 디자이너가 디자인 고치다가 로직이 같이 뻑나거나 이런 상황이 올 수 있다고 합니다. 흐흐흐;

그래서, 저자는 템플릿 언어 차원에서의 로직과 템플릿의 강제적인 분리를 이렇게 강조하고 있습니다.

• 캡슐화: 사이트 모양은 완전히 템플릿에 있고, 로직은 모두 데이터 모델 (코드)에 모두 있다. 각각은 완전한 별도의 개체다.

• 명료성: 템플릿은 HTML을 뽑아 내는 프로그램이 아니다. 템플릿은 디자이너와 코더가 바로 읽을 수 있는 HTML 파일일 뿐이다.

• 작업의 분리: 그래픽 디자이너와 코더의 개발은 병렬적으로 일어날 수 있어야 한다. 이렇게 작업이 분리가 되면 코더들이 디자인을 고치기 위해 신경 쓸 필요가 없고, 디자이너와 코더의 커뮤니케이션을 위한 비용이 현저히 줄어든다. 디자이너들은 프로그래머와 얘기하지 않고도 디자인을 마음대로 고칠 수 있다.

• 컴포넌트 재사용: 프로그래머들이 보통 명료성과 재사용성을 높이기 위해 큰 메쏘드를 작은 여러개의 메쏘드로 분리하듯이, 디자이너들도 템플릿을 여러개의 서브 템플릿으로 분리할 수 있다. 즉, 로그인 상태, 네비게이션바, 검색창, 데이터 목록 등등.. 코드가 템플릿에 얽혀있는 경우에는 리팩터링을 통해 분리하기 매우 어렵고, 재활용하기도 어렵다.

• 고칠 곳은 한군데만 (single-point-of-change): 템플릿을 정리함으로써, 디자이너들은 링크 목록, 사용자 기록 뷰같은 여러 개념적인 원소들로 템플릿들을 분리할 수 있다. 이렇게 돼서, 나중에 사이트의 공통적인 한 부분을 고치는 경우 진짜로 한 파일의 한 군데에서만 고치면 되게 된다. 이렇게 하면, 하나를 고치기 위해 여러 부분을 고치다가 뻑나는 경우를 피할 수도 있기 때문에 이것은 아주 중요하다. “관리자인가” 같은 로직은 여러개의 템플릿에서 항상 반복되기 때문에 템플릿 안에 로직을 넣는 것은 절대 피해야 한다.

• 유지보수: 사이트의 모양을 바꾸는 것은 템플릿만 바꿔야지, 절대 프로그램을 바꾸는 작업이어서는 안 된다. 프로그램을 바꾸는 것은 템플릿을 바꾸는 것에 비해 훨씬 위험한 작업이고, 템플릿을 바꾸는 것은 새로운 삶을 시작할 필요도 없다. (즉, 사용되고 있는 서버 애플리케이션을 재컴파일하거나 새로 띄울 필요가 없다.)

• 바꿀 수 있는 뷰: 몽땅 뭉쳐서 쓰는 데이터 모델에서는 디자이너들은 “스킨”이나 “테마”같은 기능을 지원하기 위해서 디자인을 직접 입힐 수가 없다. jGuru.com 사이트에서는 “그룹”이라고 불리는 템플릿 모듬이 있다. “그룹”은 단순히 색깔이나 스타일 시트를 바꾸는 정도가 아니라, 사이트의 전체적인 모양을 바꿀 수 있다. 이렇게 모양이 달라져도 단순히 코드에서는 한 가지 방법으로 데이터를 전달해 주고, 어느 템플릿을 사용할 지 정해주기만 하면 된다.

• 보안: 블로그 사이트들에서는 이제 템플릿을 사용자가 직접 바꿀 수 있는 것이 흔한 것이 되었다. Microsoft Word에서 매크로 쓰는 것처럼 템플릿의 제한되지 않은 기능은 매우 심각한 보안 결함이다. 블로그 템플릿에서 클래스 로더를 띄워버리는 여러 보안 사건이 일어난 이후 squarespace.com은 Velocity와 StringTemplate를 사용하기 시작했다. 가장 쉽게 생각할 수 있는 공격은 무한 루프다. 모델을 뷰에서 완전히 독립하고, 페이지 제어를 금지함으로써 보안성을 얻을 수 있다.

그 외에도 그동안 생각 못했던 여러가지 이유들이 들어있습니다. 웹 프로그래밍에 염증을 느껴보신 분이라면 꼭 한번 읽어보세요. –;

아으아. 최근엔 빠른 속도와 파일 이동이 가능하다는 점 때문에 회사에서 subversion을 쓰고 있습니다. 그런데, 이놈이 소문대로 워낙에 잘 깨져서, 5명이 쓰는 중 거의 1명이 하루에 한번씩은 복구해야할 정도로 DB관리가 정말 허술합니다. 그래도, 뭐 recover를 해 주면 영영 데이터를 잃어버리는 것은 아니기에 그래도 고맙게 쓰고 있었는데, 어제는 그야말로 일이 터졌습니다. DB가 깨졌길래 복구하려고 했더니만, 복구 프로세스가 족족 모두 행 돼버리는 것이었습니다. 게다가 프로세스를 죽여도 좀비가 돼버리고 –; 이런.. 이거 프로젝트도 바쁜데 버전 관리 시스템까지 문제냐~ 참.. 우흐..

그래서, 우선은 침착하게 DB를 다른 디렉토리로 복사해서 복구를 해 보니까 행은 안 되고 그런대로 복구는 되는군요. 아무래도 한번 깨진 DB는 계속 깨질 것 같아서. 덤프한 뒤에 다시 로드했습니다. (리비전이 900가까이 돼서, 복구하는데만 20분 -ㅇ-) 흐흐.. 근데 자세히 살펴보니까 마지막 리비전 하나가 날아갔더군요.. 이런! 그동안은 그래도 깨졌다고 마크만 되고 실제로 날아가지는 않았는데 이제는 ㅠ.ㅠ subversion 앞으로 fsfs가 나온다고 하니 기대는 해 보지만.. 이제는 무서워서 더 못 쓰겠네요 흑흑~

요즘 python-dev 메일링에서도 subversion얘기가 굉장히 많습니다. 역시나 다들 엄청나게 깨지는 버클리DB얘기를 하고 있는데, perforce는 다 DB에 넣는데도 탄탄한데 왜 subversion은 이모양 이꼴이냐 뭐 이런쪽 얘기가 역시 주를 이루는 듯 합니다. 어서 subversion이 perforce 반이라도 따라가길 –;

libgmail 프로젝트에서 gmail을 위한 smtp, pop3, ftp 프락시를 만드는 것을 보고도 상당히 충격을 받았지만, 오늘 #perky의 Burnhard님께서 보여준 이 프로젝트를 보고서는 패닉에 빠져서 ~( _-_)~

gmailfs는 리눅스와 SunOS에서 유저랜드측 프로세스에서 파일 시스템을 제공할 수 있게 하는 FUSE를 기반으로 구현된 gmail 파일시스템입니다. 그리고 당연히 구현은 파이썬으로 되어있지요~ 흐흐; 이것 만든 사람은 이틀밖에 안 걸렸다니 참, 이거 libgmail의 위력이란~

저자가 올린 스크린샷을 보면 아이고 ;_; 흐흐 FUSE가 BSD를 지원 안 해서, 테스트 못 해보는게 참 한입니다. ㅠ.ㅠ 이제 FreeBSD책도 나오고 했으니 파일시스템 부분을 공부해서 프비 portalfs 부활운동을..