JMK 트레이더 레벨 1. 스킬포인트 뭐찍지?

stream/

20 Nov 2009

stackless python: retlang 생각나는군요. 비슷함. 근데 이것도 결국 GIL ... 아....

19 Nov 2009

SRM441 연습

예전에 연습했더라도 홈페이지에 연습 로그가 없으면 다 한다는 각오로 돌고 있다. 자바로 돈 두번째 세트. 실제 알고리즘보다 코딩에 신경을 더 쓰게 되는 사태가... 연습방에서 이전에 내가 문제 푼 게 있는데, C# 으로 짜놨더라. 나도 레인보우 코딩 가나여...

(more)

SRM442 연습 (자바)

그제인가 돌았던 매치인데 IntelliJ 로 돌아보았다. 그전에는 넷빈즈랑 이클립스로 div2 한 라운드씩 돌았는데, 지금까지는 IntelliJ 가 제일 낫다. 유료인데다 비싸지만 회사에서 사준 라이센스가 있어서...

결론은 음 나름 할만하네.. 라는 것. 특히 950 은 무려 넷웍플로인데, 넷웍플로 클래스 안쓰고 그냥 짰다. ㅋㅋ 오랜만에 해보네 이런거 ㅋㅋㅋ

소스가 깔끔한 것은 좋다.

(more)

17 Nov 2009

Moving On From C++

다들 아는 얘기 반복 주의

C++ 을 지난 7년 동안 주력 (?) 언어로 써오고 있는데, 이제 바꿀 때가 되지 않았나 하는 생각이 요즘 새록새록 들고 있다. 어릴 때는 파스칼을 한참 썼었는데, 대학교에서 ICPC 하면서 다른 팀원들이 다 C 쓰니까 C 로 넘어왔고, C++ 는 C 나 파스칼보다 훨씬 자유로운데다 (무려... 변수 선언을 아무데나 할 수 있다. -_-;) STL 도 쓸 수 있어서 그 이후로 쭉 써오고 있다. 이노티브, nhn 에서도 모두 C++ 로 일했었고, 작년 인턴 때도 C++ 했으니 파트타임 잡 몇 개 빼면 나의 professional career 의 전부라고 할 수 있을성 싶다. -_-; 이 말의 요는.. '쓸만큼 썼다' 되시겠다.

C++ 의 최대 장점이자 문제는 로우레벨이라는 것이다. 로우레벨이기 때문에 퍼포먼스 모델이 단순하고, 그에 따라 시스템의 퍼포먼스를 최대한으로 끌어낼 수 있다. 그렇지만 로우레벨이기 때문에, 삶이 편해지기 위한 모든 요소들을 구현하기가 너무 힘들다는 문제도 있다.

지난 이틀 동안, 회사에서 지난 한 달 동안 작성한 C++ 코드를 파이썬으로 옮겼다. 1천 5백여 라인에서 400여라인으로 소스코드가 줄어들었다. 뭐 라인수가 중요한 것은 아니니 그렇다 치자. 놀라운 것은 실제 내가 느끼는 프로그램의 동작 속도는 더욱 빨라졌다는 것이다. 내 프로그램의 실행 시간 중에는 입력 파일 파싱하는 시간의 비중이 굉장히 컸다. 파싱한 자료 구조를 하드 디스크에 덤프해 두고, 덤프해 둔 구조를 매번 가져와 쓰면 훨씬 빨라지겠지만 다른 일 하기에도 바쁜데 그럴 시간이 있나. 하지만 파이썬에서는 numpy 차원에서 행렬 덤프를 제공하고, pickle 을 내부적으로 사용하는 shelve 를 한 줄에 쓸 수 있다. 덕분에 30초씩 걸리던 로딩 시간이 3초로 줄어들었다. 내 C++ 프로그램의 실행 시간 중에는 같은 자료를 복사하는 데 걸리는 시간의 비중도 굉장히 컸다. vector 를 주고받는 것은 기본적으로 레퍼런스가 아닌 값을 주고받는 것이기 때문에, 시간이 오래 걸릴 수밖에 없다. 포인터를 주고받으면 되지만 레퍼런스 카운팅 어느 세월에 하고 있나. shared_ptr 를 쓰면 되지만 또 언제 그렇게 프로그램을 바꾸나. 더더욱이, 행렬의 다양한 view (특정 행만을 slice 한다거나, 특정 열만을 본다거나) 를 얻고 이들이 자료를 공유하게 하고 싶다... 뭐 이쯤 되면 각각을 랩핑하는 클래스를 직접 짤 수 밖에 없다. 내 컴퓨터는 제온 쿼드코어인데, C++ 에서 쿼드코어 다 쓰는 프로그램 짜려면.... 아, 상상도 하기 싫다. 그런데 파이썬에선 이런게 다 된다. 막상 C++ 이 우월한 타이트한 루프 돌리는 데서는 weave.inline 으로 C++ 인라이닝을 낼름 해 버릴 수 있다. 내가 포팅했지만 이건 뭐 얄미울 정도다. -_-;

생각해 보면 이와 같은 문제는 참 산재해있다. C++ 으로 깔끔한 프로그램을 짜기란 정말 너무나도 힘들다. 결국 어디선가는 타협을 하게 되고, 그 타협은 언젠가 내 발목을 잡게 된다. 물론 파이썬 같은.. 에, 동적 언어와 비교하는 게 불공평할 수도 있지만, 요즘의 다른 주류 언어에 다 있는 gc 나 closure, RTTI 등등등... 없는 걸로 따지자면 뭐어 안습이다. C++ 는 스포츠카와 같다. 튜닝을 존내 열심히 하고 수십명이 달라붙어서 낑낑대면 누구보다도 빨리 달릴 수 있지만 그러는 과정이.. 아... 치질이 올 것만 같은 고통을 수반한다. 심지어 시트도 졸라 불편해서 치질이 걸릴 수도 있.. 아 왜이렇게 치질드립이 하고싶담.

여기까지 너무 당연한 얘기들을 했다. -_-; 다들 알고 있고 나도 아는 얘기였지만, 요즘 점점 더 실감하게 된다. 내가 나중에 무언가 프로덕션 코드를 다시 짜게 된다면, C++ 을 선택하게 될까 하는 생각을 오늘 문득 했는데, 결론은 "Hell no -_-" 였다. (물론 1ms 단위로 타임 크런칭하는 작은 단위의 소프트웨어라면 얘기가 다르겠지만.. 작년 인턴 프로젝트처럼) 리소스는 한정되어 있고, 가장 좋은 퍼포먼스는 알고리즘과 프로그램 구조의 개선에서 오지 인스트럭션 단위 최적화에서 오지 않기 때문이다.

그렇게 생각하니, 아직도 다 모르는 C++ 의 어두운 구석들을 내가 공부해야 할 필요가 있나 하는 생각이 든다. 내가 계속 프로그래밍 대회 코드를 C++ 로 짜는 것도 왠지 낭비같다. 난 C++ 의 상당 부분을 대회 코드를 짜면서 배웠는데, 다른 언어로 compete 하면 더 많이 배울 것 같다.

결론이 뭐냐면, 그래서 앞으로 자바로 탑코더하겠다는 거다. [.....]

왜 자바냐... 하면..

  • 오픈소스에 mature 한 VM 이 있고
  • 이 위에서 Scala 나 Groovy 같은 다른 언어들이 잘 돌아가기 때문에, VM 에 대한 지식이 넓게 쓰일 수 있고
  • 다른 대안은 C# 였는데 (솔직히 C# 캡좋다) 나 리눅스 데탑 써서 VS 못깐다....

뭐 이런거다. 이렇게 길게 글을 썼으니, 설마 앞으로는 자바로 연습하겠지... -_-;;;

SRM442 연습

페글이랑 비주얼드를 너무 열심히 해서 눈깔이 어지러운 상태에서 돌았다.. =_= 600 에서 실수해서 틀림. 제정신이 아니다. 초간단 250, 구현 550, 네트워크 플로 950 순서.

(more)

해보고 싶은 게 많은 건 좋은데, 맨날 밤새서 모든걸 다 할 게 아니면 하기로 한 걸 먼저 해야지. 우와 이거 재밌겠다 해서 시간 한참 낭비해 놓고 나중에 따라가자니 미치겠다. 아. 난 초딩이었단 말인가.

16 Nov 2009

SRM443 연습

간단 기하 + 트리 250 에 (포함관계는 트리 모델링의 아주 좋은 사례) 어려운 상태공간 탐색 600, 그리고 matrix exponentiation 1000. 600 을 bidirectional search 로 풀었다가 TLE 나는거 확인하고 그냥 1000 으로 넘어감. 1k 는 알고리즘은 맞았는데, implementation level detail 때문에 TLE 나주심. 이거 최적화하려고 졸랭 삽질했는데... ㅠㅠ 답은 둘 중 하나인 듯:

  • matrix exponentiation 할 때 각 단계들을 미리 캐싱해 둔다.
  • sum of powers 패턴을 쓰지 말고, powers includes accumulation (이거 풀어 쓰자면 너무 어려워서 대충 -_-) 전략을 쓴다.

여튼 첫번째로 바꿔서 냈는데, 시스테스트는 여전히 TLE. 근데 웃긴게, 하나씩 돌려보면 다 1초 안에 나온다. 뭔가 잘못됐나. -_-

(more)

SRM444 연습

250 삽질, 500 레코드 찍고 11등 했던 셋. 한번 돌아보았다. 근데 SRM444 가 꽤나 옛날이더라.. 미혼 시절이니... -_-;;;; 근데 250은 더 빨리 풀었지만 500은 완전 느리게 풀고, 1000 도 섭밋만 했지 틀리고.. 완전 패망이라능.. ㅠㅠ 점점 퇴화하는 것 같아. 1000 은 inclusion-exclusion principle 의 좋은 예. 그거 생각 못해서 일단 틀리고, 그거 코딩한 다음엔 off-by-one error 로 틀림.

(more)

SRM445 연습

지난번에 연습한 것 오랫동안 포스팅 못하고 있다가, 오늘 연습하려고 들어갔는데 소스코드가 있길래 포스팅.. 미디엄 gray code 처럼 생각해서 잘못했다가 중간에 버리고 하드로 갔는데, 하드는 왜 틀린지도 모르겠고, 미디엄은 생각보다 쉬웠다. T_T 코딩하기 전에 제대로 검증해볼 생각을 안한 탓인 듯.

(more)

아침에 logistic regression 꿈을 꾸면서 깼다. 아.... 이게 말이 되나.... -_-;;;;

15 Nov 2009

여름에 놓쳤던 혼혈왕자를 이제야 보고 있는데, 헤르미온느 빼고 맘에 드는 부분이 하나도 없다 ㅋㅋㅋㅋㅋㅋ 아 덤블도어 말투 짜증나 ㅠㅠ

14 Nov 2009

Go language promo 를 보는데, 나온 아저씨가 Russ Cox. 어디서 많이 들어본거 같다라는 생각이 드시는 분이라면: USACO 문제내던 아저씹니다.

Performance Computing In Python 예전에 링크 있었는데 잃어버려서 다시.

13 Nov 2009

시개작 환송회

약 한달 반 전쯤 되나? 인사동에서 모였을 때의 사진. 하드 정리하다 찾아서 올려본다. 이렇게 사진을 보고 있노라면 집을 떠나왔다는 게 실감나곤 한다. 아 그리고 사진 업로드 졸라 느릴때도 실감난다.

애플+일기

수열이가 맥북프로를 쓰기 시작한지 3일째. 나는 노트북은 쓸 일도 없을 뿐더러, 처음 써보는 맥 잡으면 적응하느라 한참 짜증날 걸 알면서도 역시 탐이 난다. 블링블링한 인터페이스를 보고 있으면 단축키 설정하느라 그나마 있던 특수효과도 다 꺼버리고, 종종 폰트 렌더링도 정말 구린 투박한 리눅스 데스크탑이 갑갑하기조차 할 정도. 하여간 이쁜건 정말 중요하다. 애플이 정말 물건은 이쁘게 잘 만드는구나. 아이팟에 아이폰에 맥북까지 샀으니 이제 나도 장호형처럼 27인치 아이맥사면 애플 덕후 인증인가...

사실 요즘 리눅스 데탑에서 뭐 좀 안되서 짜증날 때면 내가 뭐하러 이 삽질을 하고 있나 싶을 때도 있긴 하다. -_-; 그래도 개발은 리눅스에서 해야하니까. (뭐 그렇다고 요즘 딱히 뭐 개발하는건 아니다..) 오늘은 노트북 쿨러를 사와서 예전에 쓰던 R6 에 물리고 외장하드 두개를 끼워서 삼바 서빙용 홈서버로 만들었다. 우분투는 예전에 듀얼 부팅으로 깔아놓았고, 토렌트랑 파일 서빙만 하더라도 남는 장사인 것 같아서. 노트북 사실 쓰지도 않고 열도 좀 있어서 팔아버릴까 생각했지만, 이런 물건 팔릴지도 모르겠고 (나같아도 넷북 사겠다...) 이거 팔면 또 베어본 시스템 사서 셋업하느라 삽질해야 되잖아. .. 그런이유로 2년간 잘쓴 내 노트북은 TV밑에서 오늘도 열심히 가십걸 새 에피소드를 받고 있다. 그런 셋업 하고 외장하드 정리하느라 오늘 저녁이 날아감.

오늘 회사에서 너무 피곤해서 오늘은 기필코 일찍 자리라 했는데 또 열한시 반이다. 주여!

파이썬으로 코드베이스를 옮기고 있는데, 루프가 아무래도 느려서 결국 scipy.weave 로 C++ 인라이닝했더니, 1일치에 48초 거리던 것이 10일치에 0.19초 걸린다. ... 2526배의 속도 향상이란거냐 지금? 이걸 믿으라고? oTL

12 Nov 2009

PKU3740 Time Attack: gradual optimization

어제 자기 전에 IRC 에 가보니 사람들이 열심히 pku 문제 하나 를 잡고 숏코딩과 타임어택을 하고 있었다. 숏코딩은 whitespace 포함 가장 작은 소스코드로 문제를 푸는 것이고, 타임어택은 가장 짧은 시간 걸려서 문제를 푸는 것. 아기 코끼리 덤보마냥 귀를 팔락거리면서 말려서 결국 타임어택에 도전했다. 641ms 였던 프로그램을 16ms 로 낮추면서 가장 낮은 시간 중 하나 가 됨. pku 저지의 timing resolution 때문에 아마 이보다 낮은 시간은 puts("output file"); 아니면 불가능하지 않을까 생각됨.

비교적 가장 단순하고 무식한 코드에서 시작해서 bottleneck 을 없애고 알고리즘을 최적화하는 방식으로 진행했기 때문에, 나름대로 재미있을 것 같아서 각 단계별로 소스코드를 모아보았다. ...