Spinta per la programmazione GPU

Sono molto nuovo nella programmazione GPGPU, quindi ti prego di perdonarmi se la domanda non è particolarmente appropriata. Da quello che ho capito la programmazione GPU è un lavoro di ingegneria molto complicato rispetto alla normale programmazione della CPU. Bisogna stare molto attenti a problemi di divergenza, piastrellatura, allocazione di memoria appuntata e sovrapposizione di calcolo dispositivo / comunicazione host-dispositivo.

Dopo aver fatto un po 'di ricerca, ho trovato la libreria di spinta che sembra provare a imitare il C ++ STL. Questo è abbastanza carino Tuttavia, in base alla mia esperienza molto limitata e dopo aver visto tutta la micro-gestione richiesta per ottenere buone prestazioni, sono un po 'scettico riguardo alle prestazioni. Può gestire efficacemente tutta la parte di programmazione complessa internamente? Alcune librerie molto note, come PETSc, sembrano usare questo pacchetto che mi fa credere che in qualche modo dovrebbe.

Mi chiedevo se le persone con più esperienza su CUDA e fiducia potessero dire una parola o due sulle prestazioni del pacchetto rispetto alla programmazione CUDA di basso livello. Quando posso usare la spinta e quando devo tornare a CUDA?

Non ho esperienza personale con la spinta, ma uso ViennaCL, che è un'altra libreria GPU di alto livello che nasconde quasi tutti i dettagli. Dal mio benchmark personale posso vedere accelerazioni di 2x - 40x sul calcolo effettivo se ignori il tempo necessario per spostarsi nella memoria.

Quando dovresti usare la CPU contro la spinta contro la CUDA tutto dipende dal problema che stai risolvendo, dalle tue abilità e dal tempo che hai a disposizione. Consiglierei di iniziare risolvendo problemi semplici con tutti e 3 i metodi per vedere le loro prestazioni relative. Quindi puoi scrivere il tuo vero software in modo rapido, confrontarlo e applicare il metodo gpu appropriato nelle aree che richiedono l'accelerazione, piuttosto che perdere tempo a scrivere software CUDA che ti farà guadagnare solo un paio di minuti di tempo di esecuzione .

Ho usato Thrust nel mio progetto di espansione del cluster collegato. A seconda della situazione, Thrust è in grado di eseguire sia meglio che un'implementazione di basso livello che esegui tu stesso (in particolare, il reducekernel ha funzionato abbastanza bene per me). Tuttavia, la natura e la flessibilità generiche di Thrust fanno sì che a volte debba fare molte copie extra, riempimento di array, ecc., Che può rallentarlo un po 'in alcuni casi difficili. L'ultima volta che l'ho usato sortè stato piuttosto lento rispetto ad altre librerie come b40c o mgpu. Tuttavia, NVIDIA ha lavorato per migliorare le prestazioni algoritmiche di Thrust in modo che in futuro ciò possa rappresentare un problema minore.

Dovresti provare a scrivere il tuo codice utilizzando sia Thrust che CUDA e quindi utilizzare Visual Profiler per determinare quale sia la soluzione migliore per l'attività specifica che ti interessa. Se è probabile che il trasferimento di memoria occupi la maggior parte del tempo di esecuzione del tuo programma e tu don non voglio preoccuparmi di ottimizzare i tuoi kernel per conflitti bancari, conteggio delle istruzioni, ecc. quindi userei Thrust. Ha anche il vantaggio di rendere il tuo codice molto meno dettagliato e più facile da leggere per le persone che non hanno familiarità con la programmazione della GPU.

Lo scopo di thrust (come la maggior parte delle librerie di template) è quello di fornire un'astrazione di alto livello, preservando nel contempo prestazioni buone o addirittura eccellenti.

Suggerirei di non preoccuparti troppo delle prestazioni, ma di chiederti se

• l'applicazione può essere descritta in termini di algoritmi implementati in spinta e if

• ti piace la possibilità di scrivere codice parallelo "generico", senza la necessità di entrare nei dettagli cruenti di trovare una mappatura efficiente per la data architettura hardware / software.

Se rispondi positivamente a entrambe le domande, dovresti essere in grado di implementare il tuo programma con meno sforzi rispetto all'implementazione di CUDA. Quindi puoi profilare la tua applicazione e decidere se vale la pena provare a migliorare le prestazioni.

Detto questo, devo confessare che non mi piace la programmazione "generica", perché sono disposto a imparare qualcosa di nuovo quando scrivo un programma. Seguirei un'altra strada: scrivere un'implementazione prototipo in python + numpy + scipy, quindi aggiungere i kernel CUDA per l'1% - 2% del codice che necessita davvero di ottimizzazione ed è adatto per essere eseguito su una GPU. Ovviamente facendo ciò è necessaria una sorta di pre-scienza, poiché una decisione sbagliata nella fase di prototipazione (ad esempio una struttura di dati non adatta per i kernel CUDA) può avere risultati terribili sulle prestazioni. Di solito sono necessarie più iterazioni per ottenere un buon codice e non vi è alcuna garanzia di fare meglio della spinta.