MPI o socket?

Question

Sto lavorando su un cluster liberamente accoppiato per l'elaborazione di alcuni dati. Il codice di rete e il codice di elaborazione sono in atto, ma stiamo valutando diverse metodologie nel nostro approccio. In questo momento, come dovremmo essere, siamo legati all'I / O per problemi di prestazioni e stiamo cercando di ridurre il collo di bottiglia. Ovviamente, gli switch più veloci come Infiniband sarebbero fantastici, ma non possiamo permetterci il lusso di buttare via quello che abbiamo e ottenere nuove attrezzature.

La mia domanda posta è questa. Tutte le applicazioni HPC tradizionali e serie eseguite su cluster sono in genere implementate con il passaggio di messaggi rispetto all'invio diretto tramite socket. Quali sono i vantaggi prestazionali di questo? Dovremmo vedere uno speedup se siamo passati dalle prese?

Answer 1

MPI POTREBBE utilizzare le prese. Ma ci sono anche implementazioni MPI da usare con SAN (System area network) che usano la memoria condivisa distribuita diretta. Questo ovviamente se hai l'hardware per quello. Quindi MPI ti consente di utilizzare tali risorse in futuro. In questo caso puoi ottenere enormi miglioramenti delle prestazioni (sulla mia esperienza con i cluster all'università, puoi ottenere guadagni di alcuni ordini di grandezza). Quindi, se stai scrivendo codice che può essere portato su cluster di fascia alta, usare MPI è un'ottima idea.

Anche scartando i problemi di prestazioni, l'uso di MPI può farti risparmiare un sacco di tempo, che puoi usare per migliorare le prestazioni di altre parti del tuo sistema o semplicemente salvare la tua sanità mentale.

Answer 2

Consiglierei di usare MPI invece di farne uno tuo, a meno che tu non sia molto bravo in quel genere di cose. Dopo aver scritto alcune applicazioni distribuite basate su computer utilizzando i miei protocolli, mi ritrovo sempre a riprodurre (e riprodurre male) le funzionalità che si trovano all'interno di MPI.

Per quanto riguarda le prestazioni, non mi aspetterei che MPI ti desse tangibili accelerazioni di rete: utilizza socket come te. MPI ti fornirà tuttavia molte funzionalità necessarie per la gestione di molti nodi, ovvero la sincronizzazione tra nodi.

Answer 3

Le prestazioni non sono l'unica considerazione in questo caso, anche su cluster ad alte prestazioni. MPI offre un'API standard ed è "portatile". È relativamente banale cambiare un'applicazione tra le diverse versioni di MPI.

La maggior parte delle implementazioni MPI utilizza socket per comunicazioni basate su TCP. Le probabilità sono buone che qualsiasi data implementazione MPI sarà ottimizzata meglio e fornirà un passaggio più rapido dei messaggi rispetto a un'applicazione domestica che utilizza direttamente i socket.

Inoltre, se dovessi mai avere la possibilità di eseguire il tuo codice su un cluster che ha InfiniBand, il livello MPI renderà astratta qualsiasi di queste modifiche al codice. Questo non è un vantaggio banale: codificare un'applicazione per utilizzare direttamente l'implementazione OFED (o un altro verbo IB) è molto difficile.

La maggior parte delle applicazioni MPI include piccole app di prova che possono essere utilizzate per verificare la correttezza della configurazione di rete indipendentemente dall'applicazione. Questo è un grande vantaggio quando arriva il momento di eseguire il debug dell'applicazione. Lo standard MPI include il "pMPI" interfacce, per la profilazione di chiamate MPI. Questa interfaccia consente inoltre di aggiungere facilmente checksum o altre verifiche dei dati a tutte le routine di passaggio dei messaggi.

Answer 4

MPI ha il vantaggio di poter fare comunicazioni collettive. Fare trasmissioni / riduzioni in O (log p) / * p è il tuo numero di processori * / invece di O (p) è un grande vantaggio.

Answer 5

Dovrò essere d'accordo con OldMan e freespace. A meno che non si conosca uno specifico e un miglioramento di alcune metriche utili (prestazioni, manutenibilità, ecc.) Rispetto a MPI, perché reinventare la ruota. MPI rappresenta una grande quantità di conoscenza condivisa per quanto riguarda il problema che stai cercando di risolvere.

Esistono moltissimi problemi da risolvere che vanno oltre l'invio di dati. La configurazione e la manutenzione della connessione diventeranno tutte responsabilità dell'utente. Se MPI è l'astrazione esatta (sembra che sia) che ti serve, usala.

Per lo meno, l'utilizzo di MPI e successivamente il refactoring con il proprio sistema è un buon approccio che costa l'installazione e la dipendenza di MPI.

Mi piace soprattutto il punto di OldMan che MPI ti dà molto di più oltre la semplice comunicazione socket. Ottieni una serie di implementazioni di elaborazione parallele e distribuite con un'astrazione trasparente.

Answer 6

Il Message Passing è un paradigma non una tecnologia. Nell'installazione più generale, MPI utilizzerà i socket per comunicare. Potresti vedere una velocità passando a MPI, ma solo nella misura in cui non hai ottimizzato la comunicazione del socket.

Come viene associato l'I / O dell'applicazione? È vincolato al trasferimento dei blocchi di dati ai nodi di lavoro o è vincolato a causa della comunicazione durante il calcolo?

Se la risposta è " a causa della comunicazione " quindi il problema è che si sta scrivendo un'applicazione strettamente accoppiata e si tenta di eseguirla su un cluster progettato per attività non vincolanti. L'unico modo per ottenere prestazioni sarà ottenere un hardware migliore (switch più veloci, infiniband, ecc.) ... forse potresti prendere tempo sull'HPC di qualcun altro?

Se la risposta è "blocco dati" i trasferimenti quindi prendere in considerazione l'assegnazione di più blocchi di dati ai lavoratori (in modo che rimangano occupati più a lungo) & amp; comprimere i blocchi di dati prima del trasferimento. Questa è una strategia che può aiutare in un'applicazione debolmente accoppiata.

Answer 7

Non ho usato MPI, ma ho usato un po 'i socket. Ci sono alcune cose da considerare su prese ad alte prestazioni. Stai facendo molti pacchetti piccoli o pacchetti grandi? Se stai facendo molti piccoli pacchetti considera di disattivare l'algoritmo Nagle per una risposta più veloce:

setsockopt (m_socket, IPPROTO_TCP, TCP_NODELAY, ...);

Inoltre, l'uso dei segnali può effettivamente essere molto più lento quando si cerca di ottenere un volume elevato di dati. Molto tempo fa ho fatto un programma di test in cui il lettore avrebbe aspettato un segnale e letto un pacchetto - avrebbe avuto un attacco di circa 100 pacchetti / sec. Poi ho appena bloccato le letture e ho ottenuto 10000 letture / sec.

Il punto è esaminare tutte queste opzioni e in realtà provarle. Condizioni diverse renderanno le tecniche diverse più veloci / più lente. È importante non solo ottenere opinioni, ma metterle alla prova. Steve Maguire ne parla in "Scrivere codice solido". Usa molti esempi controintuitivi e li verifica per scoprire cosa rende il codice migliore / più veloce.

Answer 8

MPI utilizza i socket sottostanti, quindi l'unica differenza dovrebbe essere l'API con cui il tuo codice si interfaccia. È possibile ottimizzare il protocollo se si utilizzano direttamente socket, ma questo è tutto. Che cosa stai facendo esattamente con i dati?

Answer 9

MPI utilizza i socket e se sai cosa stai facendo puoi probabilmente ottenere più larghezza di banda dai socket perché non è necessario inviare più metadati.

Ma devi sapere cosa stai facendo ed è probabile che sia più soggetto a errori. essenzialmente sostituiresti mpi con il tuo protocollo di messaggistica.

Answer 10

Per la messaggistica business a volume elevato e overhead bassa che potresti voler controllare OAMQ con diversi prodotti. La variante open source OpenAMQ presumibilmente gestisce il trading su JP Morgan, quindi dovrebbe essere affidabile, non è vero?