결과

소스를 컴파일하고 링킹하여 나온 실행파일을 실행시켜 나온 결과입니다.

구간은 7679445번째부터 9521831까지이며 그 구간의 값은 17680824079입니다.

링킹할 때 clock.c를 컴파일한 clock.o를 포함하였습니다. 결과로 제일 마지막으로 측정한 결과인 시작점과 끝점, 최대값, counter와 시간(단위 second)를 화면에 출력하였습니다. 그리고 별도로 output.txt라는 파일을 만들어 3000번의 수행 결과에 대한 결과를 저장하였습니다. 이를 엑셀에서 불러들여 평균과 표준편차, boxplot을 만들었습니다.

counter와 time(단위는 μs)를 boxplot으로 그린 것입니다. 왼쪽은 엑셀, 오른쪽은 MATLAB으로 그렸습니다.

몇 개의 값이 크게 나왔습니다. 이는 한 프로세스 당 약 0.13초의 시간이 걸리고, 이를 3000번을 수행하여 총 6.5분의 시간동안 측정하였습니다. 그 동안 다른 프로세스(프로그램)이 작동하여 CPU 자원을 나눠쓰게 되어 이런 일이 발생하였습니다. 이를 최소화 하고자 데몬 서비스를 끄고 동작시켰지만 어쩔 수 없었습니다. 교수님의 제안대로 상위 5%는 없앤 나머지 95%로 진행하였지만 여전히 그러하였습니다.

결과를 표로 정리하였습니다.

작업을 한 노트북 사용환경입니다.

OS : Linux Fedora Core 8

Kernel version : 2.6.25.14-69.fc8

CPU : Intel(R) Pentium(R) M processor 1400MHz

Compiler : GCC 4.1.2 20070925

Editor : vi 7.1.242

하지만 노트북 성능이 그리 좋지 못해 속도가 떨어지는 듯싶어 동아리 서버에서 테스트하였습니다.

그렇지만 동아리 서버가 x86_64인지라 clock.c을 사용할 수 없었습니다.

따라서 교재에서 제공하는 방법으로 하였습니다.

결과값은 동일하게 구간은 7679445번째부터 9521831까지이며 그 구간의 값은 17680824079입니다.

하지만 time에서 훨씬 빨라졌다는 것을 확인할 수 있었습니다.

이 역시 boxplot을 그렸습니다.

counter와 time(단위는 μs)를 boxplot으로 그린 것입니다. 왼쪽은 엑셀, 오른쪽은 MATLAB으로 그렸습니다.

이 역시 몇몇의 값이 크게 나와 깔끔하지 않습니다.

또한, 평균과 표준편차를 구했습니다.

time을 보면 노트북 평균이 243251.6877㎲이지만, 동아리 서버는 81168.52281㎲로 서버가 제 노트북보다 훨씬 좋은 성능(약 3배)을 가졌다는 것을 알 수 있었습니다. 아마도 이것은 long long int에서 노트북은 라이브러리로 구현이 되었겠지만, 서버는 이를 하드웨어적으로 구현하여(왜냐하면 64 bit이기에...) 그 차이가 큰 듯싶습니다.

서버 사용환경은 다음과 같습니다.

OS : Linux Fedora Core 9

Kernel version : 2.6.26.3-29.fc9.x86_64

CPU : Intel(R) Core(TM)2 CPU 6400  @ 2.13GHz

Compiler : gcc 4.3.0 20080428

Editor : GNU Emacs 22.2.1

느낀 점

휴학 기간 동안 공부해보겠다며 잡은 책 중의 하나가 ‘생각하는 프로그래밍’이었습니다. 하지만 그 문제가 매우 난해하여 이해가 아닌 ‘이런 알고리즘이 있구나.’라는 식으로 접근하였습니다. 그렇기에 과제를 처음 들었을 때 전에 보았다는 것을 잊고 있다가 어느 순간 생각이 나서 살펴보았습니다. 그 때까지 짠 코드와 비교를 해보면 제가 만든 것이 복잡하다는 것을 알 수 있었지만, 각 element에 한 번씩 접근하므로 O(n)의 Time Complexity를 갖지 않았나 생각합니다.

교수님께서 제공하신 count.c에 나오는 방법은 x86_64 버전으로 설치한 리눅스에서는 작동을 하지 않았습니다. 그래서 서버에서 count를 교재에서 제공하는 방법인 clock() 함수를 호출하는 것으로 처리하였습니다. 그런데 이것이 맞는 것인지 모호합니다. 왜냐하면 time을 측정한 것에 약 1000000을 곱한 것이었기 때문입니다. 그러하여 서로 비례함을 알 수는 있었지만 제대로 된 측정값인지는 잘 모르겠습니다.

또한, struct를 써서 자주 쓰이는 Max_value에 접근하였습니다. 하지만 구조체의 경우 그 안의 element가 register에 홀로 등록되어 작동이 되도록 컴파일이 되는지 의문이었습니다. 혹시나 하는 마음에 Max_value에 register라는 접두어를 붙이니 에러가 났습니다. 거기에 -O2와 같은 컴파일 최적화 옵션을 넣지도 않았습니다. 그렇기에 이런 부분에 신경을 써서 코딩했다면 조금 더 빠른 프로그램이 되지 않았을까 생각합니다.

마지막으로 입력값들이 int이라는 생각에 sum 역시 long int로 한정시킨 것이 제대로 된 값을 얻지 못한 일이 되었습니다. 강의 Q&A에서 학우들과 정보를 교환하다가 실수를 한 것을 깨닫고 바로 고칠 수 있었습니다. 이래서 discussion이 필요하다는 것을 느꼈습니다.

Reference

count.c

gen.c

존 벤틀리, 유성준, 조상민 역, <생각하는 프로그래밍>, 인사이트, 2006, pp. 149~165

HOROWITZ ? SAHNI ? ANDERSON-FREED, <Fundamentals of Data Structures>, SILICON PRESS, 2008, pp. 44~46

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.