amaç
Birincisi, MPICH ve Open-MPI'nin ne kadar farklı olduğunu, yani farklı ihtiyaçları karşılamak için tasarlandıklarını anlamak önemlidir. MPICH'nin, en son MPI standardının yüksek kaliteli referans uygulaması ve özel amaçlı ihtiyaçları karşılamak için türev uygulamalarının temeli olması beklenir. Open-MPI, hem kullanım hem de ağ kanalları açısından ortak durumu hedefler.
Ağ Teknolojisi Desteği
Open-MPI, ağ desteğini burada belgeler . MPICH bu bilgileri her sürümle birlikte dağıtılan README'de listeler (örn. Bu 3.2.1 içindir). Not o Açık MPI ve MPICH ikisini de destekler çünkü ofi (diğer adıyla libfabric) ağ katmanını desteklediğinden, aynı ağların çoğunu desteklediklerini unutmayın. Bununla birlikte, libfabric çok yönlü bir API'dir, bu nedenle her ağ her ikisinde de aynı şekilde desteklenmeyebilir (örneğin, MPICH, OFI tabanlı bir IBM Blue Gene / Q uygulamasına sahiptir, ancak Open-MPI'de eşdeğer bir desteğin farkında değilim) . Bununla birlikte, hem MPICH hem de Open-MPI'nin OFI tabanlı uygulamaları, paylaşılan bellek, Ethernet (TCP / IP yoluyla), Mellanox InfiniBand, Intel Omni Path ve muhtemelen diğer ağlarda çalışmaktadır. Open-MPI ayrıca hem bu ağları hem de diğerlerini yerel olarak destekler (yani ortada OFI olmadan).
Geçmişte MPICH ile ilgili yaygın bir şikayet, InfiniBand'i desteklememesi, oysa Open-MPI desteklemesidir. Bununla birlikte, her ikisi de MPICH türevleri olan MVAPICH ve Intel MPI (diğerleri arasında) InfiniBand'ı destekler, bu nedenle MPICH'yi "MPICH ve türevleri" olarak tanımlamaya istekliyseniz, MPICH hem InfiniBand hem de tescilli olmak üzere son derece geniş bir ağ desteğine sahiptir. Cray Seastar, Gemini ve Aries ile IBM Blue Gene (/ L, / P ve / Q) gibi birbirleriyle bağlantı kurar. Open-MPI, Cray Gemini ara bağlantısını da destekler, ancak kullanımı Cray tarafından desteklenmez. Daha yakın zamanlarda, MPICH bir netmod aracılığıyla InfiniBand'i destekledi (artık kullanımdan kaldırıldı), ancak MVAPICH2, onu neredeyse tüm durumlarda tercih edilen uygulama yapan kapsamlı optimizasyonlara sahiptir.
En Son MPI Standardından Özellik Desteği
Donanım / platform desteğine ortogonal bir eksen, MPI standardının kapsamıdır. Burada MPICH genellikle çok daha üstündür. MPICH, MPI standardının MPI-1'den MPI-3'e kadar her bir sürümünün ilk uygulaması olmuştur. Open-MPI yakın zamanda MPI-3'ü destekledi ve bazı MPI-3 özelliklerinin bazı platformlarda hatalı olduğunu görüyorum (MPICH elbette hatasız değildir, ancak MPI-3 özelliklerindeki hatalar çok daha az yaygın olmuştur).
Tarihsel olarak, Open-MPI, MPI_THREAD_MULTIPLEbazı uygulamalar için kritik olan bütünsel bir desteğe sahip değildi . Bazı platformlarda desteklenebilir ancak genellikle çalıştığı varsayılamaz. Öte yandan, MPICH, MPI_THREAD_MULTIPLEuygulama her zaman yüksek performanslı olmasa da, yıllardır bütünsel desteğe sahiptir ( bir analiz için bkz. "Çok İş Parçacıklı MPI Uygulamalarında Yönleri Kilitleme" ).
Open-MPI 1.x'te kırılan bir başka özellik de tek taraflı iletişimdi, RMA. Bu daha yakın zamanda düzeltildi ve bu özelliklerin çok yoğun bir kullanıcısı olarak, genellikle Open-MPI 3.x'te iyi çalıştıklarını buldum (örneğin, RMA ile çalışan RMA'yı gösteren sonuçlar için Travis CI'daki ARMCI-MPI test matrisine bakın) her iki uygulama da, en azından paylaşılan bellekte. Intel Omni Yolunda benzer olumlu sonuçlar gördüm, ancak Mellanox InfiniBand'i test etmedim.
Süreç yönetimi
Açık-MPI'nin önemli ölçüde üstün olduğu bir alan, süreç yöneticisiydi. Eski MPICH fırlatma (MPD) kırılgandı ve kullanımı zordu. Neyse ki, uzun yıllardır kullanımdan kaldırıldı (ayrıntılar için MPICH SSS girişine bakın). Bu nedenle, MPICH'nin MPD nedeniyle eleştirilmesi sahte.
Hydra süreç yöneticisi oldukça iyidir ve ORTE (Açık MPI'de) olarak benzer kullanılabilirlik ve özellik setine sahiptir, örneğin, her ikisi de süreç topolojisi üzerinde kontrol için HWLOC'u destekler. Açık-MPI sürecinin daha büyük işler için (1000'den fazla işlem) MPICH türevlerinden daha hızlı başlatıldığına dair raporlar var, ancak burada ilk elden deneyime sahip olmadığım için herhangi bir sonuca varmaktan çekiniyorum. Bu tür performans sorunları genellikle ağa özeldir ve hatta bazen makineye özgüdür.
MacOS'u bir VPN ile kullanırken Open-MPI'nin daha sağlam olduğunu gördüm, yani MPICH, ana bilgisayar adı çözümleme sorunları nedeniyle başlangıçta askıda kalabilir. Bu bir hata olduğundan, bu sorun gelecekte ortadan kalkabilir.
İkili Taşınabilirlik
Hem MPICH hem de Open-MPI, çok çeşitli platformlarda derlenebilen açık kaynaklı yazılımlar olsa da, MPI kitaplıklarının ikili biçimde veya bunlarla bağlantılı programların taşınabilirliği genellikle önemlidir.
MPICH ve türevlerinin çoğu ABI uyumluluğunu ( web sitesi ) destekler, bu da kütüphaneye ikili arayüzün sabit olduğu ve bu nedenle birinin mpi.hbir uygulamadan derlenebileceği ve ardından bir başkasıyla çalışabileceği anlamına gelir. Bu, kitaplıkların birden çok sürümünde bile geçerlidir. Örneğin, Intel MPI'yi sık sık derliyorum ancak LD_PRELOADçalışma zamanında MPICH'nin bir geliştirme sürümünü derliyorum. ABI uyumluluğunun en büyük avantajlarından biri, ISV'lerin (Bağımsız Yazılım Satıcıları) MPICH ailesinin yalnızca bir üyesine karşı derlenen ikili dosyaları yayınlayabilmesidir.
ABI, ikili uyumluluğun tek türü değildir. Yukarıda açıklanan senaryolar, kullanıcıların her yerde MPI başlatıcısının (genellikle mpirunveya mpiexechesaplama düğümü arka plan programlarıyla birlikte) ve MPI kitaplığının aynı sürümünü kullandıklarını varsayar . Bu kaplar için zorunlu değildir.
Open-MPI, ABI uyumluluğunu vaat etmese de, konteynerleri ( dokümanlar , slaytlar ) desteklemek için büyük yatırım yaptı . Bu, MPI başlatıcısının, başlatıcı arka plan programlarının ve MPI Kitaplığının farklı sürümleri arasında uyumluluğun korunmasında büyük özen gerektirir, çünkü bir kullanıcı, kapsayıcı desteğindeki başlatıcı arka plan programlarından daha yeni bir MPI başlatıcısı sürümünü kullanarak işleri başlatabilir. Başlatıcı arabirim kararlılığına dikkat edilmeden, başlatıcının her bileşeninin sürümleri uyumlu olmadığı sürece kapsayıcı işleri başlatılmayacaktır. Bu aşılmaz bir problem değil:
Örneğin Docker dünyası tarafından kullanılan geçici çözüm, altyapıyı uygulama ile birlikte konteyner haline getirmektir. Diğer bir deyişle, MPI arka plan programını uygulamanın kendisiyle birlikte kapsayıcıya dahil edersiniz ve ardından tüm kapsayıcıların (mpiexec dahil) aynı sürümde olmasını gerektirirsiniz. Bu, artık sürümler arası altyapı işlemlerine sahip olmadığınız için sorunu önler.
Open-MPI ekibinden Ralph Castain'e konteyner sorunlarını bana açıkladığı için teşekkür ediyorum. Hemen önceki alıntı onun.
Platforma Özgü Karşılaştırma
Platform bazında değerlendirmem şöyle:
Mac OS: Hem Open-MPI hem de MPICH iyi çalışmalıdır. MPI-3 standardının en son özelliklerini elde etmek için, Homebrew'den temin edilebilen yeni bir Open-MPI sürümünü kullanmanız gerekir. Bir Mac dizüstü bilgisayarda çalışıyorsanız MPI performansını düşünmek için hiçbir neden yok.
Paylaşılan belleğe sahip Linux: Hem Open-MPI hem de MPICH iyi çalışmalıdır. Tüm MPI-3 veya MPI_THREAD_MULTIPLE'ı destekleyen bir yayın sürümü istiyorsanız, Open-MPI'yi kendiniz oluşturmadığınız sürece muhtemelen MPICH'ye ihtiyacınız vardır, çünkü örneğin Ubuntu 16.04 yalnızca APT üzerinden 1.10 eski sürümünü sağlar. İki uygulama arasında herhangi bir önemli performans farkından haberdar değilim. İşletim sistemi izin veriyorsa, her ikisi de tek kopya optimizasyonlarını destekler.
Mellanox InfiniBand ile Linux: Open-MPI veya MVAPICH2 kullanın. Tüm MPI-3'ü destekleyen bir yayın sürümü istiyorsanız veya MPI_THREAD_MULTIPLEmuhtemelen MVAPICH2'ye ihtiyacınız var. MVAPICH2'nin çok iyi performans gösterdiğini ancak InfiniBand'de OpenMPI ile doğrudan bir karşılaştırma yapmadığını görüyorum, çünkü performansın benim için en önemli olduğu özellikler (RMA, diğer adıyla tek taraflı) geçmişte Open-MPI'de kırılmıştı.
Intel Omni Path ile Linux (veya öncülü True Scale): Bu tür sistemlerde MVAPICH2, Intel MPI, MPICH ve Open-MPI kullanıyorum ve hepsi çalışıyor. Intel MPI en iyi optimize edilmiş olma eğilimindeyken, Open-MPI, iyi optimize edilmiş PSM2 tabanlı bir arka uca sahip oldukları için açık kaynak uygulamalarının en iyi performansını sağladı . GitHub'da farklı açık kaynak uygulamalarının nasıl oluşturulacağına dair bazı notlarım var , ancak bu tür bilgiler oldukça hızlı bir şekilde eskimektedir.
Cray veya IBM süper bilgisayarlar: MPI bu makinelere otomatik olarak kurulur ve her iki durumda da MPICH'ye dayanır. Cray XC40 üzerinde MPICH'nin ( burada ) OFI kullanılarak , Cray XC40 üzerinde Intel MPI ( burada ) kullanılarak, OFI kullanılarak Blue Gene / Q üzerinde MPICH ( burada ) ve hem OFI hem de uGNI kullanılarak Cray XC40 üzerinde Open-MPI kullanılarak gösterimleri yapılmıştır. ( burada ), ancak bunların hiçbiri satıcı tarafından desteklenmiyor.
Windows: Windows'ta MPI çalıştırmanın Linux VM dışında bir anlamı göremiyorum, ancak hem Microsoft MPI hem de Intel MPI Windows'u destekliyor ve MPICH tabanlıdır. Linux için Windows Alt Sistemini kullanan başarılı MPICH veya Open-MPI derlemeleri hakkında raporlar duydum , ancak kişisel deneyimim yok.
notlar
Tam açıklamayla, şu anda Intel için araştırma / yol bulma kapasitesinde çalışıyorum (yani herhangi bir Intel yazılım ürünü üzerinde çalışmıyorum) ve daha önce MPICH ekibiyle yoğun bir şekilde işbirliği yaptığım Argonne Ulusal Laboratuvarı için beş yıl çalıştım.