Gestione delle connessioni

Una delle caratteristiche interessanti di MPI è che le sue applicazioni non devono preoccuparsi di gestione delle connessioni. Non c'è concetto di "aprire una connessione a pari X" - in MPI, è sufficiente inviare o ricevere da pari X.

Questo è in qualche modo simile a molti trasporti di rete senza connessione (ad esempio, UDP) dove basta inviare a un indirizzo di destinazione, senza esplicitamente la creazione di una connessione a tale indirizzo. Ma è diverso in modo fondamentale da molti mezzi di trasporto senza connessione (ad esempio, UDP): trasporto MPI è affidabile , nel senso che qualsiasi cosa si inviano è garantita per arrivarci.

Tutta questa magia accade sotto le coperte delle API MPI. Ciò significa che in alcuni ambienti, MPI deve gestire le connessioni per voi, e deve anche garantire la consegna affidabile.

A metà degli anni '90, basata su Ethernet implementazioni MPI genere aperto socket TCP tra tutti i peer durante MPI_INIT. Per il 32 - lavori o 64-processo che erano la norma allora, che andava bene.

Come utilizzo è scalata, però, "tipici" lavori MPI sono diventati più grandi. Lavori che si estendono centinaia di processi MPI sono comuni, rendendo così il "aperto tutti i collegamenti possibili durante MPI_INIT" strategie irrealizzabile.

Pensare in questo modo: "tutti i collegamenti possibili" si trasforma in un (N ^ 2) il funzionamento O con le risorse corrispondenti. Si consideri un lavoro di 512-processo (con 32-core server commodity, questo è solo 16 macchine - che non è irrealistico per i lavori di comune oggi). Se ogni processo MPI aperto un socket TCP a ciascuno dei suoi coetanei, che sarebbero 511 ^ 2 = 261121 socket.

Non solo questo crea una "tempesta di collegamento" in rete, sarebbe anche consumare 511 descrittori di file in ogni processo , o 16.352 descrittori di file su ogni server .

Yowza! :-(

È per questo che la maggior parte (se non tutti) implementazioni MPI moderna utilizzando la connessione basata trasporti di rete utilizzano un "pigro connessione" schema di gestione. In particolare: la prima volta un processo MPI invia a un peer, viene aperta una connessione tra di loro.

Questo richiede purtroppo un po 'di codice e logica al lavoro, perché il processo pari MPI non può avere un agente di ascolto pronto ad accettare la connessione. Tipicamente, il processo di invio avvia una sorta di non-blocking inizio connessione, e poi periodicamente sondaggi per il completamento dopo. Il mittente può anche avere bisogno di ri-avviare la richiesta di connessione se non il destinatario risponde, e la domanda iniziale scaduta.

Gli studi hanno dimostrato nel corso degli anni rispetto a molti applicazioni tipiche MPI solo "nearest neighbour" comunicazione basata, nel senso che ogni processo MPI davvero comunica solo con un piccolo numero di suoi pari. Quindi, anche in un 512-processo di lavoro, un processo tipico di tale lavoro può utilizzare solo MPI per comunicare con i 5 o 6 dei suoi coetanei.

Questa osservazione, in coppia con un sistema di connessione pigro, riduce drasticamente il network-based consumo di risorse.

Corso Cisco - Corsi Cisco - Corso CCNA

 Corso Security - CCNA Security - Certificazione Cisco