C'è qualcosa che DEVE essere fatto su una CPU multi-core?

Quando consideriamo quanto il nostro programma sia multi-thread-friendly, il mio team si è preoccupato del fatto che ci sia qualcosa che non può assolutamente essere fatto su una CPU single-core. Ho ipotizzato che l'elaborazione grafica richieda un'elaborazione parallela massiccia, ma sostengono che cose come DOOM sono state fatte su CPU single-core senza GPU.

C'è qualcosa che deve essere fatto su un processore multi-core?

Supponiamo che ci sia un tempo infinito sia per lo sviluppo che per l'esecuzione.

Se non ti interessa il tempo di esecuzione, tutto ciò che puoi fare su una macchina multi-core, puoi farlo su una macchina single-core. Una macchina multi-core è solo un modo per accelerare alcuni tipi di calcoli.

Se riesci a risolvere un problema nel tempo su una macchina multi-core con core, allora puoi risolverlo time (o meno guardare la legge di Amdahl ) su una macchina single-core. La macchina single-core può emulare una macchina multi-core usando time-slicing / time-sharing .n ∼ T $T$$n$$\sim Tn$

La domanda è: sotto quali vincoli?

Vi sono certamente problemi in cui, se poniamo la domanda "possiamo risolvere questo problema sull'hardware X in un determinato lasso di tempo", la risposta sarà no.

Ma questa non è una risposta "a prova di futuro": le cose che in passato non potevano essere fatte abbastanza velocemente in un singolo core probabilmente possono essere ora, e non possiamo prevedere di cosa sarà capace l'hardware futuro.

In termini di calcolabilità, sappiamo che una Turing Machine a nastro singolo è in grado di calcolare tutte le stesse funzioni di un computer singolo o multi-core, quindi, a parte il runtime, non ci sono problemi che un computer multi-core può risolvere che un single-core non può.

In termini di qualcosa come la grafica, letteralmente tutto ciò che è sulla GPU potrebbe essere fatto sulla CPU ... se sei disposto ad aspettare abbastanza a lungo.

Come hanno indicato altre risposte, una singola CPU può sempre emulare più CPU tagliando il tempo e giocando il ruolo di ogni CPU virtuale. Questa emulazione calcolerà sicuramente le risposte corrette.

Nel mondo reale, i tempi di esecuzione possono essere importanti. Potrebbe significare la differenza tra un frame rate mediocre e un'esperienza visiva stellare. O la differenza tra profitti e perdite nel trading.

Una situazione patologica in cui un multiprocessore è notevolmente più veloce di un uniprocessore è quella in cui l'elaborazione è una pipeline di dati, il cambio di contesto è costoso e il codice macchina per ogni fase della pipeline si adatta a malapena alla cache della CPU.

Vorrei illustrare con alcuni numeri. Supponiamo di avere una pipeline di dati (rendering 3D, ecc.) Con 4 fasi di elaborazione, ogni fase ha 256 KiB di codice programma e si hanno convenientemente 4 CPU con 256 KiB di cache L2. Se si tenta di eseguire questa elaborazione su una singola CPU, la commutazione tra le 4 attività sarà costosa e comporterà notevoli perdite di cache. D'altro canto, se lo si esegue su un sistema a 4 core, il calcolo potrebbe essere potenzialmente molto fluido, i mancati errori nella cache sono minimi e gli switch di contesto sono inesistenti. (Come nota a margine, ciò è correlato all'idea di bloccare determinate applicazioni su determinati core, ad esempio eseguendo solo le operazioni del kernel del sistema operativo in un core, o la gestione TCP / IP, ecc.)

È molto più difficile sviluppare gare di dati davvero nefasti con una singola CPU. Voglio dire, certo, puoi interrompere lo strappo tra le parole se interrompi una singola CPU, ma puoi costruire scenari esotici in cui non esiste un singolo interfogliamento di thread che fa quello che vuoi?

Va bene, forse fare bug insidiosi non conta come un uso valido di avanzamenti multi-codice. A quanto pare, non c'è molto che il multi-core può fare a quel singolo core non può avere tempo. Il motivo è semplice Se si tenta di evitare quelle razze di dati malvagi, è necessario disporre di punti di sincronizzazione nel codice. Se modelli il tuo codice come un reticolo di calcoli in cui i tuoi input devono essere completi e sincronizzati prima di poter calcolare e produrre output, è facile vedere che una singola CPU può semplicemente farsi strada lungo il reticolo, calcolando il successivo blocco di lavoro disponibile .

Infatti, se puoi dimostrare che il tuo algoritmo può essere risolto da una macchina di Turing (che è praticamente ogni algoritmo che ci interessa), si può dimostrare che l'algoritmo può essere fatto non solo da una singola CPU core, ma in realtà un macchina a stati con un pezzo di nastro molto lungo per la memoria!

Il rilevatore di gara CHESS in realtà sfrutta questo per trovare i casi di gara. Esegue tutto singlethreaded ed esplora sistematicamente tutte le possibili interfacce tra i thread, cercando di trovare casi in cui un test fallisce a causa di un caso di gara. CHESS dipende dal fatto che è possibile eseguire qualsiasi applicazione multithread su un singolo core.

I casi in cui è necessario il multicore vengono visualizzati quando si inizia a estendere i limiti dell'hardware. Quello ovvio è quando hai vincoli di tempo. Alcuni problemi con vincoli di tempo in tempo reale sono impossibili da eseguire single core perché semplicemente non riescono a guidare l'orologio di un singolo core abbastanza velocemente. C'è un motivo per cui le CPU sono salite fino a 4 Ghz e poi si sono stabilizzate un po ', preferendo più core a velocità inferiori.

Una versione più esotica di questo vincolo di temporizzazione è nei sistemi in tempo reale. In alcuni sistemi in tempo reale difficile, il servizio di interrupt è così impegnativo che devi effettivamente scegliere una CPU multi-core che ti consenta di dividere gli interrupt su tutti i core o di incontrare limiti di temporizzazione.

Un altro limite sorge con i bus di dati. Considera il Blue Gene / P come esempio. JUGENE, un particolare supercomputer Blue Gene / P, ha 144 terabyte di memoria. Semplicemente non creano singoli computer CPU che possono accedere a tutta quella memoria.

Se devi osservare un processo in esecuzione su un singolo elemento di elaborazione senza disturbare il suo comportamento in tempo reale (o il meno possibile), come per il benchmarking o la registrazione delle attività, probabilmente avrai bisogno di una risorsa di elaborazione separata.

Le altre risposte aderiscono alla visione limitata del parallelismo come "concorrenza distribuita". Questo dà alcune risposte: in un modello pulito di calcolo alla Turing, più core non offrono alcun vantaggio; l'unico vantaggio che potresti ottenere è l'efficienza.

C'è i molteplici unità di elaborazione una cosa (PUS) possono fare che uno solo non può, però: eseguire operazioni in parallelo , che è allo stesso tempo .

Ciò è molto utile se si eseguono più programmi contemporaneamente. Certo, è solo raramente che tu abbia assolutamente bisogno di qualcosa di più dell'esecuzione simultanea e la maggior parte degli usi si riduce a una maggiore efficienza. Ma v'è questa differenza.

Supponiamo che tu debba elaborare i dati del sensore di dati da più fonti in tempo reale. Qualunque cosa significhi esattamente nella tua applicazione, una PU può gestire solo così tanti flussi di input contemporaneamente senza violare il suo limite di tempo di risposta. Quindi hai bisogno di più PU una volta che hai troppi sensori per la tua attuale generazione di PU.

$k$

$k$$k$$k$

da un punto di vista CS, "multicore" non è molto diverso in teoria dal "calcolo distribuito". il concetto di base è "elementi di calcolo indipendenti (che calcolano in parallelo". Quindi riformulare leggermente la domanda ("multicore" non è proprio un concetto teorico in CS) porta ad altre possibilità. Come sottolineato in altre risposte, la programmazione sequenziale è equivalente alla programmazione parallela da un punto di vista CS. questo risale alla definizione del sistema teorico per l'informatica, vale a dire una macchina di Turing. L'analisi teorica delle prestazioni CS è in definitiva in termini di TM in cui la distinzione tra parallelo e sequenziale non si applica realmente ( sebbene vi sia una certa analogia con le multitape TM ).

ma considerando questa domanda in modo meno astratto, il calcolo distribuito è davvero superiore o forse quasi addirittura richiesto per alcuni problemi che coinvolgono la tolleranza agli errori . in quest'area esiste un concetto che si applica quando / dove si ritiene che gli elementi di calcolo indipendenti abbiano un certo grado di inaffidabilità (questo non è in realtà un presupposto universalmente applicabile per tutti i contesti). qui ci sono diversi casi in cui la tolleranza agli errori è migliorata o richiede persino elementi di calcolo indipendenti.

• considera che ogni processore ha una probabilità "[x]%" indipendente di fallire durante il calcolo. un sistema può essere ideato in base al quale attraverso la comunicazione la tolleranza d'errore globale del sistema è superiore ai singoli componenti. questo è stato applicato molti decenni fa, ad esempio nei sistemi Space Shuttle. più recentemente ci sono protocolli di base progettati per utilizzarlo, ad esempio Paxos, che risolvono il cosiddetto problema del consenso . un esempio più concreto è Google che ha molti algoritmi proprietari per costruire essenzialmente i loro supercomputer da elementi individualmente inaffidabili accoppiati con algoritmi tolleranti ai guasti.

• Bitcoin implica transazioni distribuite per calcolare il libro mastro e ciò non è semplicemente dovuto a problemi di carico di elaborazione. l'algoritmo è progettato con cura per contrastare i nodi corrotti. in breve "risolve" / attua il problema dei generali bizantini che non si limita semplicemente a massimizzare le prestazioni parallele, implica entità indipendenti che "si controllano" a vicenda e "rifiutano algoritmicamente / crittograficamente / in modo sicuro" il rifiuto di calcoli non validi, ovvero una sorta di "imbroglio" o " corruzione".

• un'analisi classica del parallelismo conclude che esistono circa 7 tipi di schemi di problemi "fondamentali" che si decompongono in particolari interruzioni dell'esecuzione parallela. vedi Il panorama della ricerca informatica parallela: una vista da Berkeley

• c'è qualche elemento di una domanda teorica aperta qui rispetto alle considerazioni sulle prestazioni affrontate nella maggior parte delle altre risposte. la questione se ci siano problemi "intrinsecamente più veloci" in parallelo rispetto a quelli sequenziali è anche conosciuta approssimativamente come il problema P =? NC in cui NC è considerata la classe di algoritmi "parallelamente efficienti" e P è "algoritmi [sequenziali] efficienti "