come gestire la programmazione parallela [chiusa]

Sono arrivato da uno sfondo di supercalcolo (generalmente per usi scientifici e ingegneristici). I due principali stili di parallelismo sono la memoria condivisa, in cui un programma viene eseguito con più thread nello stesso spazio di indirizzi - un modo frequente per implementare OPENMP - e il passaggio di messaggi, con MPI come il software più popolare.

Se ti interessa solo utilizzare alcuni processori, ad esempio il numero che puoi ottenere su una macchina dual socket, che supporta 2 chip, inizierei con OPENMP. Di solito lo usi aggiungendo le direttive (pragma) ai loop per. A volte puoi prendere un'applicazione esistente e in modo frammentario parallelizzarla, un ciclo alla volta.

Il trasferimento dei messaggi, con MPI o qualche altro pacchetto, è solitamente più difficile, sebbene sia garantito che i processi di differenza abbiano spazi di memoria indipendenti. Tuttavia, ogni volta che i dati devono essere condivisi, devono essere memorizzati nel buffer e inviati a uno o più processi che devono effettuare chiamate per ricevere i dati. Il messaggio che passa parallelismo, di solito richiede che l'applicazione sia progettata da zero per il parallelismo. Ma data una domanda sufficientemente parallela, il numero di processori che può scalare è sostanzialmente illimitato. Cluster di centinaia o migliaia di core non sono rari.

Puoi anche mescolare i metodi, con ogni processo MPI, utilizzando diversi processori per calcolare il proprio pezzo parallelamente localizzato di un'applicazione parallela più grande.

Non ho usato OpenCL, ma non è un modo di utilizzare il chip grafico per eseguire calcoli? Cuda è attualmente utilizzato per programmare quelli che vengono chiamati GPGPU (General Purpose Graphical Processing Units), come quelli forniti da NVidia Fermi.

Personalmente, penso che gli sforzi per imparare e scrivere Cuda possano essere sprecati. Penso che il numero di core per processore vero per tutti (x86) in offerta continueranno a salire e il numero di unità in virgola mobile per core (accessibile tramite AVX) crescerà anche di più nei prossimi anni. Quindi IMHO, utilizzando GPGPU per compensare una carenza di unità in virgola mobile per chip, sarà probabilmente solo una soluzione preferita a breve termine. Potrebbero esserci dei buoni posti di lavoro disponibili per i buoni programmatori CUDA, sii pronto a cambiare drasticamente l'intero campo nel giro di pochi anni.

Iniziando con l'ultima domanda, la programmazione funzionale non è necessariamente importante per comprendere il calcolo parallelo, ma può essere utile per la programmazione parallela. In particolare, la mancanza di modifiche dello stato significa che di solito è relativamente facile avere alcune funzioni x e una funzione che si eseguono isolatamente l'una dall'altra, e si assicura che entrambe funzionino nello stesso modo come farebbero se (per esempio) condividessero un spazio degli indirizzi. Significa anche che tutte le comunicazioni tra le funzioni sono facili da rilevare e generalmente ben conosciute dall'inizio.

Continuando indietro, direi che il modo migliore per capire qualcosa come Cuda o OpenCL è quello di studiarlo direttamente. La maggior parte dei modelli teorici presuppone che (ad esempio) una macchina CREW PRAM utilizzi esattamente quel modello in ogni momento, in tutte le circostanze. OpenCL, al contrario, consente di specificare quali dati sono globali e quali dati sono locali. Il suo modello di memoria è descritto in dettaglio abbastanza decente nella specifica OpenCL . Cuda è leggermente diverso, ma lo stesso vale generalmente anche per questo - - Se vuoi usare Cuda, generalmente preferisci studiarlo direttamente. Sì, non sarebbe male aver anche studiato alcuni dei modelli più teorici per avere almeno un'idea di come gli algoritmi di base vengano implementati in macchine in parallelo, ma non aspettatevi che la maggior parte di essi si applichi direttamente.

Non penso che esista un modo migliore per gestire la programmazione parallela, non più del modo migliore per gestire la programmazione seriale. Ci sono (almeno) una mezza dozzina di modelli / paradigmi / qualsiasi cosa che la programmazione seriale abbia seguito nel corso degli anni. Sono abbastanza sicuro che tutti questi e altri si applicheranno anche alla programmazione parallela.

Il calcolo parallelo e distribuito vanno di pari passo. Omega Centauri ha giustamente sottolineato l'architettura della memoria condivisa. Ma l'architettura condivisa di nulla basata sul modello di attore sembra essere il precursore dell'informatica generale. Se vuoi imparare la programmazione parallela in generale, dal momento che anche le CPU moltiplicano i loro core, ti suggerisco di imparare quanto segue

1. Informatica distribuita in generale. Sistemi distribuiti: Concept and Design ti offre una visione eccellente
2. MapReduce - solo per pensare in modo parallelo e distribuito
3. Erlang - Programmazione attuale

Inoltre, OpenCL è indipendente dalla piattaforma mentre CUDA non lo è, ma CUDA è più maturo. E una nota finale, né MapReduce è un proiettile d'argento, né Erlang è una macchina veloce