Futuro di OpenCL?

Il paradigma di programmazione OpenCL promette di essere uno standard aperto senza royalty per il calcolo eterogeneo. Dovremmo investire il nostro tempo nello sviluppo di software basato su OpenCL? Vantaggi svantaggi?

La domanda è troppo ampia e vaga per essere veramente risolta. Tuttavia, vedo un punto notevole contro OpenCL, dal punto di vista dell'informatica scientifica, che raramente viene enfatizzato. Finora, non vi è stato alcuno sforzo per produrre librerie di infrastrutture open source per OpenCL, mentre CUDA ha diverse eccellenti opzioni:

• CUBLAS , CUFFT , CUSPARSE
• Spinta , cuspide , OpenCurrent
• Supporto PETSc

Credo che questo danneggerà davvero OpenCL poiché un importante facilitatore dell'adozione sono librerie aperte di alta qualità.

OpenCL vs cosa?

Se la domanda è OpenCL vs CUDA, vedo un sacco di domande su questa domanda, e mi sembra folle. Non importa Onesto. I kernel - dove deve andare tutto il pensiero duro - sono praticamente identici tra le due lingue; potresti scrivere macro per il tuo editor preferito per fare il 99% del lavoro per rimbalzare tra OpenCL e CUDA. Deve essere così; sono un controllo a basso livello di hardware alla fine abbastanza simile. Dopo aver capito come scrivere i tuoi kernel importanti in {OpenCL, CUDA}, è banale portarli su {CUDA, OpenCL}.

Anche il codice host del plateplate che devi scrivere è simile, ma CUDA semplifica i casi semplici. Ecco perché insegniamo a CUDA nel nostro centro; puoi saltare direttamente alla scrittura del codice del kernel, mentre dovremmo passare 1-2 ore del nostro corso di una giornata spiegando semplicemente le cose di lancio del kernel per OpenCL.

Ma anche lì la differenza non è così importante; una volta che inizi a fare cose più complicate (kernel asincroni su più gpus), sono entrambi ugualmente complicati e di nuovo puoi praticamente fare una traduzione riga per riga dall'una all'altra.

Se si tratta di OpenCL rispetto agli approcci basati sulla direttiva - OpenACC o HMPP o qualcosa del genere - quelli probabilmente (si spera?) Saranno in futuro buoni modi per programmare questo tipo di architetture, dove è possibile ottenere il 90% delle prestazioni per 10% del lavoro. Ma quale scelta "vincerà" resta da vedere e non consiglierei di passare molto tempo a lavorare con quelli ancora.

Quindi direi che tra CUDA o OpenCL scegli una lingua che è conveniente per te e la usi, e non preoccuparti troppo. La parte preziosa - capire come scomporre il problema in codice SIMD massicciamente parallelo per piccoli core con pochissima memoria - sarà facilmente trasportabile tra i modelli di programmazione.

Se stai usando l'hardware NVIDIA - e probabilmente lo sei - allora in genere raccomando CUDA - il punto di Matt Knepley sulle librerie è morto. Se non lo sei, allora OpenCL.

Se dovresti investire il tuo tempo nello sviluppo di software basato su OpenCL è una domanda a cui solo tu puoi rispondere. Se sembra che abbia il potenziale per risolvere i problemi che stai affrontando in questo momento, e nessun'altra soluzione aperta lo fa, il tuo miglior modo di agire è probabilmente correre un rischio sull'implementazione di un piccolo progetto con esso.

Se ciò va bene, puoi provarlo con progetti più grandi e così via fino a quando non hai abbastanza fiducia per standardizzare su di esso, o scartalo a favore di un'altra soluzione (che potrebbe essere la tua soluzione proprietaria, un'altra soluzione aperta o persino un'altra soluzione proprietaria).

La cosa meravigliosa del movimento open source è che, poiché hai la fonte, hai tutto il necessario per biforcare il progetto, se necessario. Anche se la stessa comunità non ti offre le strutture di cui hai bisogno, non c'è nulla che ti impedisca di implementare queste strutture da solo. Inoltre, se volevi quelle strutture, c'è una chiara possibilità che altri utenti possano desiderarle, quindi ti sarei grato se contribuissi a quelle modifiche al progetto principale.

Non solo, ma se lo rendi migliore dal tuo punto di vista, potrebbe renderlo migliore per gli altri, incoraggiarli a presentare i propri miglioramenti e alla fine rendere il software migliore per tutti.

Infine, sì, questa è una risposta piuttosto generica a una domanda piuttosto generica. Per rispondere in modo più completo, dobbiamo sapere quali sono le tue preoccupazioni su OpenCL. È maturità? Supporto comunitario? Facilità d'uso? Tempo necessario per imparare? È tempo di svilupparsi? Stai cambiando le tue procedure? Quando chiedi dei pro e contro, a quali altri prodotti stai tentando di confrontare OpenCL ? Che ricerca hai già fatto? Di quali funzionalità hai bisogno per supportare il tuo ambiente informatico eterogeneo?

Un grande PRO è il numero di fornitori dietro OpenCL. Ho una certa esperienza aneddotica a riguardo, avendo incontrato un gruppo di ricerca che ha speso molto tempo e sforzi per sviluppare un codice CUDA abbastanza complicato per un sistema alimentato da NVIDIA. Un anno dopo lo sviluppo del codice, il gruppo di ricerca ha avuto accesso a un sistema AMD più grande e più veloce, ma non è stato possibile utilizzarlo poiché non disponeva delle risorse (umane) per il porting del codice.

Anche se il set di funzionalità di base di CUDA e OpenCL è quasi identico (come ben sottolineato da @JonathanDursi), se lo sviluppatore originale non è quello assegnato al compito di convertire il codice, l'intero progetto di porting può richiedere molto tempo.

Tuttavia, ci sono alcune incompatibilità ufficiali tra CUDA e OpenCL. In particolare, CUDA supporta i modelli c ++ mentre OpenCL non li supporta ancora ufficialmente. Tuttavia, AMD sta compiendo uno sforzo per sviluppare un'estensione di OpenCL con supporto per modelli e altre funzionalità C ++, maggiori informazioni in questo post da AMD dev central . Spero che una futura revisione di OpenCL possa aggiungere questo lavoro.

A questo punto (inizio 2012), le fantastiche librerie a cui @MattKnepley si collega sono modelli chiusi o utilizzano modelli, quindi non saranno disponibili per hardware diverso da NVIDIA, almeno nel frattempo.

Per qualcuno che sta imparando gpu-computing, direi che OpenCL C può essere piuttosto difficile, poiché ci sono molti dettagli che distraggono lo studente dalle idee di base, mentre CUDA è più semplice e diretto. Tuttavia, ci sono strumenti che rendono OpenCL molto più semplice da imparare e usare come PyOpenCL (il wrapper python per opencl) che porta tutto lo zucchero python su OpenCL (nota che esiste anche un PyCUDA). Ad esempio, la demo di PyOpenCL per l'aggiunta di due array ha poco meno di 25 righe e include: creazione di array su host e dispositivo, trasferimenti di dati, creazione di contesto e coda, kernel, come costruire ed eseguire il kernel , ottenendo i risultati dalla GPU e confrontandoli con numpy (vedi link sotto).

PyOpenCL - http://mathema.tician.de/software/pyopencl

PyCUDA - http://mathema.tician.de/software/pycuda

Per programmatori esperti di gpu, qui sono d'accordo con @JonathanDursi, CUDA e OpenCL sono fondamentalmente uguali e non ci sono davvero differenze tra i sindaci. Inoltre, il duro lavoro di sviluppo di un algoritmo efficiente per le GPU è molto indipendente dal linguaggio, e il supporto OpenCL da parte dei fornitori e la documentazione è ora molto più maturo di quanto affermi 2 anni fa. L'unico punto che fa ancora la differenza è che NVIDIA sta davvero facendo un ottimo lavoro con il loro supporto alla comunità CUDA.

OpenCL ha l'ulteriore vantaggio che può funzionare su CPU ed è già supportato da Intel e AMD. Quindi non è necessario modificare il framework algoritmico se si desidera sfruttare i core della CPU disponibili. Non credo che OpenCL sia la migliore soluzione per una singola applicazione orientata alla CPU / multicore poiché un kernel ottimizzato per CPU potrebbe apparire significativamente diverso da un kernel ottimizzato per GPU. Tuttavia, nella mia esperienza, lo sviluppo di CODE beneficia della capacità di funzionare sulla CPU.

Penso che OpenCL stia attualmente soffrendo della mancanza di un "campione". Ad esempio, se visiti il ​​sito NVIDIA in questo momento (16/12/2011), nella pagina iniziale sono presenti numerosi scatti in stile "Ken Burns Effect" incentrati sul lato scientifico / industriale dell'informatica GPU e ~ 1 / La quarta delle tue opzioni di navigazione ti indirizza verso cose che probabilmente finiranno al CUDA. I produttori che vendono server e workstation "GPU computing" vendono soluzioni NVIDIA.

Le offerte concorrenti di ATI si confondono con il sito AMD generale, più difficile da trovare e non così pesantemente descritto in soluzioni di terze parti. Quelle soluzioni e la capacità di eseguire la programmazione basata su OpenCL certamente esistono, ma è rimasta una percezione - almeno nella mia mente, ma nella mente di altre persone con cui ho parlato - che i grandi sponsor aziendali della piattaforma OpenCL hanno già " uscire dal campo ". Le persone che usano OS X, ad esempio, sono probabilmente troppo impegnate a speculare sull'esistenza o meno di una workstation Apple in un anno per avere fiducia in esse che spingono il computing GPU OpenCL.

Il fattore più importante è che CUDA rimarrà supportato solo dall'hardware NVIDIA.

Pertanto, se si desidera creare software robusto e portatile, OpenCL è l'unica opzione. Al massimo puoi costruire attorno ad alcune librerie attualmente basate su CUDA e sperare che vengano estese su OpenCL in futuro tirando con te il tuo codice.