Melhor abordagem para GPGPU / CUDA / OpenCL em Java?

94

A computação de propósito geral em unidades de processamento gráfico ( GPGPU ) é um conceito muito atraente para aproveitar o poder da GPU para qualquer tipo de computação.

Adoraria usar GPGPU para processamento de imagens, partículas e operações geométricas rápidas.

No momento, parece que os dois contendores neste espaço são CUDA e OpenCL. Eu gostaria de saber:

  • O OpenCL ainda pode ser usado em Java no Windows / Mac?
  • Quais são as formas de bibliotecas de interface com OpenCL / CUDA?
  • O uso de JNA diretamente é uma opção?
  • Estou esquecendo algo?

Qualquer experiência / exemplos / histórias de guerra do mundo real são apreciados.

java cuda gpgpu opencl Frederik
fonte
1
Eu imagino que programar em GPU em Java seria difícil, considerando o quanto eu uso ponteiros em programação cuda. Não sei se haveria muitos benefícios em usar Java na programação de dispositivos, uma vez que é improvável que você tenha recursos / bibliotecas Java completos implementados que diferenciam Java de C ++
Anycorn
2
Já vi algumas demos Java impressionantes que usaram GLSL e provavelmente CUDA, então certamente é possível.
Frederik
1
Você verificou jcuda.org e jocl.org?
bakkal de
1
Eu sei sobre eles, mas não posso julgar a qualidade. Você tem alguma experiência com eles?
Frederik
4
@Nils: e é por isso que ele quer empurrar todo o processamento de números na GPU ... De qualquer forma, mesmo o conjunto simples C ou x86 teria uma tarefa difícil para competir contra processadores paralelos de dados massivos como GPUs.
Stringer

Respostas:

62

AFAIK, JavaCL / OpenCL4Java é a única ligação OpenCL disponível em todas as plataformas no momento (incluindo MacOS X, FreeBSD, Linux, Windows, Solaris, tudo em variantes Intel 32, 64 bits e ppc, graças ao uso de JNA ).

Ele tem demos que realmente funcionam bem a partir do Java Web Start, pelo menos no Mac e Windows (para evitar travamentos aleatórios no Linux, consulte esta página wiki , como esta Demonstração de partículas .

Ele também vem com alguns utilitários (geração de números aleatórios GPGPU, redução paralela básica, álgebra linear) e um Scala DSL .

Finalmente, é o vínculo mais antigo disponível (desde junho de 2009) e tem uma comunidade de usuários ativa .

(Isenção de responsabilidade: sou o autor do JavaCL :-))

zOlive
fonte
Oh, eu estava tão animado para o JNLP, mas aparentemente ele não gosta do meu macbook. Tanto para plataforma cruzada.
Karl,
5
@Karl Oh, desculpe, quebrei o JNLP (o JAR mudou de nome recentemente)! Isso agora foi corrigido, espero que você tente novamente ... (e em várias plataformas: ele estava quebrado de forma consistente em todas as plataformas ;-))
zOlive
3
O recente aperto na segurança do Java 7 faz com que o Particle Demo Web Start falhe com uma exceção.
Thorbjørn Ravn Andersen
@zOlive O último link JavaCl para o código do google não está mais disponível.
tryman de
34

Você também pode considerar Aparapi . Ele permite que você escreva seu código em Java e tentará converter bytecode em OpenCL em tempo de execução.

Transparência completa. Eu sou o desenvolvedor Aparapi.

gfrost
fonte
O aparapi ainda é mantido?
Sr. Jedi de
@MrJedi: Acho que sim, o último commit no github tem apenas alguns dias: github.com/aparapi/aparapi
Aydin K.
É "um pouco mantido";) Eu sou um mantenedor.
barneypitt
12

Bem, CUDA é uma modificação de C, para escrever o kernel CUDA você tem que codificar em C e, em seguida, compilar para a forma executável com o compilador CUDA da nvidia. O código nativo produzido pode então ser vinculado ao Java usando JNI. Então, tecnicamente, você não pode escrever código kernel em Java. Existe JCUDA http://www.jcuda.de/jcuda/JCuda.html , que fornece apis cuda para gerenciamento geral de memória / dispositivo e alguns métodos Java que são implementados em CUDA e JNI wrap (FFT, alguns métodos de álgebra linear .. etc etc..).

Por outro lado, o OpenCL é apenas uma API. Os kernels OpenCL são strings simples passadas para a API, portanto, usando o OpenCL do Java, você deve ser capaz de especificar seus próprios kernels. A vinculação OpenCL para java pode ser encontrada aqui http://www.jocl.org/ .

Ivan
fonte
2
se JNA ( jna.dev.java.net ) for suportado em sua plataforma, eu usaria isso para invocar o código nativo, pois é muito menos trabalhoso do que codificar uma biblioteca JNI.
mdma
11

Tenho usado o JOCL e estou muito feliz com isso.

A principal desvantagem do OpenCL em relação ao CUDA (pelo menos para mim) é a falta de bibliotecas disponíveis (Thrust, CUDPP, etc). No entanto, CUDA pode ser facilmente portado para OpenCL, e ver como essas bibliotecas funcionam (algoritmos, estratégias, etc) é realmente muito bom, pois você aprende muito com ele.

meia-urdidura
fonte
7

Eu sei que é tarde, mas dê uma olhada nisso: https://github.com/pcpratts/rootbeer1

Não trabalhei com ele, mas parece muito mais fácil de usar do que outras soluções.

Na página do projeto:

Rootbeer é mais avançado do que CUDA ou OpenCL Java Language Bindings. Com ligações, o desenvolvedor deve serializar gráficos complexos de objetos em matrizes de tipos primitivos. Com o Rootbeer, isso é feito automaticamente. Também com ligações de linguagem, o desenvolvedor deve escrever o kernel da GPU em CUDA ou OpenCL. Com o Rootbeer, é feita uma análise estática do Java Bytecode (usando o Soot) e o código CUDA é gerado automaticamente.

karl
fonte
2

Também posso recomendar o JOCL da jogamp.org , funciona em Linux, Mac e Windows. CONRAD , por exemplo, usa fortemente OpenCL em combinação com JOCL.

Michael Dorner
fonte
1

Se você quiser fazer algum processamento de imagem ou operações geométricas, pode querer uma biblioteca de álgebra linear com suporte de gpu (com CUDA, por exemplo). Eu sugeriria que você ND4J bruxa é a álgrebra linear com suporte de GPU CUDA em que DeepLearning4J é construído. Com isso, você não tem que lidar diretamente com CUDA e tem que baixar o código em c. Além disso, se você quiser fazer mais coisas com imagens com DL4J, terá acesso a operações específicas de processamento de imagens, como convolução.

Guillaume Surroca
fonte