MPI on Multicore, an OpenMP Alternative?

원문보기 : http://www.linux-mag.com/id/4608

위의 글이 영문으로 되어있어서.. 영문을 적어놓고 해석을 달까.. 했으나... 솔직히.. 오역을 한 이후에 딴지걸릴것도 무섭고해서.. 그냥 제가 아는것 + 해석한 내용으로 작성을 하겠습니다.

 최근의 PC들은 다 멀티코어를 탑재하였고, 그에 따라 병렬 프로그래밍이 필요하게 되었다. 기존의 코드들을 확장성 있게 만들고싶다면, 코드를 다시 작성하여야 할 것이다. (이거는 좀 해석이..-_-..)

 Multicore Programming의 과제는, 병렬 프로그래밍이고, 이것은 개발자에게 있어서 조금 더 하드웨어에 가까워져야하고 응용 프로그램의 용량이나 문제도 고려해야한다. (실제로 MPI로 프로그래밍을 하면..-_-.. 각 노드별로 실행될 프로세스가 얼만큼의 메모리가 요구되는지 알고있어야한다-_-. MPI는 여기서 미리 적어놓지만 메시지를 주고받아서 병렬 프로그래밍에서 사용될 데이터를 공유하고 - 주거니 받거니 ㅋ - 동기화를 실행한다. 각 노드별로 처리가능한 용량, 처리 속도가 다 다르다.. 특히, 헤테로 클러스터는 더욱 그럴것이다. 그럴때일수록.. 머리아프게.. 노드들에게 부하가 균형적으로 걸리도록 해주어야 할 필요도 있다.) 그래도 다행인것은, HPC분야에서는 병렬 소프트웨어를 많이쓴다.(맞나? ㅋ.. 여튼 HPC분야에서는 병렬프로그래밍이 필수이다. 절대적이다.)
 
 많은 개발자들이 알듯, 기존에 존재하는 코드가 매우 유용하다는 것을 알것이다. 먼저, 재사용성이 가장 큰 장점이 될 것이고, 기존의 코드를 재사용하게 되어 비슷한 문제가 생겨도 해결이 쉽지않을까 싶다만.. (역시 여기도 낵옹부종.. ㅠㅠ..)
 
 HPC분야에서, 많은 병렬 프로그램은 MPI (Message Passing Interface)로 작성되었다. MPI는 일반적으로 대형 컴퓨팅 시스템(클러스터)에서 사용되곤 하나 멀티코어 프로세서에서도 사용이 가능하다. 이러한 "MPI proposition" (MPI의 제안?)은 MPI가 분산 메모리 시스템(각 프로세서가 개별적인 메모리를 가지는 경우이다.)을 위하여 디자인되었다는 것과, OpenMP는 공유 메모리를 위하여 디자인되었다는 사실에 대응한다.

 OpenMP가 공유 메모리를 위하여 디자인 되었기 때문에 이것이 더 좋은 솔루션일 것이라고 게으른 가정을 해버릴 수 있다. 그러나 기존에 존재하는 MPI코드를 재사용 할 수 있다는 것이, software-wheel(??)을 재 개발하는것 보다 가치있다. 뭐... 결과적으로는 효율성에 대한 질문인데. 명백히 말해서, 멀티코어 시스템에서 MPI와 OpenMP의 성능을 비교해보자~라는 말이 될 수 있겠다.

 이 질문에 대한 답은 예민한 답이 될 것이다. 만약 멀티코어에서 MPI코드를 재사용한다고 하면, OpenMP를 사용할때에 비해서 다시 코딩을 해야할 필요는 없다. 만약, 다시말해 OpenMP나 스레드들은 다시 코드를 작성하는데 투자하는 시간을 고려하더라도 그만큼의 잇점을 가져다 준다.

 이런 Application들은 동일한 코드를 MPI와 OpenMP를 사용하여 작성한 후 테스트를 한다.  다행히도, NASA는 이러한 것에 대해서 흥미가 있다. 이 대단한(?약간 광고성인듯?ㅋㅋ) NAS Parallel Suite는 이제 MPI, OpenMP, Java, HPF(High Performance Fortran)을 지원한다.

 이것은 head to head로 MPI와 OpenMP를 비교하는 것이 가능하다는 말이다.

OpenMP and MPI Primer

 native한 Pthread 프로그래밍은 OpenMP라 불리는 높은 레벨의 추상화를 통한 개발에 방해가 될수 있다. OpenMP는 사용자가 사용하기 편하도록 만들기 위해서 core부분은 보여주지 않는다. (즉, 사용자에게는 어떻게 thread들이 돌아가는지 보여지지않는다.)

 OpenMP는 program comment처럼 적어놓은 지시어를 컴파일러에 의해서 실행한다. 일반적으로, 방대한 계산의 루프는 OpenMP 지시어로 확장하여 자동적으로 "스레드 loop"로 사용한다. 이런 타입의 접근은 원래 프로그램을 "건드리지않고" 실행가능하고 단순히 재컴파일만으로 sequantial한 버전을 만들 수 있다.

 그리고 이 이후로는.. 이 이러한 아직 주류는 아닌 소프트웨어 트렌드를 Linux Magazine 컬럼니스트들이 OpenMP를 아주 까발긴다고 한다-_-..
사용한건 GCC4.2 (or later ^^;) 여튼 OMP를 지원해야 쓰것지. 우선 대략적인 결과를 보자.. 현재 프로그램은 같은 프로그램 소스를 가지고 OMP버전과 시퀀스 버전을 놓고 한 결과다.
 normal   : 0m9.079s
 openmp : 0m4.967s
대략 45%정도 감소하였다고 한다.

 그리고 OMP vs MPI도 있다.
 OMP :  1m11.735s
 MPI  :   1m16.138s
 MPI가 더 느리게 나왔는데.. 음.. 뭐... 이건 당연한 결과라 보여진다. 우선 OpenMP가 수행될 수 있는 환경에서는 OpenMP가 더 빠를 수 밖에 없다.-_-...
MPI는 네트워크레벨로 내려가서 메시지 던지고 받고 쇼를 하고.. 무엇보다 송/수신을 하면서 해당 버퍼를 새로이 만들어서 그곳에 임시 계산 결과를 저장한다-_-..
OpenMP는 공유메모리라서 걍 가져다 쓰니.. 당연히 빠르겠지-_-.. 근데 중요한것은 MPI의 버전일 것 같다. MPICH (MPI이 GNU버전이라 생각하면 되것다.-_-) 2부터였던가 MPI 2.x(MPI2가 맞을것이다.)에서 아예 공유메모리 환경에서는 OpenMP처럼 동작 가능하도록 업그레이드 되었다고 기억한다. 그렇다면 OpenMP에 비해 크게 손색이 없을 듯 하다.
뭐.. 여튼.. 그건 그렇고.. OMP와 MPI를 비교한 표가 있어., 이거까지만 올리고 글을 여기서 마친다.

Test	OpenMP gcc/gfortran 4.2	MPI LAM 7.1.2	Percent Difference
CG	790.6	739.1	7%
EP	166.5	162.8	2%
FT	3535.9	2090.8	69%
IS	51.1	122.5	139%
LU	5620.5	5168.8	9%
MG	1616.0	2046.2	27%

Table One: Results for the OpenMP/MPI benchmarks. (winning test is in bold)

뭐.. 이 결과 나름대로 재미있는 결과이지않을까.. 싶다. 하지만 가장 중요한 것은 MPI와 OpenMP는 각각 특성이 있다.. 해당 특성을 잘 조합하여야 강력한 병렬 프로그램이 등장하지않을까.. 하는 생각을 하면서.. 해석 및 잡설을 적은 글을 여기서 마무리짓겠습니다.
 (제 블로그의 글을 발행을 처음해보는군요.. 음.. 어케 써야할지를 잘 모르겠습니다. ㅋ;;; 혹시 병렬프로그래밍 하시는분 있으면 같이 정보공유를 해보아요 ㅋ)