Elaborazione distribuita vs thread

Question

Quanto sono simili il computing distribuito e il threading? Ho trovato due articoli che arrivano a conclusioni piuttosto opposte:

" Il multi-threading è più facile del networking. In che modo il threading è semplice e simile al codice di rete "

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

(questo mi dà l'impressione che siano così simili che dopo l'incapsulamento questi due approcci potrebbero essere fatti 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 tali tentativi sono falliti a causa delle differenze fondamentali tra rete e concorrenza?

Answer 1

Non li ho mai trovati molto simili. Consentitemi di definire ai fini di questo post un "nodo" essere un thread hardware in esecuzione su una macchina. Quindi una macchina quad core ha quattro nodi, così come un cluster di quattro scatole a singolo processore.

In genere ogni nodo eseguirà un po 'di elaborazione e dovrà esserci un qualche 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 distribuiti, ecc. Ma i più facili da usare, memoria condivisa e semafori, non sono in genere disponibili in una rete. I file condivisi potrebbero essere disponibili, ma le prestazioni sono generalmente scarse. 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 occuparti dei dettagli dell'architettura di rete, tra cui latenza, larghezza di banda, perdita di pacchetti, topologia di rete e altro ancora.

Se inizi con una coda di lavoro, i nodi sullo stesso computer possono usare una semplice memoria condivisa per fare le cose. Puoi persino scriverlo senza lucchetti e funzionerà perfettamente. Con i nodi su una rete, dove metti la coda? Se lo centralizzi, quella macchina potrebbe subire costi di larghezza di banda molto elevati. Prova a distribuirlo e le cose si complicano molto rapidamente.

Quello che ho scoperto, in generale, è che le persone che affrontano questo tipo di architettura parallela tendono a scegliere problemi paralleli imbarazzanti da risolvere. Viene in mente Raytracing. Non è richiesta molta comunicazione tra nodi, a parte la distribuzione dei lavori. Ci sono molti problemi come questo, certo, ma trovo un po 'disonesto suggerire che il calcolo distribuito sia essenzialmente lo stesso del threading.

Ora, se hai intenzione di andare a scrivere thread che si comporta in modo identico a un sistema distribuito, usando il puro passaggio di messaggi e non supponendo che nessun thread sia il "principale" uno e così, quindi sì, saranno molto simili. Ma quello che hai fatto è far finta di avere un'architettura distribuita e implementarla in thread. Il fatto è che il threading è un caso molto più semplice di parallelismo rispetto al vero calcolo distribuito. Puoi astrarre i due in un unico problema, ma scegliendo la versione più difficile e attenendoti rigorosamente. E i risultati non saranno buoni come potrebbero essere quando tutti i nodi sono locali su una macchina. Non stai approfittando del caso speciale.

Answer 2

La distribuzione dell'elaborazione avviene su più macchine indipendenti diverse, generalmente con sistemi operativi talvolta 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 spiegano come assegnare nodi ai problemi e archiviare i dati.

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

Answer 3

La differenza sembra tornare allo stato di condivisione dei thread, i processi passano i messaggi.

Devi decidere come mantenere lo stato nella tua app prima di sceglierne uno.

È facile iniziare a condividere lo stato, tutti i dati e le variabili sono lì. Ma una volta che si verificano deadlock / condizioni di gara, è difficile modificarle / ridimensionarle.

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

Answer 4

Penso che sia molto più utile confrontare i processi con gli approcci di calcolo distribuito 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 (), per esempio). Ciò potrebbe essere realizzato 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 ho la tua idea molto chiara, fammi sapere se sbaglio: quando parliamo di calcolo distribuito stiamo assumendo più di un codice di elaborazione di computer o server nella stessa applicazione, ma quando parliamo di Multi-Threading abbiamo stanno parlando dell'elaborazione di thread diversi dell'applicazione contemporaneamente nello stesso computer. Puoi pensare come un esempio di calcolo distribuito, in un'applicazione che accede a un servizio Web situato in Internet. Esistono due computer diversi che lavorano nella stessa app.

Se vuoi un esempio di multi-threading, pensa a un'applicazione che cerca di trovare un grande numero primo. Se non utilizzi il multi-threading in esso, non sarai in grado di vedere o fare qualsiasi altra cosa nell'applicazione nel momento in cui sta calcolando il numero primo successivo (può essere un tempo di vita o più) perché l'applicazione è non reattivo mentre sta lavorando nel calcolo.

Puoi anche mescolarli: come esempio più complesso, puoi sempre utilizzare il multi-threading per accedere a diversi servizi Web contemporaneamente dalla stessa applicazione, questo per rendere la tua applicazione reattiva anche se non si connette quando uno dei server.

Answer 6

Penso che questi 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, che è un po 'strano e fuorviante per me. Non sono sicuro del motivo per cui hanno scelto un modo di presentare il threading, forse si sono rivolti a persone che hanno familiarità con il networking, che è probabilmente più noto o almeno riconosciuto del threading.

Il documento di Sun, d'altra parte, è un articolo serio, che descrive tutte le difficoltà legate alla programmazione distribuita. Tutto quello che posso fare è semplicemente confermare ciò che dicono.

A mio avviso, un'astrazione che tenta di nascondere il fatto che un oggetto sia remoto è dannosa in quanto di solito porta a una performance molto negativa. Il programmatore deve essere consapevole della lontananza di un oggetto per poterlo invocare in modo efficiente.