2009-08-20 4 views
35

Con tutto l'hype intorno calcolo parallelo ultimamente, ho pensato molto su di parallelismo, macinare il numero, cluster, ecc ...Quando il parallelismo di Erlang supera le sue debolezze nel calcolo numerico?

ho iniziato a leggere Learn You Some Erlang. Man mano che più persone imparano (me compreso), Erlang gestisce la concorrenza in un modo molto impressionante ed elegante.

Quindi l'autore afferma che Erlang è not ideal for number crunching. Posso capire che un linguaggio come Erlang sarebbe più lento di C, ma il modello per la concorrenza sembra idealmente adatto a cose come la gestione delle immagini o la moltiplicazione delle matrici, anche se l'autore dice esplicitamente di no.

È davvero così male? C'è un punto di svolta in cui la forza di Erlang supera la sua debolezza di velocità locale? Sono/quali sono le misure prese per affrontare la velocità?

Per essere chiari: non sto cercando di avviare un dibattito; Voglio solo sapere.

+0

Erlang è stato creato per essere un linguaggio concorrente per la creazione di servizi di telecomunicazione distribuiti massicci e affidabili: è piuttosto naturale che si stessero concentrando su es. protocollo che analizza più del tipico numero crunch. – nos

+0

Vedo un voto ravvicinato sui motivi di "soggettivo e argomentativo", e concordo sul fatto che il titolo lasci qualcosa a desiderare, ma le domande sono ben formulate e neutrali, e ad oggi abbiamo solo risposte utili. Direi di lasciarlo a meno che le cose non vadano in discesa. ** @ Jon: ** Considerare la riformulazione del titolo. – dmckee

+0

Che ne dici? Ho davvero provato a dire le cose con attenzione e obiettivamente. Non ho visto le cose per rispondere alle mie domande, quindi ho dovuto chiedere. –

risposta

43

È un errore pensare al parallelismo come solo alla potenza di calcolo dei numeri grezzi. Erlang è più simile al modo in cui funziona un computer cluster, ad esempio una GPU o un supercomputer classico.

Nelle moderne GPU e supercomputer di vecchio stile, le prestazioni riguardano l'aritmetica vettoriale, l'hardware di calcolo per scopi speciali e la comunicazione a bassa latenza tra le unità di elaborazione. Poiché la latenza delle comunicazioni è bassa e ogni singola unità di elaborazione è molto veloce, il modello di utilizzo ideale è caricare la RAM della macchina con i dati e farla scricchiolare tutto in una volta. Questa elaborazione potrebbe comportare molti passaggi di dati tra i nodi, come accade nell'elaborazione delle immagini o in 3D, dove ci sono molte attività legate alla CPU da fare per trasformare i dati dal modulo di input alla forma di output. Questo tipo di macchina è una scelta sbagliata quando si deve spesso accedere a un disco, una rete o qualche altro canale I/O lento per i dati. Questo inattivo almeno un costoso processore specializzato, e probabilmente anche soffoca la pipeline di elaborazione dei dati, quindi nient'altro viene fatto.

Se il programma richiede un uso intenso dei canali di I/O lenti, un tipo migliore di macchina è uno con molti processori indipendenti a basso costo, come un cluster. È possibile eseguire Erlang su una singola macchina, nel qual caso si ottiene qualcosa come un cluster all'interno di quella macchina, oppure è possibile eseguirlo facilmente su un cluster hardware effettivo, nel qual caso si dispone di un cluster di cluster.In questo caso, il sovraccarico della comunicazione è ancora inattivo nelle unità di elaborazione, ma poiché sono presenti molte unità di elaborazione in esecuzione su ciascun bit dell'hardware di elaborazione, Erlang può passare a uno degli altri processi all'istante. Se succede che un'intera macchina è lì seduta in attesa di I/O, hai ancora gli altri nodi nel cluster hardware che possono funzionare in modo indipendente. Questo modello si rompe solo quando il sovraccarico della comunicazione è così alto che ogni nodo è in attesa su qualche altro nodo, o per I/O generale, nel qual caso è necessario un I/O più veloce o più nodi, entrambi i quali Erlang ne approfitta in modo naturale di.

I sistemi di comunicazione e controllo sono le applicazioni ideali di Erlang perché ogni singola attività di elaborazione richiede poca CPU e solo occasionalmente necessita di comunicare con altri nodi di elaborazione. La maggior parte delle volte, ogni processo funziona in modo indipendente, ognuno dei quali richiede una piccola parte della potenza della CPU. La cosa più importante qui è la capacità di gestire molte migliaia di questi in modo efficiente.

Il classico caso in cui è assolutamente necessario un supercomputer classico è la previsione del tempo. Qui, dividi l'atmosfera in cubi e fai simulazioni di fisica per scoprire cosa succede in ogni cubo, ma non puoi usare un ammasso perché l'aria si muove tra ogni cubo, così ogni cubo comunica costantemente con i suoi 6 vicini adiacenti. (L'aria non attraversa i bordi o gli angoli di un cubo, essendo infinitamente fine, quindi non parla con gli altri 20 cubi vicini.) Esegui questo in un cluster, sia eseguendo Erlang su di esso o qualche altro sistema, e diventa immediatamente vincolato all'I/O.

+0

Questo è stato molto utile - grazie. –

10

C'è un punto di svolta in cui la forza di Erlang supera la sua debolezza di velocità locale?

Beh, certo che c'è. Ad esempio, quando si cerca di trovare la mediana di un trilione di numeri :):

http://matpalm.com/median/question.html

Poco prima hai postato, mi è capitato di notare che questo era il posto numero 1 su erlang.reddit.com.

+2

Questo è piuttosto fresco - ho intenzione di dover leggere che –

+1

Bene , puoi farlo in qualsiasi lingua che offra parallelismo. Semplicemente non sarebbe così pulito ed elegante come in Erlang. Quindi è più di un compromesso correttezza/sforzo rispetto alla performance/parallelismo – jalf

+2

Guardando il codice sorgente del modulo worker (number_less_than/2), potrebbero avere generato un processo separato per controllare ogni singolo elemento dell'elenco, e quindi riassumerli in o (log n) ora. Invece hanno scelto di farlo linearmente in o (n) tempo. Questo sarebbe un caso in cui la rappresentazione dei dati limita il parallelismo? – Zed

5

C'è pressione affinché Erlang esegua il codice numerico più velocemente. Il compilatore HiPe compila per codice nativo invece del bytecode BEAM, e probabilmente ha la sua ottimizzazione più efficace sul codice su punti mobili dove può evitare il pugilato. Questo è molto utile per il codice in virgola mobile, dal momento che può memorizzare i valori direttamente nei registri FPU.

Per la maggior parte dell'utilizzo di Erlang, Erlang è molto veloce così com'è. Usano Erlang per scrivere sistemi di controllo sempre in cui la più importante misurazione della velocità che conta sono le risposte a bassa latenza. Le prestazioni sotto carico tendono ad essere vincolate all'IO. Questi utenti tendono a stare lontano da HiPe poiché non è flessibile/malleabile nel debug dei sistemi live.

Ora che i server con 128 GB di RAM non sono così rari, e non c'è ragione per cui avranno ancora più memoria, alcuni problemi legati all'IO potrebbero spostarsi per essere un po 'legati alla CPU. Quello potrebbe essere un autista.

È necessario seguire HiPe per lo sviluppo.


I tuoi esempi di manipolazioni di immagini e di moltiplicazioni di matrici mi sembrano tuttavia molto dannose per Erlang. Questi sono esempi che traggono vantaggio dalle operazioni vettoriali/SIMD. Erlang non è bravo nel parallelismo (dove si fa la stessa cosa a più valori contemporaneamente).

I processi di Erlang sono MIMD, più istruzioni multiple di dati. Erlang fa molte ramificazioni dietro il pattern matching e i loop ricorsivi. Questo uccide il pipelining dell'istruzione della CPU.

La migliore architettura per problemi fortemente parallellizzati sono le GPU. Per programmare le GPU in un linguaggio funzionale, vedo il miglior potenziale nell'utilizzo di Haskell per la creazione di programmi che li riguardano. Una GPU è fondamentalmente una pura funzione dai dati di input ai dati di output.Vedere il progetto Lava in Haskell per la creazione di circuiti FPGA, se è possibile creare circuiti in modo pulito in Haskell, non può essere più difficile creare dati di programma per GPU.

L'architettura della cella è molto utile anche per i problemi vettoriali.

+1

È piuttosto interessante che tu dica "Erlang non è buono al parallelismo (dove si fa la stessa cosa a più valori contemporaneamente)", che penso sia corretto - ma il link nella risposta precedente indica quanto è bello Erlang perché di essere in grado di fare la stessa cosa su più valori in parallelo (controllando se il valore è inferiore a una costante). – Zed

10

Quasi tutte le lingue possono essere parallelizzate. In alcune lingue è semplice, in altri è un rompicapo, ma può essere fatto. Se vuoi eseguire un programma C++ su 8000 CPU in una griglia, vai avanti! Ce la puoi fare. È stato fatto prima.

Erlang non fa nulla di impossibile in altre lingue. Se una singola CPU che esegue un programma Erlang è meno efficiente della stessa CPU che esegue un programma C++, allora duecento CPU in esecuzione su Erlang saranno anche più lente di duecento CPU in esecuzione C++.

Cosa Erlang fa non sta facendo questo tipo di parallelismo facile da lavorare. Risparmia tempo per gli sviluppatori e riduce la possibilità di bug.

Quindi ho intenzione di dire di no, non c'è un punto di svolta in cui il parallelismo di Erlang gli permette di sovraperformare la forza di sgranatura numerica di un altro linguaggio.

Nei casi in cui i punteggi di Erlang lo rendano più facile, scalare e farlo correttamente. Ma può ancora essere fatto in altre lingue che sono migliori per il numero-crunch, se sei disposto a dedicare il tempo di sviluppo extra.

E, naturalmente, non dimentichiamo il buon vecchio punto che le lingue non hanno una velocità. Un compilatore Erlang sufficientemente buono darebbe un codice perfettamente ottimale. Un compilatore C sufficientemente cattivo produrrebbe un codice che funziona più lentamente di qualsiasi altra cosa.

+0

"Il tempo di sviluppo è uguale" dovrebbe essere un dato. Gli studi hanno dimostrato in modo conclusivo che Erlang supera di gran lunga il C++ nell'ottimizzazione del tempo di sviluppo per alcuni problemi. La domanda è, fare qualsiasi tipo di problemi di calcolo numerico rientrano in questa categoria. – mwt

+0

L'OP non ha detto nulla sul fatto che il tempo di sviluppo sia uguale. – jalf

+0

Non ha bisogno di essere dichiarato. La domanda non ha senso altrimenti. Se il tempo di sviluppo non deve essere uguale, possiamo dire categoricamente che un cluster di assembly distribuiti sarà più veloce di Erlang. – mwt

1

Penso che la necessità più ampia sia quella di sottolineare che il parallelismo non è necessariamente o anche tipicamente relativo alla velocità.

Si tratta di come esprimere algoritmi o programmi in cui la sequenza di attività è parziale.