Bisakah seseorang menguraikan perbedaan antara implementasi OpenMPI dan MPICH dari MPI? Manakah dari keduanya yang merupakan implementasi yang lebih baik?
Kami secara pribadi memilih OpenMPI sebagai implementasi MPI kami. Bagi kami, ini merupakan benchmark yang lebih baik dan portabilitas tidak menjadi masalah besar. Lihat tautan pertanyaan yang diposting Taylor L.
Xorlev
1
Anda juga dapat mempertimbangkan bahwa dalam tren Google OpenMPI 2-3 kali lebih banyak dicari daripada MPICH / MPICH2.
Isi
Saya pikir MPICH tidak lagi didukung dalam versi Linux terbaru (mis., Ubuntu 18 tidak dapat menjalankannya), IIRC hanya berfungsi pada versi kernel tertentu
jrh
Jawaban:
148
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.
Mungkin saja OpenMPI memiliki dukungan superior untuk memori bersama dalam kolektif, tetapi saya perlu menyelidiki dengan seksama sebelum memperbarui jawaban saya.
Jeff
2
Bisakah Anda menguraikan mengapa Anda tidak melihat gunanya menjalankan MPI di Windows?
Dmitri Nesteruk
3
Tidak, tetapi ingin mengajukan pertanyaan baru tentang StackOverflow tentang HPC di Windows.
Jeff
@ Jeff, Anda menyorot MPI_THREAD_MULTIPLEjawabannya, tapi saya tidak punya pengalaman nyata untuk menggunakannya sebelumnya. Bisakah Anda memberikan beberapa case / contoh pengguna MPI_THREAD_MULTIPLEyang bermanfaat dan efisien dibandingkan dengan mode lain seperti MPI THREAD FUNNELED? Kesan pertama saya adalah fungsi ini membuat program lebih kompleks dan sulit untuk di-debug antara utas dan proses. Terima kasih.
Patric
1
Hanya sebuah catatan bahwa Open-MPI sekarang mengkompilasi dan berjalan dengan baik pada Windows Subsytem untuk Linux - saya kira mpich juga.
jawknee
12
Jika Anda melakukan pengembangan daripada sistem produksi, ikuti MPICH. MPICH memiliki debugger bawaan, sedangkan Open-MPI tidak terakhir kali saya periksa.
Dalam produksi, Open-MPI kemungkinan besar akan lebih cepat. Tetapi Anda mungkin ingin mencari alternatif lain, seperti Intel MPI.
Saya tidak yakin apa yang Anda maksud dengan debugger bawaan, tetapi saya menemukan bahwa Open-MPI memiliki integrasi yang baik dengan misalnya gdb: open-mpi.org/faq/?category=debugging .
Jeff
Untuk produksi, apakah ada pemikiran untuk menggunakan MPICH dengan TAO?
namu
10
Saya setuju dengan poster sebelumnya. Coba keduanya untuk melihat yang mana aplikasi Anda berjalan lebih cepat kemudian menggunakannya untuk produksi. Keduanya memenuhi standar. Jika desktop Anda baik-baik saja. OpenMPI keluar dari kotak di Macbooks, dan MPICH tampaknya lebih ramah Linux / Valgrind. Itu antara Anda dan rantai alat Anda.
Jika ini adalah cluster produksi, Anda perlu melakukan benchmark lebih luas untuk memastikannya dioptimalkan ke topologi jaringan Anda. Mengkonfigurasinya pada cluster produksi akan menjadi perbedaan utama dalam hal waktu Anda karena Anda harus RTFM.
@ Jeff Um bagaimana dengan bug? Dokumen kedaluwarsa? Itu di belakang sejumlah (ratusan ..) pertanyaan saya di sini;)
javadba
6
Keduanya sesuai standar, jadi tidak masalah yang Anda gunakan dari sudut pandang kebenaran. Kecuali jika ada beberapa fitur, seperti ekstensi debug tertentu, yang Anda butuhkan, maka patok keduanya dan pilih mana yang lebih cepat untuk aplikasi Anda di perangkat keras Anda. Juga pertimbangkan bahwa ada implementasi MPI lain yang mungkin memberikan kinerja atau kompatibilitas yang lebih baik, seperti MVAPICH (dapat memiliki kinerja InfiniBand terbaik) atau Intel MPI (ISV yang didukung secara luas). HP bekerja keras untuk mendapatkan MPI mereka yang memenuhi syarat dengan banyak kode ISV juga, tetapi saya tidak yakin bagaimana hasilnya setelah dijual ke Platform ...
Dari pengalaman saya, satu fitur bagus yang didukung OpenMPI tetapi MPICH tidak adalah afinitas proses . Misalnya, di OpenMPI, menggunakan -npersocketAnda dapat mengatur jumlah peringkat yang diluncurkan pada setiap soket. Selain itu, OpenMPI rankfilesangat berguna ketika Anda ingin menentukan peringkat untuk core atau berlangganan secara berlebihan .
Terakhir, jika Anda perlu mengontrol pemetaan peringkat ke inti, saya pasti akan menyarankan menulis dan mengkompilasi kode Anda menggunakan OpenMPI.
Jawaban:
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 holistikMPI_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 tetapiLD_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
mpirunataumpiexec, 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:
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.
sumber
MPI_THREAD_MULTIPLEjawabannya, tapi saya tidak punya pengalaman nyata untuk menggunakannya sebelumnya. Bisakah Anda memberikan beberapa case / contoh penggunaMPI_THREAD_MULTIPLEyang bermanfaat dan efisien dibandingkan dengan mode lain sepertiMPI THREAD FUNNELED? Kesan pertama saya adalah fungsi ini membuat program lebih kompleks dan sulit untuk di-debug antara utas dan proses. Terima kasih.Jika Anda melakukan pengembangan daripada sistem produksi, ikuti MPICH. MPICH memiliki debugger bawaan, sedangkan Open-MPI tidak terakhir kali saya periksa.
Dalam produksi, Open-MPI kemungkinan besar akan lebih cepat. Tetapi Anda mungkin ingin mencari alternatif lain, seperti Intel MPI.
sumber
Saya setuju dengan poster sebelumnya. Coba keduanya untuk melihat yang mana aplikasi Anda berjalan lebih cepat kemudian menggunakannya untuk produksi. Keduanya memenuhi standar. Jika desktop Anda baik-baik saja. OpenMPI keluar dari kotak di Macbooks, dan MPICH tampaknya lebih ramah Linux / Valgrind. Itu antara Anda dan rantai alat Anda.
Jika ini adalah cluster produksi, Anda perlu melakukan benchmark lebih luas untuk memastikannya dioptimalkan ke topologi jaringan Anda. Mengkonfigurasinya pada cluster produksi akan menjadi perbedaan utama dalam hal waktu Anda karena Anda harus RTFM.
sumber
Keduanya sesuai standar, jadi tidak masalah yang Anda gunakan dari sudut pandang kebenaran. Kecuali jika ada beberapa fitur, seperti ekstensi debug tertentu, yang Anda butuhkan, maka patok keduanya dan pilih mana yang lebih cepat untuk aplikasi Anda di perangkat keras Anda. Juga pertimbangkan bahwa ada implementasi MPI lain yang mungkin memberikan kinerja atau kompatibilitas yang lebih baik, seperti MVAPICH (dapat memiliki kinerja InfiniBand terbaik) atau Intel MPI (ISV yang didukung secara luas). HP bekerja keras untuk mendapatkan MPI mereka yang memenuhi syarat dengan banyak kode ISV juga, tetapi saya tidak yakin bagaimana hasilnya setelah dijual ke Platform ...
sumber
Dari pengalaman saya, satu fitur bagus yang didukung OpenMPI tetapi MPICH tidak adalah afinitas proses . Misalnya, di OpenMPI, menggunakan
-npersocketAnda dapat mengatur jumlah peringkat yang diluncurkan pada setiap soket. Selain itu, OpenMPIrankfilesangat berguna ketika Anda ingin menentukan peringkat untuk core atau berlangganan secara berlebihan .Terakhir, jika Anda perlu mengontrol pemetaan peringkat ke inti, saya pasti akan menyarankan menulis dan mengkompilasi kode Anda menggunakan OpenMPI.
sumber