Di quali funzionalità hanno bisogno gli utenti da un'interfaccia MPI C ++?

La versione 3.0 dello standard MPI ha eliminato formalmente l'interfaccia C ++ (era precedentemente deprecata). Sebbene le implementazioni possano ancora supportarlo, le funzionalità nuove in MPI-3 non hanno un'interfaccia C ++ definita nello standard MPI. Vedere http://blogs.cisco.com/performance/the-mpi-c-bindings-what-happened-and-why/ per ulteriori informazioni.

La motivazione per rimuovere l'interfaccia C ++ da MPI era che non aveva un valore significativo sull'interfaccia C. Vi erano pochissime differenze oltre a "s / _ / :: / g" e molte funzionalità alle quali gli utenti di C ++ sono abituati non sono state utilizzate (ad esempio, determinazione automatica del tipo tramite modelli).

Come qualcuno che partecipa al forum MPI e lavora con una serie di progetti C ++ che hanno implementato la propria interfaccia C ++ per le funzioni MPI C, vorrei sapere quali sono le caratteristiche desiderabili di un'interfaccia C ++ per MPI. Anche se non mi impegno per nulla, sarei interessato a vedere l'implementazione di un'interfaccia MPI C ++ autonoma che soddisfi le esigenze di molti utenti.

E sì, ho familiarità con Boost :: MPI ( http://www.boost.org/doc/libs/1_54_0/doc/html/mpi.html ) ma supporta solo le funzionalità MPI-1 e il modello di serializzazione sarebbe estremamente difficile da supportare per RMA.

Un'interfaccia C ++ per MPI che mi piace è quella di Elemental ( https://github.com/poulson/Elemental/blob/master/src/core/imports/mpi.cpp ), quindi forse le persone possono fornire qualche pro e contro che approccio. In particolare, penso che MpiMap risolva un problema essenziale.

Consentitemi innanzitutto di rispondere al motivo per cui penso che le interfacce C ++ per MPI non abbiano generalmente avuto un esagerato successo, avendo riflettuto sul problema per molto tempo quando ho cercato di decidere se dovremmo semplicemente usare i binding C standard di MPI o basarci su qualcosa di livello superiore :

Quando guardi i codici MPI del mondo reale (diciamo, PETSc o nel mio caso.II), si scopre che forse sorprendentemente, il numero di chiamate MPI non è in realtà molto grande. Ad esempio, nelle 500k linee di offerta.II, ci sono solo ~ 100 chiamate MPI. Una conseguenza di ciò è che il dolore coinvolto nell'uso di interfacce di livello inferiore come i collegamenti MPI C, non è troppo grande. Viceversa, non si otterrebbero così tanti vantaggi utilizzando interfacce di livello superiore.

La mia seconda osservazione è che su molti sistemi sono installate più librerie MPI (diverse implementazioni MPI o versioni diverse). Ciò rappresenta una difficoltà significativa se si desidera utilizzare, ad esempio, boost :: mpi che non consiste solo di file di intestazione: o devono essere presenti anche più installazioni di questo pacchetto, oppure è necessario costruirlo come parte del progetto che utilizza boost :: mpi (ma questo è di nuovo un problema in sé, dato che boost usa il proprio sistema di build, che è diverso da qualsiasi altra cosa).

Quindi penso che tutto questo abbia cospirato contro l'attuale crop di interfacce C ++ per MPI: i vecchi binding MPI C ++ non offrivano alcun vantaggio e pacchetti esterni avevano difficoltà con il mondo reale.

Detto questo, ecco cosa penso siano le caratteristiche killer che vorrei avere da un'interfaccia di livello superiore:

• Dovrebbe essere generico. Dover specificare il tipo di dati di una variabile non è decisamente C ++. Naturalmente, porta anche a errori. La classe MpiMap di Elemental sarebbe già un bel primo passo (anche se non riesco a capire perché diavolo la MpiMap::typevariabile non sia const statica, quindi è possibile accedervi senza creare un oggetto).

• Dovrebbe disporre di strutture per lo streaming di tipi di dati arbitrari.

• Le operazioni che richiedono un MPI_Opargomento (ad es. Riduzioni) dovrebbero integrarsi perfettamente con l' std::functioninterfaccia di C ++ , in modo che sia facile semplicemente passare un puntatore a funzione (o un lambda!) Piuttosto che dover goffamente registrare qualcosa.

boost :: mpi in realtà soddisfa tutti questi. Penso che se fosse una libreria di sola intestazione, sarebbe molto più popolare in pratica. Sarebbe anche utile se supportasse le funzioni post-MPI 1.0, ma siamo onesti: questo copre la maggior parte di ciò di cui abbiamo bisogno la maggior parte del tempo.

Per far rotolare la palla, ecco due dei miei bisogni:

• L'interfaccia dovrebbe essere in grado di eliminare argomenti ridondanti o superflui, ad esempio MPI_IN_PLACE.
• L'interfaccia dovrebbe rilevare automaticamente i tipi di dati incorporati su MpiMap di Elemental.
• Se / quando possibile, i tipi di dati definiti dall'utente dovrebbero essere costruiti per le classi.

La mia lista in nessun ordine di preferenza particolare. L'interfaccia dovrebbe:

• essere solo intestazione, senza dipendenze ma <mpi.h>, e la libreria standard,
• essere generico ed estensibile,
• essere non-blocking solo (se si desidera bloccare, quindi bloccare in modo esplicito, non per impostazione predefinita),
• consentire il concatenamento basato su continuazione di operazioni non bloccanti,
• supportare la serializzazione estensibile ed efficiente (tipo Boost.Fusion, in modo che funzioni con RMA),
• avere penalità di astrazione pari a zero (ovvero essere veloce almeno quanto l'interfaccia C),
• essere al sicuro (si chiama il distruttore di un futuro non pronto? -> std :: terminate!),
• avere una DEBUGmodalità forte con tonnellate di affermazioni,
• estremamente sicuro (non più ints / void * per tutto, diamine voglio che i tag siano tipi!),
• dovrebbe funzionare con lambdas (ad es. tutti riducono + lambda),
• utilizzare le eccezioni costantemente come meccanismo di segnalazione e gestione degli errori (niente più codici di errore! niente più argomenti di output delle funzioni!),
• MPI-IO dovrebbe offrire un'interfaccia I / O non bloccante nello stile di Boost.AFIO,
• e basta seguire le buone pratiche moderne di progettazione dell'interfaccia C ++ (definire tipi regolari, funzioni non amiche per i non membri, giocare bene con la semantica dei movimenti, operazioni con la gamma di supporto, ...)

extra:

• mi permetta di scegliere l'esecutore dell'ambiente MPI, ovvero quale pool di thread utilizza. In questo momento puoi avere applicazioni con un mix di OpenMP, MPI, CUDA e TBB ... tutto allo stesso tempo, dove ogni runtime pensa di possedere l'ambiente e quindi chiedere al sistema operativo i thread ogni volta che si sentono come esso. Sul serio?

• usa la convenzione di denominazione STL (e Boost). Perché? Tutti i programmatori C ++ lo sanno.

Voglio scrivere codice in questo modo:

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();

Pensa come si potrebbero concatenare tutte queste operazioni usando MPI_C request. Dovresti testare a più (o ogni singolo) passaggio intermedio attraverso un sacco di codice non correlato per vedere se puoi far avanzare la catena senza bloccare .

Personalmente, non mi dispiace davvero chiamare lunghe funzioni in stile C per la ragione esatta menzionata da Wolfgang; ci sono davvero pochi posti in cui è necessario chiamarli e anche in questo caso, vengono quasi sempre racchiusi in un codice di livello superiore.

Le uniche cose che mi infastidiscono davvero con l'MPI di tipo C sono i tipi di dati personalizzati e, in misura minore, le operazioni personalizzate (perché le utilizzo meno spesso). Per quanto riguarda i tipi di dati personalizzati, direi che una buona interfaccia C ++ dovrebbe essere in grado di supportare un modo generico ed efficiente di gestirlo, molto probabilmente attraverso la serializzazione. Questo è ovviamente il percorso che boost.mpiha preso, che se stai attento , fa risparmiare molto tempo.

Per quanto riguarda boost.mpile dipendenze extra (in particolare boost.serializationche di per sé non è solo intestazione), di recente mi sono imbattuto in una libreria di serializzazione C ++ solo intestazione chiamata cereale che sembra promettente; a condizione che richieda un compilatore conforme a C ++ 11. Potrebbe valere la pena esaminarlo e usarlo come base per qualcosa di simile a boost.mpi.

Il progetto github easyLambda fornisce un'interfaccia di alto livello a MPI con C ++ 14.

Penso che il progetto abbia obiettivi simili e darà un'idea delle cose che possono essere e che si stanno facendo in quest'area usando il C ++ moderno. Guida di altri sforzi e di easyLambda stesso.

I benchmark iniziali su prestazioni e linee di codice hanno mostrato risultati promettenti.

Di seguito è una breve descrizione delle funzionalità e dell'interfaccia che fornisce.

L'interfaccia si basa sulla programmazione del flusso di dati e sulle operazioni dell'elenco funzionale che forniscono parallelismo intrinseco. Il parallelismo è espresso come proprietà di un compito. L'allocazione del processo e la distribuzione dei dati per l'attività possono essere richieste con una proprietà .prll (). Ci sono un buon numero di esempi nella pagina web e nel repository di codici che includono la post-elaborazione della dinamica molecolare LAMMPS, la soluzione di differenza finita esplicita all'equazione del calore, la regressione logistica ecc. Ad esempio, il problema della diffusione del calore discusso nell'articolo HPC sta morendo ... può essere espresso in ~ 20 righe di codice.

Spero che vada bene fornire collegamenti piuttosto che aggiungere maggiori dettagli e codici di esempio qui.

Disclamer: sono l'autore della biblioteca. Credo di non fare alcun male nella speranza di ottenere un feedback costruttivo sull'interfaccia attuale di easyLambda che potrebbe essere vantaggioso per easyLambda e qualsiasi altro progetto che persegue obiettivi simili.