Il miglior approccio per GPGPU / CUDA / OpenCL in Java?

94

Il calcolo generico su unità di elaborazione grafica ( GPGPU ) è un concetto molto interessante per sfruttare la potenza della GPU per qualsiasi tipo di elaborazione.

Mi piacerebbe usare GPGPU per l'elaborazione di immagini, particelle e operazioni geometriche veloci.

In questo momento, sembra che i due contendenti in questo spazio siano CUDA e OpenCL. Mi piacerebbe sapere:

  • OpenCL è ancora utilizzabile da Java su Windows / Mac?
  • Quali sono i modi delle biblioteche per interfacciarsi con OpenCL / CUDA?
  • Usare JNA direttamente è un'opzione?
  • Sto dimenticando qualcosa?

Qualsiasi esperienza / esempi / storie di guerra del mondo reale sono apprezzati.

java  cuda  gpgpu  opencl 
— Frederik
fonte
1
Immagino che programmare GPU in Java sarebbe difficile, considerando quanto uso i puntatori nella programmazione cuda. Non so se ci sarebbe stato molto vantaggio nell'usare Java nella programmazione del dispositivo, dal momento che è improbabile che siano implementate funzionalità / librerie Java complete che differenziano Java da C ++
— Anycorn
2
Ho visto alcune demo Java impressionanti che utilizzavano GLSL e probabilmente CUDA, quindi è certamente possibile.
— Frederik
1
Hai controllato jcuda.org e jocl.org?
— Bakkal
1
Li conosco, ma non posso giudicare la qualità. Hai qualche esperienza con loro?
— Frederik
4
@ Nils: ed è per questo che vuole spingere tutti i numeri sulla GPU ... Comunque, anche il semplice C o x86 asm avrebbe un compito difficile per competere con enormi processori paralleli di dati come le GPU.
— Stringer

Risposte:

62

AFAIK, JavaCL / OpenCL4Java è l'unico binding OpenCL disponibile su tutte le piattaforme in questo momento (inclusi MacOS X, FreeBSD, Linux, Windows, Solaris, tutti nelle varianti Intel 32, 64 bit e ppc, grazie al suo utilizzo di JNA ).

Ha demo che in realtà funzionano bene da Java Web Start almeno su Mac e Windows (per evitare arresti anomali casuali su Linux, vedere questa pagina wiki , come questa Demo di Particles .

Inoltre viene fornito con alcune utilità (generazione di numeri casuali GPGPU, riduzione parallela di base, algebra lineare) e un DSL Scala .

Infine, è il binding più vecchio disponibile (da giugno 2009) e ha una comunità di utenti attiva .

(Disclaimer: sono l'autore di JavaCL :-))

— zOlive
fonte
Oh, ero così eccitato per il JNLP, ma a quanto pare non mi piace il mio macbook. Questo per quanto riguarda la multipiattaforma.
— Karl
5
@Karl Oh scusa, ho rotto il JNLP (il JAR ha recentemente cambiato nome)! Ora è stato risolto, spero che ci riproverai ... (e dal punto di vista multipiattaforma: è stato rotto in modo coerente su tutte le piattaforme ;-))
— zOlive
3
Il recente rafforzamento della sicurezza di Java 7 ha causato il fallimento di Particle Demo Web Start con un'eccezione.
— Thorbjørn Ravn Andersen
@zOlive L'ultimo collegamento JavaCl al codice Google non è più disponibile.
— tryman
34

Puoi anche considerare Aparapi . Ti consente di scrivere il codice in Java e tenterà di convertire il bytecode in OpenCL in fase di esecuzione.

Divulgazione completa. Sono lo sviluppatore Aparapi.

— gfrost
fonte
Aparapi è ancora mantenuto?
— Mr Jedi
@MrJedi: Penso di sì, l'ultimo commit su GitHub ha solo pochi giorni: github.com/aparapi/aparapi
— Aydin K.
È "in qualche modo mantenuto";) Sono un manutentore.
— barneypitt
12

Bene CUDA è una modifica di C, per scrivere il kernel CUDA devi codificare in C, e poi compilare in forma eseguibile con il compilatore CUDA di nvidia. Il codice nativo prodotto potrebbe quindi essere collegato a Java utilizzando JNI. Quindi tecnicamente non puoi scrivere il codice del kernel da Java. Esiste JCUDA http://www.jcuda.de/jcuda/JCuda.html , fornisce le API di cuda per la gestione generale della memoria / dispositivo e alcuni metodi Java implementati in CUDA e JNI wrapping (FFT, alcuni metodi di algebra lineare .. ecc ecc ..).

D'altra parte OpenCL è solo un'API. I kernel OpenCL sono semplici stringhe passate all'API, quindi utilizzando OpenCL da Java dovresti essere in grado di specificare i tuoi kernel. Il binding OpenCL per java può essere trovato qui http://www.jocl.org/ .

— Ivan
fonte
2
se JNA ( jna.dev.java.net ) è supportato sulla tua piattaforma, lo userei per invocare il codice nativo, poiché è molto meno impegnativo rispetto alla codifica di una libreria JNI.
— mdma
11

Sto usando JOCL e ne sono molto soddisfatto.

Il principale svantaggio di OpenCL su CUDA (almeno per me) è la mancanza di librerie disponibili (Thrust, CUDPP, ecc.). Tuttavia CUDA può essere facilmente portato su OpenCL, e osservare come funzionano queste librerie (algoritmi, strategie, ecc.) È davvero molto bello perché impari molto con esso.

— halfwarp
fonte
7

So che è tardi ma dai un'occhiata a questo: https://github.com/pcpratts/rootbeer1

Non ci ho lavorato ma sembra molto più facile da usare rispetto ad altre soluzioni.

Dalla pagina del progetto:

Rootbeer è più avanzato di CUDA o OpenCL Java Language Bindings. Con le associazioni lo sviluppatore deve serializzare grafici complessi di oggetti in array di tipi primitivi. Con Rootbeer questo viene fatto automaticamente. Anche con i collegamenti del linguaggio, lo sviluppatore deve scrivere il kernel della GPU in CUDA o OpenCL. Con Rootbeer viene eseguita un'analisi statica del Bytecode Java (utilizzando Soot) e il codice CUDA viene generato automaticamente.

— karl
fonte
1

Se vuoi eseguire l'elaborazione delle immagini o operazioni geometriche, potresti volere una libreria di algebra lineare con supporto gpu (con CUDA per esempio). Ti suggerirei che la strega ND4J è l'algrebra lineare con supporto GPU CUDA su cui è costruito DeepLearning4J. Con questo non devi avere a che fare direttamente con CUDA e devi avere un codice di basso livello in c. Inoltre, se vuoi fare più cose con l'immagine con DL4J avrai accesso a specifiche operazioni di elaborazione delle immagini come la convoluzione.

— Guillaume Surroca
fonte
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.