Futuro do OpenCL?

O paradigma de programação OpenCL promete ser um padrão aberto livre de royalties para computação heterogênea. Devemos investir nosso tempo no desenvolvimento de software baseado em OpenCL? Prós e contras?

A pergunta é muito ampla e vaga para ser realmente respondida. No entanto, vejo um ponto notável contra o OpenCL, do ponto de vista da computação científica, que raramente é enfatizado. Até o momento, não houve nenhum esforço para produzir bibliotecas de infraestrutura de código aberto para o OpenCL, enquanto o CUDA possui várias opções excelentes:

• CUBLAS , CUFFT , CUSPARSE
• Pressão , cúspide , corrente contínua
• Suporte PETSc

Acredito que isso realmente prejudicará o OpenCL, pois um dos principais facilitadores da adoção é a alta qualidade das bibliotecas abertas.

OpenCL vs o que?

Se a pergunta é OpenCL vs CUDA, vejo muitas perguntas sobre essa questão, e isso parece uma loucura para mim. Não importa. Honesto. Os núcleos - para onde todo o pensamento difícil precisa ir - são praticamente idênticos entre os dois idiomas; você pode escrever macros para o seu editor favorito para fazer 99% do trabalho para alternar entre o OpenCL e o CUDA. Tem que ser assim; eles são controle de baixo nível de tipos de hardware bastante semelhantes. Depois de descobrir como escrever seus kernels importantes no {OpenCL, CUDA}, é trivial transportá-los para o {CUDA, OpenCL}.

O código do host padrão que você precisa escrever também é semelhante, mas o CUDA mantém casos simples simples. É por isso que ensinamos a CUDA em nosso centro; você pode pular direto para a criação de código do kernel, enquanto teríamos que passar de uma a duas horas de nosso curso de um dia apenas explicando as coisas de lançamento do kernel para o OpenCL.

Mas mesmo aí a diferença não é tão importante; depois que você começa a fazer coisas mais complicadas (kernels assíncronos em vários gpus), elas são igualmente complicadas e, novamente, você pode praticamente fazer uma tradução linha por linha de um para o outro.

Se for OpenCL vs abordagens baseadas em diretivas - OpenACC ou HMPP ou algo assim - essas provavelmente serão (esperamos?) Boas maneiras de programar esses tipos de arquiteturas no futuro, onde você poderá obter 90% do desempenho para 10% do trabalho. Mas qual opção "vencerá" ainda está por ser vista e eu não recomendaria gastar muito tempo trabalhando com elas ainda.

Então, eu diria que, entre CUDA ou OpenCL, escolha um idioma que seja conveniente para você e use-o, e não se preocupe muito com isso. A parte valiosa - descobrir como decompor seu problema em código SIMD massivamente paralelo para núcleos pequenos com muito pouca memória - será muito fácil de transportar entre os modelos de programação.

Se você estiver usando o hardware da NVIDIA - e provavelmente está -, então eu normalmente recomendo a CUDA - o argumento de Matt Knepley sobre as bibliotecas é imediato. Se você não é, então OpenCL.

Se você deve investir seu tempo no desenvolvimento de software baseado em OpenCL é uma pergunta que você pode responder. Se parece que ele tem o potencial de resolver os problemas que você está enfrentando no momento e nenhuma outra solução aberta o faz, seu melhor curso de ação provavelmente é correr o risco de implementar um pequeno projeto com ele.

Se isso der certo, você poderá testá-lo com projetos maiores e assim por diante até obter confiança suficiente para padronizá-lo ou descartá-lo em favor de outra solução (que pode ser sua própria solução proprietária, outra solução aberta ou até outra solução proprietária).

O maravilhoso do movimento de código aberto é que, como você tem o código - fonte, tem tudo o que precisa para bifurcar o projeto, se necessário. Mesmo que a própria comunidade não ofereça as instalações necessárias, não há nada que o impeça de implementar essas instalações. Além disso, se você quisesse essas instalações, há uma possibilidade distinta de que outros usuários possam desejá-las, então agradeceria se você contribuísse com essas mudanças de volta ao projeto principal.

Não apenas isso, mas se você melhorar da sua perspectiva, pode melhorar para outras pessoas, incentivá-las a enviar seus próprios aprimoramentos e, finalmente, melhorar o software para todos.

Finalmente, sim, esta é uma resposta bastante genérica para uma pergunta genérica. Para responder de maneira mais completa, precisamos saber quais são suas preocupações com o OpenCL. É maturidade? Suporte da comunidade? Fácil de usar? Tempo necessário para aprender? Hora de desenvolver? Mudando seus procedimentos? Quando você pergunta sobre os prós e contras, com quais outros produtos você está tentando comparar o OpenCL ? Que pesquisa você já fez? Quais recursos você precisa para suportar seu ambiente de computação heterogêneo?

Um grande PRO é o número de fornecedores por trás do OpenCL. Tenho alguma experiência anedótica sobre isso, depois de conhecer um grupo de pesquisa que gastou muito tempo e esforço para desenvolver um código CUDA bastante complicado para um sistema alimentado pela NVIDIA. Um ano depois que o código foi desenvolvido, o grupo de pesquisa obteve acesso a um sistema AMD maior e mais rápido, mas eles não puderam usá-lo, pois não tinham os recursos (humanos) para portar o código.

Mesmo que o conjunto principal de recursos do CUDA e do OpenCL seja quase idêntico (como o @JonathanDursi bem apontou), se o desenvolvedor original não for o responsável pela tarefa de converter o código, todo o projeto de portabilidade pode demorar bastante.

No entanto, existem algumas incompatibilidades oficiais entre CUDA e OpenCL. O CUDA notavelmente suporta modelos c ++, enquanto o OpenCL ainda não os suporta oficialmente. No entanto, há um esforço feito pela AMD para desenvolver uma extensão para o OpenCL com suporte para modelos e outros recursos C ++, mais informações nesta postagem da AMD dev central . Espero que uma futura revisão do OpenCL possa adicionar este trabalho.

Neste momento (início de 2012), as incríveis bibliotecas às quais o @MattKnepley se vincula são de código fechado ou usam modelos, para que não fiquem disponíveis para hardware que não seja a NVIDIA, pelo menos nesse meio tempo.

Para alguém que está aprendendo gpu-computing, eu diria que o OpenCL C pode ser bastante difícil, pois há muitos detalhes que desviam o aluno das idéias básicas, enquanto o CUDA é mais simples e direto. No entanto, existem ferramentas que tornam o OpenCL muito mais simples de aprender e usar, como PyOpenCL (o empacotador python para opencl), que traz todo o açúcar python para o OpenCL (observe que também existe um PyCUDA). Por exemplo, a demonstração do PyOpenCL para adicionar duas matrizes tem pouco menos de 25 linhas e inclui: criação das matrizes no host e no dispositivo, as transferências de dados, a criação do contexto e fila, o kernel, como construir e executar o kernel , obtendo os resultados da GPU e comparando-os com o numpy (veja os links abaixo).

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

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

Para programadores gpu experientes, aqui eu concordo com @ JonathanDursi, CUDA e OpenCL são fundamentalmente os mesmos e realmente não há grandes diferenças. Além disso, o trabalho árduo de desenvolver um algoritmo eficiente para GPUs é muito independente da linguagem, e o suporte ao OpenCL dos fornecedores e a documentação agora são muito mais maduros do que há 2 anos. O único ponto que ainda faz diferença é que a NVIDIA está realmente fazendo um ótimo trabalho com o apoio à comunidade CUDA.

O OpenCL possui o benefício adicional de poder ser executado em CPUs e já é suportado pela Intel e AMD. Portanto, você não precisa alterar sua estrutura algorítmica se quiser aproveitar os núcleos de CPU disponíveis. Não é minha opinião que o OpenCL seja a melhor solução para um único aplicativo orientado a CPU / multicore, pois um kernel otimizado para CPU pode parecer significativamente diferente de um kernel otimizado para GPU. No entanto, na minha experiência, o desenvolvimento do CODE se beneficia de poder executar na CPU.

Eu acho que o OpenCL atualmente está sofrendo com a falta de um "campeão". Por exemplo, se você visitar o site da NVIDIA agora (16/12/2011), terá várias fotos no estilo "Efeito Ken Burns" na página inicial, focando no lado científico / industrial da computação de GPU e ~ 1 / A quarta das opções de navegação aponta para coisas que provavelmente acabarão na CUDA. Os fabricantes que vendem servidores e estações de trabalho "GPU computing" estão vendendo soluções NVIDIA.

As ofertas concorrentes da ATI são misturadas ao site geral da AMD, mais difíceis de encontrar e não são tão destacadas em soluções de terceiros. Essas soluções e a capacidade de fazer programação baseada em OpenCL certamente existem, mas deixou uma percepção - pelo menos em minha mente, mas na mente de outras pessoas com quem conversei - de que os grandes patrocinadores corporativos da plataforma OpenCL já " saia do campo ". As pessoas que usam o OS X, por exemplo, provavelmente estão muito ocupadas especulando se uma estação de trabalho da Apple existirá ou não em um ano para ter fé nelas pressionando a computação da GPU OpenCL.

O fator mais importante é que o CUDA permanecerá suportado apenas pelo hardware da NVIDIA.

Portanto, se você deseja criar software robusto e portátil, o OpenCL é a única opção. No máximo, você pode construir em torno de algumas bibliotecas atualmente alimentadas por CUDA e espero que elas sejam estendidas sobre o OpenCL no futuro, puxando seu código com ele.