'지금까지 해온 공부' 카테고리의 글 목록

지금까지 해온 공부

[ 2006년 10월 ] Panorama 2007.12.05
[ 2006년 9월 ] Multi-Camera Capture using DirectShow 2007.12.05 1
[ 2006년 3월 ] Fish-eye Image Calibration 2007.12.05
[ 2005년 11월 ] Dense Matrix Multiplication using GPU 2007.12.05 1
[ 2004년 12월 ] IBM S/370 VM 2007.12.05 6
[ 2004년 5월 ] 정규표현 -> NFA -> DFA -> Reduced DFA로 2007.12.04 1
[ 2004년 11월 ] Bresenham 알고리즘 및 Etc. 2007.12.04 1
[ 2004년 11월 ] GNEX를 사용한 핸드폰 용 알카노이드 게임 2007.12.04 1
[ 2004년 5월 ] 서버 프로그래밍 (가위바위보 게임) 2007.12.04
[ 2003년 11월 ] MFQ 스케쥴링 알고리즘 시뮬레이션 (OS) 2007.12.04 3

[ 2006년 10월 ] Panorama

承寶(참참) 2007. 12. 5. 00:12

2007. 12. 5. 00:12

image mosaic

비젼 시간의 과제로 만들어 본 파노라마 영상 생성.
음.. 원래 하는 일이 이거긴 하지만..

워낙 공부를 등한시 하고 살아왔기에.. 비젼시간을 통해서 기본적인 파노라마 영상생성 방식부터..
파노라마 영상은.. 음.. 연속된 이미지 시퀸스를 이어붙여서 만든
넓은 fov를 가지는 영상을 일컫는다.

그럼 만들어보자.
우선은 영상 획득..
이건 교수님이 제공해주셨다. 학교에서 찍었단다.
영상획득시 주의점
Rotation Center의 고정..
Translation 존재시엔 motion parallax와 scale 문제등이 발생하기에..
Center를 고정시키고 Rotation만을 수행해서 사진을 찍는다고 가정한다.

자.. 이게 획득된 영상이다.
사진은 100장.. 맞나? 101장인가.. ?
어쨌든 이미지 시퀸스..
먼저 우리가 할것은 Feature Detection..
harris로 corner를 찾든.. KLT로 찾든.. 직접 찾든..
찾아서 각 영상들 사이의 correspondence를 구해한다. ..

아참.. 지금 하는 건 mosaic method 중에 feature based method..
그렇게 해서 correspondence를 이용해서..
영상들간의 homography를 구한다.
matching했을대 outlier가 많이 존재할 테니까..
RANSAC 알고리즘(지금 하는 공부 부분 참조)을 이용해서 outlier들을 제거하고
inlier들로만 homography를 만들어서
alignment..

그리고 blending.. 하면..
다음 결과 완성.. 여기서 각 부분은 opencv 이용해서 하면 쉽게 해결할 수 있다.
알고보니 opencv에 homography 구해주는 함수도 있던데..
어쨌든.. 파노라마 영상이라.. 괴롭다. ㅡㅡ;

자 이제 이게 완성된 파노라마 영상..
두둥.. 역시 로테이션만 있으니 깨끗하게 잘 붙었군..
그외에 여러 후처리가 있지만 전혀 안해도 되는군..

근데 지금하는건 완전히.. 이런 젠장.. 황당할 정도네 ㅡㅡ;
지금 하는 것도 결과 좋으면 올려볼까나..

[ 2006년 9월 ] Multi-Camera Capture using DirectShow

承寶(참참) 2007. 12. 5. 00:09

2007. 12. 5. 00:09

VFW를 사용해서 흔히들 캠으로부터 영상을 많이 얻어낸다. 간단하고 쉽게 적용할 수 있다. 그 외에도 opencv로도 artoolkit으로도 이용할 수 있다. 하지만.. 다수의 카메라를 빠르게 제어하긴 힘이 든다. 아니 힘이 들었다. 여러대 인식이 안되는 녀석도 있었고.. 매번 세팅창이 뜨거나.. 그리고 무엇보다 여러개를 억지로 띄워도 느리다. ㅡㅡ; 빠르게... 지금 필요한 캡쳐 시스템은 좀 빨라야 하기 때문에.. 어차피.. 딴 일하는데 잠시 이런 캡쳐 프로그램이 필요했으니.. 간단히 만들어보자. 우선 다이렉트 쇼를 공부... 하려고 보니.. 머 이렇게 많냐.. 모르겠는 말이 너무 많다. 이 따위것 다 공부할 시간없는데.. image capture 프로그램 예제로 직행.. Still cap이라는 예제가 DirectX sdk 깔면 들어 있다. 이 녀석을 고쳐서 쓰기로 결정.. 쓰기 어렵게 된 이녀석을 제대로 분류해서 다시 클래스 화 시키고.. 클래스 하나에 완전히 독립된 캡쳐시스템을 구성하여 완성.. 그리고 그 클래스를 여러개로 인스턴스화해서.. 사용하면 끝.. 이쁘게 프리뷰 좀 만들어주고.. 일정간격으로 설정하면 자동으로 캡쳐해주게 좀 바꿔주고.. 카메라들로 부터 들어오는 영상의 sync 맞춰주고 하면 오케이.. 그럼 저 녀석이 탄생한다. 뭐 만들어진 예제 참고해서 다시 고쳐 내는 작업이었기에 얼마 걸리지도 않는다. 다시 클래스화하고 sync 맞춰서 이미지 저장되게 하는게 조금 걸리적 거리긴 하지만. 그리고 간단한 directshow의 함수들 기능만 이해하면.. 이런건 공부가 아니라.. 단순 노가다.. 이게 더 편한데.. 거참.. 어케 된 영문인지.. 공부랑 거리가 먼가.. ㅡㅡ; written by chamcham reference : microsoft directX 9.0b

[ 2006년 3월 ] Fish-eye Image Calibration

承寶(참참) 2007. 12. 5. 00:06

2007. 12. 5. 00:06

fish-eye lens를 사용하여 촬영된 이미지는 radial 방향과 tangetial 방향으로 극심한 왜곡을 가진다. 그럼 이 영상을 보정해서 펴 보자. 수 많은 방법이 있지만.. 쉽게.. 간단하게 펴 보자.

위의 사진이 fish-eye lens camera에서 획득된 사진이다. 이 사진은 인터넷 어딘가의 샘플이미지 였던거 같다. 구글 이미지에서 검색 가능.. 어쨌든 이 녀석을 펴 보면 된다. 쉽게 하면 디게 간단하다.

이 영상이 펴본 모습.. 어려운 다항식을 많이 사용할수도 있지만.. 여기선 렌즈의 곡면을 구면이라고 가정을 하고 펴보았다. 이때 camera의 focal length를 알고 있다면 이 작업은 수월하게 끝이 난다. 바로 다음 그림과 같이 보정 작업을 수행하였다.

즉 렌즈의 곡면이 저 구라고 보면 구 상에 맺힌 이미지가 왜곡된 이미지 일거다. 그럼 왜곡된 이미지의 한점을 노란색 평면으로 보내는 식을 생각해보면 쉽게 풀릴 일이다. 구면과 평면사이는 직각삼각형의 모양을 이루므로 다음 그림과 같이 Focal length의 값과 L값, 그리고 왜곡된 점의 좌표를 알고 있으면 보정된 점의 좌표를 구할 수가 있다. but, 항상 이쯤에서 주의할점.. backward mapping할것... 설명하기는 forward mapping이 좋지만.. hole이 생기는 것을 방지하려면 backward mapping이 좋다. 아니면 interpolation해서 메우던가.. 어쨌든 이 내용도 논문에 나왔던 내용..

written by chamcham

reference : 신주홍, 남동환, 권기준, 정순기, "Ellipsoid를 이용한 어안렌즈의 non-metric 접근 왜곡 보정 기법", HCI 2005 中

[ 2005년 11월 ] Dense Matrix Multiplication using GPU

承寶(참참) 2007. 12. 5. 00:02

2007. 12. 5. 00:02

Matrix Multiplication은 상당히 잦은 연산중에 하나다. 이 연산의 효율은 상당히 떨어진다. 이 연산을 빠르게 할수만 있다면 얼마나 많은 프로그램에서 보다 빠르게 프로그램을 구동할 수 있을까? 빠르게 하려면 어떻게 해야 좋을까? 놀고 있는 그래픽 카드를 써보자. 그래서 유로그래픽스에 발표된 논문이 바로 Matrix Multiplication이란 논문이다. 수업시간에 과제를 겸해서 이걸 간단하게 이 논문 내용을 구현해 보기로 했다. 미리 말하지만.. 3x3, 4x4 행렬의 곱을 말하는 게 아니다. Dense Matrix.. 즉, 데땅 큰 행렬만 취급한다. 실험은 32x32부터 1024x1024까지 해봤다. 그래픽 카드는 Geforce 6200, 6800에서 해봤고.. 최근에 7900에서 해봤다. 결과적으로 빠르다. 아니 빨라야 정상이다. 하지만, 6200의 경우 Dense한 정도가 낮으니 오히려 느려졌다. 물론 논문에서 처럼 수학전문 라이브러리를 쓴건 아니지만... 여튼.. 그런 cpu 알고리즘 보다 늦었다. 이유는.. 그래픽카드에서 메인 메모리로 넘겨주는 버스 속력이 느리기 때문에.. 하지만 매트릭스가 dense할 수록.. cpu는 급격히 느려지는 반면.. gpu는 그 느려짐이 완만해 졌다. 즉, gpu내부의 연산 능력은 훨씬 빠르다는 뜻.. 최근의 7900에서 테스트 결과.. 버스 스피드도 많이 개선되었고.. gpu 자체의 속력도 엄청나게 올라갔다. 그래서.. 훨~~씬 빠른 계산 능력을 보여줬다. 그럼 결론은 여기까지 하고.. 그럼 어케 그림 그리는 그래픽 카드로 계산을 하느냐.. 그래픽 파이프 라인안에 우린 손을 델 수 있으니까.. 제한적이긴 하지만.. shading language로 fragment 부분을 프로그래밍 해주면 된다. 물론 데이터는 texture에 넣어서 넘겨주고.. 그렇게 텍스쳐에 n x n 행렬을 넣어주고 그걸 읽어와서.. 계산을 해주면 그래픽 카드는 병렬처리하니까.. 더 빠르게 계산될테고.. 처리해서 다시 graphic buffer에 써주면 된다. 그 buffer에서 다시 데이터를 읽고 그걸 출력하면 끝.. 이때 graphic buffer에서 데이터를 읽을때 무진장 긴 시간을 소비한다. 여기서 bottle neck 발생.. 여튼 아직 공부도 더 필요하고 개선될 여지도 많은.. 재미있는 분야.. 다만.. 뭔가 다른 주제 하나를 가지고 있어야.. 이걸 응용하는 것이 가능할듯.. 기존에 했던 작업을 이걸로 더 개선한다거나 하는.. 언젠간 공부한거 써 먹겠지.. 교수님 말 안듣고.. 혼자 심심해서 해봤던 공부.. 음.. 덕분에 많이 손해봤지만.. 그래도.. 나름 재미있었는데.. ㅋ

[ 2004년 12월 ] IBM S/370 VM

承寶(참참) 2007. 12. 5. 00:00

2007. 12. 5. 00:00

1970년대 IBM에서는 S/360의 뒤를 잊는 S/370이라는 메인프레임 컴퓨터를 시판했다. 현재 PC의 근간이 되는 구조를 가진 컴퓨터로서.. 이때 처음 가상메모리 개념을 도입했다고 한다. 컴퓨터 크기는 큰 방 하나를 메울 정도 이고.. 지금 이 컴퓨터를 보려면 서울에 국립 무슨 박물관 가라고 하던데... 어쨌든.. 이 컴퓨터가 중요한 이유는 현재 PC의 레지스터리구조라던가 메모리 구조등 모든 것이.. 이 컴퓨터로부터 파생되었다는 것이다. 그래서 지금도 S/370의 어셈블리 랭귀지를 가르침으로서 컴퓨터의 동작원리를 가리치는 곳이 많다고 한다. 라는게... 나이드신 교수님들의 설명이다. 음 과연.. 뭐 확실한 건.. 이 녀석 구조가 ARM 프로세서랑 유사하다. 전에 심심해서 ARM 단기코스 교육 받으러 간적이 있었는데 그때.. 보니.. 거의 유사했다. 그래서 거의 놀면서 들을 수 있었다. 어쨌든.. 이제 사라진 이 컴퓨터를 만들어 보자. 이 컴퓨터는 입력을 천공카드로 받는다고 한다. 그래서 프로그래밍 시트에 코드를 적어서 뚫어서 입력으로 넣는다. 헐.. 그렇게 만들수는 없으니까.. 일단 구조를 파악하고.. 입력은 TEXT 파일로.. 자 컴퓨터라면 기계어 명령을 받아서 그것을 처리해서 그 결과를 보여줄 수 있어야 할 거다. 하지만 기계어로 코딩할 수 있는가? 재주 좋은 분들이라면 몰라도.. 난 한줄이상 기계어로 코딩 못한다. 그럼 최소한 컴파일러는 없더라도.. 어셈블러 정도는 탑재해야 할거다. 그리고 간단한 매크로를 처리할 수 있는 매크로 프로세서도 전처리로 넣어주는게 예의아닌가.. ? 난 예의가 있으니까.. 넣어주기로 결정.. 하지만 문제는 시간.. 과제도 해야하고.. 학교도 다녀야 하고.. 내 공부도 해야하고.. 만화도 봐야하고.. 게임도 해야하고.. 교수님한테 혼도 나야하고.. 여자도 좀 만나봐야겠기에.. 이럴 시간이 없었다. 그당시엔.. 지금은 시간 많다. " 저는 시간이 많아요. 웃을때까지. 쭉쭉쭉 쭉쭉쭉" ㅡㅡ;; 그래서 방학이되면 틈틈히 교수님께 체크 받으면 만들어갔다. 가장 큰 문제는 자료가 없다는 것! 당시 배우던 시스템 프로그래밍 책 외에는 자료가 단 하나도 없었다. 도서관에 누렇게 빛바랜 책이 두어권 있었다. 서베이했지만.. 논문 다운로드 불가.. 그시절엔 그걸 어떻게 하면 다운 받을 수 있는지도 모르고.. 그렇게 그렇게 시간만 끌면서 하나하나 만들어갔다. 가장 먼저 만든 것이 M6 매크로 프로세서 전처리로 이녀석을 탑재하기로 했다. 매크로 프로세스는 문자 입력을 단순 반복을 통해서 처리해주는 녀석이라서.. 걍 잘 만들어주면 된다. M6 매크로 완성 장착! 잊지말자.. 입력은 S/370 어셈블리 소스코드.. 전처리 된 것을 .. 이제 어셈으로 기계어로 바꿔줘야 한다. 그렇다면.. 필요한 것은 S/370 어셈블러 뚝딱뚝딱.. 처음에 명령어들이 제대로 나와 있지 않아서 찾느라 고생하고.. 이해를 잘못해서 잘못짜고.. 완전 엉망진창이었다. 고치고 고치고.. 결국 완성.. 기계어로 주루룩 출력.. 이제 만들 녀석은... 링커.. 소스 파일은 한개가 아니다. 헬로씨 만들거도 아니고... 소스 파일이 하나만 있을리가 없다. 소스 파일이 여러개고 여러개라면 ... Extern 으로 선언된 녀석도 있을 것이고.. 여튼 통합해줄 링커가 필요하다. 철컹.. 만들어서 장착.. 이제 진짜 진짜 마지막.. 가장 핵심 Interpreter 가 등장할 차례.. 이제 완성된 기계어 코드를 읽어서 할당된 메모리에 올리고 그 메모리에서 PC가 가르키는 부분을 읽어서 명령어 레지스터에 명령어 넣고.. 명령어 분석해서.. 데이터 읽어들이고.. 그걸 ALU가 처리하고. .등등등... 이러한 작업을 할 우리의 S/370 컴퓨터가 있어야 한다. 그 녀석이 위에 보이는 인터프리터.. 매크로 프로세서나 어셈블러, 링커까지는 유닉스상에서 작성하는 바람에.. 콘솔모드용 프로그램이었는데.. 인터프리터는 걍 윈도우용으로 만들어봤다. 물론 유닉스에서 짠 것도 윈도우 콘솔에서 돌아가도록 다 바꿨지.. 인터프리터 내부에 Arithmetic 연산을 처리할때.. 이 부분은 객기 부린다고 인라인 어셈으로 짰었다... 왜 그랫지? ㅡㅡ; 그냥 그러고 싶었다.. 여튼 그렇게 뚝딱뚝딱 해서 이 녀석 완성.. 레지스터 상태라던가 메모리 상태.. 결과 윈도우.. 입력 기계어.. 현재 동작 상태.. 등을 보여준다.. 생긴건 저래도 저게 S/370 프로그램이다. 그럼 정리해 보면.. 1. 입력 (S/370 어셈블리 코드) 2. M6 매크로 프로세서가 전처리 3. S/370 어셈블러가 기계어로 번역 4. 링커가 통합 5. 인터프리터가 기계어를 수행 6. 출력 (어셈블리 코드가 수행된 결과 출력) S/370에서 여러 파일로 된 제대로 된 코드를 구하질 못해서 책에 나온 입력 수 5개에 적당한 값을 곱해서 출력하는 예제 소스를 이용해서 테스트 해봤다. 물론 인터프리터가 S/370의 전체 명령을 지원하는 건 아니다. 지원하는 건 전체 명령의 70%정도.. 나머지 명령을 쓰는 예제도 드물고.. 명령어의 제대로 된 형태도 안나와 있어서.. 실제 시스템 소프트웨어 책에서 소개하는 건 50%도 안된다. 그나마 다른 책에서 찾아서 많이 끼워넣은거다. ㅡㅡ; 여튼 이렇게 수행이 된다. 이걸 다 합쳐서 하나의 IDE로 만들어 줘야 하는데.. 급 귀차니즘 발동.. 하기 싫다. 윈도우 디지인 다시하기도 싫고.. 어쨌든.. 지금은 이때랑 많이 다른 일을 하고 있지만.. 모르는 걸 찾아보고 해결하려고 노력한다는 점은 비슷한 거 같다. 하는 동안 정말 재미있었던거 같다. 컴퓨터 시스템 쪽으로 대학원 찾아서 갈까라고 심각하게 고민할 정도로.. 하지만 뭐든.. 난 너무 어중간해서... ^^;

written by chamcham

[ 2004년 5월 ] 정규표현 -> NFA -> DFA -> Reduced DFA로

承寶(참참) 2007. 12. 4. 23:58

2007. 12. 4. 23:58

컴파일러 시간이었다. 학부시절 담당 교수님 수업.. 항상 엄하고.. 갈구고.. 그랬지만.. ㅋ 그래도... 강의 능력만큼은 탁월한 분... 내가 본 사람들 중에서 가장 쉽게 지식을 전달하는 분 같다. 어느 곳에서도 그렇게 쉽고 명료하게 전달하는 분은 없었던거 같다. 그 시간에 배웠던 이것.. 물론 내 머리속 메모리는 Short Term과 Sensory 뿐이라서.. 데이터를 오래 담지는 못한다. 그 시절.. 과제였다. 단순히 정규표현을 받아서 처리하는 건데.. 생각보다 애 먹었었다. 정말.. 뭐 이따구인지... 보통 NFA 를 DFA로 바꾸는 알고리즘을 소개한 책은 많다. 하지만 문제는 Regular expression을 NFA로 바꾸는 과정.. 생각보다 감안해야할 문제가 많았다. 그리고 Reduce하는 것도.. 물론 NFA를 DFA로 만드는 것은 알고리즘도 다 나와있고.. 쉽다. 그렇게 해서 쭉 만들어 봤다. 리눅스에서 작성한 터라... 그래피컬하게 만들어보진 않았지만.. 그래피컬하게 나타내봐도 재미있는 프로그램이 될 듯하다. 어쨌든 거의 한달간 머리싸메고 이거 오류없이 입력받고 처리할 수 있는데만.. 초점을 맞춘거 같다. 이거 다해서 보고서랑 PT 정리해서 가져갔을때 하는 말.. " 이거 단순하게 했자나? 이걸로 뭘 시간을 끌고 그래? " 라는 말을 들었다. ㅠ.ㅠ 에공~ 아마 이때... 컴파일러관련 지식을 머리에서 다 지웠는가 보다 ㅡㅡ; written by chamcham

[ 2004년 11월 ] Bresenham 알고리즘 및 Etc.

承寶(참참) 2007. 12. 4. 23:55

2007. 12. 4. 23:55

이것 역시 과제였던 거 같다. 흔히 선 긋는거랑.. 원그리는거... 쉽다. 그냥 라이브러리에서 호출해주면 된다. OpenGL이라던가.. OpenCV등등... 직접 점 찍어서 그려본 적은 있는가? 예전에 Direct X 처음 배웠을때 버퍼락 걸고 점찍는거 배웠을때 처음 해 본게 선 긋는거 였다. 생각보다 잘 되지 않았다. 그래서 Bresenham 알고리즘을 보고 선긋는 걸 해결했던 기억이 난다. 이 과제 역시.. Bresenham 알고리즘이라던가. midpoint 알고리즘 등을 이용해서 선을 긋고, 원을 그리는 작업을 하는 프로그램이다. 그리고 그려진 Transform을 주면 그 결과를 출력해주는 간단한 프로그램이다. 그다지 특별할 것도... 힘들 것도 없는 거지만.. 그래도 예전에 처음 Direct X 배울때 생각나서 재미있었다. 물론 그전에도 선을 그어본 기억은 난다. 처음 도스에서 어셈코드로 점찍는 거 배웠을때.. 그때나.... DirectX나.. 별반 다른건 못느끼겠다. 지금은 뭐 맨날 OpenCV만 쓴다만.. 여튼.. 그랬던 것이었다. ㅡㅡ; written by chamcham

reference : bresenham 선그리기 알고리즘 (http://www.cs.helsinki.fi/group/goa/mallinnus/lines/bresenh.html)

[ 2004년 11월 ] GNEX를 사용한 핸드폰 용 알카노이드 게임

承寶(참참) 2007. 12. 4. 23:50

2007. 12. 4. 23:50

무선 통신 어쩌구 하는 수업이었는데.. 그다지 관심이 없었던 탓인지 재미를 못느꼈다. 계속 잠만 잔거 같다. ㅡㅡ; 그러던중 과제 등장.. 신지에서 만든 GNEX용 게임을 만들어 보라는 것! 과연... 이.. 이럴수가.. 레퍼런스가 한글이다. 이렇게 반가울 수가.. 그리고 게임용 플랫폼인지라.. GNEX 개발툴에는 게임 제작을 위한 기본툴들이 다 제공 되고 있었다. 그래픽 에디터까지.. 난.. 어디서든 간단한 게임을 만들자고 하면.. 가장 먼저.. 항상 알카노이드를 만든다. 다이렉트 X를 공부할때도 그랬고.. GDI를 공부할때도 그랬고.. 항상. 그래서 이번에도 알카노이드.. 블럭을 그리고.. 막대를 그리고.. 공을 그리고.. 뚝딱뚝딱.. 이미지 로딩하고... 그 이후엔 어디서 만들든 게임 프로그램은 똑같지.. 머.. 샥샥.. 이 게임의 중요한 부분은 충돌처리뿐.. 레퍼런스가 한글이라서 너무 프로그램짜기 쉽다. 그리고 IDE도 제공되고.. 편집툴까지 주는데... 이까이꺼 만드는데 몇시간 걸리지도 않는다.. 완전 GNEX는 게임 짜기에 편리한 환경을 제공하고 있었다. 하지만, 핸드폰 특성상 다중키 입력도 지원되지 않고.. 쩝.. 문제가 좀.. 그래도.. 심심타파.. 재밌었다...

[ 2004년 5월 ] 서버 프로그래밍 (가위바위보 게임)

承寶(참참) 2007. 12. 4. 22:09

2007. 12. 4. 22:09

학부때.. 정보통신학과에서 가서 수업을 들은적이 있다. 네트워크 관련 수업은 모두 여기서 들었지 싶다. 네트워크 프로그래밍 2란 수업이었는데.. 그 시간에 과제로 나온 프로그램이다. 진짜 단순한 게임으로 클라이언트들이 접속하면 그 클라이언트들끼리 가위,바위,보를 계속하게 만드는 프로그램이다. 그래서 승수라던가. 뭐 이런걸 기록하는.. 교수님께서 클라이언트를 작성해주시면 그 클라이언트에 프로토콜을 맞춰서.. 서버 프로그램을 작성하면 된다. 다른 사람의 프로그램과 프로토콜을 맞춰본다는 것에서 재미를 찾을 수 있었다. 그닥 어려운 것도 없었고.. 참여 클라이언트의 인원수는 리소스가 허용되는 만큼 무제한으로 받도록 했다. 뭐 그다지... 난이도가 있는 것도 아니고.. 그냥 재미로 한번 해볼만한 것 같다

[ 2003년 11월 ] MFQ 스케쥴링 알고리즘 시뮬레이션 (OS)

承寶(참참) 2007. 12. 4. 22:05

2007. 12. 4. 22:05

운영체제 시간이었다.
학부시절 운영체제 과제는 항상 팀과제였다.

하는 것은 스케쥴링 알고리즘을 시뮬레이션 해보는 프로그램 작성..
RR, SRT, MLQ, MFQ 등을 선택해서 만드는데..
MFQ 같은 경우는 multiple feedback quene라서..
RR, SRT등을 다 구현해야한다.

그래서 항상 사다리로 결정..
그래서.. 사다리를 탔다. 재수없는 놈은 뒤로 넘어져도 코가 깨진다고..
MFQ 결정..
그냥 만들어야지 뭘..

초반엔 각 스케쥴링 알고리즘에 대한 조사를 했다.
그당시.. 하고 있던 일이 있어서.. 초반엔 간단한 조사들을 조원들에게 역할을 나눠부탁하고..
서베이해 온것을 토대로 프로그램을 내가 작성하기로 했다.

그 무렵 교수님 밑에서 S370 매크로프로세서랑 어셈을 만들고 있던 때라서..
뭔가 여기에 집중이 되질 않았다.

그러다.. 역시 급하니까.. 여기에 매달리게 되더이다..
처음엔 스케쥴링 알고리즘들을 자료를 보며 공부하고.
각 큐별로 사용될 알고리즘을 결정하고..
각 큐를 클래스화 시키고..

그 클래스들 사이의 인터페이스를 결정해보았다.
그렇게 해서 간단한 Text version으로 먼저 작성을 했다.

여기까지 2주가량의 시간 소모..
그리고 그 다음 한주를 Debugging과 수정에 소모했다.
그리고 Text version의 완성..

다음은 그냥 MFC로 그냥 나타내주면 되는거다.
걍 GDI로 쭉쭉 그렸다.
쭉쭉쭉 쭉쭉쭉.. 저는 시간이 많아요.. 될때까지 쭉쭉쭉 쭉쭉쭉.. ㅡㅡ;;

팀원들과 교수님이 지적한 사항 수정..
다듬고 수정.. 내 맘대로 결국 수정..

그렇게 해서 이 프로그램을 완성한 것 같다.
그닥.... 짐 보니 상태는 별루네..
여튼.. 뭐 그런거다. 이 바닥이 다 그렇지..

이런건 차라리 간단하다.. 헐.. 지금 하는건 왜 일케 안풀리냐.. ㅠ.ㅠ

written by chamcham

PREV 이전 1 2 NEXT 다음

Vision