Sono interessato a sapere se alcuni algoritmi comuni (ordinamento, ricerca, grafici, ecc.) Sono stati portati su OpenCL (o qualsiasi linguaggio GPU) e come il rendimento si confronta con lo stesso algoritmo eseguito dalla CPU. Sono specificamente interessato ai risultati (numeri).GPU rispetto alle prestazioni della CPU per algoritmi comuni
Grazie!
Ci sono quite a few samples di questo genere di cose sul sito Web di NVidia. Tieni presente che alcune cose come l'ordinamento richiedono speciali algoritmi per un parallelismo efficiente e potrebbero non essere altrettanto efficienti di un algoritmo senza thread su un singolo core.
Le GPU sono hardware altamente specializzati progettati per eseguire una piccola serie di attività molto bene e altamente parallelizzate. Questo è fondamentalmente aritmetico (in particolare matematica a virgola mobile a precisione singola anche se le GPU più recenti funzionano abbastanza bene con una precisione doppia). In quanto tali sono adatti solo a particolari algoritmi. Non sono sicuro che l'ordinamento si adatti a questa categoria (almeno nel caso generale).
Esempi più comuni sono la determinazione del prezzo di strumenti finanziari, grandi quantità di matematica a matrice e persino defeating encryption (per forza bruta). Detto questo, ho trovato Fast parallel GPU-sorting using a hybrid algorithm.
Un altro esempio comunemente citato è running [email protected] on an Nvidia GPU ma sta confrontando le mele con le arance. Le unità di lavoro per le GPU sono diverse (e molto limitate) rispetto a quelle ordinariamente utilizzate dalle CPU.
Dai un'occhiata alla thrust:
spinta è una libreria CUDA di paralleli algoritmi con un'interfaccia simile al C++ standard Template Library (STL). Thrust fornisce un'interfaccia ad alto livello flessibile per GPU che migliora notevolmente la produttività dello sviluppatore .
ATTENZIONE, MOLTO VITTO di qualsiasi numero di prestazioni indicato per GPGPU. Un sacco di persone piace postare numeri davvero impressionanti che non prendono in considerazione il tempo di trasferimento necessario per ottenere i dati di input dalla CPU alla GPU e i dati di output, entrambi andando su un collo di bottiglia PCIe.
Il ridimensionamento delle immagini deve essere comune su molti siti Web che accettano caricamenti di immagini.
Il ridimensionamento di un'immagine jpeg da 2 megabyte 2600ish x 2000ish (a 512x512) ha richiesto 23,5 millisecondi in C# con le opzioni di qualità più bassa e il campionamento del vicinato più vicino. La funzione usata era graphics.DrawImage() basata su uno. Anche l'utilizzo della CPU era% 21,5.
Ottenere l'estrazione "rgba byte array" sul lato C# e inviarlo a GPU e ridimensionare in GPU e ottenere i risultati in un'immagine ha richiesto 6,3 millisecondi e l'utilizzo della CPU era% 12,7. Questo è stato fatto con una gpu più economica% 55 con solo 320 core.
Solo moltiplicatore di accelerazione 3.73X.
Il fattore limitante è stato, inviando i dati rgb estratti di 20 MB (jpeg è solo 2 MB!) Alla GPU. Quella parte che consuma tempo era quasi 90% del tempo totale, inclusa l'estrazione di array di byte lato C#! Quindi penso che ci sarebbe circa 30X di accelerazione almeno se la parte di estrazione potrebbe essere fatta anche in GPU.
30X non è male.
Quindi è possibile eseguire la pipeline del livello di estrazione con il livello di ridimensionamento per nascondere la latenza della copia di memoria per ottenere ancora più velocità! Questo potrebbe essere 40X-50X.
Quindi aumentare la qualità del campionamento (ad esempio bicubico anziché il vicino più vicino), si ha ancora più vantaggio nel lato GPU. L'aggiunta di un filtro gaussiano 5x5 ha aggiunto solo 0,77 milliseilles. La CPU otterrebbe un tempo più elevato, soprattutto se i parametri gaussiani necessari sono diversi dall'implementazione C# .Net.
Anche se non siete soddisfatti con rapporto di accelerazione, scarico per GPU e con un "core libero" sulla CPU è ancora vantaggioso per la spinta di più lavoro per quel server.
Ora aggiungo il fatto dei livelli di consumo energetico della GPU (30 W rispetto a 125 W in questo esempio), è molto più vantaggioso.
CPU non poteva vincere in
C[i]=A[i]+B[i]
benchmark quando entrambe le parti eseguite su codici ottimizzati e si può ancora scaricare la metà degli array di GPU e finire più veloce utilizzando CPU + GPU allo stesso tempo.
GPU non è stato progettato per lavori non uniformi. Le GPU hanno condutture profonde, quindi stare in piedi dopo uno stallo a causa della ramificazione richiede troppo tempo. Anche l'hardware di tipo SIMD lo obbliga a fare la stessa cosa su tutti i workitems su di esso. Quando un workitem fa una cosa diversa rispetto al gruppo, perde traccia e aggiunge bolle all'intera pipeline SIMD o semplicemente altri attendono il punto di sincronizzazione. Quindi la brancing interessa sia le aree di pipeline profonde che quelle vaste e la rende ancora più lenta della CPU in condizioni perfettamente caotiche.
Anche Thrust ha appena rilasciato la versione 1.1. – Eric