Objetivo
Primeiro, é importante reconhecer como o MPICH e o Open-MPI são diferentes, ou seja, eles são projetados para atender a diferentes necessidades. Supõe-se que o MPICH seja uma implementação de referência de alta qualidade do último padrão MPI e a base para implementações de derivativos para atender a necessidades de propósitos especiais. O MPI aberto visa o caso comum, tanto em termos de uso quanto de conduítes de rede.
Suporte para tecnologia de rede
O MPI aberto documenta seu suporte de rede aqui . MPICH lista esta informação no README distribuído com cada versão (por exemplo, esta é para 3.2.1). Observe que, porque o Open-MPI e o MPICH suportam o OFI(aka libfabric), eles suportam muitas das mesmas redes. No entanto, libfabric é uma API multifacetada, portanto, nem toda rede pode ser suportada da mesma forma em ambas (por exemplo, o MPICH possui uma implementação IBM Blue Gene / Q baseada em OFI, mas não tenho conhecimento do suporte equivalente no Open-MPI) . No entanto, as implementações baseadas em OFI do MPICH e do Open-MPI estão trabalhando em memória compartilhada, Ethernet (via TCP / IP), Mellanox InfiniBand, Intel Omni Path e provavelmente em outras redes. O MPI aberto também suporta essas redes e outras de forma nativa (ou seja, sem OFI no meio).
No passado, uma reclamação comum sobre o MPICH é que ele não suporta o InfiniBand, enquanto o Open-MPI sim. No entanto, MVAPICH e Intel MPI (entre outros) - ambos derivados da MPICH - suportam o InfiniBand; portanto, se alguém quiser definir o MPICH como "MPICH e seus derivados", o MPICH terá um suporte de rede extremamente amplo, incluindo o InfiniBand e o proprietário. interconexões como Cray Seastar, Gemini e Aries, bem como IBM Blue Gene (/ L, / P e / Q). O MPI aberto também suporta a interconexão do Cray Gemini, mas seu uso não é suportado pelo Cray. Mais recentemente, o MPICH deu suporte ao InfiniBand por meio de um netmod (agora obsoleto), mas o MVAPICH2 possui otimizações extensas que o tornam a implementação preferida em quase todos os casos.
Suporte a recursos do mais recente padrão MPI
Um eixo ortogonal ao suporte de hardware / plataforma é a cobertura do padrão MPI. Aqui o MPICH geralmente é superior e distante. O MPICH foi a primeira implementação de cada versão do padrão MPI, do MPI-1 ao MPI-3. O Open-MPI oferece suporte apenas ao MPI-3 recentemente e eu acho que alguns recursos do MPI-3 são defeituosos em algumas plataformas (o MPICH não é livre de erros, é claro, mas os erros nos recursos do MPI-3 têm sido muito menos comuns).
Historicamente, o Open-MPI não teve suporte holístico MPI_THREAD_MULTIPLE, o que é crítico para alguns aplicativos. Pode ser suportado em algumas plataformas, mas geralmente não se pode supor que funcione. Por outro lado, o MPICH possui suporte holístico MPI_THREAD_MULTIPLEhá muitos anos, embora a implementação nem sempre seja de alto desempenho (consulte "Bloqueando aspectos em implementações MPI multithread" para uma análise).
Outro recurso que foi quebrado no Open-MPI 1.x foi a comunicação unilateral, também conhecida como RMA. Isso foi corrigido mais recentemente e eu acho, como um usuário muito pesado desses recursos, que eles geralmente funcionam bem no Open-MPI 3.x (veja, por exemplo, a matriz de teste ARMCI-MPI no Travis CI para obter resultados mostrando RMA trabalhando com ambas as implementações, pelo menos na memória compartilhada.Eu vi resultados positivos semelhantes no Intel Omni Path, mas não testei o Mellanox InfiniBand.
Gerenciamento de processos
Uma área em que o Open-MPI costumava ser significativamente superior foi o gerente de processos. O antigo lançamento do MPICH (MPD) era frágil e difícil de usar. Felizmente, ele foi suspenso por muitos anos (consulte a entrada de MPICH FAQ para obter detalhes). Assim, as críticas ao MPICH por causa do MPD são espúrias.
O gerenciador de processos Hydra é muito bom e possui a usabilidade e os recursos semelhantes definidos como ORTE (em Open-MPI), por exemplo, ambos oferecem suporte ao HWLOC para controle sobre a topologia do processo. Há relatos de que o processo MPI aberto é mais rápido que os derivados MPICH para trabalhos maiores (mais de 1000 processos), mas como não tenho experiência em primeira mão aqui, não me sinto à vontade para tirar conclusões. Esses problemas de desempenho geralmente são específicos da rede e, às vezes, específicos da máquina.
Eu descobri que o Open-MPI é mais robusto ao usar o MacOS com uma VPN, ou seja, o MPICH pode travar na inicialização devido a problemas de resolução de nome de host. Como esse é um erro, esse problema pode desaparecer no futuro.
Portabilidade binária
Embora o MPICH e o Open-MPI sejam softwares de código aberto que podem ser compilados em uma ampla variedade de plataformas, a portabilidade das bibliotecas MPI em formato binário ou programas vinculados a elas é frequentemente importante.
O MPICH e muitos de seus derivados suportam a compatibilidade ABI ( site ), o que significa que a interface binária da biblioteca é constante e, portanto, é possível compilar com mpi.huma implementação e depois executar com outra. Isso é verdade mesmo em várias versões das bibliotecas. Por exemplo, eu frequentemente compilo o Intel MPI, mas LD_PRELOADuma versão de desenvolvimento do MPICH em tempo de execução. Uma das grandes vantagens da compatibilidade com a ABI é que os ISVs (Independent Software Vendors) podem liberar binários compilados contra apenas um membro da família MPICH.
ABI não é o único tipo de compatibilidade binária. Os cenários descritos acima assumem que os usuários empregam a mesma versão do iniciador MPI (geralmente mpirunou mpiexec, juntamente com seus daemons de nós de computação) e a biblioteca MPI em todos os lugares. Este não é necessariamente o caso de contêineres.
Embora o Open-MPI não prometa compatibilidade com ABI, eles investiram pesadamente no suporte a contêineres ( documentos , slides ). Isso requer muito cuidado em manter a compatibilidade entre diferentes versões do iniciador MPI, daemons do iniciador e Biblioteca MPI, porque um usuário pode iniciar tarefas usando uma versão mais recente do iniciador MPI que os daemons do iniciador no suporte ao contêiner. Sem uma atenção cuidadosa à estabilidade da interface do iniciador, os trabalhos de contêiner não serão iniciados, a menos que as versões de cada componente do iniciador sejam compatíveis. Este não é um problema intransponível:
A solução alternativa usada pelo mundo do Docker, por exemplo, é containerizar a infraestrutura junto com o aplicativo. Em outras palavras, você inclui o daemon MPI no contêiner com o próprio aplicativo e exige que todos os contêineres (incluindo mpiexec) sejam da mesma versão. Isso evita o problema, pois você não tem mais operações de infraestrutura entre versões.
Agradeço a Ralph Castain, da equipe Open-MPI, por me explicar os problemas de contêineres. A citação imediatamente anterior é dele.
Comparação específica de plataforma
Aqui está a minha avaliação plataforma por plataforma:
Mac OS: o Open-MPI e o MPICH devem funcionar perfeitamente. Para obter os recursos mais recentes do padrão MPI-3, você precisa usar uma versão recente do Open-MPI, disponível na Homebrew. Não há razão para pensar no desempenho do MPI se você estiver executando em um laptop Mac.
Linux com memória compartilhada: o Open-MPI e o MPICH devem funcionar perfeitamente. Se você deseja uma versão de lançamento que suporte todos os MPI-3 ou MPI_THREAD_MULTIPLE, provavelmente precisará do MPICH, a menos que você mesmo construa o Open-MPI, porque, por exemplo, o Ubuntu 16.04 fornece apenas a versão antiga 1.10 via APT. Não estou ciente de nenhuma diferença significativa de desempenho entre as duas implementações. Ambos suportam otimizações de cópia única, se o sistema operacional permitir.
Linux com Mellanox InfiniBand: use Open-MPI ou MVAPICH2. Se você deseja uma versão de lançamento compatível com todo o MPI-3 ou MPI_THREAD_MULTIPLE, provavelmente precisará do MVAPICH2. Acho que o MVAPICH2 tem um desempenho muito bom, mas não fez uma comparação direta com o OpenMPI no InfiniBand, em parte porque os recursos para os quais o desempenho é mais importante para mim (RMA, unilateral) foram quebrados no Open-MPI no passado.
Linux com Intel Omni Path (ou seu antecessor, True Scale): Eu uso MVAPICH2, Intel MPI, MPICH e Open-MPI em tais sistemas, e todos estão funcionando. O Intel MPI tende a ser o mais otimizado, enquanto o Open-MPI oferece o melhor desempenho das implementações de código aberto, porque eles têm um back-end baseado em PSM2 bem otimizado . Eu tenho algumas notas no GitHub sobre como criar diferentes implementações de código aberto, mas essas informações ficam obsoletas rapidamente.
Supercomputadores Cray ou IBM: o MPI é instalado nessas máquinas automaticamente e é baseado no MPICH nos dois casos. Houve demonstrações de MPICH no Cray XC40 ( aqui ) usando OFI , Intel MPI no Cray XC40 ( aqui ) usando OFI, MPICH no Blue Gene / Q usando OFI ( aqui ) e MPI aberto no Cray XC40 usando OFI e uGNI ( aqui ), mas nenhum deles é suportado pelo fornecedor.
Windows: Não vejo sentido em executar o MPI no Windows, exceto por meio de uma VM Linux, mas o Microsoft MPI e o Intel MPI suportam o Windows e são baseados no MPICH. Ouvi relatos de compilações bem-sucedidas de MPICH ou Open-MPI usando o Windows Subsystem para Linux, mas não tenho experiência pessoal.
Notas
Na divulgação completa, atualmente trabalho para a Intel em uma capacidade de pesquisa / busca de caminhos (ou seja, não trabalho em nenhum produto de software da Intel) e anteriormente trabalhei no Argonne National Lab por cinco anos, onde colaborei extensivamente com a equipe do MPICH.