Librerie parallele a memoria condivisa basate su attività nel calcolo scientifico

Negli ultimi anni sono apparsi numerosi progetti di biblioteche / software che offrono in qualche modo un parallelismo della memoria condivisa basato sui dati per scopi generici.

L'idea principale è che invece di scrivere un codice esplicitamente thread, i programmatori implementano i loro algoritmi come attività interdipendenti che vengono quindi programmate dinamicamente da un middleware per uso generico su una macchina a memoria condivisa.

Esempi di tali librerie sono:

• QUARK : Originariamente progettato per la libreria di algebra lineare parallela MAGMA , sembra essere stato usato anche per un metodo multipolare veloce parallelo .

• Cilk : Originariamente un progetto basato sul MIT, ora supportato da Intel, implementato come estensioni di linguaggio / compilatore a C, utilizzato nel software di scacchi per computer Cilkchess e sperimentalmente in FFTW .

• SMP superscalar : sviluppato presso il Centro di supercomputer di Barcellona, ​​simile a Cilk per molti aspetti, basato su #pragmaestensioni.

• StarPU : "codelet" basati su libreria simili che possono essere compilati e pianificati su diverse architetture diverse, comprese le GPU.

• Attività OpenMP: a partire dalla versione 3.0, OpenMP ha introdotto "attività" che possono essere programmate in modo asincrono (vedere la Sezione 2.7 delle specifiche).

• Intel Threading Building Blocks : utilizza le classi C ++ per creare e avviare attività asincrone, vedere la Sezione 11 del Tutorial.

• OpenCL : supporta il parallelismo basato su attività su più core.

Mentre c'è molta letteratura che descrive il funzionamento interno di queste biblioteche / estensioni di linguaggio e la loro applicazione a problemi specifici, ho trovato solo pochissimi esempi di loro che vengono utilizzati nella pratica in applicazioni di informatica scientifica.

Quindi, ecco la domanda: qualcuno conosce i codici scientifici informatici che utilizzano una di queste librerie / estensioni di linguaggio o simili per il parallelismo della memoria condivisa?

deal.II usa i Threading Building Blocks in tutta la biblioteca e nel complesso ne siamo ragionevolmente soddisfatti. Abbiamo esaminato alcune alternative, in particolare OpenMP poiché tutti sembrano utilizzarlo per codici più semplici, ma le abbiamo trovate carenti. In particolare, OpenMP ha l'enorme svantaggio che il suo modello di attività non consente di ottenere un handle per un'attività avviata e, di conseguenza, è difficile accedere allo stato di un'attività (ad es. Attendere il completamento) o restituire i valori di funzioni eseguite su un'attività separata. OpenMP è principalmente utile per parallelizzare i loop più interni, ma si ottiene efficienza parallela parallelizzando i loop più esterni e complessi, e OpenMP non è lo strumento per quello mentre i TBB sono ragionevolmente buoni per questo.

A mio avviso, questi sistemi non hanno avuto successo a causa principalmente dei seguenti motivi.

• L'ingenua prospettiva che il calcolo parallelo riguardi il parallelizzare il calcolo (ad esempio i flop) piuttosto che esporre la località di memoria e rimuovere i punti di sincronizzazione. Anche se alcuni problemi, come gli algoritmi a matrice densa, sono ancora limitati a FP, ciò si verifica solo dopo un'attenta considerazione del sottosistema di memoria e la maggior parte dei kernel computazionali (specialmente nel mondo PDE) sono più sensibili alla memoria. Le code di lavoro tendono a scambiare la località di memoria per un migliore bilanciamento ingenuo dei flop e più operazioni di memoria atomica (a causa della sincronizzazione attraverso la coda).
• Affidamento alla sovra-decomposizione per un bilanciamento dinamico del carico a scapito della forte scalabilità. Le attività hanno generalmente dipendenze di dati sovrapposte (valori fantasma). Man mano che le dimensioni dell'interno si riducono, aumenta il rapporto fantasma / interno. Anche quando ciò non implica un lavoro ridondante, implica un aumento del movimento della memoria. Riduzioni significative dei requisiti di larghezza di banda della memoria possono essere ottenute con approcci come il prefetch cooperativo mediante il quale più thread condividono una cache L1 o L2 mediante il prefetching del software per i loro vicini (che mantiene implicitamente il gruppo di thread approssimativamente coerente). Questo è esattamente l'opposto della sovra-decomposizione.
• Prestazioni imprevedibili, principalmente a causa dei problemi relativi alla memoria di cui sopra.
• Mancanza di componenti compatibili con la libreria. Questo può quasi riassumersi come non avere un analogo di un MPI_Commche consente a diverse librerie di eseguire operazioni avanzate senza scontrarsi, oltre a passare il contesto tra le librerie e recuperare gli attributi necessari. L'astrazione fornita dal "comunicatore" è importante per la composizione della libreria indipendentemente dal fatto che venga utilizzata la memoria condivisa o distribuita.