Bibliotecas Matemáticas para OpenCL?

Estoy buscando información de cualquiera que haya intentado usar OpenCL en su código científico. ¿Alguien ha intentado (recientemente) ViennaCL ? Si es así, ¿cómo se compara con la cúspide ?

¿Qué pasa con OCLTools ? ¿Cumple con la promesa? Si es así, ¿sería una forma factible de comenzar a escribir núcleos matemáticos en OpenCL?

En primer lugar, deseo agradecer a Aron Ahmadia por señalarme este hilo.

En cuanto a OpenCL en el código científico: OpenCL está destinado a ser una API de bajo nivel, por lo tanto, es crucial envolver esta funcionalidad de alguna manera para alcanzar una productividad razonable. Además, tan pronto como intervienen varios núcleos de cómputo, el código puede ensuciarse MUY si el núcleo de OpenCL y los controladores de memoria deben pasarse en gran medida dentro de una aplicación. No conozco OCLTools, por lo tanto, no puedo decir si son útiles a este respecto.

En cuanto a ViennaCL: soy el jefe de ViennaCL, así que he trabajado recientemente con la biblioteca. :-) A continuación trataré la solicitud de una comparación con cusp en un ámbito un poco más amplio, a saber, ViennaCL versus las bibliotecas de matemáticas basadas en CUDA cusp y MAGMA . Solo se considera el estado actual, a pesar de que hay mucho desarrollo en curso (al menos de nuestro lado).

Funcionalidad . MAGMA proporciona la funcionalidad BLAS para matrices densas a través de las interfaces de funciones habituales. La mayor parte de esta funcionalidad también se proporciona con ViennaCL 1.2.0 que utiliza sobrecargas del operador y otro azúcar sintáctico.

Los mismos tres solucionadores iterativos (CG, BiCGStab, GMRES) se proporcionan con cúspide y ViennaCL. El conjunto de preacondicionadores difiere notablemente: Cusp proporciona preacondicionadores diagonales, SA-AMG y varios Bridson. ViennaCL ofrece factorizaciones LU incompletas, preacondicionadores diagonales y recientemente varios sabores AMG y preacondicionadores inversos aproximados dispersos. Que yo sepa, todos los preacondicionadores de cúspides se ejecutan completamente en la GPU, mientras que ViennaCL se basa particularmente durante la fase de configuración en los cálculos basados ​​en la CPU. Actualmente, el número de formatos de matriz dispersos es mayor en cúspide: COO, CSR, DIA, ELL, HYB, mientras que ViennaCL 1.2.0 proporciona COO y CSR.

Hay una serie de características adicionales proporcionadas con ViennaCL, que no forman parte de MAGMA o cúspide: tipos de matriz estructurada (circulante, Hankel, etc.), transformación rápida de Fourier, algoritmos de reordenamiento (por ejemplo, Cuthill-McKee) y envoltorios para álgebra lineal tipos de otras bibliotecas.

Actuación. El conjunto más amplio de características y soporte de hardware en ViennaCL generalmente tiene el costo de un rendimiento más bajo en comparación con las implementaciones basadas en CUDA. Esto también se debe en parte al hecho de que CUDA se adapta a la arquitectura de los productos NVIDIA, mientras que OpenCL representa, en cierto sentido, un compromiso razonable entre diferentes arquitecturas de muchos núcleos.

En general, ViennaCL es actualmente más lento que MAGMA, particularmente en el nivel 3 de BLAS. Las razones son el enfoque diferente de ViennaCL (álgebra lineal escasa en lugar de densa) y, por lo tanto, el mayor grado de optimización en MAGMA. En particular, las operaciones de nivel 3 de BLAS son considerablemente más rápidas en MAGMA.

Del mismo modo, la cúspide proporciona un rendimiento general ligeramente mejor en general. Sin embargo, dado que las operaciones de matriz dispersa generalmente tienen un ancho de banda de memoria limitado, las diferencias son considerablemente más pequeñas y a menudo insignificantes en comparación con la configuración de datos y similares. La elección del preacondicionador y sus parámetros generalmente tiene un mayor impacto en el tiempo de ejecución general que cualquier diferencia de rendimiento en las multiplicaciones dispersas de vectores de matriz.

Portabilidad . En cuanto a la portabilidad del hardware, ViennaCL puede usar CPU y GPU de todos los principales proveedores gracias a OpenCL. Por el contrario, cusp y MAGMA se basan en una GPU NVIDIA adecuada.

ViennaCL es solo de encabezado, puede compilarse en una amplia gama de compiladores de C ++ y solo necesita vincularse con la biblioteca OpenCL si se requiere soporte de GPU. En principio, los algoritmos genéricos en ViennaCL también se pueden usar sin ningún enlace OpenCL, mientras que cusp y MAGMA requieren el compilador NVIDIA para la compilación y la biblioteca CUDA en el sistema de destino para la ejecución. MAGMA también requiere una biblioteca BLAS, que a veces puede ser un poco difícil de encontrar o instalar en un nuevo sistema.

API . MAGMA proporciona interfaces de funciones de estilo BLAS para la funcionalidad BLAS. La interfaz C ++ de cusp también usa algunas funciones de BLAS, pero no sobrecargas del operador. Dado que la mayoría de las interfaces en ViennaCL son intencionalmente similares a Boost.uBLAS y presentan azúcar sintáctica como sobrecargas de operadores, ViennaCL también está diseñada para usarse como Boost.uBLAS. Por lo tanto, además de llamar a un conjunto predefinido de operaciones y algoritmos, nuestra intención es hacer una transición de la ejecución puramente basada en la CPU al código de la GPU lo más simple posible, incluso si se van a utilizar algoritmos no estándar. En el caso de que se requiera un núcleo OpenCL dedicado, también hay un marco para integrar sus propios núcleos OpenCL en ViennaCL. Por lo tanto, ViennaCL apunta mucho más haciaalta productividad en el sentido de que se minimiza el tiempo requerido para implementar nuevos algoritmos en la GPU . Estos ahorros pueden superar significativamente cualquier penalización de rendimiento (si corresponde) en comparación con cúspide y MAGMA. (También se ha mencionado en el hilo de las pruebas unitarias que el tiempo de desarrollo del código es un recurso precioso en la ciencia).

Ciertamente hay una serie de problemas ideológicos (por ejemplo, CUDA vs. OpenCL, interfaz BLAS vs. sobrecargas del operador) a lo largo de mi comparación, pero su discusión está más allá del alcance de la pregunta inicial.

OpenCL se puede utilizar, sin embargo, hay una falta de infraestructura, por ejemplo, importantes bibliotecas de matemáticas estándar maduras con componentes de álgebra lineal estándar ajustados de facto y, en cierta medida, buenas herramientas de creación de perfiles, aunque este último problema ha mejorado significativamente para las GPU. Esto está disponible en CUDA a partir de hoy y se puede contribuir a una parte del éxito de Nvidia con este modelo de programación. Sin embargo, OpenCL parece estar poniéndose al día (lentamente).

Hoy, como punto de partida para la programación de GPU, CUDA está bien, y si es necesario, no hay nada que impida usar OpenCL como alternativa, por ejemplo, para hacer que el código sea más portátil. Esencialmente, se puede usar el mismo código de kernel tanto en CUDA como en OpenCL, por lo que no debería ser un problema importante pasar de CUDA a OpenCL. Esto lo confirman las propias experiencias que prueban esto. Desde una perspectiva de rendimiento, se pueden usar las mismas técnicas de optimización y para compiladores de código concurrentes triviales deberían funcionar bien (por ejemplo, desenrollar bucles, etc.).