데스티의 문서보관소

물론, 멀티스레딩에 관련된 복잡한 작업을 하려면 당연히 각 OS별로 제공하는 라이브러리를 사용해야 할 테지만(pthread같은),

단순한 반복 작업을 멀티스레딩으로 처리하려 할 때 사용할 수 있는 라이브러리가 OpenMP이다.


현재, linux용 gcc, visual studio(OpenMP 2.0 지원), linux/windows용 Intel c++ compiler에서 OpenMP를 지원하고 있다.


내부 로직이 효율적으로 구현되어 있어 속도 향상도 조금 기대할 수 있다.




필자의 경우, linux에서 pthread를 이용하여 멀티스레딩을 구현하였던 부분을 OpenMP로 교체, 성능 테스트를 해 보았다.

pthread로 구현되어 있던 부분.

for(int i = 0; i < num_threads; i++)
{
          pthread_create(&p_thread[i], NULL, BIG_FUCKING_FUNCTION, NULL);
}
for(int i = 0; i < num_threads; i++)
{
          pthread_join(p_thread[i], NULL);
}

본 코드에서 생기는 문제점들은 다음과 같다.
1. pthread_create에서 새로운 스레드를 생성하는 동안 먼저 생성된 쓰레드가 돌아가고 있다. 비효율적.
2. pthread_join에서 thread를 끝난 순서가 아닌 생성된 순서대로 join하기 때문에 성능 저하가 발생한다.

가장 문제가 되는 부분은 2번이였는데, 실제로 시간이 오래 걸리는 작업을 걸어 놓아도 전체 cpu 점유율이 일정 수준 이상(60%)
올라가지 않는 문제를 확인할 수 있었다.

이 코드를, 다음과 같은 간단한 OpenMP 코드로 바꾸어 보자.

#progma omp parallel for
for(int i = 0; i < num_threads; i++)
{
          pthread_create(&p_thread[i], NULL, BIG_FUCKING_FUNCTION, NULL);
}

참 간단하지 않은가.

필자의 프로그램의 경우, critical section을 관리해야 한다던지, thread에서 공통적으로 사용하는 자원이 있다던지 하는 일이 없다.
(없다기 보다는, 필자의 프로그래밍 실력이 미천해서 저런 부분이 없도록 설계하였다.)

따라서 #progma 하나를 덧붙이는 것 만으로 기존의 threading code를 대체할 수 있었다.


속도 향상도 꽤 있는 편.

기존 코드에서 23초 정도 걸리던 작업이, OpenMP를 통해 계산했을 때 15초 정도 걸렸으니
약 150% 정도의 속도 향상이 있다고 생각하면 된다.
이는 위에 적어놓았던 이유(pthread를 사용했을 경우 cpu점유율이 60% 이상 올라가지 않는다)를 OpenMP에서 해결해 주었기 때문이라고 생각된다.

별 내용은 아니고.

ubuntu에서 apt-get install을 통해 eclipse와 eclipse-cdt를 설치할 경우,

cdt의 버젼이 3.0이 되고, 이 상태에서 cdt 5.0만 추가할 경우 설치가 되지 않는다.

에러 메세지는 org.eclipse.core.filesystem이 없다는 것.


우분투에서 이클립스 업데이트가 늦어져 생기는 문제라고 생각되어

eclipse를 새로 받아서 무설치로 실행하면 문제 없이 실행할 수 있다.


본인의 경우, linux에서 intel compiler를 사용하려고 eclipse plugin을 설치하려 시도했는데,

cdt 5.0이 깔려있지 않아 조금 삽질을 했었다.

커그에서 시간에 따른 불판의 개수.

흥미로운 것은 나뿐?

나름 올인원 책상을 꿈꾸고 있지만,




현실은 시궁창. 포트 리플리케이터를 이용해서 노트북에 듀얼모니터를 연결, 사용하고 있음.