Limiti al calcolo parallelo

21

Sono curioso in senso lato di ciò che è noto sulla parallelizzazione degli algoritmi in P. Ho trovato il seguente articolo di Wikipedia sull'argomento:

http://en.wikipedia.org/wiki/NC_%28complexity%29

L'articolo contiene la seguente frase:

Non è noto se NC = P, ma la maggior parte dei ricercatori sospetta che ciò sia falso, il che significa che probabilmente ci sono alcuni problemi trattabili che sono "intrinsecamente sequenziali" e non possono essere accelerati in modo significativo usando il parallelismo

Sembra ragionevole? Ci sono casi noti in cui un problema in P non può essere accelerato usando il parallelismo?

cc.complexity-theory complexity-classes big-picture

— Vladimir Levin
fonte

5

Vedi anche domande simili cstheory.stackexchange.com/questions/1643/nc-p-consequences e cstheory.stackexchange.com/questions/799/…

— András Salamon

Sì, sembra ragionevole. Un capitolo del libro Computational Complexity di Papadimitriou fornisce una buona spiegazione per apprendere questo argomento.

— Tsuyoshi Ito,

17

Non è nemmeno noto se NC = P, ma i problemi P-completi sembrano intrinsecamente difficili da parallelizzare. Questi includono Programmazione lineare e Horn-SAT. (Al contrario, i problemi in NC sembrano ragionevolmente facili da parallelizzare.)

Vedi domanda Problemi tra NC e P: quanti sono stati risolti da questo elenco? per materiale di riferimento (inclusi collegamenti a un classico libro di testo che ora è disponibile per il download gratuito) e ulteriori discussioni sui problemi che si trovano in P ma che non sono noti per essere parallelizzabili.

Vedi la domanda Teorema di Ladner generalizzato per la struttura delle classi di complessità tra NC e P. In breve, se differiscono, allora ci sono infinite classi di complessità rigorosamente tra NC e P.

Vedi domanda NC = P conseguenze? per una bella dimostrazione di Ryan Williams che è possibile amplificare i crolli nella gerarchia delle classi di complessità all'interno di P in crolli forse più improbabili come PSPACE = EXP .

Vale la pena sottolineare che una conseguenza del fatto che Horn-SAT è P-complete, e i collegamenti sopra, è che non sembra possibile parallelizzare le query SQL generali nei database, a meno che non possiamo anche riscrivere qualsiasi calcolo su larga scala da usare solo una ragionevole quantità di spazio di archiviazione. Questa è una discrepanza sconcertante - penso che sia abbastanza controverso affermare che ci sono limiti alla compressione , ma vedo spesso articoli che sembrano costruiti partendo dal presupposto che è possibile parallelizzare qualsiasi query del database.

— András Salamon
fonte

Certamente potresti non essere in grado di parallelizzare una determinata porzione di una query del database, o almeno in modo semplice. Tuttavia, una query del database (escluse le query secondarie per semplificare le cose) può essere ridotta a una scansione completa della tabella su alcune tabelle unite e quella tabella unita stessa può sempre essere scansionata in parallelo. Questo è il motivo per cui, quando si aumentano le impostazioni di parallelismo in Oracle, è più propenso a utilizzare scansioni di tabelle complete anziché indici.

— sclv,

@sclv: questo è vero, ma in generale i join intermedi possono essere esponenziali nella dimensione di input? Quindi si può parallelizzare tramite join, ma a costo di dover scansionare un numero esponenziale di tuple.

— András Salamon,

1

Cosa consideri la dimensione di input qui? Inoltre, se si dispone di un m n o cross-aderire, c'è sempre la possibilità che si potrebbe tornare proprio che molte tuple - vale a dire non c'è alcuna possibilità di meglio legato al caso peggiore. E questo è più pratico che teorico, ma in generale ti preoccupi non di parallelizzare le prestazioni di un predicato su una riga, ma di throughput IO, poiché è lì che tenderà ad essere il limite.

— sclv,

10

Bene, se ci fossero casi noti, saremmo in grado di separare P e NC. Ma ci sono molti problemi noti per essere P-complete (cioè sotto riduzioni dello spazio di log), e presentano lo stesso tipo di barriere per mostrare P = NC come fanno i problemi NP-complete per P = NP. Tra questi vi sono la programmazione lineare e la ~~corrispondenza (e i~~ flussi massimi in generale).

Ketan Mulmuley ha dimostrato un risultato separando P e una forma debole di NC (senza operazioni di bit) nel 1994. In un certo senso, il suo programma attuale per P vs NP decolla da dove si era interrotto ( in modo molto lento ).

Il libro " Limits on Parallel Computation " ha di più su questo.

— Suresh Venkat
fonte

2

Attenzione. Non penso che la corrispondenza sia P-completa. È noto che la corrispondenza si trova in RNC mediante test di identità polinomiale (verificare se il determinante della matrice Tutte del grafico è identicamente zero). Se fosse P-completo, seguirà l'improbabile collasso P = RNC.

— slimton,

Argh. hai ragione. Avrei dovuto attenermi ai flussi massimi. grazie per la correzione.

— Suresh Venkat,

0

Ho risposto alla domanda simile Esistono problemi / algoritmi famosi nell'informatica scientifica che non possono essere accelerati dalla parallelizzazione sul sito di scienza computazionale . Vorrei citarlo qui, perché offre una prospettiva pratica su un'istanza molto concreta di un tale problema:

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.)

— Thomas Klimpel
fonte