¿El mejor enfoque para GPGPU / CUDA / OpenCL en Java?

94

La computación de propósito general en unidades de procesamiento de gráficos ( GPGPU ) es un concepto muy atractivo para aprovechar la potencia de la GPU para cualquier tipo de computación.

Me encantaría usar GPGPU para procesamiento de imágenes, partículas y operaciones geométricas rápidas.

En este momento, parece que los dos contendientes en este espacio son CUDA y OpenCL. Me gustaría saber:

  • ¿Se puede utilizar OpenCL desde Java en Windows / Mac?
  • ¿Cuáles son las formas de las bibliotecas para interactuar con OpenCL / CUDA?
  • ¿Usar JNA directamente es una opción?
  • ¿Me estoy olvidando de algo?

Se agradece cualquier experiencia / ejemplo / historia de guerra del mundo real.

java cuda gpgpu opencl Frederik
fuente
1
Me imagino que programar GPU en Java sería difícil, considerando cuánto uso punteros en la programación cuda. No sé si sería muy beneficioso usar Java en la programación de dispositivos, ya que es poco probable que tenga implementadas las funciones / bibliotecas completas de Java que diferencian a Java de C ++
Anycorn
2
He visto algunas demostraciones impresionantes de Java que usaban GLSL y probablemente CUDA, así que ciertamente es posible.
Frederik
1
¿Revisó jcuda.org y jocl.org?
bakkal
1
Los conozco, pero no puedo juzgar la calidad. ¿Tienes alguna experiencia con ellos?
Frederik
4
@Nils: y es por eso que quiere impulsar todo el procesamiento de números en la GPU ... De todos modos, incluso el asm simple C o x86 tendría una tarea difícil para competir contra procesadores paralelos de datos masivos como las GPU.
Stringer

Respuestas:

62

AFAIK, JavaCL / OpenCL4Java es el único enlace OpenCL que está disponible en todas las plataformas en este momento (incluyendo MacOS X, FreeBSD, Linux, Windows, Solaris, todo en Intel 32, 64 bits y variantes ppc, gracias a su uso de JNA ).

Tiene demostraciones que realmente funcionan bien desde Java Web Start al menos en Mac y Windows (para evitar bloqueos aleatorios en Linux, consulte esta página wiki , como esta Demostración de partículas .

También viene con algunas utilidades (generación de números aleatorios GPGPU, reducción paralela básica, álgebra lineal) y un Scala DSL .

Finalmente, es la vinculación más antigua disponible (desde junio de 2009) y tiene una comunidad de usuarios activa .

(Descargo de responsabilidad: soy el autor de JavaCL :-))

zOlive
fuente
Oh, estaba tan emocionado por el JNLP, pero aparentemente no le gusta mi macbook. Tanto para multiplataforma.
Karl
5
@Karl ¡Lo siento, rompí el JNLP (el JAR cambió de nombre recientemente)! Eso ahora está arreglado, espero que lo intente de nuevo ... (y multiplataforma: se rompió constantemente en todas las plataformas ;-))
zOlive
3
El reciente ajuste en la seguridad de Java 7 hace que Particle Demo Web Start falle con una excepción.
Thorbjørn Ravn Andersen
@zOlive El último enlace JavaCl al código de Google ya no está disponible.
tryman
34

También puede considerar Aparapi . Le permite escribir su código en Java e intentará convertir el código de bytes a OpenCL en tiempo de ejecución.

La divulgación completa. Soy el desarrollador de Aparapi.

gfrost
fuente
¿Se mantiene aparapi?
Mr Jedi
@MrJedi: Creo que sí, la última confirmación en github tiene solo unos días de antigüedad: github.com/aparapi/aparapi
Aydin K.
Está "algo mantenido";) Soy un mantenedor.
barneypitt
12

Bueno, CUDA es una modificación de C, para escribir el kernel de CUDA tienes que codificar en C y luego compilar en forma ejecutable con el compilador CUDA de nvidia. El código nativo producido podría vincularse con Java mediante JNI. Entonces, técnicamente, no puede escribir código del kernel desde Java. Existe JCUDA http://www.jcuda.de/jcuda/JCuda.html , le proporciona las apis de cuda para la gestión general de memoria / dispositivo y algunos métodos Java que se implementan en CUDA y JNI envuelto (FFT, algunos métodos de álgebra lineal .. etcétera etcétera..).

Por otro lado, OpenCL es solo una API. Los núcleos de OpenCL son cadenas simples que se pasan a la API, por lo que al usar OpenCL de Java debería poder especificar sus propios núcleos. El enlace OpenCL para Java se puede encontrar aquí http://www.jocl.org/ .

Iván
fuente
2
si JNA ( jna.dev.java.net ) es compatible con su plataforma, lo usaría para invocar el código nativo, ya que es mucho menos esfuerzo que codificar una biblioteca JNI.
mdma
11

He estado usando JOCL y estoy muy contento con él.

La principal desventaja de OpenCL sobre CUDA (al menos para mí) es la falta de bibliotecas disponibles (Thrust, CUDPP, etc.). Sin embargo, CUDA se puede portar fácilmente a OpenCL, y observar cómo funcionan esas bibliotecas (algoritmos, estrategias, etc.) es realmente muy bueno, ya que aprende mucho con él.

media deformación
fuente
7

Sé que es tarde, pero mira esto: https://github.com/pcpratts/rootbeer1

No he trabajado con él, pero parece mucho más fácil de usar que otras soluciones.

Desde la página del proyecto:

Rootbeer es más avanzado que CUDA u OpenCL Java Language Bindings. Con enlaces, el desarrollador debe serializar gráficos complejos de objetos en matrices de tipos primitivos. Con Rootbeer esto se hace automáticamente. También con los enlaces de idioma, el desarrollador debe escribir el kernel de la GPU en CUDA u OpenCL. Con Rootbeer se realiza un análisis estático del código de bytes de Java (utilizando Soot) y se genera automáticamente el código CUDA.

karl
fuente
2

También puedo recomendar JOCL de jogamp.org , funciona en Linux, Mac y Windows. CONRAD , por ejemplo, usa mucho OpenCL en combinación con JOCL.

Michael Dorner
fuente
1

Si desea realizar algún procesamiento de imágenes u operaciones geométricas, es posible que desee una biblioteca de álgebra lineal con soporte para gpu (con CUDA, por ejemplo). Te sugiero que ND4J sea el álgrebra lineal con soporte de GPU CUDA en el que se construye DeepLearning4J. Con eso no tiene que lidiar con CUDA directamente y tiene que codificar de bajo nivel en c. Además, si desea hacer más cosas con imágenes con DL4J, tendrá acceso a operaciones específicas de procesamiento de imágenes, como la convolución.

Guillaume Surroca
fuente