지난글
- HOWTO #1 : OpenMP를 이용한 멀티 쓰레드 프로그래밍 HOWTO #1
- HOWTO #2 : OpenMP를 이용한 멀티 쓰레드 프로그래밍 HOWTO #2
- HOWTO #3 : OpenMP를 이용한 멀티 쓰레드 프로그래밍 HOWTO #3
- HOWTO #4 : OpenMP를 이용한 멀티 쓰레드 프로그래밍 HOWTO #4
목차
0. 시작하기에 앞서
1. OpenMP란?
2. OpenMP의 시작
3. OpenMP를 이용한 work-sharing 모델
4. Loop construct
4.a Loop consturct 기본 형태
4.b 병렬 처리시 주의점
4.c 스케줄링
* 연습문제 (멀티 쓰레딩과 reentrant 함수의 관계에 대한 문제)
5. Section construct
* 연습문제 (섹션별로 task를 할당하는 방법)
6. Single Construct
7. Master Construct
8. Barrier
8.a Implicit barrier
8.b Explicit barrier
9. critical & atomic construct
9.a critical construct
9.b atomic construct
10. OpenMP API
11. OpenMP에서 제공하는 환경변수 및 전처리기
12. OpenMP vs pthread (POSIX thread)
13. 마치면서
9. critical & atomic construct
critical construct와 atomic construct는 공유(shared) 영역을 보호하는 lock의 일종이다. 따라서 critical과 atomic을 사용한 영역은 쓰레드 중에 단 하나의 쓰레드만 진입하고 나머지는 대기하게 된다. 즉 직렬실행구간이 된다. 따라서 역으로 말하면 critical과 atomic을 남발하는 프로그래밍을 하면 성능이 확 떨어진다는 소리이다. 그럼에도 불구하고 꼭 lock이 필요한 기능이므로 잘 익혀두어야만 한다.
우선 둘의 차이부터 이해하고 넘어가자. 만일 두 단어만 보고도 감이 오는 사람은 학생 때 운영체제 수업에서 critical section이나 atomic operation을 배운 사람일 것이다.
• critical : 범용적인 lock
• atomic : critical보다 가볍고 빠른 lock (critical의 special한 케이스)
critical은 노멀한 lock이지만 atomic은 매우 가벼운 용도에만 사용한다. 가볍다는 것은 보통 1개의 스칼라 변수를 업데이트 하는 정도를 의미한다. 만일 변수 업데이트를 넘어서 계산이나 캐스팅, 복잡한 데이터 핸들링을 하는 경우라면 critical을 사용하도록 한다.
[참고로 정수형 변수 1개의 값을 변경하는 정도라면 atomic 없이 프로그래밍을 하는 것도 추천한다. atomic을 쓰지 않으면 수치상의 오류가 생기는 경우도 있겠지만 일반적으로는 10ppm(part per million) 이하인 경우이므로 무시할 수 있는 오차 일 수 있다. 왜냐하면 atomic의 가벼운 lock도 멀티 쓰레드에서는 성능을 많이 떨어뜨리기 때문이다.]
[보충 설명: 일반적으로 공유된 데이터에 복수개의 쓰레드가 접근할 경우에는 무조건 lock으로 보호해야만 한다. 모든 교과서나 매뉴얼에는 이렇게 나와있다. 그러나 프로그래머가 어느 정도 멀티 쓰레드에 대한 이해가 깊어지면 교과서나 매뉴얼을 응용할 수 있어야만 한다. 필자가 앞에서 정수형 변수 1개의 값을 업데이트하는 경우에는 lock을 쓰지 않는 것도 좋다고 했는데 이는 감히 교과서에는 쓸 수 없는 내용이다. 하지만 공유된 변수가 약간의 오차가 생겨도 괜찮은 경우, 즉 근접해나 근사치를 계산하는 시뮬레이션이나 휴리스틱 코드라면 atomic을 쓰지 않을 경우 더 빠르게 작동할 수 있다. 그리고 빠른 실행이 가능해졌기 때문에 시행횟수를 더 늘림으로서 오차를 보정할 수 있게된다. 그러므로 오차 보정이 가능한 수치계산이나 오차보다 속도가 더 중요한 문제라면 atomic을 생략하는 것도 고려하라는 뜻이 담겨있는 것이다. 그러나 주의할 점은 꼭 프로그래밍을 할 때 atomic을 선택적으로 적용할 수 있도록 코딩해두고 atomic을 사용한 버전과 사용하지 않은 버전의 차이를 꼭 비교해봐야 한다. 만일 atomic을 사용하지 않은 버전이 메리트가 없다면 반드시 lock을 사용한 버전을 택하는 것이 좋다.
9.a critical construct
#pragma omp critical [(lock_name)]
critical에서 락 이름(lock_name)을 생략하는 경우는 동일한 lock을 사용하는 것으로 간주되어 critical 지시어가 여러 번 나오더라도 동일하게 보호되는 구간이 된다. 자세한 것은 예제를 보면서 익히도록 하자. 예제로 아래와 같은 pseudo code가 있다.
위의 예제에서 chk_process() 함수가 lock으로 보호되어야 한다면 critical 지시어를 사용하여 아래와 같이 할 수 있다.
#pragma omp parallel for
for (i = 0; i<MAX_ITERATION; i++) {
process_a();
#pragma omp critical
chk_process();
process_b();
#pragma omp critical
chk_process();
process_c();
chk_summary();
}
|
그렇다면 이번에는 chk_summary()에 critical을 추가해보겠다. 하지만 chk_process()와는 상관없이 다른 락으로 보호하도록 하겠다. 이 경우에는 필수적으로 lock_name을 사용해야 한다.
#pragma omp parallel for
for (i = 0; i<MAX_ITERATION; i++) {
process_a();
#pragma omp critical (lock1)
chk_process();
process_b();
#pragma omp critical (lock1)
chk_process();
process_c();
#pragma omp critical (lock2)
chk_summary();
}
|
9.b atomic construct
#pragma omp atomic
atomic은 스칼라 변수 한개를 업데이트 한다고 했다. 너무 간단하기 때문에 간단한 예제 하나로 끝내겠다.
#pragma omp parallel
...생략...;
#pragma omp atomic
n_count++;
}
|
atomic에서 쓸 수 있는 표현식은 ++나 --같은 unary operation이나 "변수=값"정도의 간단한 대입식 정도이다.
10. OpenMP API
앞에서 omp_get_thread_num() 같은 openmp의 함수들을 보았다. 이번에는 주로 사용되는 함수들을 정리해서 보도록 하겠다.
* 쓰레드 풀에 관련된 함수들
void omp_set_num_threads(int num_threads); 병렬 구간에서 생성할 쓰레드 개수를 설정
int omp_get_num_threads(void); 병렬 구간에서 생성할 쓰레드 개수를 리턴
int omp_get_max_threads(void); 쓰레드 최대값 리턴
int omp_get_thread_num(void); 현재 쓰레드 번호 리턴
int omp_get_num_procs(void); 물리적 프로세서의 개수 리턴
int omp_in_parallel(void); 병렬 구간일 경우 true(0이 아닌값), 아니면 false(0)을 리턴
void omp_set_dynamic(int dynamic_threads); 생성할 쓰레드 개수를 동적으로 조정할 지 여부 (dynamic_threads가 1이면 true, 0이면 false)
int omp_get_dynamic(void); 위의 omp_set_dynamic의 설정을 리턴
아래 예제처럼 omp_set_dynamic이 설정되면 사용량에 따라서 쓰레드의 개수가 10개를 넘지 않는 범위에서 적당하게 조정된다.
#include <omp.h>
int main()
{
omp_set_dynamic(1);
#pragma omp parallel num_threads(10)
{
/* do work here */
}
return 0;
}
|
예제 출처: OpenMP 2.5 Specification
* OpenMP에서 제공하는 lock 기능 API : 정교한 모델을 만들때 유용하므로 꼭 읽어두자.
void omp_set_nested(int nested); nested가 1이면 병렬구간의 중첩을 허용, 0이면 허용하지 않음
int omp_get_nested(void); 위의 nested 설정을 리턴
void omp_init_lock(omp_lock_t *lock); OMP의 lock을 초기화
void omp_init_nest_lock(omp_nest_lock_t *lock); 중첩 lock버전의 위와 같은 기능의 함수 (=재귀잠금이 가능한 lock)
void omp_destroy_lock(omp_lock_t *lock); OMP의 lock을 제거
void omp_destroy_nest_lock(omp_nest_lock_t *lock); nested lock버전의 위와 같은 기능의 함수
void omp_set_lock(omp_lock_t *lock); OMP의 lock을 잠금
void omp_set_nest_lock(omp_nest_lock_t *lock); nested lock버전의 위와 같은 기능의 함수
void omp_unset_lock(omp_lock_t *lock); OMP의 lock을 잠금 해제
void omp_unset_nest_lock(omp_nest_lock_t *lock); nested lock버전의 위와 같은 기능의 함수
int omp_test_lock(omp_lock_t *lock); 잠금 여부를 테스트하여 가능한 상태면 잠그고 다른 쓰레드에 의해 잠긴 상태면 false를 리턴 (=nonblocking 버전의 함수임)
int omp_test_nest_lock(omp_nest_lock_t *lock); nested lock버전의 위와 같은 기능의 함수
double omp_get_wtime(void); 병렬처리 구간에서의 수행 시간(단위: 초)
double omp_get_wtick(void); omp_get_wtime()에서 제공하는 시간 정밀도 (최소 단위 시간)
double start;
double end;
start = omp_get_wtime();
... work to be timed ...
end = omp_get_wtime();
printf("Work took %f seconds\n", end -
start);
|
OpenMP 2.5에서 제공하는 모든 API를 다루었다. 특히 lock관련 함수는 중요하기 때문에 잘 알아두면 도움이 된다.
11. OpenMP에서 제공하는 환경변수 및 전처리기
OpenMP에서는 스케줄링, 생성할 쓰레드 개수, 동적 조정 여부, 병렬구간에서 쓰레드의 중첩 허용을 runtime시에 결정할 수 있도록 환경변수를 설정할 수 있다.
• OMP_SCHEDULE : 스케줄링 타입과 chunk 크기를 설정
• OMP_NUM_THREADS : 병렬 구간에서 생성할 쓰레드 개수
• OMP_DYNAMIC : 쓰레드 개수의 동적 조정 여부를 설정
• OMP_NESTED : 쓰레드 중첩의 허용 여부를 설정
사용예 : bash (or POSIX shell)의 명령
export OMP_SCHEDULE="dynamic"export OMP_SCHEDULE "guided,4" export OMP_NUM_THREADS 16 export OMP_DYNAMIC true export OMP_NESTED false |
#include <stdio.h>
int main()
{
# ifdef _OPENMP
printf("Compiled by an OpenMP-compliant
implementation.\n");
# endif
return 0;
}
|
12. OpenMP vs pthread (POSIX thread)
OpenMP로 작성한 프로그램을 그대로 pthread 버전으로 바꾸면서 둘의 차이를 보도록 하겠다.
예제로 볼 것은 앞에서 numerical integration으로 pi를 계산한 프로그램을 두가지 버전으로 작성해서 비교하도록 하겠다.
우선 HOWTO #1에서 봤던 OpenMP 버전을 다시 보도록 하겠다.
예제 파일 : pi_numerical_integration.c
#include <stdio.h>
#include <stdlib.h>
int num_steps = 1000000000; /* 10억번 : 너무 많으면 조금 줄이시길... */
int main()
{
int i;
double x, step, sum = 0.0;
step = 1.0 / (double)num_steps;
#pragma omp parallel for private(x) reduction(+:sum)
for (i = 0; i<num_steps; i++) {
x = (i + 0.5) * step;
sum += 4.0 / (1.0 + x*x);
}
printf("PI = %.8f (sum = %.8f)\n", step*sum, sum);
return EXIT_SUCCESS;
}
|
OpenMP버전은 이미 설명했었기 때문에 이를 바로 Pthread 버전으로 바꾸도록 하겠다.
pthread 버전 예제 파일 : pi_integration_pth.c
#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>
static int num_steps = 1000000000;
double pi, step;
struct start_arg {
int i_start;
int i_end;
double sum;
} start_arg[2];
void *start_func(void *arg)
{
int i;
double x, sum = 0.0;
struct start_arg *p_arg = (struct start_arg *) arg;
for (i = p_arg->i_start;
i<p_arg->i_end; i++) {
x = (i + 0.5) * step;
sum += 4.0 / (1.0 + x*x);
}
p_arg->sum = sum;
return NULL;
}
int main()
{
int i;
double sum;
pthread_t pt_id[2];
step = 1.0 / (double)num_steps;
start_arg[0].i_start = 0;
start_arg[0].i_end = num_steps >> 1;
start_arg[1].i_start = start_arg[0].i_end + 1;
start_arg[1].i_end = num_steps;
printf("%d~%d, %d~%d\n",
start_arg[0].i_start, start_arg[0].i_end,
start_arg[1].i_start, start_arg[1].i_end);
for (i = 2; i--; ) { /* create pthread */
if (pthread_create(&pt_id[i], NULL, start_func, &start_arg[i])) {
perror("pthread_create");
return 1;
}
}
for (i = 2; i--; ) { /* join pthread : explicit
barrier */
if (pthread_join(pt_id[i], NULL)) {
perror("pthread_join");
return 1;
}
}
sum = start_arg[0].sum + start_arg[1].sum;
printf("PI = %.8f (sum = %.8f)\n", step*sum, sum);
return EXIT_SUCCESS;
}
|
pthread 버전으로 바꾸면 openmp버전보다 코딩량이 훨씬 늘어난다.
POSIX thread를 사용하면 OpenMP에서 없는 explicit barrier를 넣어주어야 하므로 pthread_join()함수를 사용했으며, OpenMP에서 간단하게 reduction을 했던 것이 POSIX thread에서는 개별적인 start_arg라는 구조체를 통해서 확인했다. 이로 인해서 코딩량과 자료구조까지 신경써야 하는 불편함이 생긴다.
그러나 OpenMP가 POSIX thread보다 우월하다고 말하는 것은 아니다. 문제가 정교함을 요구하는 경우에는 오히려 OpenMP가 적합하지 않은 경우도 많기 때문이다. 실제로 조건변수를 이용한다든지 쓰레드 키를 이용한 라이브러리등을 사용하는 경우라면 POSIX thread외에는 대안이 없는 경우가 많기 때문이다. 이 글은 OpenMP를 소개하는 글이므로 OpenMP에 대해 좋은 말만 늘어놓고 있지만 필자의 말을 비판없이 받아들여서 OpenMP가 최고라는 편협한 사고에 휩싸이지는 않았으면 좋겠다.
잡설이 길었는데 마지막으로 두가지 버전의 실행 결과를 확인해보자. 첫번째 실행한 파일인 pi_integration이 OpenMP버전이고, 두번째의 pi_integration_pth가 Pthread버전이다.
| $ time ./pi_integration PI = 3.14159265 (sum = 3141592653.59036255) real 0m3.910s user 0m7.484s sys 0m0.018s |
| $ time ./pi_integration_pth 0~500000000, 500000001~1000000000 PI = 3.14159265 (sum = 3141592650.38979244) real 0m4.071s user 0m7.399s sys 0m0.022s |
결과를 보면 실행결과나 성능에 큰 차이가 없어 보인다. 하지만 몇몇 컴파일러에서는 특정 버전이 더 느린 경우도 있다.(이는 해당 플랫폼의 특징에서 기인한다. 표준안에는 성능에 대한 제약은 없기 때문에 몇몇 플랫폼은 OpenMP 구현시 덜 최적화 되어있는 경우도 있다.)
13. 마치면서.
처음 시작하면서 멀티 쓰레드 프로그래밍의 필요성에 대해서 언급했었다. CPU의 개별 코어의 주파수(frequency)는 거의 한계치에 와 있기 때문에 개별 코어의 속도는 파이프라인의 증설이나 몇가지 기술로 약간의 진보밖에 이룰 수 없게 되었다. 따라서 멀티코어를 적극적으로 사용하는 기술이 뒷받침되지 않고는 프로그램의 성능을 높일 수 있는 방법은 거의 없다.(일각에서 언급되는 그래픽카드의 코어를 병렬로 이용하는 GPGPU도 같은 맥락이다.) 하지만 멀티 쓰레드 프로그래밍은 다음과 같은 난제가 있다.
- 멀티 쓰레드 프로그램의 문제점 : 디버깅이 힘들다. (재현성이 나쁘기 때문)
- 아키텍처와 메모리 모델에 대한 이해가 필요하다. (본인도 부족하다. 그래서 실수를 할 때가 있다.)
첫째로 문제인 디버깅에서 언급되는 재현성은 쓰레드 프로그래밍에서 큰 난제이다. 디버깅을 위해서는 같은 조건하에서 시행하였을때 동일한 문제가 재현되어야만 버그를 찾아낼 수 있다. 그러나 멀티 쓰레드 프로그램은 각각의 쓰레드들이 같은 순서로 실행된다는 보장이 없기 때문에 버그가 발생한 순서조합이 디버깅때도 항상 발생하지 않는다. 즉 문제를 찾아내려고 할때는 오히려 제대로 작동하는 경우도 많다는 것이다.
따라서 멀티 쓰레드 프로그램을 대형 모델에 적용할 때는 투명성을 높여서 각각의 데이터나 태스크의 흐름을 모니터링할 수 있도록 만들어야 한다. 이를 위해서 여러 방법론이 나와있지만 스페셜한 케이스에는 딱 들어맞는 것은 없다. 그러므로 반복적인 프로그래밍 훈련만이 투명성을 높이고 디버깅이 쉬운 개발철학을 만들 수 있게 해준다.
둘째로 우리가 종종 사용하는 x86 인텔 호환 플랫폼은 PC환경에서 가장 많이 쓰이지만 산업체에서는 IA64, Sparc, MIPS, PPC(PowerPC) 등등의 CPU에 여러가지 OS조합의 플랫폼이 사용된다. 그러나 같은 프로그래밍을 짜도 표준안에서 언급한 semantic을 만족하면서 미묘한 차이를 보이는 경우가 많다. 특히 기능은 제대로 작동하는데 성능은 이상하게 차이나는 경우가 발생할 수 있다. 이를 해결하기 위해서는 각각의 플랫폼에 대한 이해와 하드웨어 지식이 필요한데, 한사람의 프로그래머가 모든 플랫폼에 정통할 수는 없기 때문에 적극적으로 다른 플랫폼의 전문가와 소통할 수 있는 채널이 있어야만 한다. (더 중요한 점은 다른 플랫폼의 전문가와 제대로 소통할 수 있도록 질문을 잘 하는 방법을 익히는 것이다. 간혹 질문을 잘 못하고 횡설수설하면 답변을 해주고 싶어도 못한다. 필자도 좀 횡설수설하는 스타일이라 고치려고 하는데 참 어렵다.)
하지만 이런 어려움은 점차 해소될 전망이다. 앞으로 나오는 많은 기술들과 소프트웨어 방법론들은 프로그래머가 복잡한 이론이나 방법론을 몰라도 멀티 쓰레드 프로그래밍을 쉽게 할 수 있도록 돕고 있다. 실제로 10년전과 지금은 하늘과 땅 차이로 멀티 쓰레드 프로그래밍이 쉬워졌다.(그럼에도 불구하고 아직도 멀티 쓰레드 프로그래밍은 어려운 분야이지만...)
비슷한 예를 하나 들자면 15년전쯤에 필자가 프로그래밍을 처음 접하던 시절에는 그래픽 처리를 위해 어셈블리어를 배우는 것이 유행했던 시절이 있었다. 속도와 최적화 문제에서 다른 대안이 없었기 때문이었다. 그러나 지금은 어셈블리어를 몰라도 왠만한 그래픽 최적화를 하는데 무리가 없다.(아주 가끔 어셈블러에 의지해야 하는 스페셜 케이스가 있긴하다.) 이는 시간이 지나면 좀 더 편리한 프로그래밍 환경이 만들어진다는 것을 의미한다.
그렇다면 이쯤에서 독자들은 필자에게 반문할 것이다. "멀티 쓰레드 프로그래밍이 쉬워지기를 기다리라는 말입니까?" 이에 대한 필자의 대답은 "절반은 그렇다"이다. 왜 절반만 Yes를 하는지는 그 쉬워지는 시점 때문이다. 많은 선도자들은 예측하기를 멀티 쓰레드 프로그래밍의 하드웨어적, 소프트웨어적 난제들이 해결되어 많은 부분에서 변화가 생기려면 적어도 5~10년후가 되어야 할 것이라고 한다. 그렇다면 본인이 앞으로 5~10년을 기다릴 수 있는 형편인지 아니면 당장 써야 하는지 결정해야한다. 한창 공부하는 학생이라면 더 기다리다가 공부해도 되겠지만 field에서 일하는 산업역군이라면 당장 공부하라고 말해주겠다.
원문 : http://sunyzero.egloos.com/4258873
댓글 없음:
댓글 쓰기