Quais recursos os usuários precisam de uma interface MPI C ++?

A versão 3.0 do padrão MPI excluiu formalmente a interface C ++ (ela foi descontinuada anteriormente). Embora as implementações ainda possam suportá-lo, os recursos novos no MPI-3 não possuem uma interface C ++ definida no padrão MPI. Consulte http://blogs.cisco.com/performance/the-mpi-c-bindings-what-happened-and-why/ para obter mais informações.

A motivação para remover a interface C ++ do MPI era não ter valor significativo sobre a interface C. Havia poucas diferenças além de "s / _ / :: / g" e muitos recursos aos quais os usuários do C ++ estão acostumados não foram empregados (por exemplo, determinação automática de tipo por meio de modelos).

Como alguém que participa do Fórum MPI e trabalha com vários projetos C ++ que implementaram sua própria interface C ++ para as funções MPI C, gostaria de saber quais são os recursos desejáveis ​​de uma interface C ++ para MPI. Embora eu não me comprometa com nada, eu estaria interessado em ver a implementação de uma interface MPI C ++ independente que atenda às necessidades de muitos usuários.

E sim, eu estou familiarizado com o Boost :: MPI ( http://www.boost.org/doc/libs/1_54_0/doc/html/mpi.html ), mas ele suporta apenas os recursos MPI-1 e o modelo de serialização seria extremamente difícil de suportar para RMA.

Uma interface C ++ para o MPI que eu gosto é a do Elemental ( https://github.com/poulson/Elemental/blob/master/src/core/imports/mpi.cpp ), para que talvez as pessoas possam fornecer alguns prós e contras de que aproximação. Em particular, acho que o MpiMap resolve um problema essencial.

Deixe-me primeiro responder por que eu acho que as interfaces C ++ para MPI geralmente não obtiveram muito sucesso, tendo pensado sobre o problema por um bom tempo ao tentar decidir se devemos apenas usar as ligações C padrão do MPI ou desenvolver algo de nível superior :

Quando você olha para os códigos MPI do mundo real (digamos, PETSc ou, no meu caso, II), percebe-se que, surpreendentemente, o número de chamadas MPI não é realmente muito grande. Por exemplo, nas 500 mil linhas de acordo.II, existem apenas ~ 100 chamadas MPI. Uma conseqüência disso é que a dor envolvida no uso de interfaces de nível inferior, como as ligações MPI C, não é muito grande. Por outro lado, não se ganha muito usando interfaces de nível superior.

Minha segunda observação é que muitos sistemas têm várias bibliotecas MPI instaladas (diferentes implementações MPI ou versões diferentes). Isso representa uma dificuldade significativa se você deseja usar, digamos, boost :: mpi, que não consiste apenas em arquivos de cabeçalho: também é necessário que haja várias instalações deste pacote ou é necessário compilá-lo como parte do projeto que usa boost :: mpi (mas isso é um problema em si mesmo novamente, dado que o boost usa seu próprio sistema de compilação, que é diferente de qualquer outro).

Então, acho que tudo isso conspirou contra a atual safra de interfaces C ++ para MPI: as antigas ligações MPI C ++ não ofereciam nenhuma vantagem e os pacotes externos tinham dificuldades com o mundo real.

Tudo isso dito, aqui está o que eu acho que seriam os recursos mais interessantes que eu gostaria de ter em uma interface de nível superior:

• Deve ser genérico. A necessidade de especificar o tipo de dados de uma variável não é decididamente semelhante ao C ++. Obviamente, isso também leva a erros. A classe MpiMap da Elemental já seria um bom primeiro passo (embora eu não consiga entender por que diabos a MpiMap::typevariável não é const estática, para que possa ser acessada sem a criação de um objeto).

• Deveria ter facilidades para transmitir tipos de dados arbitrários.

• Operações que requerem um MPI_Opargumento (por exemplo, reduções) devem se integrar perfeitamente à std::functioninterface do C ++ , para que seja fácil passar apenas um ponteiro de função (ou um lambda!) Ao invés de ter que registrar algo desajeitadamente.

O boost :: mpi realmente satisfaz tudo isso. Eu acho que se fosse uma biblioteca apenas de cabeçalho, seria muito mais popular na prática. Também ajudaria se suportasse funções pós-MPI 1.0, mas sejamos honestos: isso cobre a maior parte do que precisamos na maioria das vezes.

Para fazer a bola rolar, aqui estão duas das minhas necessidades:

• A interface deve ser capaz de eliminar argumentos redundantes ou desnecessários, por exemplo, MPI_IN_PLACE.
• A interface deve detectar automaticamente tipos de dados internos, como o MpiMap da Elemental.
• Se / sempre que possível, tipos de dados definidos pelo usuário devem ser construídos para classes.

Minha lista em nenhuma ordem particular de preferência. A interface deve:

• somente o cabeçalho, sem nenhuma dependência <mpi.h>, mas a biblioteca padrão,
• ser genérico e extensível,
• ser non-blocking única (se você deseja bloquear, em seguida, bloquear explicitamente, não por padrão),
• permitir encadeamento baseado em continuação de operações sem bloqueio,
• suporta serialização extensível e eficiente (como o Boost.Fusion, para que funcione com RMA),
• tem zero de penalidade de abstração (ou seja, pelo menos, tão rápido quanto a interface C),
• estar seguro (o destruidor de um futuro não pronto é chamado? -> std :: terminate!),
• tem um DEBUGmodo forte com toneladas de afirmações,
• extremamente seguro (não há mais ints / void * para tudo, diabos, eu quero que as tags sejam do tipo!),
• deve funcionar com lambdas (por exemplo, todos reduzem + lambda),
• use as exceções de forma consistente como mecanismo de relatório e tratamento de erros (sem mais códigos de erro! sem mais argumentos de saída de função!),
• O MPI-IO deve oferecer uma interface de E / S sem bloqueio no estilo Boost.AFIO,
• e siga as boas práticas modernas de design de interface C ++ (defina tipos regulares, funções que não são membros e não são amigos, jogam bem com a semântica de movimentos, suportam operações de intervalo, ...)

Extras:

• permita-me escolher o executor do ambiente MPI, ou seja, qual pool de threads ele usa. No momento, você pode ter aplicativos com uma mistura de OpenMP, MPI, CUDA e TBB ... tudo ao mesmo tempo, em que cada tempo de execução pensa que é o proprietário do ambiente e, portanto, solicita threads ao sistema operacional sempre que lhe apetecer. isto. A sério?

• use a convenção de nomenclatura STL (e Boost). Por quê? Todo programador de C ++ sabe disso.

Eu quero escrever código como este:

auto buffer = some_t{no_ranks};
auto future = gather(comm, root(comm), my_offsets, buffer)
              .then([&](){
                /* when the gather is finished, this lambda will 
                   execute at the root node, and perform an expensive operation
                   there asynchronously (compute data required for load 
                   redistribution) whose result is broadcasted to the rest 
                   of the communicator */
                return broadcast(comm, root(comm), buffer);
              }).then([&]() {
                /* when broadcast is finished, this lambda executes 
                   on all processes in the communicator, performing an expensive
                   operation asynchronously (redistribute the load, 
                   maybe using non-blocking point-to-point communication) */
                 return do_something_with(buffer);
              }).then([&](auto result) {
                 /* finally perform a reduction on the result to check
                    everything went fine */
                 return all_reduce(comm, root(comm), result, 
                                  [](auto acc, auto v) { return acc && v; }); 
              }).then([&](auto result) {
                  /* check the result at every process */
                  if (result) { return; /* we are done */ }
                  else {
                    root_only([](){ write_some_error_log(); });
                    throw some_exception;
                  }
              });

/* Here nothing has happened yet! */

/* ... lots and lots of unrelated code that can execute concurrently 
   and overlaps with communication ... */

/* When we now call future.get() we will block 
   on the whole chain (which might have finished by then!).
*/

future.get();

Pense em como alguém poderia encadear todas essas operações usando os MPI_C's request. Você precisaria testar em várias etapas intermediárias (ou em todas as etapas) de um monte de código não relacionado para ver se é possível avançar sua cadeia sem bloquear .

Pessoalmente, não me importo de chamar funções longas no estilo C pelo motivo exato que Wolfgang mencionou; realmente existem poucos lugares em que você precisa chamá-los e, mesmo assim, eles quase sempre ficam envolvidos por algum código de nível superior.

As únicas coisas que realmente me incomodam com o MPI no estilo C são os tipos de dados personalizados e, em menor grau, as operações personalizadas (porque eu as uso com menos frequência). Quanto aos tipos de dados personalizados, eu diria que uma boa interface C ++ deve oferecer suporte à maneira genérica e eficiente de lidar com isso, provavelmente por meio de serialização. É claro que esse é o caminho que boost.mpi, se você for cuidadoso , economiza muito tempo.

Quanto a boost.mpiter dependências extras (principalmente as boost.serializationque não são apenas de cabeçalho), recentemente deparei com uma biblioteca de serialização C ++ de cabeçalho chamada cereal, que parece promissora; concedido, requer um compilador compatível com C ++ 11. Pode valer a pena examiná-lo e usá-lo como base para algo semelhante a boost.mpi.

O projeto github easyLambda fornece uma interface de alto nível para MPI com C ++ 14.

Eu acho que o projeto tem objetivos semelhantes e dará uma idéia das coisas que podem ser e estão sendo feitas nessa área usando o C ++ moderno. Orientando outros esforços, além da própria easyLambda.

Os benchmarks iniciais de desempenho e linhas de código mostraram resultados promissores.

A seguir, é apresentada uma breve descrição dos recursos e da interface que ele fornece.

A interface é baseada na programação do fluxo de dados e nas operações da lista funcional que fornecem paralelismo inerente. O paralelismo é expresso como propriedade de uma tarefa. A alocação do processo e a distribuição de dados para a tarefa podem ser solicitadas com uma propriedade .prll (). Há um bom número de exemplos na página da Web e no repositório de códigos que incluem o pós-processamento da dinâmica molecular LAMMPS, solução explícita de diferença finita para equação do calor, regressão logística etc. Como exemplo, o problema de difusão de calor discutido no artigo HPC está morrendo ... pode ser expresso em ~ 20 linhas de código.

Espero que seja bom fornecer links em vez de adicionar mais detalhes e códigos de exemplo aqui.

Disclamer: Eu sou o autor da biblioteca. Acredito que não estou prejudicando a esperança de obter um feedback construtivo sobre a interface atual do easyLambda que possa ser vantajosa para o easyLambda e qualquer outro projeto que busque objetivos semelhantes.