http://daybreaker.info/blog/ Daybreakin Things 2009-01-06T20:23:18+09:00 Textcube 1.7.7 : Beta 1 (그네고치기) http://daybreaker.info/blog/entry/PS-%EC%9D%B8%EA%B3%B5%EC%A7%80%EB%8A%A5-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8-%EB%81%9D#comment2108 2006-12-12T22:58:26+09:00

수고하셨습니다. m(_._)m

(daybreaker) http://daybreaker.info/blog/entry/PS-%EC%9D%B8%EA%B3%B5%EC%A7%80%EB%8A%A5-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8-%EB%81%9D#comment2109 2006-12-13T12:30:01+09:00

고맙습니다.;

(Yuyudevil) http://daybreaker.info/blog/entry/PS-%EC%9D%B8%EA%B3%B5%EC%A7%80%EB%8A%A5-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8-%EB%81%9D#comment2110 2006-12-12T23:44:13+09:00

원래 그런 에세이들은 발로 써야 좋은 점수가 나온대요 =3 (그런데 날뷁옹은 정말 발로 쓰셨을까요?)

(daybreaker) http://daybreaker.info/blog/entry/PS-%EC%9D%B8%EA%B3%B5%EC%A7%80%EB%8A%A5-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8-%EB%81%9D#comment2111 2006-12-13T12:30:37+09:00

정말 발로 썼어요;; 오후 5시 넘어서 시작한 거라 배가 고파서 머릿속에서 아무것도 안 떠오르는 상태에서 억지로 쥐어짰거든요-_-

(코카스) http://daybreaker.info/blog/entry/PS-%EC%9D%B8%EA%B3%B5%EC%A7%80%EB%8A%A5-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8-%EB%81%9D#comment2112 2006-12-12T23:50:27+09:00

본좌팀은 멀티쓰레드 안 써도 충분하다고 하면서 그냥 꺼버렸죠. 본좌팀도 메모리, CPU 줄이려고 각종 최적화 기법을 많이 썼는데 무지막지한 bitwise 연산들과 loop-unrolling을 비롯한 컴파일러 최적화 옵션 먹이기 등등이 있었습니다. 옆에서 소식을 많이 들어서.. 축하드려요. :)

(daybreaker) http://daybreaker.info/blog/entry/PS-%EC%9D%B8%EA%B3%B5%EC%A7%80%EB%8A%A5-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8-%EB%81%9D#comment2113 2006-12-13T12:31:24+09:00

저도 컴파일러 최적화 옵션을 먹일까 했는데 C#은 의외로(?) 옵션이 별로 없더라는.. -_-; (오버플로 검사 이런 거 빼볼까 했는데...) bit연산까지 쓸 생각은 못해봤군요.;

(진실's) http://daybreaker.info/blog/entry/PS-%EC%9D%B8%EA%B3%B5%EC%A7%80%EB%8A%A5-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8-%EB%81%9D#comment2114 2006-12-13T01:30:41+09:00

우아 축하해! 니 글을 보니까 PS 안 듣길 정말 잘했다는 생각이 들어.. 고수들의 세계인 것이냐!

(daybreaker) http://daybreaker.info/blog/entry/PS-%EC%9D%B8%EA%B3%B5%EC%A7%80%EB%8A%A5-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8-%EB%81%9D#comment2115 2006-12-13T12:31:39+09:00

그래도 이게 다 뼈가 되고 살이 되는(?) 것이야.;

(Neon) http://daybreaker.info/blog/entry/PS-%EC%9D%B8%EA%B3%B5%EC%A7%80%EB%8A%A5-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8-%EB%81%9D#comment2116 2006-12-13T09:42:42+09:00

아니 Time cut을 멀티쓰레드로 구현하면 님하 그건좀 수준인데...

(daybreaker) http://daybreaker.info/blog/entry/PS-%EC%9D%B8%EA%B3%B5%EC%A7%80%EB%8A%A5-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8-%EB%81%9D#comment2117 2006-12-13T12:34:54+09:00

뭐, 전부다 클래스화해서 짠 데다 private 멤버변수로 주기적으로 결과값을 저장하게 해놓고, property 형식으로 받아오게 했더니 join 써서 간단히 해결되던데요? ;; (C++이 아니라 C#이라 언어적으로 lock 구조 등을 지원해서 보다 쉬웠음) 알고리즘에서 루프 돌면서 매번 tick count 계산하는 것보다는 차라리 쓰레드 join시키는 게 훨씬 효율이 낫지 않을까요;

(Neon) http://daybreaker.info/blog/entry/PS-%EC%9D%B8%EA%B3%B5%EC%A7%80%EB%8A%A5-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8-%EB%81%9D#comment2118 2006-12-14T19:44:12+09:00

CPU가 context switch+job scheduling하는데 드는 비용을 생각하면 외부에서 join하는게 빠를거라고는 동의 못하겠는데... lock 체크하랴, context switch하랴. 단순히 틱 계산하는것보다는 훨씬 로드가 큰 작업들이지; 상위 언어에서 한줄로 지원하는 기능이 알고보면 시간 잡아먹는 괴물이라던가 하는 경우 많아...

(daybreaker) http://daybreaker.info/blog/entry/PS-%EC%9D%B8%EA%B3%B5%EC%A7%80%EB%8A%A5-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8-%EB%81%9D#comment2119 2006-12-15T02:25:09+09:00

흠.. 근데 어차피 context switch는 프로세스 사이에서만 이루어지는 거고 스레드 사이에서는 그 전환 cost가 매우 작지 않던가요? 게다가 priority 설정 같은 걸로 인공지능 스레드가 더 많은 cpu 시간을 잡아먹게 한다든가.. (그러면서 다른 것이 blocking되게 하지 않는..) 무엇보다도, 싱글스레드로 프로그램을 짰다고 해도 어차피 다른 스레드로의 전환은 운영체제가 해버릴 텐데, 멀티스레드로 짰다고 해서 특별히 효율이 떨어질 것 같진 않습니다. (Join 메소드 자체의 오버헤드가 얼마나 되는지는 모르겠지만, 생각만큼 클 것 같지는 않네요) 그리고 알고리즘 자체는 싱글스레드였기 때문에 lock에 의한 성능 저하는 없었습니다. 그리고 제가 프로그램을 짤 때 인공지능이 돌아가는 동안은 다른 스레드에서 할 일이 거의 없도록 해놨기 때문에 틱만 계산하는 것과 별다른 차이는 없을 거에요. 저는 일단 프로그램이 백지(..)되는 걸 원치 않았기 때문에..-_-

(Neon) http://daybreaker.info/blog/entry/PS-%EC%9D%B8%EA%B3%B5%EC%A7%80%EB%8A%A5-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8-%EB%81%9D#comment2120 2006-12-18T23:09:29+09:00

이론적으로 동의하지 못하겠다면 실험을 해보는 수밖에 -_-; 그리고 멀티쓰레드는 디버거 사용이 꽤나 불편하지 않나 하는 생각도.

(daybreaker) http://daybreaker.info/blog/entry/PS-%EC%9D%B8%EA%B3%B5%EC%A7%80%EB%8A%A5-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8-%EB%81%9D#comment2121 2006-12-18T23:25:34+09:00

흠.. 실험을 한다고 해도 어차피 오차 범위 밖에서 수십 ms 이상 차이나지는 않을 것 같습니다만.. 정 원하신다면 시험 끝나고.. (....) 참고로 저거 디버깅은 전혀 어렵지 않았어요. 막강한 Visual Studio의 디버깅 기능으로 아주 편하게...(...) 리눅스에서 gdb로 멀티스레드 디버깅해봐서 알지만 거의 천국과 지옥 차이는 나는 같군요.;;; 물론 내부적으로 메모리가 꼬이기 시작하면 그때부터는 힘들어집니다만(예전에 VB.NET으로 IRC 봇 만들 때 여러 스레드에서 쓰는 오브젝트를 lock 제대로 안 걸어주니까 중간에 증발해버리는 현상이 나타난 적이 있었습니다-_-) 말씀드렸다시피 알고리즘 자체는 싱글스레드였기 때문에 lock이 전혀 없었고 따라서 멀티스레드에 따른 어려움은 전혀 없었습니다. 제가 멀티스레드를 사용한 것은 순전히 아키텍처 관점에서, GUI 응답성 확보 관점이었을 뿐, Timeout Join을 호출한 쪽에서 사용한 것 외에는 알고리즘에서 멀티스레드 프로그래밍 요소가 들어있지 않기 때문에, 새 스레드를 하나 만들어서 Join을 해서 기다리는 동안 그 스레드가 실행되는 시간과 그냥 현재 스레드에서 작업을 수행하는 것과의 차이 외에는 발생하지 않을 겁니다. (프로그램이 먹통되지 않게만 했을 뿐 알고리즘이 돌아갈 때 메인스레드를 쓰는 GUI를 사용한다는 전제는 없었으니까요.) 무엇보다도 저는 아주 significant한 성능 저하나 문제 해결에 critical하게 방해가 되는 것이 아니라면, 가능하면 프로그래머가 편하게, 직관적으로 짤 수 있도록 하는 방향을 선호합니다. 이에 대한 관점은 사람마다 차이가 있을 수 있겠죠. 하지만 적어도 PS 프로젝트로 인공지능을 돌리는 데 있어서 저 정도의 성능 저하(가 있었다면)는 충분히 감수할 만한 가치가 있었다고 생각합니다. 그만큼 팀원들이 생소한 언어에서 AI에 편하게 접근할 수 있었고, 분명하게 용도가 분리된 클래스와 설계로 편하다는 얘기를 했었으니까요. (여러 명이 프로그래밍을 했기 때문에 서로가 서로의 코드를 모르는 채 완전하게 돌아가려면 클라이언트 기반을 짠 제가 팀원들이 다른 부분과 상호작용을 고려하지 않고 AI만 짤 수 있도록 하는 게 가장 좋겠죠.)

(익룡ㅋㅋ) http://daybreaker.info/blog/entry/PS-%EC%9D%B8%EA%B3%B5%EC%A7%80%EB%8A%A5-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8-%EB%81%9D#comment2122 2006-12-19T22:56:01+09:00

으헉 ㅎㄷㄷ;; 이거 문제해결기법 그 과목인가요? 무서워라 ㅡㅡ