Tujuan
Pertama, penting untuk mengenali bagaimana MPICH dan Open-MPI berbeda, yaitu mereka dirancang untuk memenuhi kebutuhan yang berbeda. MPICH seharusnya menjadi implementasi referensi berkualitas tinggi dari standar MPI terbaru dan dasar untuk implementasi derivatif untuk memenuhi kebutuhan tujuan khusus. Open-MPI menargetkan kasus umum, baik dalam hal penggunaan dan saluran jaringan.
Dukungan untuk Teknologi Jaringan
Open-MPI mendokumentasikan dukungan jaringan mereka di sini . MPICH mencantumkan informasi ini dalam README yang didistribusikan dengan setiap versi (mis. Ini untuk 3.2.1). Perhatikan bahwa karena Open-MPI dan MPICH mendukung OFI(alias libfabric) lapisan jaringan, mereka mendukung banyak jaringan yang sama. Namun, libfabric adalah multi-faceted API, jadi tidak setiap jaringan dapat didukung yang sama di keduanya (mis. MPICH memiliki implementasi IBM Blue Gene / Q berbasis OFI, tetapi saya tidak mengetahui adanya dukungan setara di Open-MPI) . Namun, implementasi MPICH dan Open-MPI berbasis OFI bekerja pada shared-memory, Ethernet (melalui TCP / IP), Mellanox InfiniBand, Intel Omni Path, dan kemungkinan jaringan lainnya. Open-MPI juga mendukung kedua jaringan ini dan lainnya secara native (yaitu tanpa OFI di tengah).
Di masa lalu, keluhan umum tentang MPICH adalah bahwa ia tidak mendukung InfiniBand, sedangkan Open-MPI mendukung. Namun, MVAPICH dan Intel MPI (antara lain) - keduanya merupakan turunan MPICH - mendukung InfiniBand, jadi jika seseorang mau mendefinisikan MPICH sebagai "MPICH dan turunannya", maka MPICH memiliki dukungan jaringan yang sangat luas, termasuk InfiniBand dan kepemilikan. interkoneksi seperti Cray Seastar, Gemini dan Aries serta IBM Blue Gene (/ L, / P dan / Q). Open-MPI juga mendukung interkoneksi Cray Gemini, tetapi penggunaannya tidak didukung oleh Cray. Baru-baru ini, MPICH mendukung InfiniBand melalui netmod (sekarang sudah tidak digunakan lagi), tetapi MVAPICH2 memiliki optimisasi luas yang menjadikannya implementasi yang disukai dalam hampir semua kasus.
Dukungan Fitur dari Standar MPI Terbaru
Sumbu ortogonal untuk dukungan perangkat keras / platform adalah cakupan standar MPI. Di sini MPICH biasanya jauh dan unggul. MPICH telah menjadi implementasi pertama dari setiap rilis standar MPI, dari MPI-1 ke MPI-3. Open-MPI hanya baru-baru ini mendukung MPI-3 dan saya menemukan bahwa beberapa fitur MPI-3 buggy pada beberapa platform (tentu saja MPICH tidak bebas bug, tetapi bug pada fitur MPI-3 jauh lebih jarang terjadi).
Secara historis, Open-MPI belum memiliki dukungan holistik untuk MPI_THREAD_MULTIPLE, yang sangat penting untuk beberapa aplikasi. Mungkin didukung pada beberapa platform tetapi umumnya tidak dapat dianggap berfungsi. Di sisi lain, MPICH telah memiliki dukungan holistik MPI_THREAD_MULTIPLEselama bertahun-tahun, meskipun implementasinya tidak selalu berkinerja tinggi (lihat "Mengunci Aspek dalam Implementasi MPI Multithreaded" untuk satu analisis).
Fitur lain yang rusak di Open-MPI 1.x adalah komunikasi satu sisi, alias RMA. Ini baru-baru ini diperbaiki dan saya menemukan, sebagai pengguna yang sangat berat dari fitur-fitur ini, bahwa mereka umumnya bekerja dengan baik di Open-MPI 3.x (lihat misalnya matriks tes ARMCI-MPI di Travis CI untuk hasil yang menunjukkan RMA bekerja dengan kedua implementasi, setidaknya dalam memori bersama. Saya telah melihat hasil positif yang serupa pada Intel Omni Path, tetapi belum menguji Mellanox InfiniBand.
Manajemen proses
Satu bidang di mana Open-MPI dulu secara signifikan unggul adalah manajer proses. Peluncuran MPICH lama (MPD) rapuh dan sulit digunakan. Untungnya, itu telah ditinggalkan selama bertahun-tahun (lihat entri FAQ MPICH untuk detailnya). Dengan demikian, kritik terhadap MPICH karena MPD adalah palsu.
Manajer proses Hydra cukup baik dan memiliki kegunaan dan fitur yang sama ditetapkan sebagai ORTE (dalam Open-MPI), misalnya keduanya mendukung HWLOC untuk kontrol atas topologi proses. Ada laporan peluncuran proses MPI Terbuka yang lebih cepat daripada MPICH-turunan untuk pekerjaan yang lebih besar (1000+ proses), tetapi karena saya tidak memiliki pengalaman langsung di sini, saya tidak nyaman menyatakan kesimpulan apa pun. Masalah kinerja seperti itu biasanya khusus untuk jaringan dan kadang-kadang bahkan untuk mesin.
Saya telah menemukan Open-MPI menjadi lebih kuat ketika menggunakan MacOS dengan VPN, yaitu MPICH mungkin hang di startup karena masalah resolusi hostname. Karena ini adalah bug, masalah ini dapat hilang di masa mendatang.
Portabilitas Biner
Sementara MPICH dan Open-MPI adalah perangkat lunak open-source yang dapat dikompilasi pada berbagai platform, portabilitas perpustakaan MPI dalam bentuk biner, atau program yang dikaitkan dengannya, seringkali penting.
MPICH dan banyak turunannya mendukung kompatibilitas ABI ( situs web ), yang berarti bahwa antarmuka biner ke pustaka adalah konstan dan karenanya seseorang dapat dikompilasi dengan mpi.hdari satu implementasi dan kemudian dijalankan dengan yang lain. Ini benar bahkan di beberapa versi perpustakaan. Sebagai contoh, saya sering mengkompilasi Intel MPI tetapi LD_PRELOADversi pengembangan MPICH saat runtime. Salah satu keuntungan besar kompatibilitas ABI adalah bahwa ISV (Vendor Perangkat Lunak Independen) dapat merilis binari yang dikompilasi hanya dengan satu anggota keluarga MPICH.
ABI bukan satu-satunya jenis kompatibilitas biner. Skenario yang dijelaskan di atas mengasumsikan bahwa pengguna menggunakan versi yang sama dari peluncur MPI (biasanya mpirunatau mpiexec, bersama dengan daemon komputasi-simpulnya) dan perpustakaan MPI di mana-mana. Ini belum tentu berlaku untuk wadah.
Sementara Open-MPI tidak menjanjikan kompatibilitas ABI, mereka telah banyak berinvestasi dalam wadah pendukung ( dokumen , slide ). Hal ini membutuhkan kehati-hatian dalam menjaga kompatibilitas di berbagai versi peluncur MPI, peluncur daemon, dan Perpustakaan MPI, karena pengguna dapat meluncurkan pekerjaan menggunakan versi peluncur MPI yang lebih baru daripada daemon peluncur dalam dukungan penampung. Tanpa memperhatikan stabilitas antarmuka peluncur, pekerjaan kontainer tidak akan diluncurkan kecuali versi masing-masing komponen peluncur kompatibel. Ini bukan masalah yang tidak dapat diatasi:
Solusi yang digunakan oleh dunia Docker, misalnya, adalah untuk membuat kontainer infrastruktur beserta aplikasi. Dengan kata lain, Anda memasukkan daemon MPI dalam wadah dengan aplikasi itu sendiri, dan kemudian mengharuskan semua kontainer (termasuk mpiexec) dari versi yang sama. Ini menghindari masalah karena Anda tidak lagi memiliki operasi infrastruktur lintas versi.
Saya mengakui Ralph Castain dari tim Open-MPI karena menjelaskan masalah kontainer kepada saya. Kutipan segera sebelumnya adalah miliknya.
Perbandingan Platform-Spesifik
Berikut ini adalah evaluasi saya berdasarkan platform per platform:
Mac OS: Open-MPI dan MPICH seharusnya berfungsi dengan baik. Untuk mendapatkan fitur terbaru dari standar MPI-3, Anda perlu menggunakan versi terbaru dari Open-MPI, yang tersedia dari Homebrew. Tidak ada alasan untuk berpikir tentang kinerja MPI jika Anda menggunakan laptop Mac.
Linux dengan memori bersama: Open-MPI dan MPICH seharusnya berfungsi dengan baik. Jika Anda menginginkan versi rilis yang mendukung semua MPI-3 atau MPI_THREAD_MULTIPLE, Anda mungkin memerlukan MPICH, kecuali Anda membuat Open-MPI sendiri, karena misalnya Ubuntu 16.04 hanya menyediakan versi kuno 1.10 melalui APT. Saya tidak mengetahui adanya perbedaan kinerja yang signifikan antara kedua implementasi. Keduanya mendukung optimasi salin tunggal jika OS mengizinkannya.
Linux dengan Mellanox InfiniBand: gunakan Open-MPI atau MVAPICH2. Jika Anda menginginkan versi rilis yang mendukung semua MPI-3 atau MPI_THREAD_MULTIPLE, Anda mungkin memerlukan MVAPICH2. Saya menemukan bahwa MVAPICH2 berkinerja sangat baik tetapi belum melakukan perbandingan langsung dengan OpenMPI di InfiniBand, sebagian karena fitur yang paling penting kinerjanya bagi saya (RMA alias sepihak) telah rusak di Open-MPI di masa lalu.
Linux dengan Intel Omni Path (atau pendahulunya, True Scale): Saya telah menggunakan MVAPICH2, Intel MPI, MPICH dan Open-MPI pada sistem seperti itu, dan semuanya bekerja. Intel MPI cenderung yang paling dioptimalkan sementara Open-MPI memberikan kinerja terbaik dari implementasi open-source karena mereka memiliki back-end berbasis PSM2 yang dioptimalkan dengan baik . Saya punya beberapa catatan tentang GitHub tentang bagaimana membangun implementasi open-source yang berbeda, tetapi informasi seperti itu menjadi agak membosankan.
Komputer super atau IBM superkomputer: MPI dipasang pada mesin ini secara otomatis dan didasarkan pada MPICH dalam kedua kasus. Telah ada demonstrasi MPICH di Cray XC40 (di sini ) menggunakan OFI , Intel MPI di Cray XC40 (di sini ) menggunakan OFI, MPICH di Blue Gene / Q menggunakan OFI (di sini ), dan Open-MPI di Cray XC40 menggunakan OFI dan uGNI (di sini ), tetapi tidak ada satupun yang didukung vendor.
Windows: Saya melihat tidak ada gunanya menjalankan MPI di Windows kecuali melalui Linux VM, tetapi baik Microsoft MPI dan Intel MPI mendukung Windows dan berbasis MPICH. Saya telah mendengar laporan sukses membangun MPICH atau Open-MPI menggunakan Windows Subsystem untuk Linux tetapi tidak memiliki pengalaman pribadi.
Catatan
Dalam pengungkapan penuh, saya saat ini bekerja untuk Intel dalam kapasitas penelitian / pencarian jalan (yaitu saya tidak bekerja pada produk perangkat lunak Intel) dan sebelumnya bekerja untuk Argonne National Lab selama lima tahun, di mana saya berkolaborasi secara luas dengan tim MPICH.