코드의 변경 없이(물론 변형을 하면 더 다양한 경우에 이용할 수 있지만) 간단하게 멀티쓰래드를 처리 할 수 있다는 장점이 있습니다.

예를들어 for 최적화라면 그저 단순이 for 위에 #pragma 절 한줄 적어주는 것 만으로도 최적화(병렬화)가 가능합니다.
또하나의 장점이라면 #pragma 절을 이용 하기 때문에, OpenMP 를 지원하지 않는 컴파일러에서도 병렬화를 무시하고 바이너리를 만들어 낼 수 있다는겁니다.


예를들겠습니다.
1부터 1억까지 루프를 돌면서 합을 계산 하는 작업이 있다고 칩시다. 이 코드를 4코어에 최적화 하려면

1~ 2500만 - 1,
2500만 ~ 5000만 -1,
5000만~7500만 -1,
7500만~ 1억

이런식으로 4개의 함수로 분리한 후 4개를 별도의 Thread 에 할당해서 계산을 시키고 메인 Thread 에서는 Wait하는 것이 일반적으로 계산을 최적화 하는 방법입니다(거기 (1 + 1억) * 5천만 하신분은 좀 자제를 ㅡ.ㅡ)

그런데 OpenMP를 사용하면 1~1억의 단일 루프를 내부적 으로 4개의 루프로 분리해서 Thread 로 나누는 작업 역시 가능하고(For 최적화) 명시적으로 4개의 부분으로 나눈 뒤 그것을 병렬처리하도록 하는것(Section 최적화) 도 가능합니다.

즉 시스템을 건드리지 않고, CreateThreadEx 같은 플랫폼 의존적인 코드를 사용 하지 않고도 OpenMP 를 지원하는 컴파일러만 사용한다면 간단히 최적화 할 수 있다는 겁니다.

또하나의 장점은 같은 병렬화 도구인 TBB와 달리 부가적인 코드가 전혀 없다는겁니다.
(TBB의 경우 템플릿으로 이루어져있어 최적화 외의 작업에 들어가는 오버헤드가 큽니다)

제 경우는 512 * 512 이미지를 512 개 프로세싱 해야 되는 곳에서 OpenMP 를 사용해서 간단하게 큰 효과를 본 경험이 있습니다.

컴퓨터 비전쪽에 사용 했다는 말인듯 하네요. (2D 이미지 분석)
영상처리 쪽이 알고리즘은 워낙 많지만... 이것 저것 좋은것 합치다 보면 정말 느려져서...
에디슨을 OpenMP로 돌리면 성능 향상이 엄청날듯 하지만... 하드코어 알고리즈머들 입장에서 봤을때... 결국 건더기 도움 받은 것이라 ... ㅎㅎ (전 하드코어 하고 관련 없습니다. ;;)

원래 OpenMP의 출처가 Fortran 인걸 보면... 아무래도 영상이나 신호처리, 수치해석 하는 사람들 위해서 나온거 같습니다 ㅡㅡㅋ

포트란자주 쓰는분야가 그쪽이니

게임 서버에서도 시도하려고 고민한 적이 있었지만 당장 급한게 아니라 만에 하나의 사태를 확신할 수 없어(할수나 있는지 -_-;) 결국 뒤로 미룬적이 있습니다. 여유가 된다면 의미가 있겠지만... 그 여유란 것은... 실패해도 웃으며? OK~ 할 수 있는 분위기여야...;;

게임서버는 이미 많은 쓰래드가 돌고 있어서 궂이 병렬화 하는 의미가 있을까 싶은...

OpenMP는 EXE의 멀티프로세스 지원을 위한 공개라이브러리인데요.. 멀티쓰레드하고는 좀 다릅니다. 멀티쓰레드는 CPU가 하나 일때에도 사용될 수 있는것이지만 멀티프로세스는 CPU의 코어가 두 개 이상일 때에 사용됩니다. '소스코드의 이 부분에서 요 부분까지는 두 번째 CPU를 사용해서 처리해라'와 같이 지정합니다. 멀티쓰레드를 이용해도 멀티프로세스는 구현할 수 있습니다. 쓰레드가 하나 더 생기면 그 쓰레드는 두번째 CPU로 처리됩니다. 그러므로 이미 쓰레드를 많이 사용하고 있다면 멀티프로세스는 별로 의미가 없습니다.

엄청난 양의 계산 즉 머신 비전 이나 수치 해석등에 사용하면 좋을듯하군요. OpenMP를 지원하는 컴파일러라면 호환성도 있을테니 큰 장점이겠네요.. VC++로 OpenMP 적용해서 개발한 소스를 C++Builder 에서 OpenMP 지원한다면.. 다시 컴파일만 하면 되니 편하긴 하겠네요.. TThread로 포팅하려면 끝도 없을텐데.... ㅋㅋ

기존에 멀티프로세스를 염두에 두고 개발하지 않은 소스도 최적화를 위해 차후에 OpenMP를 적용할 수 있겠군요