Che futuro GPU hanno in informatica?[chiuso]

Question

La tua CPU potrebbe essere un quad-core, ma lo sapevate che alcune schede grafiche di oggi hanno più di 200 anime?Abbiamo già visto cosa GPU oggi le schede grafiche in grado di fare quando si tratta di grafica.Ora, essi possono essere utilizzati per i non-grafica compiti, e a mio parere i risultati sono a dir poco sorprendenti.Un algoritmo che si presta bene a parallelismo ha il potenziale per essere molto, molto più veloce su una GPU di quanto potrebbe mai essere su una CPU.

Ci sono alcune tecnologie che rendono possibile tutto questo:

1.) CUDA da NVidia.Sembra essere il più noto e ben documentato.Purtroppo, sarà solo lavorare su schede video NVidia.Ho scaricato l'SDK, provato alcuni dei campioni, e non c'è un sacco di roba che è stato fatto in CUDA.Ma il fatto che è limitata per le schede NVidia mi fa porre delle domande sul suo futuro.

2.) Stream da ATI.ATI equivalente a CUDA.Come ci si potrebbe aspettare, funziona solo con le schede ATI.

3.) OpenCL - Il Khronos Group ha messo insieme questo standard, ma è ancora nella sua infanzia fasi.Mi piace l'idea di OpenCL però.La speranza è che si dovrebbe essere supportato dalla maggior parte dei produttori di schede video e dovrebbe fare cross-scheda video di sviluppo che molto più facile.

Ma quali altre tecnologie per i non-grafica GPU di programmazione sono venuta, e ciò che mostra la promessa?E non si vede o ti piacerebbe vedere queste tecnologie in fase di realizzazione in alcuni dei principali framework di sviluppo quali .NET per rendere molto più facile?

Answer 1

Prevedo che questa tecnologia diventerà popolare e mainstream, ma ci vorrà del tempo per farlo. La mia ipotesi è di circa 5 a 10 anni.

Come annotato correttamente, uno dei principali ostacoli per l'adozione della tecnologia è la mancanza di una libreria comune che gira sulla maggior parte delle schede - sia ATI e nVidia. Fino a quando questo è risolto ad un livello accettabile, la tecnologia non entrerà mainstream e rimarrà nella nicchia di applicazioni su misura che girano su hardware specifico.

Per quanto riguarda l'integrazione con C # e altri linguaggi gestiti di alto livello - questo richiederà un po 'più a lungo, ma XNA dimostra già che shaders personalizzati e ambiente gestito possono mescolare insieme - in una certa misura. Naturalmente, il codice dello shader non è ancora in C #, e ci sono diversi importanti ostacoli a farlo.

Una delle principali ragioni per l'esecuzione rapida di codice GPU è che ha gravi limitazioni su ciò che il codice può e non può fare, e utilizza VRAM invece di solito RAM. Questo rende difficile riunire il codice della CPU e il codice della GPU. Mentre soluzioni alternative sono possibili, avrebbero in pratica negano il guadagno di prestazioni.

Una possibile soluzione che vedo è quello di fare un sub-lingua per C # che ha i suoi limiti, è compilato in codice della GPU, e ha un modo ristretto di comunicare con il codice ususal C #. Tuttavia, questo non sarebbe molto diverso da quello che abbiamo già - appena più a suo agio di scrivere a causa di qualche zucchero sintattico e funzioni della libreria standard. Eppure, anche questo è secoli di distanza, per ora.

Answer 2

Penso che si può contare il prossimo DirectX come un altro modo di utilizzare la GPU.

Dalla mia esperienza, le GPU sono estremamente veloci per gli algoritmi che sono facili da parallelizzare. Recentemente ho ottimizzato un'immagine speciale algoritmo di ridimensionamento in CUDA essere più di 100 volte più veloce sulla GPU (nemmeno una fascia alta uno) di un processore quad core Intel. Il problema è stato sempre i dati alla GPU e poi va a prendere il risultato di nuovo alla memoria principale, entrambe le direzioni limitata dalla velocità memcpy () su quella macchina, che era meno di 2 GB / s. Di conseguenza, l'algoritmo è stato solo leggermente più veloce rispetto alla versione della CPU ...

Quindi dipende davvero. Se si dispone di un'applicazione scientifica in cui è possibile mantenere la maggior parte dei dati sulla GPU, e tutti gli algoritmi di mappare a un'implementazione GPU, allora bene. Altrimenti avrei aspettato fino a quando c'è un tubo più veloce tra CPU e GPU, o vediamo cosa ATI ha le maniche con un chip combinato ...

A proposito, che la tecnologia da utilizzare: Penso che una volta che hai le tue cose in esecuzione in CUDA, il passo ulteriore di portarlo a OpenCL (o un'altra lingua) non è così grande. Hai fatto tutto il lavoro pesante parallelizzando algoritmi, e il resto è solo un 'sapore' diverso

Answer 3

Monte Carlo è imbarazzante parallelo, ma si tratta di una tecnica di base in informatica finanziaria e scientifica.

Uno degli intervistati è leggermente corretto dire che la maggior parte delle sfide del mondo reale non sono scomponibili facilmente in questi tipi di attività.

Molto indagine scientifica tractible avviene sfruttando ciò che può essere espresso in maniera imbarazzante parallelo.

Proprio perché si chiama "imbarazzante" parallelo non significa che non è un campo estremamente importante.

Ho lavorato in diverse case finanziarie, e noi forsee che siamo in grado di buttare fuori le aziende agricole di 1000+ motori Montecarlo (molte pile di lame allineate insieme) per diversi grandi installazioni NVIDIA CUDA - in maniera massiccia riduzione dei costi di alimentazione e di calore nel data center.

Un vantaggio significativo di architettura è che c'è molto meno carico di rete anche, come ci sono molto meno macchine che hanno bisogno di essere nutriti i dati e riferire i loro risultati.

Fondamentalmente però tali tecnologie sono ad un livello di astrazione più basso di un linguaggio di runtime gestito come C #, stiamo parlando di dispositivi hardware che eseguono il proprio codice sui propri processori.

L'integrazione deve prima essere fatto con Matlab, Mathematica mi aspetto, insieme con le API C, naturalmente ...

Answer 4

Un'altra tecnologia che sta arrivando per l'elaborazione basata su GPU è versioni GPU di librerie di calcolo di alto livello esistenti. Non molto appariscente, lo so, ma ha vantaggi significativi per codice portabile e la facilità di programmazione.

Per esempio, 2.0 SDK flusso di AMD comprende una versione del loro BLAS (algebra lineare) libreria con alcuni dei calcoli realizzati sulla GPU. L'API è esattamente lo stesso come la loro versione della CPU solo della biblioteca che hanno spediti per anni e anni; tutto ciò che serve è il ricollegamento l'applicazione, e utilizza la GPU e corre più veloce.

Allo stesso modo, Dan Campbell a GTRI ha lavorato su un'implementazione CUDA dello standard VSIPL per l'elaborazione del segnale. (In particolare, il tipo di segnale e di elaborazione delle immagini che è comune nei sistemi radar e attrattive correlati come imaging medicale.) Anche in questo caso, che è un'interfaccia standard e applicazioni che sono state scritte per implementazioni VSIPL su altri processori può semplicemente essere ricompilato con questo e utilizzare la capacità della GPU, se del caso.

In pratica, in questi giorni già un bel po 'di programmi numerici ad alte prestazioni non fanno la loro programmazione a basso livello, ma si basano su librerie. Su hardware Intel, se si sta facendo elaborazione di calcoli numerici, è generalmente difficile da battere le librerie matematiche Intel (MKL) per la maggior parte delle cose da essa svolte - e li utilizzano significa che è possibile ottenere i vantaggi di tutte le istruzioni vettoriali e trucchi intelligenti a processori x86 più recenti, senza dover specializzare il codice per loro. Con le cose come le GPU, ho il sospetto che questo diventerà ancora più diffuso.

Quindi penso che una tecnologia per guardare è lo sviluppo di librerie di general-purpose che formano i blocchi fondamentali di costruzione per applicazioni in settori specifici, in modo che le parti cattura di quegli algoritmi che possono essere inviati in modo efficiente off per la GPU, riducendo al minimo la quantità di non portabile intelligenza specifica per GPU richiesta da parte del programmatore.

(Bias disclaimer:! La mia azienda ha anche lavorato su una porta CUDA della nostra libreria VSIPL ++, quindi sono propenso a pensare che questo è una buona idea)

Inoltre, in una direzione completamente diversa, si potrebbe voler verificare alcune delle cose che RapidMind sta facendo. La loro piattaforma è stato inizialmente progettato per i sistemi multicore di tipo CPU, ma hanno fatto un bel po 'di lavoro che si estende ai calcoli GPU pure.

Answer 5

Praticamente tutto ciò che può essere in parallelo può essere in grado di trarre vantaggio. Esempi più specifici sarebbero SETI @ home, Folding @ home, e altri progetti distribuiti e calcolo scientifico.

soprattutto le cose che pesantemente si basano su aritmetica in virgola mobile. Questo perché le GPU sono specializzati circuito che è molto veloce a operazioni in virgola mobile. Ciò significa che la sua non come versatile, ma è molto bravo in quello che fa fare.

Se si desidera guardare elaborazione della GPU più dedicato, controlla Nvidia Tesla GPU . E 'una GPU, ma in realtà non hanno un'uscita monitor!

Dubito che vedremo troppo elaborazione della GPU sul desktop comuni, o almeno per un po ', perché non tutti hanno un CUDA o simile scheda grafica in grado, se hanno anche una scheda grafica a tutti. E 'anche molto difficile da rendere i programmi più parallele. Giochi potrebbero eventualmente utilizzare questo potere in più, ma sarà molto difficile e probabilmente non sarà troppo utile, dal momento che tutti i calcoli di grafica sono per lo più già sulla GPU e l'altro lavoro è sulla CPU e ha per essere sulla CPU a causa dei set di istruzioni.

elaborazione della GPU, almeno per un po ', sarà per i mercati di nicchia molto specifiche che hanno bisogno di un sacco di punto di calcolo floating.

Answer 6

E 'importante tenere a mente che anche i compiti che sono di serie intrinsecamente possono beneficiare di parallelizzazione se devono essere eseguite più volte in modo indipendente.

Inoltre, tenere a mente che ogni volta che qualcuno segnala l'aumento di velocità di un'implementazione GPU per un'implementazione di CPU, non è quasi mai un confronto equo. Per essere veramente onesti, gli esecutori devono prima passare il tempo per creare un, implementazione CPU parallelo veramente ottimizzato. Un singolo processore Intel Core i7 965 XE CPU può raggiungere circa 70 gigaflop in doppia precisione oggi. GPU di fascia alta attuali possono fare 70-80 gigaflop in doppia precisione e circa 1000 in singola precisione. Così un aumento di velocità di oltre 15 può implicare un'implementazione CPU inefficiente.

Un avvertimento importante con GPU Computing è che è attualmente "piccola scala". Con una struttura di supercalcolo, è possibile eseguire un algoritmo di parallelizzato su centinaia o addirittura migliaia di core di CPU. Al contrario, GPU "cluster" sono attualmente limitati a circa 8 GPU collegati ad una macchina. Naturalmente, molti di queste macchine possono essere combinate insieme, ma questo aggiunge ulteriore complessità i dati non devono solo passare tra computer, ma anche tra le GPU. Inoltre, non v'è ancora un equivalente MPI che permette i processi in modo trasparente scalabili in più GPU su più macchine; esso deve essere attuato manualmente (eventualmente in combinazione con MPI).

Oltre a questo problema di scala, l'altro grande limitazione delle GPU per il calcolo parallelo è rigorosa restrizione su modelli di accesso alla memoria. è possibile l'accesso alla memoria a caso, ma l'accesso alla memoria pianificato con cura si tradurrà in molte volte migliori prestazioni.

Forse il prossimo concorrente più promettente è Larrabee di Intel. Ha decisamente migliore accesso alla CPU, memoria di sistema, e, forse più importante, la memorizzazione nella cache. Questo dovrebbe dare notevoli vantaggi con molti algoritmi. Se non può corrispondere la larghezza di banda di memoria di massa su GPU attuali, però, può essere ritardo rispetto alla concorrenza per gli algoritmi che usano in modo ottimale questa larghezza di banda.

L'attuale generazione di hardware e software richiede un grande sforzo di sviluppo per ottenere prestazioni ottimali. Questo spesso include algoritmi di ristrutturazione di fare uso efficiente della memoria GPU. E 'anche spesso implica la sperimentazione di approcci diversi per trovare la migliore.

Si noti inoltre che lo sforzo richiesto per ottenere prestazioni ottimali è necessario per giustificare l'uso di hardware della GPU. La differenza tra un'implementazione naif e un'implementazione ottimizzata può essere un ordine di grandezza o più. Ciò significa che un impelemntation CPU ottimizzata sarà probabilmente come buono o addirittura meglio di un'implementazione GPU ingenuo.

La gente sta già lavorando su legature .NET per CUDA. Vedere qui . Tuttavia, con la necessità di lavorare a un livello basso, non credo GPU Computing è pronto per le masse ancora.

Answer 7

Ho sentito un gran parlare di trasformare quello che oggi sono GPU in più general-purpose "unità dell'array proceesor", da utilizzare con qualsiasi di matrice matematica problema, piuttosto che solo di elaborazione grafica. Non ho visto molto venire di esso ancora però.

La teoria era che i processori matriciali possono seguire approssimativamente la stessa traiettoria che galleggiano punti processori seguito un paio di decenni prima. Originariamente processori a virgola mobile erano costosi add-on opzioni per PC che non un sacco di gente la briga di acquistare. Alla fine sono diventati così vitale che essi sono stati messi dentro la CPU stessa.

Answer 8

Ti ripeto la risposta che ho dato qui.

A lungo termine credo che la GPU cesserà di esistere, come i processori general purpose evolvono per assumere tali funzioni. Larrabee di Intel è il primo passo. La storia ha dimostrato che scommettere contro x86 è una cattiva idea.

Answer 9

GHC (Haskell), i ricercatori (che lavorano per Microsoft Research) stanno aggiungendo il supporto per nidificati dati parallelismo direttamente ad un linguaggio di programmazione general purpose. L'idea è quella di utilizzare più core e / o GPU sull'estremità posteriore ancora esporre dati file parallele come tipo nativo nel linguaggio, indipendentemente dal runtime eseguendo il codice in parallelo (o seriale per il fallback singolo-CPU).

http://www.haskell.org/haskellwiki/GHC/Data_Parallel_Haskell

A seconda del successo di questo nei prossimi anni, mi sarei aspettato di vedere altri linguaggi (C # in particolare) prendere l'idea, che potrebbe portare questo tipo di funzionalità ad un pubblico più mainstream. Forse a quel punto la larghezza di banda e dei driver questioni CPU-GPU saranno risolti.

Answer 10

GPU lavorare bene in problemi in cui v'è un elevato livello di dati a livello di parallelismo , che significa essenzialmente non v'è un modo per suddividere i dati da elaborare tale che essi possono essere elaborati.

Le GPU non sono intrinsecamente più veloce a livello velocità di clock. In realtà io sono relativamente sicuro che la velocità di clock sulle shader (o forse hanno un termine GPGPU più per loro in questi giorni?) È piuttosto lento rispetto alla ALU su un moderno processore desktop. Il fatto è che, una GPU ha una quantità assolutamente enorme di questi shader, trasformando la GPU in un un grande processori SIMD . Con la quantità di shader su una Geforce moderna, per esempio, è possibile che una GPU di essere al lavoro su diverse centinaia (migliaia?) Galleggianti numeri in virgola in una sola volta.

così breve, una GPU può essere incredibilmente veloce per i problemi in cui è possibile partizionare i dati correttamente e elaborare le partizioni in modo indipendente. Non è così potente a Task (thread) Livello parallelismo .

Answer 11

Un grosso problema con la tecnologia GPU è che, mentre si ha un sacco di capacità di elaborazione in là, ottenendo i dati in (e fuori di esso) è terribile (performance-saggio). E guardare con attenzione per eventuali benchmark di confronto ... si confronta spesso gcc (con l'ottimizzazione minimo, senza vettorializzazione) su un singolo sistema processore per la GPU.

Un altro grosso problema con la GPU della è che se non si ATTENTAMENTE pensa a come è organizzato i dati, si soffre di una vera e propria performance hit internamente (nella GPU). Ciò comporta spesso riscrittura codice molto semplice in un mucchio contorto di errore.

Answer 12

Sono molto entusiasta di questa tecnologia. Tuttavia, penso che questo non farà che aggravare la vera sfida di grandi task paralleli, uno di larghezza di banda. Aggiungendo più core aumenterà solo contesa per la memoria. OpenCL e altre librerie GPGPU astrazione non offrono strumenti per migliorare questo.

qualsiasi piattaforma hardware calcolo ad alte prestazioni di solito è progettato con l'emissione di larghezza di banda attentamente pianificato nell'hardware, bilanciando il throughput, la latenza, il caching e il costo. Finché commodity hardware, CPU e GPU di, sono progettati in modo isolato gli uni degli altri, con larghezza di banda ottimizzata solo alla loro memoria locale, sarà molto difficile migliorare questo per gli algoritmi che ne hanno bisogno.

Answer 13

Proprio vero che la Gpu può ottenere molto hi performance numeri dati a livello di parallelismo situazioni, come molti qui menzionati.Ma per come la vedo io, non c'è molto in spazio utente ora.Non posso fare a sensazione che tutto questo GPGPU propaganda viene da GPU produttori, che vogliono trovare nuovi mercati e usi per i loro prodotti.E questo è assolutamente ok.Vi siete mai chiesti perché intel/amd non includere alcuni mini-core x86, oltre a quelle standard (diciamo - modello con quattro core x86 e 64 mini-x86-core), solo per aumentare il livello di dati paralelism funzioni ?Sono sicuramente in grado di farlo, se voleva.La mia ipotesi è che l'industria è solo bisogno di quel tipo di potenza di elaborazione desktop normale/macchine server.

Answer 14

GPU può o non può rimanere così popolare come lo sono ora, ma l'idea di base sta diventando un approccio piuttosto popolare per l'elaborazione ad alta potenza. Una tendenza che sta arrivando ora è il "acceleratore" esterna per aiutare la CPU con grandi lavori decimali. Una GPU è solo un tipo di acceleratore.

Intel sta rilasciando un nuovo acceleratore chiamato il Xeon Phi , che stanno sperando in grado di sfidare la GPU come acceleratore HPC. Il processore rel="nofollow"> cellulare ha adottato un approccio simile, avendo una CPU principale per fare i compiti generali, e scaricando calcolare attività ad alta intensità di alcuni altri elementi di elaborazione, ottenendo alcune velocità impressionanti.

Gli acceleratori, in generale, sembrano essere di interesse in questo momento, in modo che dovrebbe essere intorno per un po 'almeno. O se non la GPU rimane come l'acceleratore di fatto, resta da vedere.

Answer 15

La vostra percezione che le GPU sono più veloci CPU si basa sul malinteso creato da alcune applicazioni embarassingly parallele applicate del calibro di PS3, NVIDIA e ATI hardware.

http://en.wikipedia.org/wiki/Embarrassingly_parallel

La maggior parte delle sfide del mondo reale non sono scomponibili facilmente in questi tipi di attività. La CPU desktop è modo più adatto per questo tipo di sfida sia da un set di funzionalità e prestazioni punto di vista.

Answer 16

Mi aspetto le stesse cose che le CPU sono usati per?

Voglio solo dire questo mi sembra un espediente per me. Ho esitato a dire "che sta andando da nessuna parte", quando si tratta di tecnologia, ma la funzione primaria GPU è rendering grafico e la funzione primaria CPU è tutta altra elaborazione. Avere la GPU fare altro sembra proprio sgargianti.