Modelli paralleli attuali per il calcolo

Gli anni '80 hanno dato origine sia al modello PRAM che al modello BSP di calcolo parallelo. Sembra che il periodo di massimo splendore di entrambi i modelli fosse tra la fine degli anni '80 e l'inizio degli anni '90.

Queste aree sono ancora attive in termini di ricerca per algoritmi paralleli? Esistono modelli più recenti e più sofisticati per il calcolo parallelo? I modelli generali sono ancora in voga o i ricercatori stanno cercando di specializzarsi con il calcolo basato su GPGPU o Cloud in arrivo?

Esistono diversi modelli che fluttuano intorno, ma alcuni dei più salienti sono:

1. I modelli MUD e Mapreduce riguardano principalmente l'acquisizione del framework MapReduce, ma più in generale possono essere visualizzati come modelli di calcolo distribuiti in parallelo
2. I vari modelli multicore che sono stati proposti (ma non sono ancora lo standard)

Il DIMACS ha tenuto un seminario il mese scorso su questo argomento: esaminare gli abstract vi darà più indicazioni.

Mi scuso in anticipo per il formato post-blog della mia risposta. Non ho potuto fare a meno di fare una piccola panoramica del mondo dell'informatica parallela.

È possibile classificare i modelli di programmazione parallela in circa due categorie: modelli di flusso di controllo e flusso di dati.

I modelli di flusso di controllo cercano di far funzionare il parallelismo nel contesto di un programma di controllo esplicito, praticamente ogni computer programmabile oggi. Il problema fondamentale affrontato è che una tale "architettura Von Neumann" non è stata progettata per l'esecuzione parallela, ma per calcoli sequenziali efficienti. Il parallelismo in tale contesto si ottiene duplicando parti dei moduli di base (memoria, controllo, aritmetica).

La duplicazione solo dell'aritmetica fornisce istruzioni SIMD, tutte le ALU condividono lo stesso Program Counter (PC) e quindi eseguono sempre la stessa operazione in parallelo, anche se su dati diversi.

La duplicazione di ALU e PC, ma mantenendo il sequencer di istruzioni all'interno dell'unità di controllo offre l'esecuzione Out of Order (OoO) che produce un certo parallelismo della pipeline. In questa categoria hai anche la Very Long Instruction Word (VLWI) e le tecniche di previsione della branche. Raramente vedi questa categoria a livello di software.

Andare un po 'oltre è duplicare l'intero "core", ma mantenendo la memoria condivisa, questi sono gli attuali processori multicore che ti offrono task (o thread) parallelismo. La condivisione della memoria in questo contesto ti dà problemi di concorrenza molto, molto difficili e sottili . I calcoli paralleli sull'attuale multicore ruotano quindi completamente attorno a problemi di sincronizzazione / concorrenza, all'attento equilibrio di prestazioni (nessuna sincronizzazione) e semantica desiderata (totalmente sincronizzata, semantica di esecuzione sequenziale). Esempi di questo è la PRAM o più popolare in questi giorni il cilk di scatti come fork / join ( IntelTBB , Java.Utils.Concurrency). I modelli CSP e Actor sono modelli di concorrenza, ma come menzionato sopra la concorrenza e il parallelismo si confondono in un ambiente di memoria condivisa. nb parallelismo è per prestazioni, concorrenza per mantenere la semantica corretta.

Anche la duplicazione della memoria offre computer in rete programmati con MPI e simili o semplicemente strane architetture non Von Neumann come i processori network-on-a-chip (processore cloud, Transputer, Tilera). Modelli di memoria come UMA o NUMA cercano di mantenere l'illusione della memoria condivisa e possono esistere a livello di software o hardware. MPI mantiene il parallelismo a livello di programma e comunica solo attraverso il passaggio di messaggi. Il passaggio dei messaggi viene utilizzato anche a livello hardware per la comunicazione e la concorrenza (Transputer).

La seconda categoria sono modelli di flusso di dati . Questi sono stati progettati all'alba dell'era dei computer come un modo per scrivere ed eseguire calcoli paralleli, evitando il design di Von Neumann. Questi sono andati fuori moda (per il calcolo parallelo) negli anni '80 dopo che le prestazioni sequenziali sono aumentate in modo esponenziale. Tuttavia, molti sistemi di programmazione parallela come Google MapReduce, Microsoft Dryad o Intel Concurrent Collections sono in realtà modelli di calcolo del flusso di dati. Ad un certo punto rappresentano i calcoli come un grafico e li usano per guidare l'esecuzione.

Specificando parti dei modelli si ottengono diverse categorie e semantiche per il modello di flusso di dati. In cosa limiti la forma del grafico a: DAG (CnC, Dryad), albero (mapreduce), digraph? Esistono semantiche di sincronizzazione rigorose ( Lustre, programmazione reattiva]? Impedisci la ricorsione per poter avere una pianificazione statica (StreaMIT) o offri maggiore potenza espressiva con uno scheduler dinamico (Intel CnC)? Esiste un limite al numero di fronti in entrata o in uscita? La semantica di attivazione consente di attivare il nodo quando è disponibile un sottoinsieme dei dati in arrivo? Sono flussi di bordi di dati (elaborazione del flusso) o token di dati singoli (assegnazione singola statica / dinamica). Per il lavoro correlato puoi iniziare guardando il lavoro di ricerca sul flusso di dati di persone come Arvind, K. Kavi, j. Sharp, W. Ackerman, R. Jagannathan, ecc.

Modifica: per completezza. Vorrei sottolineare che esistono anche modelli paralleli guidati dalla riduzione e dal modello . Per le strategie di riduzione hai ampiamente riduzione del grafico e riduzione della stringa. Haskell utilizza fondamentalmente la riduzione dei grafici, che è una strategia molto efficiente su un sistema sequenziale a memoria condivisa. I duplicati per la riduzione delle stringhe funzionano, ma hanno una proprietà di memoria privata che lo rende più adatto per essere implicitamente parallelizzato. I modelli guidati da modelli sono i linguaggi logici paralleli, come il prologo simultaneo. Anche il modello Actor è un modello basato su pattern, ma con caratteristiche di memoria privata.

PS. Uso ampiamente il termine "modello", che copre le macchine astratte sia per scopi formali che di programmazione.

Per le architetture che passano messaggi, un modello che è abbastanza simile a BSP ma più facile da gestire e con analisi delle prestazioni vicino a ciò che si ottiene realmente su una macchina reale è sicuramente CGM o Multicomputer a grana grossa. È stato proposto da Frank Dehne e troverete molti articoli interessanti che presentano algoritmi sviluppati in questo contesto.

Il CGM si adatta alle architetture a grana grossa che assumono processori p, ognuno con memoria locale O (n / p) e dimensioni dell'ingresso n molto più grandi (ordini di grandezza distanti) rispetto a p, ovvero p≪n. Pertanto, il modello mappa molto meglio di altri sulle architetture attuali; è stato ampiamente studiato. Il modello si basa sui seguenti presupposti: (i) gli algoritmi eseguono i cosiddetti supersteps, che consistono in una fase di calcolo locale e una fase di comunicazione interprocessore con sincronizzazione della barriera intermedia, (ii) tutti i processori p hanno accesso a O (n / p) memoria locale, (iii) in ogni superstep, un processore può inviare e ricevere al massimo O (n / p) elementi e (iv) la rete di comunicazione tra i processori può essere arbitraria. In questo modello, un algoritmo viene valutato in base al tempo di calcolo e al numero di cicli di comunicazione. Sebbene il modello sia semplice, fornisce comunque una previsione ragionevole delle prestazioni effettive degli algoritmi paralleli; infatti, gli algoritmi paralleli per CGM di solito hanno un'analisi teorica della complessità molto vicina ai tempi effettivi determinati sperimentalmente durante l'implementazione e il benchmarking.

La memoria esterna parallela (PEM) è una combinazione naturale di una macchina di memoria condivisa in stile PRAM con il modello di memoria esterna. Si concentra sulle implicazioni della cache privata.

Da quello che so, i modelli BSP e LogP sono oggi utilizzati per algoritmi distribuiti. Inoltre, dal momento che il GPU computing, la PRAM è diventata nuovamente popolare, tuttavia si dovrebbero includere le gerarchie di memoria nell'analisi. È possibile controllare il modello UPMH (gerarchia di memoria parallela uniforme) che si integra perfettamente con PRAM.

B. Alpern, L. Carter, E. Feig e T. Selker. Il modello di calcolo della gerarchia della memoria uniforme. Algorithmica, 12: 72–109, 1994. 10.1007 / BF01185206.

Bowen Alpern, Larry Carter e Jeanne Ferrante. Modellazione di computer paralleli come gerarchie di memoria. In In Proc. Modelli di programmazione per computer fortemente paralleli, pagine 116-123. IEEE Computer Society Press, 1993.

Anche per il calcolo GPU, è stata proposta una proposta di modello teorico; il modello K:

Gabriele Capannini, Fabrizio Silvestri e Ranieri Baraglia. Modello K: un nuovo modello computazionale per processori stream. In Atti della 12a Conferenza internazionale IEEE 2010 sull'informatica e le comunicazioni ad alte prestazioni, HPCC '10, pagine 239–246, Washington, DC, USA, 2010. IEEE Computer Society.

Infine, ho visto gli automi cellulari (CA) modellati come computer paralleli, personalmente penso che questo sia un argomento di ricerca molto interessante. Chissà in futuro i processori saranno fatti in questo modo, come piccoli spazi di calcolo. Non ho un solido riferimento per questo, puoi guardare nel web.

Programmi puramente funzionali consentono l'esecuzione parallela di espressioni indipendenti. Quindi, li considererei come modelli paralleli di calcolo.

Preferisco l' approccio Bader-Jaja (vedere la sezione 2.1). Modella la complessità come un problema di passaggio dei messaggi. Per ogni messaggio inviato è presente sia una variabile per la latenza per avviare la comunicazione sia una variabile per la larghezza di banda.

$t$$u$$m$$p$$t$$u$$m$$p$

citi in particolare il cloud computing. nel giro di pochi anni c'è stata un'intensa innovazione in questo settore con il cloud di calcolo elastico Amazon, il motore delle app di Google e vari strumenti e i loro "modelli" di elaborazione parallela concettuale associati.

strumenti open source speciali includono i database Mapreduce , Apache Hadoop e NoSQL di google che stanno emergendo come standard nuovi, forti e ampiamente adattati nell'algoritmo di parallelizzazione "best practice" e "modelli di progettazione". inoltre memcacheD viene sempre più utilizzato come database distribuito in memoria. un esempio di questo è in uso su Facebook descritto in un recente documento [1].

[1] Molti negozi chiave di valori-chiave di Berezecki et al

un'altra prospettiva su questo. è vero che questo potrebbe essere considerato in qualche modo oscuro o marginale da alcuni, ma c'è qualche lavoro sulla parallelizzazione, in generale, di algoritmi probabilistici, che si afferma siano in qualche modo adatti al parallelismo.

vedi ad es calcoli probabilistici paralleli su un gruppo di stazioni di lavoro Radenski, Vann, Norris:

Gli algoritmi probabilistici sono metodi approssimativi computazionalmente intensivi per la risoluzione di problemi intrattabili. Gli algoritmi probabilistici sono candidati eccellenti per i calcoli dei cluster perché richiedono poca comunicazione e sincronizzazione. È possibile specificare una struttura di controllo parallelo comune come algoritmo generico per i calcoli probabilistici del cluster. Un tale algoritmo parallelo generico può essere incollato insieme ad algoritmi sequenziali specifici del dominio al fine di ricavare soluzioni parallele approssimative per diversi problemi intrattabili. In questo articolo proponiamo un algoritmo generico per calcoli probabilistici su un cluster di stazioni di lavoro. Usiamo questo algoritmo generico per derivare algoritmi paralleli specifici per due problemi di ottimizzazione discreti: il problema dello zaino e il problema del commesso viaggiatore.

nel caso in cui non sia chiaro, la "struttura di controllo parallelo comune come algoritmo generico" cui si fa riferimento insieme al calcolo probabilistico e alla conversione complessiva, è il "modello".

si potrebbe sostenere che il calcolo probabilistico non è un calcolo strettamente classico o Turing completo. quindi nota che c'è qualche lavoro nel legare il classico con il calcolo probabilistico anche in un contesto parallelo, ad es

Ragionamento sui programmi paralleli probabilistici di Rao:

L'uso della randomizzazione nella progettazione e nell'analisi di algoritmi promette algoritmi semplici ed efficienti a problemi difficili, alcuni dei quali potrebbero non avere una soluzione deterministica. Questo guadagno in termini di semplicità, efficienza e solvibilità si traduce in un compromesso della nozione tradizionale di assoluta correttezza degli algoritmi per una nozione più quantitativa: correttezza con una probabilità tra 0 e 1. L'aggiunta della nozione di parallelismo al già non intuitivo l'idea di randomizzazione rende ancora più tortuoso e difficile il ragionamento sui programmi paralleli probabilistici. In questo articolo affrontiamo il problema di specificare e derivare le proprietà di programmi paralleli probabilistici che valgono in modo deterministico o con probabilità 1.

ovviamente il QM computing è molto simile al calcolo probabilistico (un bel riferimento che sottolinea questo è il punto di vista della teoria della complessità del calcolo quantistico di Fortnow ) e c'è qualche suggerimento che questi approcci potrebbero essere estesi lì, ad esempio nel lavoro in simulazione QM parallela.

questo sarà considerato controverso da alcuni, e anche i sostenitori di questo angolo dovranno ammetterlo nelle prime fasi della ricerca, ma fondamentalmente l'informatica quantistica sembra avere molte connessioni al parallelismo e al calcolo parallelo. i riferimenti sono attualmente sparsi ma un tema emergente può essere visto da un ricercatore determinato.

forse la migliore connessione è con l' algoritmo di ricerca di Grovers che ha recentemente dimostrato di essere più generale nel senso di essere utilizzabile per l'accelerazione sulla maggior parte dei problemi NP completi in generale [5]. L'algoritmo di Grovers sembra avere una forte analogia / connessione con algoritmi di ricerca di database paralleli. i migliori algoritmi seriali classici non possono soddisfare le stesse prestazioni ma almeno un'autorità recentemente sostiene che gli approcci QM per la ricerca in realtà non superano gli algoritmi classici parallelizzati. [1]

ulteriori prove sono schemi che guardano esplicitamente al parallelismo nella ricerca quantistica, ad esempio [2]. sono stati proposti anche simulatori quantistici basati sull'elaborazione parallela / distribuita [3] [4] e poiché lo schema si adatta bene e conduce a simulazioni efficienti e trattabili (30 qubit sono simulati in ref [3]), questa conversione sicuramente non è solo una coincidenza e indica un ponte più profondo tra elaborazione classica parallela e elaborazione QM, ma probabilmente finora scoperto.

[1] La ricerca quantistica è pratica? di Viamontes et al

[2] Esatta ricerca quantistica mediante schemi di discriminazione unitaria parallela di Wu / Dian

[3] Simulatore parallelo per uso generico per calcolo quantistico di Niwa, Matsumoto, Imai.

[4] calcolo quantistico distribuito efficiente di Beals et al 2012

[5] Risoluzione di problemi completi NP con la ricerca quantistica di Furer 2008