MPICH vs OpenMPI


129

Ai đó có thể giải thích sự khác biệt giữa triển khai OpenMPI và MPICH của MPI không? Điều nào trong hai là thực hiện tốt hơn?



2
Cá nhân chúng tôi đã chọn OpenMPI làm triển khai MPI của chúng tôi. Đối với chúng tôi, nó được điểm chuẩn tốt hơn và tính di động không phải là vấn đề. Xem liên kết câu hỏi Taylor L đăng.
Xorlev

1
bạn cũng có thể xem xét rằng trong các xu hướng của Google, OpenMPI được tìm kiếm nhiều hơn 2-3 lần so với MPICH / MPICH2.
Foad

Tôi nghĩ MPICH không còn được hỗ trợ trong các phiên bản gần đây của Linux (ví dụ Ubuntu 18 không thể chạy nó), IIRC nó chỉ hoạt động trong các phiên bản kernel nhất định
jrh

Câu trả lời:


148

Mục đích

Đầu tiên, điều quan trọng là phải nhận ra MPICH và Open-MPI khác nhau như thế nào, tức là chúng được thiết kế để đáp ứng các nhu cầu khác nhau. MPICH được coi là triển khai tham chiếu chất lượng cao của tiêu chuẩn MPI mới nhất và là cơ sở cho việc triển khai phái sinh để đáp ứng các nhu cầu mục đích đặc biệt. Open-MPI nhắm vào trường hợp phổ biến, cả về cách sử dụng và kênh dẫn mạng.

Hỗ trợ công nghệ mạng

Tài liệu mở MPI hỗ trợ mạng của họ ở đây . MPICH liệt kê thông tin này trong README được phân phối với mỗi phiên bản (ví dụ: đây là phiên bản 3.2.1). Lưu ý rằng vì cả Open-MPI và MPICH đều hỗ trợ OFI(còn gọi là lớp libfoven), chúng hỗ trợ nhiều mạng giống nhau. Tuy nhiên, libfoven là một API đa diện, vì vậy không phải mọi mạng đều có thể được hỗ trợ giống nhau trong cả hai (ví dụ MPICH có triển khai IBM Blue Gene / Q dựa trên OFI, nhưng tôi không biết về hỗ trợ tương đương trong Open-MPI) . Tuy nhiên, việc triển khai cả MPICH và Open-MPI dựa trên OFI đang hoạt động trên bộ nhớ chia sẻ, Ethernet (thông qua TCP / IP), Mellanox InfiniBand, Intel Omni Path và các mạng khác. Open-MPI cũng hỗ trợ cả hai mạng này và các mạng khác (tức là không có OFI ở giữa).

Trước đây, một khiếu nại phổ biến về MPICH là nó không hỗ trợ InfiniBand, trong khi Open-MPI thì có. Tuy nhiên, MVAPICH và Intel MPI (trong số những người khác) - cả hai đều là dẫn xuất MPICH - hỗ trợ InfiniBand, vì vậy nếu ai đó sẵn sàng định nghĩa MPICH là "MPICH và các dẫn xuất của nó", thì MPICH có hỗ trợ mạng cực kỳ rộng, bao gồm cả InfiniBand và độc quyền các kết nối như Cray Seastar, Gemini và Aries cũng như IBM Blue Gene (/ L, / P và / Q). Open-MPI cũng hỗ trợ kết nối Cray Gemini, nhưng việc sử dụng nó không được Cray hỗ trợ. Gần đây, MPICH đã hỗ trợ InfiniBand thông qua một netmod (hiện không dùng nữa), nhưng MVAPICH2 có các tối ưu hóa rộng rãi khiến nó trở thành triển khai ưa thích trong hầu hết các trường hợp.

Hỗ trợ tính năng từ Tiêu chuẩn MPI mới nhất

Trục trực giao để hỗ trợ phần cứng / nền tảng là phạm vi của tiêu chuẩn MPI. Ở đây MPICH thường là xa và vượt trội. MPICH là triển khai đầu tiên của mỗi bản phát hành tiêu chuẩn MPI, từ MPI-1 đến MPI-3. Open-MPI mới chỉ hỗ trợ MPI-3 và tôi thấy rằng một số tính năng MPI-3 bị lỗi trên một số nền tảng (dĩ nhiên MPICH không có lỗi, nhưng lỗi trong các tính năng MPI-3 đã ít phổ biến hơn).

Trong lịch sử, Open-MPI không có sự hỗ trợ toàn diện MPI_THREAD_MULTIPLE, điều này rất quan trọng đối với một số ứng dụng. Nó có thể được hỗ trợ trên một số nền tảng nhưng thường không thể được coi là hoạt động. Mặt khác, MPICH đã hỗ trợ toàn diện MPI_THREAD_MULTIPLEtrong nhiều năm, mặc dù việc triển khai không phải lúc nào cũng có hiệu suất cao (xem "Khóa các khía cạnh trong triển khai MPI đa luồng" cho một phân tích).

Một tính năng khác đã bị phá vỡ trong Open-MPI 1.x là giao tiếp một phía, còn gọi là RMA. Điều này gần đây đã được sửa và tôi thấy, với tư cách là người dùng rất nặng các tính năng này, chúng thường hoạt động tốt trong Open-MPI 3.x (xem ví dụ ma trận thử nghiệm ARMCI-MPI trong Travis CI để biết kết quả cho thấy RMA hoạt động với cả hai triển khai, ít nhất là trong bộ nhớ dùng chung. Tôi đã thấy kết quả tích cực tương tự trên Intel Omni Path, nhưng chưa thử nghiệm Mellanox InfiniBand.

Quản lý quy trình

Một lĩnh vực mà Open-MPI từng vượt trội đáng kể là trình quản lý quy trình. Việc khởi chạy MPICH cũ (MPD) rất dễ vỡ và khó sử dụng. May mắn thay, nó đã bị phản đối trong nhiều năm (xem mục Câu hỏi thường gặp về MPICH để biết chi tiết). Do đó, sự chỉ trích MPICH vì MPD là giả mạo.

Trình quản lý quy trình Hydra khá tốt và có tính năng sử dụng và tính năng tương tự được đặt là ORTE (trong Open-MPI), ví dụ cả hai đều hỗ trợ HWLOC để kiểm soát cấu trúc liên kết quá trình. Có các báo cáo về quá trình khởi động Open-MPI nhanh hơn các dẫn xuất MPICH cho các công việc lớn hơn (hơn 1000 quy trình), nhưng vì tôi không có kinh nghiệm trực tiếp ở đây, tôi không thoải mái đưa ra bất kỳ kết luận nào. Các vấn đề hiệu suất như vậy thường là mạng cụ thể và đôi khi thậm chí là máy cụ thể.

Tôi đã thấy Open-MPI mạnh hơn khi sử dụng MacOS với VPN, tức là MPICH có thể bị treo khi khởi động do các vấn đề về độ phân giải tên máy chủ. Vì đây là một lỗi, vấn đề này có thể biến mất trong tương lai.

Tính di động nhị phân

Mặc dù cả MPICH và Open-MPI đều là phần mềm nguồn mở có thể được biên dịch trên nhiều nền tảng, tính di động của các thư viện MPI ở dạng nhị phân hoặc các chương trình được liên kết với chúng, thường rất quan trọng.

MPICH và nhiều công cụ phái sinh của nó hỗ trợ khả năng tương thích ABI ( trang web ), có nghĩa là giao diện nhị phân cho thư viện là không đổi và do đó người ta có thể biên dịch mpi.htừ một triển khai và sau đó chạy với một triển khai khác. Điều này đúng ngay cả trên nhiều phiên bản của các thư viện. Ví dụ, tôi thường biên dịch MPI Intel nhưng LD_PRELOADlà phiên bản phát triển của MPICH khi chạy. Một trong những lợi thế lớn của khả năng tương thích ABI là ISV (Nhà cung cấp phần mềm độc lập) có thể phát hành các tệp nhị phân được biên dịch chỉ với một thành viên của gia đình MPICH.

ABI không phải là loại tương thích nhị phân duy nhất. Các kịch bản được mô tả ở trên giả định rằng người dùng sử dụng cùng một phiên bản trình khởi chạy MPI (thường mpirunhoặc mpiexeccùng với trình nền nút tính toán của nó) và thư viện MPI ở mọi nơi. Điều này không nhất thiết là trường hợp cho container.

Mặc dù Open-MPI không hứa hẹn khả năng tương thích ABI, họ đã đầu tư rất nhiều vào việc hỗ trợ các container ( tài liệu , slide ). Điều này đòi hỏi rất cẩn thận trong việc duy trì khả năng tương thích giữa các phiên bản khác nhau của trình khởi chạy MPI, trình khởi chạy trình khởi chạy và Thư viện MPI, bởi vì người dùng có thể khởi chạy các công việc bằng cách sử dụng phiên bản trình khởi chạy MPI mới hơn so với trình khởi chạy trình khởi chạy trong hỗ trợ vùng chứa. Nếu không chú ý cẩn thận đến sự ổn định của giao diện trình khởi chạy, các lệnh trong vùng chứa sẽ không khởi chạy trừ khi các phiên bản của từng thành phần của trình khởi chạy tương thích. Đây không phải là một vấn đề không thể vượt qua:

Cách giải quyết được sử dụng bởi thế giới Docker, chẳng hạn, là để chứa cơ sở hạ tầng cùng với ứng dụng. Nói cách khác, bạn bao gồm trình nền MPI trong vùng chứa với chính ứng dụng và sau đó yêu cầu tất cả các vùng chứa (bao gồm mpiexec) phải có cùng phiên bản. Điều này tránh được vấn đề vì bạn không còn có các hoạt động cơ sở hạ tầng phiên bản chéo.

Tôi thừa nhận Ralph Castain của nhóm Open-MPI đã giải thích cho tôi về các vấn đề về container. Các trích dẫn ngay trước đó là của mình.

So sánh nền tảng cụ thể

Dưới đây là đánh giá của tôi trên cơ sở từng nền tảng:

  • Mac OS: cả Open-MPI và MPICH đều hoạt động tốt. Để có được các tính năng mới nhất của tiêu chuẩn MPI-3, bạn cần sử dụng phiên bản Open-MPI gần đây, có sẵn từ Homebrew. Không có lý do để suy nghĩ về hiệu suất MPI nếu bạn đang chạy trên máy tính xách tay Mac.

  • Linux với bộ nhớ dùng chung: cả Open-MPI và MPICH đều hoạt động tốt. Nếu bạn muốn có phiên bản phát hành hỗ trợ tất cả MPI-3 hoặc MPI_THREAD_MULTIPLE, thì có lẽ bạn cần MPICH, trừ khi bạn tự xây dựng Open-MPI, vì ví dụ Ubuntu 16.04 chỉ cung cấp phiên bản cũ 1.10 qua APT. Tôi không nhận thấy bất kỳ sự khác biệt đáng kể về hiệu suất giữa hai lần thực hiện. Cả hai đều hỗ trợ tối ưu hóa bản sao đơn nếu HĐH cho phép chúng.

  • Linux với Mellanox InfiniBand: sử dụng Open-MPI hoặc MVAPICH2. Nếu bạn muốn có phiên bản phát hành hỗ trợ tất cả MPI-3 hoặc MPI_THREAD_MULTIPLE, bạn có thể cần MVAPICH2. Tôi thấy rằng MVAPICH2 hoạt động rất tốt nhưng chưa thực hiện so sánh trực tiếp với OpenMPI trên InfiniBand, một phần vì các tính năng mà hiệu suất quan trọng nhất đối với tôi (RMA hay một chiều) đã bị phá vỡ trong Open-MPI trong quá khứ.

  • Linux với Intel Omni Path (hoặc tiền thân của nó, True Scale): Tôi đã sử dụng MVAPICH2, Intel MPI, MPICH và Open-MPI trên các hệ thống như vậy và tất cả đều hoạt động. Intel MPI có xu hướng được tối ưu hóa nhất trong khi Open-MPI mang lại hiệu suất tốt nhất cho việc triển khai nguồn mở vì chúng có back-end dựa trên PSM2 được tối ưu hóa tốt . Tôi có một số lưu ý trên GitHub về cách xây dựng các triển khai nguồn mở khác nhau, nhưng thông tin đó sẽ bị chậm lại khá nhanh.

  • Siêu máy tính Cray hoặc IBM: MPI được cài đặt tự động trên các máy này và nó dựa trên MPICH trong cả hai trường hợp. Đã có các cuộc biểu tình về MPICH trên Cray XC40 ( ở đây ) bằng cách sử dụng OFI , Intel MPI trên Cray XC40 ( ở đây ) bằng OFI, MPICH trên Blue Gene / Q bằng OFI ( ở đây ) và Open-MPI trên Cray XC40 bằng cả OFI và uGNI ( ở đây ), nhưng không ai trong số này được nhà cung cấp hỗ trợ.

  • Windows: Tôi thấy không có điểm nào trong việc chạy MPI trên Windows ngoại trừ thông qua máy ảo Linux, nhưng cả Microsoft MPI và Intel MPI đều hỗ trợ Windows và dựa trên MPICH. Tôi đã nghe báo cáo về các bản dựng MPICH hoặc Open-MPI thành công khi sử dụng Windows subsystem cho Linux nhưng không có kinh nghiệm cá nhân.

Ghi chú

Để tiết lộ đầy đủ, tôi hiện đang làm việc cho Intel trong khả năng nghiên cứu / tìm đường (tức là tôi không làm việc trên bất kỳ sản phẩm phần mềm nào của Intel) và trước đây đã làm việc cho Phòng thí nghiệm quốc gia Argonne trong năm năm, nơi tôi cộng tác rộng rãi với nhóm MPICH.


Có thể OpenMPI có hỗ trợ vượt trội cho bộ nhớ chia sẻ trong tập thể, nhưng tôi cần điều tra kỹ trước khi cập nhật câu trả lời của mình.
Jeff

2
Bạn có thể giải thích lý do tại sao bạn thấy không có điểm nào trong việc chạy MPI trên Windows không?
Dmitri Nesteruk

3
Không, nhưng cảm thấy muốn hỏi một câu hỏi mới trên StackOverflow về HPC trên Windows.
Jeff

@Jeff, bạn đã nhấn mạnh MPI_THREAD_MULTIPLEcâu trả lời, nhưng tôi không có kinh nghiệm thực sự để sử dụng nó trước đây. Bạn có thể đưa ra một số trường hợp / ví dụ người dùng trong đó MPI_THREAD_MULTIPLEhữu ích và hiệu quả so với các chế độ khác như MPI THREAD FUNNELEDkhông? Ấn tượng đầu tiên của tôi là chức năng này làm cho chương trình phức tạp hơn và khó gỡ lỗi giữa luồng và tiến trình. Cảm ơn.
Patric

1
Chỉ cần lưu ý rằng Open-MPI hiện biên dịch và chạy tốt trên Windows Subsytem cho Linux - tôi cũng đoán mpich.
jawknee

12

Nếu bạn phát triển hơn là hệ thống sản xuất, hãy đi với MPICH. MPICH có trình gỡ lỗi tích hợp, trong khi Open-MPI không kiểm tra lần cuối.

Trong sản xuất, Open-MPI rất có thể sẽ nhanh hơn. Nhưng sau đó, bạn có thể muốn nghiên cứu các lựa chọn thay thế khác, chẳng hạn như Intel MPI.


3
Tôi không chắc ý của bạn về trình gỡ lỗi tích hợp, nhưng tôi thấy rằng Open-MPI có khả năng tích hợp tốt với ví dụ: gdb: open-mpi.org/faq/?carget=debugging .
Jeff

Đối với sản xuất, có bất kỳ suy nghĩ về việc sử dụng MPICH với TAO?
namu

10

Tôi đồng tình với các poster trước. Hãy thử cả hai để xem ứng dụng nào của bạn chạy nhanh hơn sau đó sử dụng nó cho sản xuất. Cả hai đều tuân thủ tiêu chuẩn. Nếu đó là máy tính để bàn của bạn hoặc là tốt. OpenMPI ra khỏi hộp trên Macbook và MPICH dường như thân thiện hơn với Linux / Valgrind. Đó là giữa bạn và toolchain của bạn.

Nếu đó là cụm sản xuất, bạn cần thực hiện đo điểm chuẩn rộng hơn để đảm bảo nó được tối ưu hóa cho cấu trúc liên kết mạng của bạn. Cấu hình nó trên một cụm sản xuất sẽ là sự khác biệt chính về thời gian của bạn vì bạn sẽ phải RTFM.


12
Nếu mọi người RTFMed, chúng tôi sẽ không cần StackOverflow :-)
Jeff

1
FWIW, Open-MPI có mục FAQ về Valgrind- cleanness
Jeff

@Jeff Um còn lỗi thì sao? Hết tài liệu? Đó là đằng sau một số lượng lớn các câu hỏi của tôi (hàng trăm ..) ở đây;)
javadba

6

Cả hai đều tuân thủ tiêu chuẩn, do đó, không quan trọng bạn sử dụng từ quan điểm chính xác nào. Trừ khi có một số tính năng, chẳng hạn như tiện ích gỡ lỗi cụ thể, mà bạn cần, sau đó điểm chuẩn cả hai và chọn bất kỳ ứng dụng nào nhanh hơn cho ứng dụng của bạn trên phần cứng. Cũng xem xét rằng có các triển khai MPI khác có thể cho hiệu năng hoặc khả năng tương thích tốt hơn, chẳng hạn như MVAPICH (có thể có hiệu suất InfiniBand tốt nhất) hoặc Intel MPI (ISV được hỗ trợ rộng rãi). HP đã làm việc chăm chỉ để có được MPI của họ đủ điều kiện với rất nhiều mã ISV, nhưng tôi không chắc nó sẽ được bán như thế nào sau khi được bán trên Nền tảng ...


2

Theo kinh nghiệm của tôi, một tính năng tốt mà OpenMPI hỗ trợ nhưng MPICH không phải là mối quan hệ quá trình . Ví dụ: trong OpenMPI, sử dụng -npersocketbạn có thể đặt số thứ hạng được khởi chạy trên mỗi ổ cắm. Ngoài ra, OpenMPI rankfilekhá tiện dụng khi bạn muốn xác định thứ hạng cho các lõi hoặc đăng ký vượt mức chúng.

Cuối cùng, nếu bạn cần kiểm soát việc ánh xạ các cấp bậc thành lõi, tôi chắc chắn sẽ khuyên bạn nên viết và biên dịch mã của mình bằng OpenMPI.


2
MPICH hỗ trợ mối quan hệ. wiki.mpich.org/mpich/index.php/
Jeff
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.