Esistono problemi / algoritmi famosi nell'informatica scientifica che non possono essere accelerati dalla parallelizzazione

Esistono problemi / algoritmi famosi nel calcolo scientifico che non possono essere accelerati dalla parallelizzazione? Mi sembra che leggendo libri su CUDA che la maggior parte delle cose possa essere.

La questione centrale è la lunghezza del percorso critico rispetto alla quantità totale della computazione T . Se C è proporzionale a T , il parallelismo offre nella migliore delle ipotesi un costante aumento di velocità. Se C è asintoticamente più piccolo di T , c'è spazio per più parallelismo all'aumentare della dimensione del problema. Per gli algoritmi in cui T è polinomiale nella dimensione di input N , il caso migliore è C ∼ log T perché è possibile calcolare pochissime quantità utili in meno del tempo logaritmico.$C$$T$$C$$T$$C$$T$$T$$N$$C \sim \log T$

Esempi

• per una risoluzione tridiagonale usando l'algoritmo standard. Ogni operazione dipende dal completamento dell'operazione precedente, quindi non esiste alcuna possibilità di parallelismo. I problemi tridiagonali possono essere risolti in tempo logaritmico su un computer parallelo usando una risoluzione diretta di dissezione nidificata, decomposizione di domini multilivello o multigrid con funzioni di base costruite usando l'estensione armonica (questi tre algoritmi sono distinti in più dimensioni, ma possono coincidere esattamente in 1D).$C = T$
• Una densa risoluzione triangolare inferiore con una matrice ha T = N = O ( m 2 ) , ma il percorso critico è solo C = m = $m\times m$$T = N = \mathcal O(m^2)$ , quindi un po 'di parallelismo può essere utile.$C = m = \sqrt T$
• Multigriglia e FMM entrambi hanno , con un percorso critico di lunghezza C = log- T .$T = N$$C = \log T$
• La propagazione esplicita dell'onda per un tempo su una mesh regolare del dominio ( 0 , 1 ) d richiede k = τ / Δ t ∼ τ N passi temporali 1 / d (per stabilità), quindi il percorso critico è almeno C = k . La quantità totale di lavoro è T = k N = τ N ( d + 1 ) / d . Il numero massimo utile di processori è P = $\tau$$(0,1)^d$$k = \tau / \Delta t \sim \tau N^{1/d}$$C = k$$T = k N = \tau N^{(d+1)/d}$ , il restante fattore N 1 / d non può essere recuperato dall'aumentato parallelismo.$P = T/C = N$$N^{1/d}$

Complessità formale

La classe di complessità NC caratterizza quei problemi che possono essere risolti in modo efficiente in parallelo (cioè nel tempo pollogaritmico). Non è noto se , ma è ampiamente ipotizzato falso. Se questo è davvero il caso, allora P-complete caratterizza quei problemi che sono "intrinsecamente sequenziali" e che non possono essere accelerati in modo significativo dal parallelismo.$NC = P$

Per dare un aspetto teorico a questo, $NC$ è definito come la classe di complessità che è risolvibile in tempo in un sistema con O ( n k ) processori paralleli. Non è ancora noto se P = N C (sebbene la maggior parte delle persone sospetti che non lo sia) in cui P è l'insieme di problemi risolvibili in tempi polinomiali. I problemi "più difficili" da parallelizzare sono noti come problemi P- completi, nel senso che ogni problema in P può essere ridotto a un problema P- completo tramite$O(log^c n)$$O(n^k)$$P=NC$$P$$P$$P$$P$Riduzioni N C. Se si mostra che un singoloproblema P- completo è in N C , si dimostra che P = N C (sebbene sia probabilmente falso come menzionato sopra).$NC$$P$$NC$$P=NC$

Quindi qualsiasi problema che sia completo sarebbe intuitivamente difficile da parallelizzare (anche se sono ancora possibili grandi accelerazioni). Un problema P- completo per il quale non abbiamo nemmeno ottime accelerazioni di fattore costante è la Programmazione lineare (vedi questo commento sullo scambio OR).$P$$P$

Inizia con il brontolio della Legge di Amdahl . Fondamentalmente qualsiasi cosa con un gran numero di passaggi seriali trarrà beneficio insignificante dal parallelismo. Alcuni esempi includono l'analisi, regex e la maggior parte della compressione ad alto rapporto.

A parte questo, il problema chiave è spesso un collo di bottiglia nella larghezza di banda della memoria. In particolare con la maggior parte delle GPU, i tuoi flop teorici superano ampiamente la quantità di numeri in virgola mobile che puoi ottenere dai tuoi ALU, poiché tali algoritmi con bassa intensità aritmetica (flop / cache-miss) trascorreranno gran parte del tempo in attesa su RAM.

Infine, ogni volta che un pezzo di codice richiede la diramazione, è improbabile che ottenga buone prestazioni, poiché la logica di ALU supera in genere la logica.

In conclusione, un esempio davvero semplice di qualcosa che sarebbe difficile ottenere un guadagno di velocità da una GPU è semplicemente il conteggio del numero di zeri in una matrice di numeri interi, poiché potrebbe essere necessario ramificarsi spesso, al massimo eseguire 1 operazione (incremento di uno) nel caso in cui trovi uno zero ed esegui almeno un recupero di memoria per operazione.

Un esempio privo del problema della ramificazione è il calcolo di un vettore che è la somma cumulativa di un altro vettore. ([1,2,1] -> [1,3,4])

Non so se questi contano come "famosi" ma c'è sicuramente un gran numero di problemi che il calcolo parallelo non ti aiuterà.

Il (famoso) metodo di marcia rapida per risolvere l'equazione di Eikonal non può essere accelerato dalla parallelizzazione. Esistono altri metodi (ad esempio metodi di scansione rapida) per risolvere l'equazione di Eikonal che sono più suscettibili alla parallelizzazione, ma anche qui il potenziale di speedup (parallelo) è limitato.

Il problema con l'equazione di Eikonal è che il flusso di informazioni dipende dalla soluzione stessa. A grandi linee, le informazioni fluiscono lungo le caratteristiche (cioè i raggi luminosi nell'ottica), ma le caratteristiche dipendono dalla soluzione stessa. E il flusso di informazioni per l'equazione di Eikonal discretizzata è ancora peggio, richiedendo ulteriori approssimazioni (come implicitamente presenti nei metodi di sweep veloce) se si desidera uno speedup parallelo.

Per vedere le difficoltà della parallelizzazione, immagina un bel labirinto come in alcuni degli esempi sulla pagina web di Sethian . Il numero di celle sul percorso più breve attraverso il labirinto (probabilmente) è un limite inferiore per il numero minimo di passaggi / iterazioni di qualsiasi algoritmo (parallelo) che risolve il problema corrispondente.

(Scrivo "(probabilmente) è", perché i limiti inferiori sono notoriamente difficili da dimostrare e spesso richiedono alcune ipotesi ragionevoli sulle operazioni utilizzate da un algoritmo.)

Un'altra classe di problemi che sono difficili da parallelizzare nella pratica sono i problemi sensibili agli errori di arrotondamento, in cui la stabilità numerica viene raggiunta dalla serializzazione.

Consideriamo ad esempio il processo Gram – Schmidt e la sua modifica seriale. L'algoritmo funziona con i vettori, quindi è possibile utilizzare operazioni vettoriali parallele, ma ciò non si adatta bene. Se il numero di vettori è elevato e le dimensioni del vettore sono ridotte, l'uso di Gram – Schmidt classico parallelo e la reorthogonalization potrebbero essere stabili e più veloci del singolo Gram – Schmidt modificato, sebbene implichi un lavoro più volte maggiore.