20113313 이창현 Optimizing merge program

1. 고급시스템프로그래밍
Optimizing merge program
컴퓨터공학과
20113313 이창현

2. Merge.c 코드는..
1. 두개의 파일을 하나로 합치는 프로그램이다.
2. 각 파일을 한줄씩 읽고 번갈아가며 새로운 파일에 write한다.
3. 입출력에 파일스트림을 이용한다.

3. 최적화 1) 파일 입출력함수 변경
open함수는 시스템에서 제공해주는 버퍼를 이용하며, fopen함수는 C 표준 라이
브러리에서 할당해주는 버퍼를 이용한다.
fopen()함수는 이중버퍼를 사용하며 파일에서 한번 데이터를 읽어온 후 다음번에
얼마정도의 데이터를 가져올지 모르기 때문에 버퍼에 미리 얼마간의 데이터를 적
재함으로서 system call횟수를 줄인다.
하지만 merge.c와 같이 사용자가 파일에서 어느정도 크기의 데이터를 가져올지
알고있을 때, open함수로 한번의 system call에서 필요한 데이터를 모두 가져오는
것이 파일read를 여러번 실행하는것보다 system call 횟수를 줄이기에 효율적일
것이다.

4. 최적화 1) 파일 입출력함수 변경
파일 입출력함수를 바꾼 모습.
read()함수로 100메가 크기의 파일을
메인 메모리로 한번에 읽어왔다.
(merge_read_write.c)
합쳐진 파일을 write할때 또한 200메가
크기를 한번에 write해주었다.
>> 결과: 실행시간이 절반가량 줄어듬
(119초=>55초)

5. 최적화 2) 병렬프로그래밍
오른쪽 사진은 라즈베리파이 내의 CPU 갯
수가 4개임을 알려준다.
이와 같은 다중코어 시스템에서는 여러개
의 스레드를 동시에 사용하면서 실행시간
을 단축시킬 수 있다.
> less /proc/cpuinfo

6. 최적화 2) 병렬프로그래밍
본 코드에서는 병렬프로그래밍을 더 쉽게 적용하기위해 오픈소스 라이브러리중
하나인 OpenMP를 이용했다.
그림1은 두 개의 파일을 읽는 행동을 동시에 하도록 만든 task parallel코드
그림2는 reverse함수 for-loop의 각 루프가 서로 dependency가 없으므로 적용시
킨 data parallel코드 (merge_openmp.c) * 컴파일시 –fopenmp 옵션필수
그림 1. 파일read 병렬화 그림 2. reverse함수 병렬화

7. 최적화 2) 병렬프로그래밍
하지만 총 실행시간은 오히려 늘어났다! (파일입출력 수정버전 55초->80초)
이유: reverse함수는 수없이 많이 실행되는 함수.
실행시킬때마다 각 스레드에 할당시키는것 또한 context switch에 따른
overhead가 발생하며 overhead로 발생하는 낭비가 스레딩으로 줄어든
시간보다 컸음을 의미한다.
결론: 병렬프로그래밍을 적용할 다른 방법을 찾아야 한다.

8. 최적화 3) reverse 분할
지금까지는 파일에서 입력받은 두 버퍼에서 한줄씩 읽고 reverse후 바로 출력버퍼에
써주었다.
원본 버퍼를 reverse해주는 부분을 함수로 따로 떼어낸 후 스레드를 할당해보았다.
=> 결과: 오히려 시간이 늘어났다.(파일입출력 수정버전 55초 => 70초)
=> 버퍼에서 한 줄씩 읽어들이는 행동이 overhead로 작용했다.
reverse함수 병렬화
[merge_divide_reverse.c]

9. 최적화 4) write 분할
Race condition때문에 두 입력버퍼에서 한줄씩 읽어 출력버퍼에 쓰는 행동을
동시에 할 수는 없다.
출력버퍼에 쓰는 코드를 앞구간과 뒷구간으로 나눠 각각 스레드를 할당해주면
실행시간을 좀 더 줄일 수 있을것이다.

10. 최적화 4) write 분할 코드
[merge_divide_outbuf.c]
Merge의 앞구간과 뒷구간으로 section이 나뉘어졌다.
두 스레드가 각각 두개의 입력버퍼를 한줄씩 읽으면
서 reverse후 출력버퍼에 써준다.
두 출력버퍼가 완성되면 write로 파일에 씌여진다.
=> 결과: 실행시간이 약간 줄어들었다.
(파일입출력 수정버전 55초 -> 30초)
=> 여기에서는 스레드 2개까지밖에 활용하지 못했지
만 스레드 4개를 모두 활용한다면 더 좋은결과가
나올 것이다.

11. 측정결과
단위: sec
표의 reverse는 문자열 뒤집기만 적용한 버전으로 fgets()함수를 사용하면서 system
call횟수가 줄어든 결과 원본보다 오히려 실행시간이 줄어들었다.
System call이 최소화되도록 입출력함수를 바꿔준 것과, 출력버퍼에 쓰는 구간을 나눠
각각 스레드를 할당해준 것이 실행시간을 줄이는데 효과가 있었다.
성능개선 최종결과: 119.83초 => 30.40초 (119.83 / 30.40 * 100) = 25.3%

12. 여기까지 1차제출 내용..

13. 1차제출 코드를 리팩토링 해보자
1. 현재 시스템의 코어갯수를 자동으로 얻어내어 병렬화.
2. 출력이 제대로 나오지 않는 버그를 수정.
3. 파일의 크기가 서로 달라도, 어떤 크기라도 merge할수있도록 수정.
4. 매크로 함수, 레지스터변수 사용.
5. 파일입출력과 동적할당부분 예외처리.
6. 코드스타일 통일, 주석 갱신.

14. 리팩토링 1~2. 병렬화 수정
기존의 방법대로 입력파일을 단순히 파일사이즈로 나눠주면 파일A와 파일B가 적절히
한줄씩 번갈아가면서 써지지 않는다.
해결법: 병렬화 방법을 바꾼다.
 입력파일의 line들을 묶어 구간을 만든다
 각 구간들을 스레드가

15. 리팩토링 1~2. 병렬화 수정
구간 1
(thread0)
구간2
(thread1)
구간3
(thread2)
구간4
(thread3)
남은 구간
구간1
(thread0)
구간2
(thread1)
구간3
(thread2)
구간4
(thread3)
Thread0
Thread1
Thread2
Thread3
File2 bufFile1 buf 가용thread가 4개인 시스템에서 크기가 같은
두 파일을 merge하는 상황을 가정해보자.
두 파일은 현재 read()함수로 사용자가 할당한
메인메모리 버퍼에 올라와있는 상태. 크기가 같
은 두 파일이라도 총 line수는 다를 수 있다.
File1의 총 line수가 File2의 총 line수보다 많다
고 할 때, File2의 총 line수/4가 하나의 스레드
에 할당해줄 구간의 크기가 된다.
왼쪽 그림은 가용스레드 갯수만큼 나뉘어진 각
구간을 시스템에 존재하는 4개의 코어(스레드)
가 할당받는 장면을 나타낸다.
남은 구간은 두 파일의 총 line수가 같지 않아
생겨나는 잉여버퍼이며 보통 크기가 그다지 크
지 않아 병렬화없이 순차적으로 처리할 것이다.

16. 가용코어 갯수를 시스템으로부터 얻어내는 코드
라즈베리파이2는 4개의 코어를 갖고있으므로
출력은 ”4 thread parallization”이 될것이다.
각 파일을 통째로 메인메모리의 버퍼에 올린
후 총 line수를 얻어내는 코드.
각 파일을 읽고 분석하는 행동에
dependency가 없으므로 병렬화 적용.
리팩토링 1~2. 병렬화 수정 코드(1)

17. 총 line수가 더 적은파일의 line수를 얻어낸 후
각 구간의 시작 line이 몇번째줄인지 계산한다.
리팩토링 1~2. 병렬화 수정 코드(2)
시작line으로 시작cursor(각 구간이 몇번째
character부터 읽어야 하는지) 계산한다.
서로다른 파일(버퍼)에서 parallel하게 이뤄진다.

18. 리팩토링 1~2. 병렬화 수정 코드(3)
구간을 나누기위한 시작커서 설정이 끝났으므로
두 입력버퍼를 번갈아가며 한줄씩 읽어 reverse후 출력버퍼에
써준다.
#pragma omp for은 바로뒤에오는 for문의 각 루프를 스레드에
할당해 병렬적으로 실행시켜주는 OpenMP의 문법이다.

19. 리팩토링 1~2. 병렬화 수정 개
요
구간 1
(thread0)
구간2
(thread1)
구간3
(thread2)
구간4
(thread3)
남은 구간
구간1
(thread0)
구간2
(thread1)
구간3
(thread2)
구간4
(thread3)
Thread0
Thread1
Thread2
Thread3
File2 bufFile1 buf
Out_buf 1구간 1
(thread0)
구간2
(thread1)
구간3
(thread2)
구간4
(thread3)
스레드 갯수만큼 나뉘어져있는 출력버퍼
(남은구간은 나중에 따로써준다)
Out_buf 2
Out_buf 3
Out_buf 4

20. 리팩토링 3. 입력파일이 어떤 크기라도 수용 가능
파일 디스크립터에서 파일정보를 얻어낼수
있는 함수 fstat()을 이용한다.
파일 사이즈가 100M보다 크거나 작아도 상
관없고, 두 파일사이즈가 서로 달라도 정상
적으로 merge되도록 코드를 수정하였다.

21. 리팩토링 4. 매크로 함수, 레지스터 변수 사용
본 프로그램에서 가장 많이 호출되는함수는
reverse내부의 swap함수.
swap함수를 매크로함수로 바꿔주고 가장 자
주사용되는 swap의 임시저장변수를 register
변수로 바꿔주었다.
=> 미미하지만 성능향상이 있었다.

22. 최종 측정결과
(단위: sec) origin: 원본프로그램, optimized: 최종프로그램 merge_final.c
파일스트림대신 파일디스크립터 이용, 병렬프로그래밍, 매크로함수 이용결과 원본 프
로그램에 비해 성능이 4배가량 향상되었다.
4개코어를 모두 사용하면서 2개코어만 이용한 1차제출 결과보다 성능이 향상되지 않은
이유는 버그픽스때 각 파일을 두번씩 순회하는 오버헤드가 추가되었기 때문이다.
성능개선 최종결과: 119.83초 => 30.40초 ( 31.84 / 119.84* 100) = 26.5%