A la hora de seleccionar una plataforma u otra, deberemos tener en mente qué es exactamente lo que queremos implementar y qué mejoras deseamos obtener.
Por un lado la disponibilidad de plataformas puede ser el único indicador para realizar la elección: CUDA solo está disponible para la arquitectura de nVidia. Así que, esta cuestión es la más importante.
Si puedes hacer una elección entre ambos, la siguiente cuestión es el objetivo de la paralelización, casi siempre suele ser el incremento del speedUp con respecto a la versión serie, o de CPU, si este es el caso, considera utilizar CUDA ya que es más eficiente tanto a la hora de compilar, obteniendo un código mejorado y optimizado, como a la hora de gestionar en tiempo de ejecución transferencias de memoria, estas dos cuestiones conducen a un comportamiento mejor con respecto a su código homólogo en OpenCL.
Puedes ampliar información a este respecto en este paper, en este otro estudio también se expone la mejora en la utilización de CUDA frente a OpenCL.
Un aspecto a destacar sobre OpenCL es que se trataría de un lenguaje portable, válido para cualquier arquitectura, si has leído los enlaces anteriores te habrás dado cuenta que no es oro todo lo que reluce. Desafortunadamente, es necesario realizar ciertos ajustes en el código cuando deseamos cambiar de plataforma, pero no son muy grandes, esto se debe a la capa de plataforma, que es la parte específica que gestiona el interface con cada arquitectura.
Si aceptas mi consejo, utiliza CUDA para mejorar el rendimiento y aplicaciones para la vida real, y mantén OpenCL cerca de ti, trata de experimentar y portar a este lenguaje tus desarrollos, algún día OpenCL será el estandar, aunque para ese entonces llegarán otros gigantes imponiendo su criterio. El grupo Khronos ya sabe de estos casos: ¿OpenGL?
Si el rendimiento no lo es todo, podrías directamente utilizar OpenCL, sobre todo si no cuentas con plataformas de nVidia, aunque también están disponibles las plataformas específicas de amd: su famoso ATI Stream o APP SDK
Espero que esto te ayude a tomar una decisión, cualquier camino que tomes seguro que te conducirá al éxito. Hasta el próximo post.
Buscar este blog
Mostrando entradas con la etiqueta OPENCL. Mostrar todas las entradas
Mostrando entradas con la etiqueta OPENCL. Mostrar todas las entradas
viernes, 30 de diciembre de 2011
sábado, 10 de diciembre de 2011
Estado del Arte II (Software)
A. Librerías para GPGPU

Han ido de la mano a la aparición del hardware y la presentación de las nuevas librerías gráficas y SDK para el manejo del nuevo hardware. Por un lado los fabricantes han sacado al mercado soluciones específicas para su arquitectura, por otro lado, nos encontramos con la iniciativa del grupo Khronos para crear un lenguaje común para desarrollo de aplicaciones que exploten las tecnologías GPGPU.
Así AMD en 2006 comenzaría con su anuncio de CTM™ ("Close To Metal"). Se trata de un SDK para uso de su arquitectura FireStream recién estrenada por esa misma época. Esta interfaz proporciona a los desarrolladores un completo acceso al conjunto de instrucciones nativas y la memoria de los elementos de cálculo masivamente paralelos de las GPUs de AMD. Con CTM, las GPUs se convierten en poderosas arquitecturas abiertas programables, como las CPUs de hoy. Al liberar la arquitectura, CTM ofrece a los desarrolladores de hardware, un acceso de bajo nivel, determinista y repetible necesario para desarrollar las herramientas esenciales como compiladores, depuradores, bibliotecas de matemáticas y plataformas de aplicaciones.
En diciembre de 2007 y como continuación con su compromiso con un entorno completo de desarrollo de software que libere el sorprendente poder informático de las GPUs de AMD, AMD presentó ATI Stream SDK. Con ATI Stream SDK, AMD añadió un nuevo lenguaje de alto nivel, denominado ATI Brook+. CTM evolucionó a ATI CAL (nivel de abstracción de cálculo), el nivel de API compatible con Brook+. La aparición de Brook+ significó que AMD fue capaz de ofrecer una completa pila de desarrollo completamente gratis para el desarrollo de ATI Stream.
En junio de 2008, AMD y varios líderes del sector de GPGPUs, así como otras tecnologías de aceleradores, formaron el grupo de trabajo OpenCL bajo la denominación The Khronos Group. Khronos es artífice de otras especificaciones bien conocidas como OpenGL, y realizó la apuesta adecuada al enfocarse en la especificación OpenCL.
El 9 de diciembre de 2008 The Khronos Group anunció la puesta en el mercado de la especificación OpenCL 1.0. Mientras tanto, AMD también integró bibliotecas de rutinas para CAL en la suite del controlador ATI Catalyst, liberando las capacidades de aceleración de ATI Stream ya incorporadas en millones de tarjetas gráficas ATI Radeon. A principios de 2009, inmediatamente después de la presentación de la especificación OpenCL 1.0, AMD anunció su intención de adoptar rápidamente el estándar de programación OpenCL 1.0 e integrar un compilador y rutinas compatibles en su ATI Stream SDK.
nVidia desde la presentación en 2006 de la GeForce 8800 GTX comenzó la senda de CUDA, que se propone de un entorno software de librerías especializadas para extraer el máximo rendimiento al hardware. Evidentemente este entorno implica una dependencia del fabricante para obtener nuevas características y prestaciones, se discutirá todo esto y más en el siguiente post.
Una iniciativa que recientemente ha terminado su andadura es Sh o Libsh , se trata de un lenguaje de alto nivel para programación en GPU, con una sintaxis similar a C++, es el resultado de la investigación del laboratorio de gráficos por ordenador de la universidad de Waterloo. Concretamente el lenguaje fue concebido por Michael McCool e implementado por varios miembros del laboratorio.
En el próximo post hablaremos más detalladamente de la evolución de CUDA, hasta entonces!
Suscribirse a:
Entradas (Atom)


