MPICH 대 OpenMPI


129

누군가 MPI의 OpenMPI와 MPICH 구현의 차이점을 자세히 설명 할 수 있습니까? 둘 중 어느 것이 더 나은 구현입니까?



2
우리는 개인적으로 OpenMPI를 MPI 구현으로 선택했습니다. 우리에게는 벤치마킹이 좋았고 이식성은 그다지 중요하지 않았습니다. Taylor L이 게시 한 질문 링크를 참조하십시오.
Xorlev

1
Google 트렌드에서 OpenMPI는 MPICH / MPICH2보다 2-3 배 더 많이 검색 된다고 생각할 수도 있습니다 .
Foad

나는 MPICH가 더 이상 리눅스의 최신 버전 (예를 들어, 우분투 (18)을 실행할 수 없습니다), IIRC가 특정 커널 버전에서 작동에서 지원됩니다 생각하지
JRH을

답변:


148

목적

첫째, MPICH와 Open-MPI가 어떻게 다른지, 즉 서로 다른 요구를 충족 시키도록 설계되었음을 인식하는 것이 중요합니다. MPICH는 최신 MPI 표준의 고품질 참조 구현이자 특수 목적 요구를 충족시키기위한 파생 구현의 기반이되어야합니다. Open-MPI는 사용량과 네트워크 도관 측면에서 일반적인 경우를 대상으로합니다.

네트워크 기술 지원

Open-MPI는 여기에서 네트워크 지원을 문서화 합니다 . MPICH는 각 버전에 배포 된 README이 정보 (예를 들어 나열 3.2.1입니다)를. Open-MPI와 MPICH는 모두 OFI를 지원하기 때문에(일명 libfabric) 네트워킹 계층은 동일한 네트워크를 많이 지원합니다. 그러나 libfabric은 다방면의 API이므로 모든 네트워크가 두 가지 모두에서 동일하게 지원되는 것은 아닙니다 (예 : MPICH에는 OFI 기반 IBM Blue Gene / Q 구현이 있지만 Open-MPI에서 동등한 지원은 알지 못합니다) . 그러나 MPICH 및 Open-MPI의 OFI 기반 구현은 공유 메모리, 이더넷 (TCP / IP를 통한), Mellanox InfiniBand, Intel Omni Path 및 기타 네트워크에서 작동합니다. Open-MPI는 이러한 네트워크와 다른 네트워크를 기본적으로 지원합니다 (즉, 중간에 OFI가 없음).

과거에는 MPICH에 대한 일반적인 불만은 InfiniBand를 지원하지 않는 반면 Open-MPI는 지원하는 것입니다. 그러나 MPICH 파생 상품 인 MVAPICH 및 Intel MPI (Intel MPI)는 InfiniBand를 지원하므로 MPICH를 "MPICH 및 그 파생 상품"으로 정의하려는 경우 MPICH는 InfiniBand 및 독점 제품을 포함하여 매우 광범위한 네트워크 지원을 제공합니다. IBM Blue Gene (/ L, / P 및 / Q)뿐만 아니라 Cray Seastar, Gemini 및 Aries와 같은 상호 연결. Open-MPI는 또한 Cray Gemini 상호 연결을 지원하지만 Cray에서는 그 사용을 지원하지 않습니다. 더 최근에 MPICH는 netmod (현재는 더 이상 사용되지 않음)를 통해 InfiniBand를 지원했지만 MVAPICH2는 거의 모든 경우에 선호하는 구현으로 광범위하게 최적화되었습니다.

최신 MPI 표준의 기능 지원

하드웨어 / 플랫폼 지원에 대한 직교 축은 MPI 표준의 적용 범위입니다. 여기서 MPICH는 일반적으로 멀리 떨어져 있습니다. MPICH는 MPI-1에서 MPI-3에 이르기까지 MPI 표준의 모든 단일 릴리스의 첫 번째 구현이었습니다. Open-MPI는 최근 MPI-3 만 지원했으며 일부 MPI-3 기능은 일부 플랫폼에서 버그가 있음을 발견했습니다 (물론 MPICH는 버그가 없지만 MPI-3 기능의 버그는 훨씬 덜 일반적입니다).

역사적으로 Open-MPI는에 대한 전체적인 지원을하지 않았으며 MPI_THREAD_MULTIPLE이는 일부 응용 프로그램에 중요합니다. 일부 플랫폼에서 지원 될 수 있지만 일반적으로 작동한다고 가정 할 수는 없습니다. 반면 MPICH는 MPI_THREAD_MULTIPLE구현이 항상 고성능 인 것은 아니지만 수년 동안 총체적인 지원을 해왔습니다 ( 한 분석에 대해서는 "멀티 스레드 MPI 구현의 측면 잠금" 참조 ).

Open-MPI 1.x에서 중단 된 또 다른 기능은 일방적 인 커뮤니케이션 (일명 RMA)이었습니다. 이것은 최근에 수정되었으며 이러한 기능을 매우 많이 사용하는 사람들은 일반적으로 Open-MPI 3.x에서 잘 작동하고 있음을 알았습니다 (예 : RMA 작업 결과를 보려면 Travis CIARMCI-MPI 테스트 매트릭스 참조). 적어도 공유 메모리에서 두 가지 구현 모두 Intel Omni Path에서 유사한 긍정적 인 결과를 보았지만 Mellanox InfiniBand를 테스트하지 않았습니다.

공정 관리

Open-MPI가 현저하게 우월했던 영역 중 하나는 프로세스 관리자였습니다. 이전 MPICH 출시 (MPD)는 취하기 쉬웠고 사용하기가 어려웠습니다. 다행히도 수년 동안 사용이 중단되었습니다 (자세한 내용은 MPICH FAQ 항목 참조). 따라서 MPD로 인한 MPICH에 대한 비판은 의심 스럽다.

Hydra 프로세스 관리자는 상당히 우수하며 ORTE (Open-MPI에서)와 유사한 사용성 및 기능 세트를 가지고 있습니다. 예를 들어 둘 다 프로세스 토폴로지 제어를 위해 HWLOC를 지원합니다. Open-MPI 프로세스 시작이 더 큰 작업 (1000 개 이상의 프로세스)에 대한 MPICH 파생어보다 빠르다는보고가 있지만 여기서 직접 경험이 없기 때문에 결론을 내리는 것이 불편합니다. 이러한 성능 문제는 일반적으로 네트워크 및 때로는 시스템에 따라 다릅니다.

VPN과 함께 MacOS를 사용할 때 Open-MPI가 더 강력하다는 것을 알았습니다. 즉 호스트 이름 확인 문제로 인해 MPICH가 시작시 중단 될 수 있습니다. 이것은 버그이므로 향후이 문제가 사라질 수 있습니다.

이진 이식성

MPICH와 Open-MPI는 모두 광범위한 플랫폼에서 컴파일 할 수있는 오픈 소스 소프트웨어이지만 바이너리 형식의 MPI 라이브러리 또는 이와 연결된 프로그램의 이식성이 중요한 경우가 많습니다.

MPICH와 많은 파생 제품은 ABI 호환성 ( website )을 지원 합니다. 이는 라이브러리에 대한 이진 인터페이스가 일정하므로 mpi.h한 구현에서 컴파일 한 다음 다른 구현으로 실행할 수 있음을 의미합니다. 여러 버전의 라이브러리에서도 마찬가지입니다. 예를 들어, 나는 자주 Intel MPI를 컴파일하지만 LD_PRELOAD런타임에 MPICH의 개발 버전을 컴파일 합니다. ABI 호환성의 큰 장점 중 하나는 ISV (Independent Software Vendor)가 MPICH 제품군의 한 구성원에 대해서만 컴파일 된 바이너리를 릴리스 할 수 있다는 것입니다.

ABI만이 이진 호환성 유형이 아닙니다. 위에서 설명한 시나리오에서는 사용자가 동일한 버전의 MPI 실행기 (일반적으로 mpirun또는 mpiexec컴퓨팅 노드 데몬과 함께) 및 MPI 라이브러리를 어디에서나 사용한다고 가정합니다 . 반드시 컨테이너의 경우는 아닙니다.

Open-MPI는 ABI 호환성을 약속하지 않지만 컨테이너 ( docs , slides ) 지원에 많은 투자를 해왔습니다 . 사용자는 컨테이너 지원의 실행기 데몬보다 최신 버전의 MPI 실행기를 사용하여 작업을 시작할 수 있기 때문에 서로 다른 버전의 MPI 실행기, 실행기 데몬 및 MPI 라이브러리 간의 호환성을 유지하는 데 세심한주의가 필요합니다. 실행기 인터페이스 안정성에주의를 기울이지 않으면, 실행기의 각 구성 요소 버전이 호환되지 않으면 컨테이너 작업이 시작되지 않습니다. 이것은 극복 할 수없는 문제가 아닙니다 :

예를 들어 Docker 세계에서 사용되는 해결 방법은 응용 프로그램과 함께 인프라를 컨테이너화하는 것입니다. 즉, 응용 프로그램 자체와 함께 컨테이너에 MPI 데몬을 포함시킨 다음 모든 컨테이너 (mpiexec 포함)의 버전이 같아야합니다. 더 이상 버전 간 인프라 작업이 없기 때문에 문제가 발생하지 않습니다.

컨테이너 문제를 설명해 주신 Open-MPI 팀의 Ralph Castain에게 감사드립니다. 바로 앞의 인용문은 그의 것입니다.

플랫폼 별 비교

다음은 플랫폼 별 평가입니다.

  • Mac OS : Open-MPI와 MPICH는 모두 잘 작동합니다. MPI-3 표준의 최신 기능을 사용하려면 Homebrew에서 제공하는 최신 버전의 Open-MPI를 사용해야합니다. Mac 랩톱에서 실행중인 경우 MPI 성능에 대해 생각할 이유가 없습니다.

  • 공유 메모리가있는 Linux : Open-MPI와 MPICH 모두 제대로 작동합니다. MPI-3 또는 MPI_THREAD_MULTIPLE을 모두 지원하는 릴리스 버전을 원한다면 Open-MPI를 직접 빌드하지 않는 한 MPICH가 필요할 것입니다. 예를 들어 Ubuntu 16.04는 APT를 통해 고대 버전 1.10 만 제공하기 때문입니다. 두 구현 사이의 중요한 성능 차이는 알지 못합니다. OS가 허용하는 경우 둘 다 단일 복사 최적화를 지원합니다.

  • Mellanox InfiniBand가있는 Linux : Open-MPI 또는 MVAPICH2를 사용하십시오. 모든 MPI-3 MPI_THREAD_MULTIPLE또는를 지원하는 릴리스 버전을 원한다면 MVAPICH2가 필요할 수 있습니다. MVAPICH2는 성능이 뛰어나지 만 InfiniBand에서 OpenMPI와 직접 비교하지 않은 것으로 나타났습니다. 부분적으로 나에게 가장 중요한 성능 (일부 RMA) 기능이 과거 Open-MPI에서 손상 되었기 때문입니다.

  • Intel Omni Path가있는 Linux (또는 그 이전 버전 인 True Scale) : 그러한 시스템에서 MVAPICH2, Intel MPI, MPICH 및 Open-MPI를 사용하고 있으며 모두 작동하고 있습니다. 인텔 MPI는 가장 최적화 된 경향이있는 반면, Open-MPI는 최적화 된 PSM2 기반 백엔드를 갖추고 있기 때문에 오픈 소스 구현의 최고 성능을 제공했습니다 . 좀이 GitHub의에 메모를 다른 오픈 소스 구현을 구축하는 방법을하지만, 이러한 정보는 오히려 빨리 부패 간다.

  • Cray 또는 IBM 슈퍼 컴퓨터 : MPI는 이러한 머신에 자동으로 설치되며 두 경우 모두 MPICH를 기반으로합니다. 이 크레이 XC40 (에 MPICH의 시연되었습니다 여기에 사용) OFI 크레이 XC40 (에, 인텔 MPI를 여기 OFI을 (사용 블루진 / Q에 OFI, MPICH를 사용하여) 여기 ), 그리고 크레이 XC40에 오픈 MPI는 OFI 및 uGNI 모두 사용 ( here )이지만 공급 업체가 지원하지 않습니다.

  • Windows : Linux VM을 제외하고 Windows에서 MPI를 실행할 때는 아무런 의미가 없지만 Microsoft MPI와 Intel MPI는 모두 Windows를 지원하며 MPICH 기반입니다. Linux 용 Windows 하위 시스템을 사용하여 MPICH 또는 Open-MPI를 성공적으로 빌드했다는보고를 들었지만 개인적인 경험은 없습니다.

노트

전체 공개에서, 나는 현재 연구 / 경로 조사 능력에서 인텔을 위해 일하고 있습니다 (즉, 어떤 인텔 소프트웨어 제품에서도 일하지 않습니다). 이전에는 5 년 동안 Argonne National Lab에서 일했으며, 여기서 MPICH 팀과 광범위하게 협력했습니다.


OpenMPI가 집단에서 공유 메모리에 대한 탁월한 지원을 제공 할 가능성이 있지만 답변을 업데이트하기 전에 철저히 조사해야합니다.
Jeff

2
Windows에서 MPI를 실행하는 데 아무런 의미가없는 이유를 자세히 설명 할 수 있습니까?
Dmitri Nesteruk

3
아니요, 그러나 Windows의 HPC에 대한 StackOverflow에 대한 새로운 질문을 느끼십시오.
Jeff

@ Jeff, 당신 MPI_THREAD_MULTIPLE은 대답에서 강조 했지만, 나는 그것을 사용하기위한 실제 경험이 없습니다. ? MPI_THREAD_MULTIPLE와 같은 다른 모드와 비교하여 유용하고 효율적인 일부 사용자 사례 / 예를 제시 할 수 MPI THREAD FUNNELED있습니까? 첫 번째 인상은이 함수가 프로그램을 스레드와 프로세스 사이에서 더 복잡하고 디버그하기 어렵게 만드는 것입니다. 감사.
Patric

1
이제 Open-MPI가 Linux 용 Windows Subsytem에서 컴파일되고 제대로 실행된다는 점에 유의하십시오. mpich도 마찬가지입니다.
jawknee

12

프로덕션 시스템이 아닌 개발을 수행하는 경우 MPICH를 사용하십시오. MPICH에는 디버거가 내장되어 있지만 Open-MPI는 마지막으로 확인하지 않았습니다.

프로덕션 환경에서는 Open-MPI가 가장 빠를 것입니다. 그러나 인텔 MPI와 같은 다른 대안을 연구 할 수도 있습니다.


3
내장 디버거가 무엇을 의미하는지 잘 모르겠지만 Open-MPI는 gdb와 잘 통합되어 있습니다. open-mpi.org/faq/?category=debugging .
Jeff

프로덕션을 위해 MPAO를 TAO와 함께 사용하는 것에 대한 생각이 있습니까?
namu

10

나는 이전 포스터와 동의합니다. 두 응용 프로그램 중 어느 것이 더 빨리 실행되는지 확인한 다음 프로덕션에 사용하십시오. 둘 다 표준을 준수합니다. 그것이 데스크탑이라면 괜찮습니다. OpenMPI는 Macbook에서 즉시 제공되며 MPICH는 Linux / Valgrind에 더 친숙한 것으로 보입니다. 그것은 당신과 당신의 툴체인 사이에 있습니다.

프로덕션 클러스터 인 경우 네트워크 토폴로지에 최적화되도록보다 광범위한 벤치마킹을 수행해야합니다. RTFM과 마찬가지로 프로덕션 클러스터에서 구성하는 것이 시간 측면에서 가장 큰 차이가됩니다.


12
모든 사람이 RTFM 한 경우 StackOverflow가 필요하지 않습니다 :-)
Jeff

1
FWIW, Open-MPI에는 Valgrind-cleanlines에 대한 FAQ 항목이 있습니다. open-mpi.org/faq/?category=debugging#valgrind_clean
Jeff

@ Jeff Um 버그는 어떻습니까? 오래된 문서? 그것은 (여러 개의 ..) 질문들에 대한 복수의 배후에 있습니다;)
javadba

6

둘 다 표준을 준수하므로 올바른 관점에서 어떤 것을 사용하든 상관 없습니다. 특정 디버그 확장 프로그램과 같은 일부 기능이 필요한 경우가 아니라면 벤치 마크하여 하드웨어의 앱에 더 빠른 기능을 선택하십시오. 또한 MVAPICH (최고의 InfiniBand 성능을 가질 수 있음) 또는 Intel MPI (광범위하게 지원되는 ISV)와 같이 더 나은 성능 또는 호환성을 제공 할 수있는 다른 MPI 구현도 고려하십시오. HP는 많은 ISV 코드로 MPI 인증을 받기 위해 열심히 노력했지만 플랫폼에 팔린 후 어떻게 진행되는지 잘 모르겠습니다 ...


2

내 경험상 OpenMPI가 지원하지만 MPICH가 지원하지 않는 좋은 기능은 프로세스 선호도 입니다. 예를 들어 OpenMPI에서를 사용 -npersocket하면 각 소켓에서 시작되는 순위 수를 설정할 수 있습니다. 또한 OpenMPI rankfile는 순위를 코어에 정확하게 지정하거나 초과 구독을 원할 때 매우 편리합니다.

마지막으로 순위를 코어에 매핑하는 것을 제어해야하는 경우 OpenMPI를 사용하여 코드를 작성하고 컴파일하는 것이 좋습니다.


2
MPICH는 선호도를 지원합니다. wiki.mpich.org/mpich/index.php/…
Jeff
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.