Calcolo distribuito vs thread

Question

Quanto è simile il calcolo distribuito e il threading? Ho trovato due documenti che vengono a conclusioni del tutto opposte:

"Multi-Threading è più facile che Reti Come threading è facile e simile al Codice di Rete."

http://software.intel.com/file/14723

(questo mi dà un'impressione che sono così simili che dopo l'incapsulamento questi due approcci potrebbe essere fatto con lo stesso codice - ma forse mi sbaglio)

"Una nota sul calcolo distribuito"

http://research.sun.com/techrep/1994/abstract-29.html

(e questo pone una forte distinzione)

Sono sicuro che la verità sta nel mezzo. Qual è la media d'oro? Esistono tecnologie che unificano questi due paradigmi? O sono falliti tali tentativi a causa di differenze fondamentali tra networking e concorrenza?

Answer 1

Non li ho mai trovati molto simili. Permettetemi di definire per gli scopi di questo post un "nodo" per essere un thread hardware in esecuzione su una macchina. Quindi una macchina quad-core è composta da quattro nodi, così come un cluster di quattro box a processore singolo.

Ogni nodo eseguirà in genere alcune elaborazioni e sarà necessario un tipo di comunicazione tra nodi. Di solito la prima istanza di questa comunicazione sta dicendo al nodo cosa fare. Per questa comunicazione, posso usare memoria condivisa, semafori, file condivisi, named pipe, socket, chiamate di procedure remote, COM distribuite, ecc. Ma i più facili da usare, memoria condivisa e semafori, non sono generalmente disponibili su una rete. I file condivisi potrebbero essere disponibili, ma le prestazioni sono in genere scadenti. Le prese tendono ad essere la scelta più comune e più flessibile su una rete, piuttosto che i meccanismi più sofisticati. A quel punto devi gestire i dettagli dell'architettura di rete, tra cui latenza, larghezza di banda, perdita di pacchetti, topologia di rete e altro ancora.

Se si inizia con una coda di lavoro, i nodi sulla stessa macchina possono utilizzare la semplice memoria condivisa per fare le cose. Puoi persino scriverlo senza chiave e funzionerà perfettamente. Con i nodi su una rete, dove metti la coda? Se lo centralizzi, quella macchina potrebbe avere costi di larghezza di banda molto elevati. Prova a distribuirlo e le cose si complicano molto rapidamente.

Quello che ho trovato, in generale, è che le persone che affrontano questo tipo di architettura parallela tendono a scegliere imbarazzanti problemi paralleli da risolvere. Raytracing mi viene in mente. Non c'è bisogno di molte comunicazioni tra nodi, a parte la distribuzione del lavoro. Ci sono molti problemi come questo, per essere sicuri, ma trovo un po 'falso suggerire che il calcolo distribuito è essenzialmente lo stesso del threading.

Ora se avete intenzione di andare a scrivere threading che si comporta in modo identico a un sistema distribuito, usando puro passaggio di messaggi e non assumendo che qualsiasi thread sia quello "principale" e così, allora sì, saranno molto simile. Ma quello che hai fatto è fingere di avere un'architettura distribuita e implementarla in thread. Il fatto è che il threading è un caso di parallelismo molto più semplice di quanto lo sia il vero computing distribuito. È possibile astrarre i due in un singolo problema, ma scegliendo la versione più dura e attenendosi strettamente ad essa. E i risultati non saranno buoni come potrebbero essere quando tutti i nodi sono locali a una macchina. Non stai approfittando del caso speciale.

Answer 2

La distribuzione dell'informatica viene eseguita su più macchine diverse, generalmente con SO a volte specializzati. È più difficile perché l'interconnessione delle macchine è molto più bassa e quindi i problemi che richiedono un accesso rapido e casuale all'intero set di dati sono molto difficili da risolvere.

In generale, sono necessarie librerie specializzate per eseguire problemi di calcolo distribuito che indichino come assegnare nodi ai problemi e fare il giro dei dati.

Mi chiedo davvero se arrivano a conclusioni diverse perché stanno cercando di risolvere i problemi sbagliati su ciascuna piattaforma. Alcuni problemi si adattano molto bene alle macchine altamente interconnesse e possono trarre vantaggio da veri supercomputer di potenza. Altri problemi possono essere affrontati su modelli semplicemente distribuiti. In generale, i supercomputer possono risolvere una vasta gamma di problemi, ma sono molto, molto più specializzati e costosi.

Answer 3

La differenza sembra tornare allo stato condiviso di Thread, i processi passano i messaggi.

È necessario decidere come si desidera mantenere lo stato nella propria app prima di sceglierne uno.

Lo stato di condivisione è facile da iniziare, tutti i dati e le variabili sono proprio lì. Ma una volta che i deadlock/condizioni di gara entrano, è difficile da modificare/scalare.

Il passaggio dei messaggi (ad es. Erlang) richiede un approccio diverso alla progettazione, è necessario pensare alle opportunità di concorrenza sin dall'inizio, ma lo stato di ogni processo distribuito è isolato, rendendo più facili i problemi di blocco/gara.

Answer 4

Penso che sia molto più utile confrontare i processi con gli approcci di calcolo distribuiti piuttosto che confrontare i thread con esso. I thread esistono all'interno di un singolo processo e condividono gli stessi dati e la stessa memoria. Questo non è possibile su più macchine. I processi d'altra parte hanno una propria memoria, sebbene in alcuni casi contenga esattamente gli stessi dati di un altro processo (dopo un fork(), ad esempio). Questo potrebbe essere ottenuto su una rete.

Qualcosa che aggiunge ulteriore peso a questa analogia è il fatto che molti strumenti utilizzati per la comunicazione tra processi sono trasparenti in rete. Un buon esempio potrebbe essere unix socket, che utilizza la stessa interfaccia dei socket di rete (ad eccezione del codice di connessione).

Answer 5

Sì in fase di sviluppo l'approccio è molto simile ma l'uso di ciascuno è molto diverso. Non capisco molto chiaramente la tua idea, fammi sapere se ho torto: quando parli di calcolo distribuito, supponiamo che più di un computer o un codice di elaborazione server nella stessa applicazione, ma quando parliamo di Multi-Threading noi stiamo parlando dell'elaborazione di threading diversi dell'applicazione contemporaneamente nello stesso computer. Si può pensare come esempio di calcolo distribuito, in un'applicazione che accede ad un servizio web localizzato in Internet. Ci sono due computer diversi che lavorano nella stessa app.

Se si desidera un esempio di multi-threading, basti pensare a un'applicazione che cerca di trovare un numero primo grande. Se non usi il multi-threading in esso non potrai vedere o fare altro nell'applicazione al momento del calcolo del numero primo successivo (può essere una vita o più) perché l'applicazione non è reattiva mentre sta lavorando nel calcolo.

È possibile anche combinarli: come esempio più complesso, è sempre possibile utilizzare il multithreading per accedere contemporaneamente a servizi Web diversi dalla stessa applicazione, al fine di rendere l'applicazione reattiva anche se non lo è collegamento quando uno dei server.

Answer 6

Penso che quei due documenti non possano essere facilmente confrontati.Il documento di Intel è una sorta di introduzione al threading e cercano di spiegarlo trovando analogie con il network computing, il che è un po 'strano e fuorviante per me. Non sono sicuro del motivo per cui hanno scelto un modo di presentazione del threading, forse si rivolgono a persone che hanno familiarità con il networking, che è probabilmente più conosciuto o almeno riconosciuto rispetto al threading.

Il documento di Sun, d'altro canto, è un articolo serio, che descrive tutte le difficoltà relative alla programmazione distribuita. Tutto quello che posso fare è semplicemente confermare quello che dicono in esso.

A mio parere, un'astrazione che tenta di nascondere il fatto che un oggetto sia remoto è dannoso in quanto di solito porta a prestazioni pessime. Il programmatore deve essere consapevole della lontananza di un oggetto per poterlo richiamare in modo efficiente.