SHHyun의 미투데이 - 2009년 12월 30일
Private / 2009/12/31 04:33
- 삼족오 덕분에 미투데이 다시 사용? ㅡ.ㅡ 그러나 미지수 ㅋ 2009-12-30 22:35:39
이 글은 SHHyun님의 2009년 12월 30일의 미투데이 내용입니다.
'2009/12'에 해당되는 글 9건
- 2009/12/31 SHHyun의 미투데이 - 2009년 12월 30일
- 2009/12/15 대학생으로서 본 마지막 기말고사.
- 2009/12/13 안드로이드폰은 대체 언제 출시되는 것인가? ㅜㅜ
- 2009/12/11 검색 서비스에 대한 아주 좋은 글
- 2009/12/11 CUDA 의 스레드 개수 제한
- 2009/12/08 구글과 네이버
- 2009/12/06 Quake Live! 와우!
- 2009/12/05 GA나 GP의 이론 검증의 어려움
- 2009/12/04 CUDA Programming
이올린에 북마크하기
대학생으로서 본 마지막 기말고사.
Private / 2009/12/15 16:50
감회가 새롭다.
마지막이라니 -_-
아직 대학원생활을 해야하니 그때도 분명 시험이라는 것을 볼테지만,
그래도 시간이 조금더 지나면 이젠 시험이라는 자체가 없어지는 세상에 살게 되는구나...
외우는 건 지지리도 못하는 탓에 시험때마다 무진장 고생했었는데
기분이 참 묘하네...
마지막 시험이지만 별 부담없이 잘 봤다고 생각이 드는데,
제발 좋은 결과가 나와서 유종의미를 잘 거둘수 있기를 빈다.
마지막이라니 -_-
아직 대학원생활을 해야하니 그때도 분명 시험이라는 것을 볼테지만,
그래도 시간이 조금더 지나면 이젠 시험이라는 자체가 없어지는 세상에 살게 되는구나...
외우는 건 지지리도 못하는 탓에 시험때마다 무진장 고생했었는데
기분이 참 묘하네...
마지막 시험이지만 별 부담없이 잘 봤다고 생각이 드는데,
제발 좋은 결과가 나와서 유종의미를 잘 거둘수 있기를 빈다.
안드로이드폰은 대체 언제 출시되는 것인가? ㅜㅜ
Private / 2009/12/13 23:48
핸드폰이 완전 작살나기 직전이라 바꾸려고 하는데,
결국 젤 기대되는건 안드로이드 폰 ...
근데 당췌 이놈 나올 생각을 안하는군요 -_-;;;
음....
베터리가 하루도 못가는 내 핸드폰을 가지고 계속 버티는건 무리인데;;
내년 중반기까지만 버티면 나오려나... ㅜㅜ
결국 젤 기대되는건 안드로이드 폰 ...
근데 당췌 이놈 나올 생각을 안하는군요 -_-;;;
음....
베터리가 하루도 못가는 내 핸드폰을 가지고 계속 버티는건 무리인데;;
내년 중반기까지만 버티면 나오려나... ㅜㅜ
검색 서비스에 대한 아주 좋은 글
Private / 2009/12/11 16:30
http://cliomedia.egloos.com/2492360
읽는 내내 엄청나게 공감했다.
나는 공대쪽 인간이기에 이분이 말씀하시는 것과 같은 형태의 레포트를 쓸일이 많이 있지는 않았지만, 단지 문제를 하나 풀어내기 위해서 작성하는 레포트를 쓸 때, 해당 문제가 있는 책 한권을 참고 하는 것만 가지고는 풀 수 없는 경우가 많이 있었다. 이럴 때 도서관에 찾아가서 회로면 회로, 통신이면 통신, 프로그래밍이면 프로그래밍에 대한 서적을 여러개를 빌려서 동시에 펼쳐놓고, 인터넷에 있는 여러가지 자료들과 함께 비교해가면서 한 문제를 풀어내는 대에도 8~9시간 이상 걸리곤 했다.
지금 생각해보면 그렇게 하지 않았다면 지금처럼 뭔가 전혀 다른 새로운 걸 배울 수 있는 기초를 닦을 수 있었을지 의문이 드는데, 내 주위의 대부분의 사람들은 어째서 그렇게까지 해야만 하느냐고 말했었다. 나야 뭐 특이한 인간인지 모르겠지만, 그것이 당연하다고 여겼기 때문에 그렇게 해 왔었던 것이고, 그렇게 해야만 자신의 것으로 만들 수 있다는 것을 어렸을때부터 많이 느껴왔기 때문에 그렇게 했었던 것 같다.
교수님들이 처음에 레포트 작성에 대한 기준이나 방법을 가르쳐 주지 않는다는 것도 하나의 문제가 아닐까 생각도 든다. 하지만 적어도 전자과 교수님들중 몇몇 분은 레포트를 제출 했을때, 해당 레포트에 대해 어떠한 내용을 어떤식으로 서술하면 좋을 것 같고, 어떻게 보강하는 것이 좋을 것 같다는 내용 정도는 언제나 첨삭을 해 주셨던 것으로 볼 때, 적어도 내가 속해있는 전자공학과 학생들은 자신이 어떻게든 자신의 의지로 손을 끄적였다면, 조금은 더 올바른 공부를 할 수 있지 않을까 싶다. 물론 내가 워낙 귀찮게 해서 그랬을 수도 있었을 것 같다.
어쩌면 이건 학교탓을 할 수도 있겠다. 내가 다니고 있는 서경대학교에 오는 대부분의 학생들 스스로가 자신에 대한 자격지심을 가지고 있던가, 그렇기 때문에 좋지도 않은 학교에서 어째서 그고생을 해야하느냐 라고 스스로 생각할 수도 있을 것이다. 제발 나의 후배를 비롯한, 다른 학생들은 그러지 않았으면 좋겠지만 말이다.
인터넷을 통해 그냥 긁어서 붙여넣는 식의 레포트, 자신의 생각이 1할도 들어가지 않은 복사지와 같은 레포트가 판을 친다는 사실은 어쩌면 조금은 서글프다. 그러한 레포트가 나타나는 데에는 그저 시키는대로만 해오던 과거의 습관을 계속 반복하기 때문은 아닐까? 강의 시간을 봐도 학생이 먼저 자신의 궁금증을 표현하거나 이것은 뭔가 이상하다고 의의를 제기하는 것을 보기 어려운 건, 해당 교수님들의 너무나 완벽한 강의를 하기 때문인것일까? 그렇지 않으면 앉아 있는 학생들이 아무런 생각도 없이 멍하니 듣는 것이 진리라고 생각하고 받아 들이기 때문인 것일까?
내 생각에는 결국 과거의 교육 습관이 현재에 까지 영향을 미치는 것이 아닐까 싶다. 인터넷에서 정보를 긁어오면 그것이 다 진리이고, 내가 원하는 해답이며, 거기에 대해선 어떠한 의문을 가질 필요도 없다. 마치 과거에 교과서가 모든 진실을 담고 있다고 배웠던 것 처럼...
오히려 그렇게 의문을 가지고 질문을 한다면, 그것이 세상을 복잡하게 사는 것이며, 다른 고민할 거리도 많은데 왜 그래야 하냐며 이상한 시선으로 바라보곤 한다. 점점 더 편한 것만을 추구하고, 빠르게만 처리하려고 할 때에 결국 그 깊이는 점점 사라져 가는 것 같다.
저분이 쓴 글을 보면서 나같은 사람들이 여전히 꽤 있는것 같고, 내가 헛짓을 한건 아니었구나 라는 생각을 다시 한번 하게 되었다.
-- 여기서부터는 사설 --
요새 학술 검색을 할 때, 구글쪽에 손이 많이 가는 것이 사실이다. 편리한 시스템인데다 무료로 제공된다는 것이 가장 큰 메리트랄까? 우리 학교에서 지원해주는 데이터 베이스가 워낙에 열악해서 정말 유명한 외국 데이터 베이스는 접근조차 할 수 없다.
결국 지금 하고 있다는 건 구글 학술검색을 통해 대표적인 유명한 논문을 검색한 후, 이 논문들이 참고하고 있는 논문을 나무의 가지치기와 같이 줄줄줄 검색하는 수 밖에 없다. 그리고 검색에 검색을 따라가다가도 어떤 데이터 베이스는 접근 자체가 어려우니 한계가 있는 것도 사실이다. 결국 이러한 정보를 찾아가는 것 조차도 돈이 문제가 되고, 환경이 문제가 되는 것인가 라는 생각도 들지만, 지금 나에게 주어진 것들을 충실하게 이용하는 수 밖에 없을 것 같다.
읽는 내내 엄청나게 공감했다.
나는 공대쪽 인간이기에 이분이 말씀하시는 것과 같은 형태의 레포트를 쓸일이 많이 있지는 않았지만, 단지 문제를 하나 풀어내기 위해서 작성하는 레포트를 쓸 때, 해당 문제가 있는 책 한권을 참고 하는 것만 가지고는 풀 수 없는 경우가 많이 있었다. 이럴 때 도서관에 찾아가서 회로면 회로, 통신이면 통신, 프로그래밍이면 프로그래밍에 대한 서적을 여러개를 빌려서 동시에 펼쳐놓고, 인터넷에 있는 여러가지 자료들과 함께 비교해가면서 한 문제를 풀어내는 대에도 8~9시간 이상 걸리곤 했다.
지금 생각해보면 그렇게 하지 않았다면 지금처럼 뭔가 전혀 다른 새로운 걸 배울 수 있는 기초를 닦을 수 있었을지 의문이 드는데, 내 주위의 대부분의 사람들은 어째서 그렇게까지 해야만 하느냐고 말했었다. 나야 뭐 특이한 인간인지 모르겠지만, 그것이 당연하다고 여겼기 때문에 그렇게 해 왔었던 것이고, 그렇게 해야만 자신의 것으로 만들 수 있다는 것을 어렸을때부터 많이 느껴왔기 때문에 그렇게 했었던 것 같다.
교수님들이 처음에 레포트 작성에 대한 기준이나 방법을 가르쳐 주지 않는다는 것도 하나의 문제가 아닐까 생각도 든다. 하지만 적어도 전자과 교수님들중 몇몇 분은 레포트를 제출 했을때, 해당 레포트에 대해 어떠한 내용을 어떤식으로 서술하면 좋을 것 같고, 어떻게 보강하는 것이 좋을 것 같다는 내용 정도는 언제나 첨삭을 해 주셨던 것으로 볼 때, 적어도 내가 속해있는 전자공학과 학생들은 자신이 어떻게든 자신의 의지로 손을 끄적였다면, 조금은 더 올바른 공부를 할 수 있지 않을까 싶다. 물론 내가 워낙 귀찮게 해서 그랬을 수도 있었을 것 같다.
어쩌면 이건 학교탓을 할 수도 있겠다. 내가 다니고 있는 서경대학교에 오는 대부분의 학생들 스스로가 자신에 대한 자격지심을 가지고 있던가, 그렇기 때문에 좋지도 않은 학교에서 어째서 그고생을 해야하느냐 라고 스스로 생각할 수도 있을 것이다. 제발 나의 후배를 비롯한, 다른 학생들은 그러지 않았으면 좋겠지만 말이다.
인터넷을 통해 그냥 긁어서 붙여넣는 식의 레포트, 자신의 생각이 1할도 들어가지 않은 복사지와 같은 레포트가 판을 친다는 사실은 어쩌면 조금은 서글프다. 그러한 레포트가 나타나는 데에는 그저 시키는대로만 해오던 과거의 습관을 계속 반복하기 때문은 아닐까? 강의 시간을 봐도 학생이 먼저 자신의 궁금증을 표현하거나 이것은 뭔가 이상하다고 의의를 제기하는 것을 보기 어려운 건, 해당 교수님들의 너무나 완벽한 강의를 하기 때문인것일까? 그렇지 않으면 앉아 있는 학생들이 아무런 생각도 없이 멍하니 듣는 것이 진리라고 생각하고 받아 들이기 때문인 것일까?
내 생각에는 결국 과거의 교육 습관이 현재에 까지 영향을 미치는 것이 아닐까 싶다. 인터넷에서 정보를 긁어오면 그것이 다 진리이고, 내가 원하는 해답이며, 거기에 대해선 어떠한 의문을 가질 필요도 없다. 마치 과거에 교과서가 모든 진실을 담고 있다고 배웠던 것 처럼...
오히려 그렇게 의문을 가지고 질문을 한다면, 그것이 세상을 복잡하게 사는 것이며, 다른 고민할 거리도 많은데 왜 그래야 하냐며 이상한 시선으로 바라보곤 한다. 점점 더 편한 것만을 추구하고, 빠르게만 처리하려고 할 때에 결국 그 깊이는 점점 사라져 가는 것 같다.
저분이 쓴 글을 보면서 나같은 사람들이 여전히 꽤 있는것 같고, 내가 헛짓을 한건 아니었구나 라는 생각을 다시 한번 하게 되었다.
-- 여기서부터는 사설 --
요새 학술 검색을 할 때, 구글쪽에 손이 많이 가는 것이 사실이다. 편리한 시스템인데다 무료로 제공된다는 것이 가장 큰 메리트랄까? 우리 학교에서 지원해주는 데이터 베이스가 워낙에 열악해서 정말 유명한 외국 데이터 베이스는 접근조차 할 수 없다.
결국 지금 하고 있다는 건 구글 학술검색을 통해 대표적인 유명한 논문을 검색한 후, 이 논문들이 참고하고 있는 논문을 나무의 가지치기와 같이 줄줄줄 검색하는 수 밖에 없다. 그리고 검색에 검색을 따라가다가도 어떤 데이터 베이스는 접근 자체가 어려우니 한계가 있는 것도 사실이다. 결국 이러한 정보를 찾아가는 것 조차도 돈이 문제가 되고, 환경이 문제가 되는 것인가 라는 생각도 들지만, 지금 나에게 주어진 것들을 충실하게 이용하는 수 밖에 없을 것 같다.
CUDA 의 스레드 개수 제한
Programming / 2009/12/11 01:40
여러가지 자료를 살펴보다 보니 왜 CUDA 를 많이 쓰는지 잘 알것 같다.
기본적으로 for loop 로 돌던 것들의 index 를 병렬적으로 배치해주는 것이 그 핵심인데,
해당 과정만 거치고 나면, 거의 모든 종류의 계산 알고리즘을 병렬화 해줄 수 있다.
Block 당 512개의 Threads 제한은 조금은 충격.
연구실의 후배가 문제를 발견해서, 해당 문제점에 대해 생각해보니 어라? 이건 좀 이상하네 라는 생각이 들었다.
그리드당 블럭의 개수는 512x512x32 였던가
그런데 레퍼런스 자체에 표현이 좀 혼동되게 되어있는 것이 Block 과 Grid 에 대한 것이다.
레퍼런스 상의 Block 은 Thread 와 같고, Grid 는 Kernel 과 같은데, 위의 그리드당 블럭 개수는 진짜 그리드당 블럭 개수로 해석해야 한다.
이거원...
조금은 더 명확히 정리해야할 필요가 있는 것 같다.
기본적으로 for loop 로 돌던 것들의 index 를 병렬적으로 배치해주는 것이 그 핵심인데,
해당 과정만 거치고 나면, 거의 모든 종류의 계산 알고리즘을 병렬화 해줄 수 있다.
Block 당 512개의 Threads 제한은 조금은 충격.
연구실의 후배가 문제를 발견해서, 해당 문제점에 대해 생각해보니 어라? 이건 좀 이상하네 라는 생각이 들었다.
그리드당 블럭의 개수는 512x512x32 였던가
그런데 레퍼런스 자체에 표현이 좀 혼동되게 되어있는 것이 Block 과 Grid 에 대한 것이다.
레퍼런스 상의 Block 은 Thread 와 같고, Grid 는 Kernel 과 같은데, 위의 그리드당 블럭 개수는 진짜 그리드당 블럭 개수로 해석해야 한다.
이거원...
조금은 더 명확히 정리해야할 필요가 있는 것 같다.
아직은 국내에서 점유율이 가장 높은 검색 엔진 네이버.
전세계적으로 가장 높은 검색 엔진은 구글.
개인적인 생각으로는 네이버는 조금은 소소한 것들(지식인이 한몫하는듯)을 검색하는데 적합한 것 같고,
구글은 정확성을 요구하는 학술정보나 전문지식 같은 것을 검색하는데 나은 것 같다.
학술검색할일이 더 많기 떄문에, 현재로서는 구글 80% 네이버 20% 지만...
글쎄...
음....
아무래도 네이버가 비중이 높아질 수 있을지 모르겠다.
전문지식을 많이 검색하게 되니... 네이버 전문 지식의 정확성이 더 높아지면 모를까...
하지만 아마 안될꺼야 -_-...
Quake Live! 와우!
Games/Others / 2009/12/06 01:05
http://www.quakelive.com
와우! 대단하군요!
퀘이크를 웹에서!!! 그것도 현재는 무료 ;;
와... 진짜 이런일이 생기다니
퀘이크 매니아"였었던" 관계로 엄청 흥분중입니다.
해보니 대박...!
퀘이크 좋아하시는분은 고고~
이올린에 추천하기GA나 GP의 이론 검증의 어려움
Intelligence System/Others / 2009/12/05 02:07
GP 의 해가 가지는 특성을 파악하기 위해 실험을 통해 대규모의 데이터를 수집하였다고 가정하자. 그리고 대부분의 해에서 나타나는 어떠한 특성이 발견 되었다면, 과연 여기서 대부분의 해는 반드시 그 어떤 특성을 갖게 되는 것일까?
GA, GP 의 조기수렴이 해의 다양성에 악영향을 끼치고, 좋은 결과로 수렴하는 것을 방해한다고 했을 때, 조기수렴을 막으면 반드시 해가 다양성을 폭넓게 가지면서, 좋은 결과로 수렴할 것인가?
어떠한 명제를 가정했을 때, 그 역이 반드시 참일것이라는 보장 같은 것은 없다. 결국 우리가 일반적으로 데이터를 수집하여 하는 일은 대부분이 그러한 특성을 보인다는 것에서 끝나는 것인데, 이것의 역을 증명해낼 좋은 방법은 없을것인가?
몇년째 계속 고민해보지만, GA, GP 쪽에서는 이를 어떤 수로 증명할 것인지 딱히 머리속에 떠오르는 것이 없다. 실험을 통해 명제 자체가 참임을 증명해낼 수는 있지만, 그 명제를 토대로 알고리즘을 구성하고 타당성을 갖기 위해서는 반드시 그 명제의 역이 참임을 증명해야 하는데 아직까지는 부족한게 많은지 딱히 좋은 방법이 떠오르지 않는다.
하지만 이 부분이 해결되지 않는 한, 결국 어떠한 알고리즘을 만든다 하더라도 이것이 타당성을 갖기는 어려울 것이 분명하기 때문에 앞으로도 계속 고민할 것 같다. 뭔가 좋은 방법은 없는 것일까?
CUDA Programming
Programming / 2009/12/04 02:21
병렬처리는 결국 필수 불가결한 요소가 될 것임에는 분명하다. 확실히 단일 코어 발전 대비 성능 비율이 언젠가부터 매우 낮아진다는 것을 확인할 수 있다. CPU 를 듀얼 혹은 쿼드로 쓰는 것도 꽤 매리트가 있지만, 알고리즘을 연구하는 사람으로써 그런 한 두개의 병렬을 가지고 큰 효과를 보기에는 그 한계가 명확하다.
결국 요래저래 살펴보다가 또다시 GPU 쪽으로 눈이 돌아가게 되었는데, 그 당시에는 그렇게 어렵게만 느껴지던 CUDA 라는 것이 그렇게 어려운 녀석이 아니었다.
일련의 흐름에 따라서 프로그래밍을 하면 되는데,
1. 디바이스의 초기화
2. GPU 상의 메모리 할당 ( cudaMalloc )
3. CPU 상에서 GPU 상으로 처리할 내용을 복사 ( cudaMemcpy )
4. 커널을 수행함으로써 원하는 연산 처리 ( function <<< blocks, threads, sharedmem >>> ( parameters ) )
5. GPU 상에서 처리된 내용을 CPU 상으로 재 이동 ( cudaMemcpy )
6. 할당했었던 메모리를 모두 해제 ( cudaFree )
7. 디바이스 종료
이러한 큰 흐름을 순서로 움직이면 된다.
얼마나 쉬운가?
마치 포인터를 처음 볼때의 그런 느낌이었다. 어라? 별거 아니네?
그런데 이놈도 포인터랑 똑같은 놈이더라. 결국 잘 쓰려고 하다보니 메모리 구조에 대한 것을 다시 확인해야 했다. CUDA 의 처리는 Block 단위의 다수의 스레드를 어떻게 관리하느냐, 그리고 이들이 처리될 때의 Shared Memory 를 잘 관리해 줘야 올바른 결과를 얻을 수 있고, 획기적인 병렬처리의 성능을 만끽할 수 있다는 것. 게다가 망할 포인터보다도 하나 더 많은 요소가 있었으니, Block 과 Thread 의 숫자를 결정해주는 것이다.
하지만 확실한 건 포인터와 마찬가지로 이놈도 쉽게 생각하면 될 것 같은 기분이 든다.
다음 번엔 SGA 에 Evaluation 과정을 CUDA 를 이용해 처리한 소스나 올려봐야 겠다. 아직 Thread 동기화에 문제가 있는지, 자꾸 마지막 변수값만 들어가는 현상이 발생하던데 요고만 해결하고 나서 하나씩 또 정리해봐야겠다.
결국 요래저래 살펴보다가 또다시 GPU 쪽으로 눈이 돌아가게 되었는데, 그 당시에는 그렇게 어렵게만 느껴지던 CUDA 라는 것이 그렇게 어려운 녀석이 아니었다.
일련의 흐름에 따라서 프로그래밍을 하면 되는데,
1. 디바이스의 초기화
2. GPU 상의 메모리 할당 ( cudaMalloc )
3. CPU 상에서 GPU 상으로 처리할 내용을 복사 ( cudaMemcpy )
4. 커널을 수행함으로써 원하는 연산 처리 ( function <<< blocks, threads, sharedmem >>> ( parameters ) )
5. GPU 상에서 처리된 내용을 CPU 상으로 재 이동 ( cudaMemcpy )
6. 할당했었던 메모리를 모두 해제 ( cudaFree )
7. 디바이스 종료
이러한 큰 흐름을 순서로 움직이면 된다.
얼마나 쉬운가?
마치 포인터를 처음 볼때의 그런 느낌이었다. 어라? 별거 아니네?
그런데 이놈도 포인터랑 똑같은 놈이더라. 결국 잘 쓰려고 하다보니 메모리 구조에 대한 것을 다시 확인해야 했다. CUDA 의 처리는 Block 단위의 다수의 스레드를 어떻게 관리하느냐, 그리고 이들이 처리될 때의 Shared Memory 를 잘 관리해 줘야 올바른 결과를 얻을 수 있고, 획기적인 병렬처리의 성능을 만끽할 수 있다는 것. 게다가 망할 포인터보다도 하나 더 많은 요소가 있었으니, Block 과 Thread 의 숫자를 결정해주는 것이다.
하지만 확실한 건 포인터와 마찬가지로 이놈도 쉽게 생각하면 될 것 같은 기분이 든다.
다음 번엔 SGA 에 Evaluation 과정을 CUDA 를 이용해 처리한 소스나 올려봐야 겠다. 아직 Thread 동기화에 문제가 있는지, 자꾸 마지막 변수값만 들어가는 현상이 발생하던데 요고만 해결하고 나서 하나씩 또 정리해봐야겠다.