Life is not that easy.

예전 수업 시간에 한 교수님이 종종..

Life is not that easy.

라는 말을 해서 학생들을 웃기곤 했는데 정말 세상 일은 그리 간단한 것이 없다.

요즘 하는 일이 프로파일링 툴을 만드는 일이다. 그런데 이 프로그램은 매우 많은 시간과 또 매우 많은 메모리를 소비한다는 치명적인 단점이 있다… 아놔…

그래서 최적화를 해야만 했다. 사실 어디를 최적화 해야 하는지는 직관적으로 알 수 있었기에 그걸 잡고 시도하였다. 아이디어도 간단하다. 시간은 어떻게 버티면 되는데, 메모리는 대책이 없으므로 (여기서 많은 메모리를 쓴다는 것은 5GB, 8GB 뭐 이런 걸 말한다 –_-. 32비트에서는 돌아가지도 않으며 8GB 머신에서도 종종 뻗는다) 메모리 줄이는데 주 목적이 있었다. 그리고 직관적으로 이걸 통해 당연히 시간도 줄일 수 있으리라 굳게 믿었다. (일반적인 알고리즘에서는 속도와 메모리는 거의 반비례 관계에 있다. 그러나 나 같은 경우는 어느 정도 까지는 메모리를 줄이면 속도도 개선할 수 있는 여지가 있었다. 특히 메모리를 8GB 이렇게 쓰는 경우, 수 많은 페이지 폴트가 발생해서 전체 수행 시간의 1/3이 커널 시간으로 허비되었다. 수 메가 정도의 메모리를 끊임없이 할당했다 해제하다보니 페이지 폴트가 발생하는 것이다. 만약 메모리를 1/20 수준으로 줄여 1GB 미만으로 줄인다면 아낄 수 있는 시간이 상당하다.)

그런데 실제 구현은 생각보다 매우 어려웠다. 기존 알고리즘의 핵심 코드가 채 2천 라인도 되지 않았는데 이 최적화를 구현해버리니 6천 라인은 족히 넘어 버렸다. 자료 구조 형태가 바뀌다 보니 핵심 알고리즘을 전부다 수정해야 했으며, 이 과정에서 생각 못 했던 예외 사항이나 버그를 잡느라 엄청 고생했다.

버블 소트는 간단하다. 너무 간단하다. 그런데 시간이 매우 오래 걸린다. 그런데 이 보다 훨씬 복잡한 퀵 소트 알고리즘은 시간을 크게 줄일 수 있다. (그러나 메모리를 더 써야 한다) 이런 경우는 알고리즘에서 흔히 찾아볼 수 있다. 간단한 최소 힙은 정말 간단히 배열로 대충 만들 수 있다. 그런데 탐색 속도를 개선하려고 여러 아이디어가 도입 되는데 그 중 피보나치 힙은 정말 복잡하다.

나도 이런 것을 믿었다. 개고생을 하지만 결국 메모리와 속도를 동시에 잡을 수 있으리라 희망에 찼다. 그러나 결과는 참담하다. 메모리를 아끼기는 아끼는데 고작 두 배 정도 밖에 안 된다. 그리고 시간도 줄지 않고 보통 나빠지거나 겨우 같아진다. 메모리를 좀 더 아끼려고 파라미터를 조작하면 시간은 매우 나빠진다. 여기서 매우는 한 10배 더 느려진다는 소리. 원래 알고리즘으로도 5시간 씩 걸리는 건 다반사... 여기서 또 곱하기 10하면??!!

역시 세상에 쉬운 건 없다. 예전 수업 시간에 교수님이 저 말씀을 외칠 때는 그저 웃기기만 했는데..

 

논문 마감이 일주일 남았는데 그냥 암울 그 자체. 이승엽은 단 10일 만에 타율을 1할이나 높였다.

나에게도 이런 기적이 찾아올 확률은 없.. 다. 그나마 요즘 이승엽 야구 보는 재미로 살고 있음.

아.. 이렇게 자막과 함께 초고화질 동영상 올려주시는 분들에겐 그저 감사의 말씀만을.. 감동의 화질.. HD를 누르고 전체 화면으로 보면 감동입니다.

by object | 2009/05/15 18:23 | 나머지 | 트랙백 | 덧글(23)
트랙백 주소 : http://minjang.egloos.com/tb/2318566
☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]
Commented by Ya펭귄 at 2009/05/15 19:04
전 졸업후에도 논문은 끝내고 가라는 교수님의 간곡한(...)설득에 반년을 lab에서 더 버티고 있었지요....
Commented by object at 2009/05/15 19:20
그래서 돈이라도 받고 일하셨는지... 아.. 한국은 그런거 없지..
Commented by 혈견화 at 2009/05/15 19:38
이승엽의 유니폼을 보고
이승엽이 한국 롯데 자이언츠에서 뛰면 얼마나 좋을까,
그런데 왠 낯모르는 여인이 낙동강에서 빨래를 하고 있는,
그 모습이 왠지 친숙한 그런 느낌을 받았습니다.
Commented by object at 2009/05/15 19:51
요즘 한국 야구는 롯데를 응원하고 있습니다만;;
Commented by 아라크네 at 2009/05/15 19:49
프로파일러를 만들다 프로파일링을 해야 하는 상황이 올 것 같군요.
Commented by object at 2009/05/15 19:51
컴파일러를 만들려면 컴파일러가 필요하고
디버거를 만들려면 디버거가 필요하고
프로파일러를 만들려면 또 프로파일러가 필요하더군요..
Commented by 몽몽이 at 2009/05/15 21:51
차라리 메모리를 더 쓰고 시간을 단축하는 쪽으로 목표를 잡으셨더라면 어찌 됐든 결과는 나왔을거라고 보는 1人
Commented by object at 2009/05/17 03:36
메모리를 줄이는게 결국 시간을 아끼는 경우라.. 쉽지 않군요.
Commented by 귀여운 동생님 at 2009/05/15 23:09
자꾸 이케아 가자 그래서 미안하다 -_- 열심히 잘 마무리 해봐라 ㅠㅠ
Commented by xeraph at 2009/05/15 23:48
이것 참 암울한 얘기군요 (..) 노가다는 미칠 것 같아도 결과라도 나오는데 이건 뭐 (....)
Commented by object at 2009/05/17 03:35
개발과 연구의 차이가 그거인 것 같습니다. 해도 잘 될지 안 될지도 모르고.
Commented by felucca at 2009/05/16 01:05
마이크로 고고씽?
Commented by object at 2009/05/17 03:35
암울한 상황.
Commented by fuhaho at 2009/05/16 12:48
메모리 사용량 반으로 줄인거만 해도 대단한듯
Commented by object at 2009/05/17 03:36
그렇게라도 위안을 삼으려고 합니다 ㅎㅎ 사실 간단한 프로그램에서는 1/10까지도 줄이는데..
Commented by 김정은 at 2009/05/16 22:33
예전에 검색엔진 만들때 초기 버젼은 3개월 걸렸는데 이거 속도 향상 시킨다고 몇년을 삽질 했는지 ;;;;

저도 이제 논문 써요 ^^ 이거 생각보다 어렵더군요...

좋은 결과 기대 해봅니다.



Commented by object at 2009/05/17 03:36
프로토타입과 정말 잘 돌아가게 만드는 건 하늘과 땅 차입니다..
Commented by null-e at 2009/05/17 01:00
제가 다녔던 학교 kms 교수님도 그런 말을 하셨어요.
인생 사는게 워낙에 피곤해서 바로 이해 되었죠.
안 그래도 피곤한데...
이젠 수학이 싫어졌답니다.
Commented by object at 2009/05/17 01:11
네.. 저도 kms 교수님으로부터 그런 말을 들었습니다.. 수업 한 3개 들은 거 같군요.
Commented by 모루 at 2009/05/17 21:21
메모리를 줄이면 속도가 빨라진다고 하셨는데 보통은 메모리 크기와 속도는 반대로 움직입니다.
차라리 메모리를 두 배로 늘이고 알고리즘을 명확하게 하는 쪽이 더 좋을지도 모릅니다.
메모리는 싸거든요. 계속 가격이 떨어지고 있고.
매번 전체 메모리를 트래버스 해야 하는 상황이 아니면 힙을 만드는 것보다는 동적인 해쉬를 이용 하는 것이 더 빠릅니다. 메모리 효율은 나빠지지만 전체 메모리 사용량이 예측 가능하면 해쉬가 더 좋습니다.
Commented by object at 2009/05/18 04:20
말씀대로 일반적으로 메모리와 속도는 절대적으로 반비례 관계에 있지요. 저도 잘 압니다. 그런데 메모리 사용이 4GB, 6GB 이렇게 올라가면 페이지 폴트 빈도가 너무 높아져서(minor page fault) 전체 수행 시간 중 커널 시간으로 허비되는게 1/3이나 됩니다. 물론 4GB/8GB라도 메모리를 한번 할당하고 계속 쓰면 괜찮지만 저 같은 경우는 몇 메가를 할당하고 해제하는 것이 매우 빈번하다 보니 페이지 폴트가 많이 생깁니다. 따라서 이런 경우는 메모리 사용율을 크게, 대충 1/20 이상 줄이면 페이지 폴트가 줄어 시간 역시 벌게 됩니다. 메모리가 줄면 속도가 빨라진다는 건 일반적인 이야기가 아니라 제 경우에 한정된 이야기입니다. 제가 구현한 것도 메모리 500MB 쓰는 것을 200MB로 줄이면 속도가 몇 배 늘어난답니다.. 그러나 메모리 사용이 수 기가 급이 되면 상황은 좀 달라집니다. 그래서 일단 얻은 것은 메모리를 1/10 이상 줄이고 시간은 기존과 비슷한 수준까지 맞췄습니다. 물론 아주 작은 미니 벤치는 메모리 속도 모두 개선됩니다만..
Commented by kalstein at 2009/05/21 17:47
근데요....1GB 이상으로 쓰면 어차피 page fault는 많이 발생할 것으로 보입니다만. 2기가를 쓰나 4기가를 쓰나 별 차이가 없을꺼 같아요;;;; (일반적인 상황이 아니므로...)

근데 어떤거 하실길래 그렇게 엄청난 데이터가 필요하신가요? -ㅁ-;;;;
Commented by object at 2009/05/22 05:31
예를 들어, 컴파일러가 인터프로시져 어낼리시스를 하고 거기서 자동병렬화/벡터라이제이션 하고 그려면 좀큰 프로그램일 땐 메모리 1~2기가를 쓰는게 우습습니다. 이처럼 프로그램을 분석하는 건 일반적으로 탐색 공간이 매우 커질 수 있어서 메모리를 많이 쓰는 것이 일반적입니다. 저는 동적 분석이라 메모리를 네이티브프로그램보다 수십배 이상 쓰는 게 그리 놀랄 일은 아니죠. 50MB 쓰는 프로그램을 동적 분석해버리면 5GB까지도 손쉽게 먹을 수 있습니다. 예를 들어, 각 메모리 접근마다 100바이트씩 정보를 할당해서 저장한다면..충분히 가능한 이야기죠.

:         :

:

비공개 덧글

<< 이전 페이지 다음 페이지 >>





by 김민장 2008 이글루스 TOP 100
최근 등록된 덧글
개발자 입장에서의 수많은 ..
by Jiyoon at 02/04
저도 아들 돌잔치때 돌잡이 ..
by 박상욱 at 01/18
미국 대학원 원서 작성중에 p..
by 태클사이야 at 01/13
TO: 박PD 로그인 하지 않아..
by 박응용 at 01/10
http://gigglehd.com/zbx..
by dhunter at 12/28
우와.. 좋네요. 태반이 ..
by 윤광배 at 12/17
항상 좋은 글 잘 보고 있습니..
by y2k at 11/23
글이 좋아서 제 블로그에 담..
by 쏭섭 at 11/23
최근 등록된 트랙백
조엘 스폴스키의 강연 (Sta..
by 인덕원칸타타
[Redis] sds.c를 분..
by 조급하지말고 천천히
메뉴릿
이글루 파인더

website counter

Add to Google

rss

skin by 이글루스