Bibliotecas matemáticas para OpenCL?

Estou procurando informações de qualquer pessoa que tenha tentado usar o OpenCL em seu código científico. Alguém já tentou (recentemente) o ViennaCL ? Em caso afirmativo, como ele se compara à cúspide ?

E o OCLTools ? Isso faz jus à promessa? Nesse caso, seria uma maneira viável de começar a escrever kernels matemáticos no OpenCL?

Antes de tudo, gostaria de agradecer a Aron Ahmadia por me indicar esse tópico.

Quanto ao OpenCL no código científico: OpenCL é uma API de baixo nível, portanto, é crucial agrupar essa funcionalidade de alguma maneira para alcançar uma produtividade razoável. Além disso, assim que vários kernels de computação estiverem envolvidos, o código poderá ficar MUITO sujo se o kernel do OpenCL e os identificadores de memória precisarem ser repassados ​​em um aplicativo. Como não conheço OCLTools, não posso dizer se são úteis nesse sentido.

Quanto ao ViennaCL: eu sou o chefe do ViennaCL, então trabalhei recentemente com a biblioteca. :-) A seguir, tratarei a solicitação de comparação com cusp em um escopo um pouco maior, ou seja, ViennaCL versus as bibliotecas matemáticas baseadas em CUDA cusp e MAGMA . Somente o estado atual é considerado, embora haja muito desenvolvimento em andamento (pelo menos do nosso lado).

Funcionalidade . O MAGMA fornece a funcionalidade BLAS para matrizes densas através das interfaces de funções usuais. A maior parte dessa funcionalidade também é fornecida com o ViennaCL 1.2.0 usando sobrecargas do operador e outro açúcar sintático.

Os mesmos três solucionadores iterativos (CG, BiCGStab, GMRES) são fornecidos com cusp e ViennaCL. O conjunto de pré-condicionadores difere notavelmente: a Cusp fornece diagonal, SA-AMG e vários pré-condicionadores da Bridson. O ViennaCL oferece fatorações LU incompletas, pré-condicionadores diagonais e, recentemente, vários sabores AMG e pré-condicionadores inversos aproximados esparsos. Que eu saiba, todos os pré-condicionadores de cúspides são executados inteiramente na GPU, enquanto o ViennaCL depende principalmente durante a fase de configuração dos cálculos baseados em CPU. Atualmente, o número de formatos de matriz esparsos é maior em cúspide: COO, CSR, DIA, ELL, HYB, enquanto o ViennaCL 1.2.0 fornece COO e CSR.

Existem vários recursos adicionais fornecidos com o ViennaCL, que não fazem parte do MAGMA ou da cúspide: tipos de matriz estruturada (Circulant, Hankel etc.), transformação rápida de Fourier, algoritmos de reordenação (por exemplo, Cuthill-McKee) e invólucros para álgebra linear tipos de outras bibliotecas.

Atuação. O conjunto maior de recursos e suporte de hardware no ViennaCL geralmente custa menos desempenho quando comparado às implementações baseadas em CUDA. Isso também se deve em parte ao fato de o CUDA ser adaptado à arquitetura dos produtos NVIDIA, enquanto o OpenCL representa, em certo sentido, um compromisso razoável entre diferentes arquiteturas de vários núcleos.

No geral, o ViennaCL é atualmente mais lento que o MAGMA, particularmente no nível BLAS 3. O motivo é o foco diferente do ViennaCL (álgebra linear esparsa em vez de densa linear) e, portanto, o maior grau de otimização no MAGMA. Atualmente, as operações de nível 3 do BLAS são consideravelmente mais rápidas no MAGMA.

Da mesma forma, cusp fornece um desempenho geral um pouco melhor em geral. No entanto, como as operações de matriz esparsa são geralmente limitadas à largura de banda da memória, as diferenças são consideravelmente menores e geralmente desprezíveis em comparação com a configuração de dados e similares. A escolha do pré-condicionador e seus parâmetros geralmente tem um impacto maior no tempo de execução geral do que quaisquer diferenças de desempenho nas multiplicações esparsas de vetores matriciais.

Portabilidade . Quanto à portabilidade de hardware, o ViennaCL pode usar CPUs e GPUs de todos os principais fornecedores, graças ao OpenCL. Por outro lado, cusp e MAGMA contam com uma GPU NVIDIA adequada.

O ViennaCL é apenas de cabeçalho, pode ser compilado em uma ampla variedade de compiladores C ++ e só precisa ser vinculado à biblioteca OpenCL se o suporte a GPU for necessário. Em princípio, os algoritmos genéricos no ViennaCL também podem ser usados ​​sem qualquer ligação OpenCL, enquanto cusp e MAGMA exigem o compilador NVIDIA para compilação e a biblioteca CUDA no sistema de destino para execução. O MAGMA também requer uma biblioteca BLAS, que às vezes pode ser um pouco complicada para encontrar ou instalar em um novo sistema.

API . O MAGMA fornece interfaces de função no estilo BLAS para a funcionalidade BLAS. A interface C ++ do cusp também usa algumas funções do BLAS, mas nenhum operador sobrecarrega. Como a maioria das interfaces no ViennaCL é intencionalmente semelhante ao Boost.uBLAS e apresenta açúcar sintático, como sobrecargas do operador, o ViennaCL também se destina a ser usado como o Boost.uBLAS. Assim, além de apenas chamar um conjunto predefinido de operações e algoritmos, nossa intenção é fazer a transição da execução puramente baseada em CPU para o código da GPU da maneira mais simples possível, mesmo que algoritmos não padrão sejam usados. Caso seja necessário um kernel OpenCL dedicado, também existe uma estrutura para integrar seus próprios kernels OpenCL no ViennaCL. Assim, o ViennaCL visa muito mais aalta produtividade, no sentido de que o tempo necessário para implementar novos algoritmos na GPU é minimizado . Essas economias podem superar significativamente qualquer penalidade de desempenho (se houver) em comparação à cúspide e ao MAGMA. (Também foi mencionado no tópico teste de unidade que o tempo de desenvolvimento do código é um recurso precioso na ciência.)

Certamente há uma série de questões ideológicas (por exemplo, CUDA x OpenCL, interface BLAS vs. sobrecargas de operadores) ao longo da minha comparação, mas a discussão delas está além do escopo da pergunta inicial.

O OpenCL pode ser usado, no entanto, há uma falta de infraestrutura, por exemplo, importantes bibliotecas matemáticas padrão maduras com componentes de álgebra linear padrão sintonizados de fato e, até certo ponto, boas ferramentas de perfil, embora o último problema tenha melhorado significativamente para as GPUs. Isso está disponível no CUDA a partir de hoje e pode contribuir para uma parte do sucesso da Nvidia com este modelo de programação. No entanto, o OpenCL parece estar alcançando (lentamente).

Hoje, como ponto de partida para a programação da GPU, CUDA é bom e, se necessário, não há nada que impeça o uso do OpenCL como uma alternativa, por exemplo, para tornar o código mais portátil. Essencialmente, o mesmo código do kernel pode ser usado no CUDA e no OpenCL, portanto, não deve ser um grande problema passar do CUDA para o OpenCL. Isso é confirmado por experiências próprias testando isso. De uma perspectiva de desempenho, as mesmas técnicas de otimização podem ser usadas e, para compiladores triviais de código simultâneo, devem fazer o trabalho bem (por exemplo, desenrolamento de loop, etc.).