지난번 회의 이후로 DCC ver1.0을 위한 진행상황이 어떻게 되는지 알고 싶습니다.
아무래도 DCC의 기능추가나 소스코드 정리 같은 작업을 개인적으로 진행하는 것보단 1.0까지 개선해야할 목표를 정해두고 일정을 세워서 진행하는게 좀더 적극적으로 참여할 수 있고 빠른 방법이라고 생각합니다.
DCC를 ver1.0까지 끌어올릴려면 ??
일단 지금까지 나온 의견과 제가 생각하고 있는겄들은...4가지 정도입니다.
1. 모니터링 프로그램 개선!
현재 모니터링 프로그램에서 버그가 좀 발생한 것같습니다.
음... 버그라기보단 저희가 더스트가 여러번 발생할 경우를 고려하지 않고 만들어서 그런것 같구요..
Agent로부터 리턴받아야할 파일이 1개 이상일 경우 DS 메세지를 받을 배열의 크기가 부족해서? 세그멘테이션 오류가 발생하는데요..
모니터 프로그램이 아무래도 프로젝트 막바지에 급하게 만들려고 하다보니 설계도 없었고....
기능추가나 비쥬얼 적인것들도 많이 고려를 못해서 이참에 새로 만들어보자는 의견이 나왔습니다.
그래서 기존의 텍스트모드인 UI도 통합하여 단순한 모니터링 프로그램 이라기보단.... 약간 IDE 필나게.. GUI를 만들어보는것도 괜찮을것 같습니다.
2. 공유메모리 부분 개선!
DCC에서 IPC를 위해서 사용하는 공유메모리가 관리하기 상당히 까다롭습니다.
다들 아시다시피 빌드 시작시점에 초기화및 공유메모리키를 생성해 줘야하구요.. 빌드 종료시점에 지워줘야 해서 예상치 못한 원인으로 빌드 중간에 coordinator가 종료되면 공유메모리가 그대로 남아있는 경우도 생기고요....
무엇보다 conf파일을 참조해서 key값을 받아오는 방식이 상당히 비효율적이라고 생각 됩니다.
아무래도 동기화같은 상당히 머리아픈 문제들이 많이 걸려있어서.. 고려를 못했을지도.. ㅎㅎ
어쨋든 지금과 같은 방법은 문제가 있기때문에 좀더 심플한? 방법으로 다시 개선해 봐야 겠습니다.
3. 멀티빌드? 가가능하도록 개선!
현재 DCC는 한순간에 하나의 빌드만 수행가능한데요.. 여러 사용자가 사용하는 분산처리 시스템에서 멀티 태스크가 안된다고 하면.. 문제가 있겠죠.
일단 Agent쪽은 설계가 잘되있어서? 인자로 받은 ip주소로 리턴 파일을 넘겨주니.. 어떤 coordinator가 작업을 요청하더라도 별 문제가 없을 것같은데..
문제는 coordinator와 파일 broadcast하는것인데요..
broadcast문제는 Coord의 Space를 사용하지 않고 가능한 방법으로 개선중에있구요.. 금방 구현될듯 합니다. ㅎㅎ
coordinator은 지금은 잘모르겠지만 일단 agent쪽에서 coordinator의 ip별로 폴더가 구분되기때문에 조금만 생각을 해보면 금방 해결 방법이 나올것같습니다.
4. 성능향상 비용절감!
이 문제는 프로젝트 시작부터 ver1.0 이후 까지 계속 고려해바야할 문제이기 때문에 일정을 정해서 진행하기는 힘들다고 생각합니다. 하지만 분산처리의 목적이 성능향상과 빌드 시간에 단축에있기 때문에 DCC에서 상당히 중요한 문제라고 생각합니다. 따라서 성능을 향상 시킬수 있는 아이디어나 의견이 있다면 게시판을 통하여 제시하고 테스트를 통하여 적용 여부를 결정하는 방법으로 진행했으면 좋겠습니다.
그리고 현제 세마포어와 동일한방식으로 동작하는 프로세스 풀이 성능향상에 도움이 되는지 의문입니다.
테스트를 통한 검증이 없었고.. 그냥 이럴것이다. 라는 가정만으로 만든 부분이기때문에.. 어쩌면 불필요한 비용만 발생시키고 있을지도 모르기때문에.. ver1.0 전까지 테스트 후 적용 여부를 결정할 필요가 있을 것 같습니다.
얼마전 distcc VS dcc 성능테스트를 해밨고 동영상도 찍어뒀습니다. 아직 편집은 안했지만..
일단 결과는 agetn를 2대, 3대, 4대 5대 붙였을때 distcc보다 20초 정도 빨랐습니다. wine을 빌드했구요..
전처리를 분산함으로써 기존의 분산컴파일 시스템보다 빠를 것이다 라는게 DCC의 차별화 전략인데.. 아직까지는 distcc보다 빠르다는 것을 채감을 할수 있을 정도는 아닌 것같습니다. 성능상의 차별화가 없다면... 사용자들은 좀더 익숙하고 사용하기 편한 것을 선택할 것 같습니다.
1.0을 위한 첫 단계로 DCC ver1.0을 위한 구체적인 목표를 정했으면 좋겠습니다.
그리고 네이버 개발자 센터에 검증된 산출물만 올리기 보다는 지금 블로그처럼 자유롭게 사용해보는 건 어떨까요? svn 서버도 직접 접근 가능하고 블로그보다 게시물 관리하는 것도 편할 것같구요.. 게시판도 카테고리만 잘 분류해서 사용하면 블로그 자료를 모두 이전해서 통합하는 방법도 괜찮을것같습니다.
아무래도 DCC의 기능추가나 소스코드 정리 같은 작업을 개인적으로 진행하는 것보단 1.0까지 개선해야할 목표를 정해두고 일정을 세워서 진행하는게 좀더 적극적으로 참여할 수 있고 빠른 방법이라고 생각합니다.
DCC를 ver1.0까지 끌어올릴려면 ??
일단 지금까지 나온 의견과 제가 생각하고 있는겄들은...4가지 정도입니다.
1. 모니터링 프로그램 개선!
현재 모니터링 프로그램에서 버그가 좀 발생한 것같습니다.
음... 버그라기보단 저희가 더스트가 여러번 발생할 경우를 고려하지 않고 만들어서 그런것 같구요..
Agent로부터 리턴받아야할 파일이 1개 이상일 경우 DS 메세지를 받을 배열의 크기가 부족해서? 세그멘테이션 오류가 발생하는데요..
모니터 프로그램이 아무래도 프로젝트 막바지에 급하게 만들려고 하다보니 설계도 없었고....
기능추가나 비쥬얼 적인것들도 많이 고려를 못해서 이참에 새로 만들어보자는 의견이 나왔습니다.
그래서 기존의 텍스트모드인 UI도 통합하여 단순한 모니터링 프로그램 이라기보단.... 약간 IDE 필나게.. GUI를 만들어보는것도 괜찮을것 같습니다.
2. 공유메모리 부분 개선!
DCC에서 IPC를 위해서 사용하는 공유메모리가 관리하기 상당히 까다롭습니다.
다들 아시다시피 빌드 시작시점에 초기화및 공유메모리키를 생성해 줘야하구요.. 빌드 종료시점에 지워줘야 해서 예상치 못한 원인으로 빌드 중간에 coordinator가 종료되면 공유메모리가 그대로 남아있는 경우도 생기고요....
무엇보다 conf파일을 참조해서 key값을 받아오는 방식이 상당히 비효율적이라고 생각 됩니다.
아무래도 동기화같은 상당히 머리아픈 문제들이 많이 걸려있어서.. 고려를 못했을지도.. ㅎㅎ
어쨋든 지금과 같은 방법은 문제가 있기때문에 좀더 심플한? 방법으로 다시 개선해 봐야 겠습니다.
3. 멀티빌드? 가가능하도록 개선!
현재 DCC는 한순간에 하나의 빌드만 수행가능한데요.. 여러 사용자가 사용하는 분산처리 시스템에서 멀티 태스크가 안된다고 하면.. 문제가 있겠죠.
일단 Agent쪽은 설계가 잘되있어서? 인자로 받은 ip주소로 리턴 파일을 넘겨주니.. 어떤 coordinator가 작업을 요청하더라도 별 문제가 없을 것같은데..
문제는 coordinator와 파일 broadcast하는것인데요..
broadcast문제는 Coord의 Space를 사용하지 않고 가능한 방법으로 개선중에있구요.. 금방 구현될듯 합니다. ㅎㅎ
coordinator은 지금은 잘모르겠지만 일단 agent쪽에서 coordinator의 ip별로 폴더가 구분되기때문에 조금만 생각을 해보면 금방 해결 방법이 나올것같습니다.
4. 성능향상 비용절감!
이 문제는 프로젝트 시작부터 ver1.0 이후 까지 계속 고려해바야할 문제이기 때문에 일정을 정해서 진행하기는 힘들다고 생각합니다. 하지만 분산처리의 목적이 성능향상과 빌드 시간에 단축에있기 때문에 DCC에서 상당히 중요한 문제라고 생각합니다. 따라서 성능을 향상 시킬수 있는 아이디어나 의견이 있다면 게시판을 통하여 제시하고 테스트를 통하여 적용 여부를 결정하는 방법으로 진행했으면 좋겠습니다.
그리고 현제 세마포어와 동일한방식으로 동작하는 프로세스 풀이 성능향상에 도움이 되는지 의문입니다.
테스트를 통한 검증이 없었고.. 그냥 이럴것이다. 라는 가정만으로 만든 부분이기때문에.. 어쩌면 불필요한 비용만 발생시키고 있을지도 모르기때문에.. ver1.0 전까지 테스트 후 적용 여부를 결정할 필요가 있을 것 같습니다.
얼마전 distcc VS dcc 성능테스트를 해밨고 동영상도 찍어뒀습니다. 아직 편집은 안했지만..
일단 결과는 agetn를 2대, 3대, 4대 5대 붙였을때 distcc보다 20초 정도 빨랐습니다. wine을 빌드했구요..
전처리를 분산함으로써 기존의 분산컴파일 시스템보다 빠를 것이다 라는게 DCC의 차별화 전략인데.. 아직까지는 distcc보다 빠르다는 것을 채감을 할수 있을 정도는 아닌 것같습니다. 성능상의 차별화가 없다면... 사용자들은 좀더 익숙하고 사용하기 편한 것을 선택할 것 같습니다.
1.0을 위한 첫 단계로 DCC ver1.0을 위한 구체적인 목표를 정했으면 좋겠습니다.
그리고 네이버 개발자 센터에 검증된 산출물만 올리기 보다는 지금 블로그처럼 자유롭게 사용해보는 건 어떨까요? svn 서버도 직접 접근 가능하고 블로그보다 게시물 관리하는 것도 편할 것같구요.. 게시판도 카테고리만 잘 분류해서 사용하면 블로그 자료를 모두 이전해서 통합하는 방법도 괜찮을것같습니다.