El paradigma de programación OpenCL promete ser un estándar abierto libre de regalías para la computación heterogénea. ¿Deberíamos invertir nuestro tiempo en desarrollar software basado en OpenCL? ¿Pros contras?
hpc
programming-paradigms
Allan P. Engsig-Karup
fuente
fuente
Respuestas:
La pregunta es demasiado amplia y vaga para ser realmente respondida. Sin embargo, veo un punto notable en contra de OpenCL, desde el punto de vista de la informática científica, que rara vez se enfatiza. Hasta ahora, no ha habido ningún esfuerzo para producir bibliotecas de infraestructura de código abierto para OpenCL, mientras que CUDA tiene varias opciones excelentes:
Creo que esto realmente perjudicará a OpenCL ya que uno de los principales facilitadores de la adopción son las bibliotecas abiertas de alta calidad.
fuente
OpenCL vs qué?
Si la pregunta es OpenCL vs CUDA, veo muchas dudas sobre esta pregunta, y me parece una locura. No importa. Honesto. Los núcleos, donde tiene que ir todo el pensamiento duro, son prácticamente idénticos entre los dos idiomas; podría escribir macros para su editor favorito para hacer el 99% del trabajo para rebotar entre OpenCL y CUDA. Tiene que ser de esa manera; son un control de bajo nivel de hardware en última instancia bastante similar. Una vez que haya descubierto cómo escribir sus núcleos importantes en {OpenCL, CUDA}, es trivial portarlos a {CUDA, OpenCL}.
El código de host repetitivo que tiene que escribir también es similar, pero CUDA mantiene simples los casos simples. Es por eso que enseñamos CUDA en nuestro centro; puede pasar directamente a escribir el código del kernel, mientras que tendríamos que pasar de 1 a 2 horas de nuestro curso de un día explicando las cosas de lanzamiento del kernel para OpenCL.
Pero incluso allí la diferencia no es tan importante; una vez que empiezas a hacer cosas más complicadas (núcleos asincrónicos en múltiples gpus), ambos son igualmente complicados y de nuevo puedes hacer una traducción línea por línea de uno a otro.
Si se trata de OpenCL frente a los enfoques basados en directivas, OpenACC o HMPP o algo así, probablemente sean buenas (¿con suerte?) Buenas maneras de programar este tipo de arquitecturas en el futuro, donde puede obtener el 90% del rendimiento para 10% del trabajo. Pero aún queda por ver qué opción "ganará" y aún no recomendaría pasar mucho tiempo trabajando con ellos.
Entonces, diría que entre CUDA u OpenCL elige un idioma que sea conveniente para ti y úsalo, y no te preocupes demasiado por eso. La parte valiosa, descubrir cómo descomponer su problema en código SIMD masivamente paralelo para núcleos pequeños con muy poca memoria, será bastante fácil de transportar entre los modelos de programación.
Si está utilizando hardware NVIDIA, y probablemente lo esté, entonces normalmente recomiendo CUDA: el punto de Matt Knepley sobre las bibliotecas es acertado. Si no lo eres, entonces OpenCL.
fuente
Si debe invertir su tiempo en el desarrollo de software basado en OpenCL es una pregunta que solo usted puede responder. Si parece que tiene el potencial de resolver los problemas que enfrenta en este momento, y ninguna otra solución abierta lo hace, su mejor curso de acción es probablemente correr el riesgo de implementar un pequeño proyecto con él.
Si eso va bien, puede probarlo con proyectos más grandes y así sucesivamente hasta que acumule suficiente confianza para estandarizarlo o lo descarte en favor de alguna otra solución (que podría ser su propia solución patentada, otra solución abierta o incluso Otra solución patentada).
Lo maravilloso del movimiento de código abierto es que, dado que tiene la fuente , tiene todo lo que necesita para bifurcar el proyecto si es necesario. Incluso si la comunidad en sí no le brinda las instalaciones que necesita, no hay nada que le impida implementar esas instalaciones. Además, si desea esas instalaciones, existe una clara posibilidad de que otros usuarios las quieran, por lo que agradecería que contribuyera con esos cambios al proyecto principal.
No solo eso, sino que si lo mejora desde su perspectiva, podría mejorarlo para otros, alentarlos a enviar sus propias mejoras y, en última instancia, mejorar el software para todos.
Finalmente, sí, esta es una respuesta bastante genérica a una pregunta bastante genérica. Para responder más completamente, necesitamos saber cuáles son sus preocupaciones sobre OpenCL. ¿Es madurez? ¿Soporte comunitario? ¿Facilidad de uso? ¿Tiempo necesario para aprender? ¿Hora de desarrollarse? ¿Cambiando sus procedimientos? Cuando pregunta sobre los pros y los contras, ¿con qué otros productos está tratando de comparar OpenCL ? ¿Qué investigación has hecho ya? ¿Qué características necesita para admitir su entorno informático heterogéneo?
fuente
Un gran PRO es la cantidad de proveedores detrás de OpenCL. Tengo algo de experiencia anecdótica sobre esto, después de haber conocido a un grupo de investigación que dedicó una gran cantidad de tiempo y esfuerzo a desarrollar un código CUDA bastante complicado para un sistema alimentado por NVIDIA. Un año más tarde, después de que se desarrolló el código, el grupo de investigación tuvo acceso a un sistema basado en AMD más grande y más rápido, pero no pudieron usarlo ya que no tenían los recursos (humanos) para portar el código.
Incluso si el conjunto básico de características de CUDA y OpenCL son casi idénticos (como bien señaló @JonathanDursi), si el desarrollador original no es el asignado a la tarea de convertir el código, todo el proyecto de portabilidad puede llevar bastante tiempo.
Sin embargo, hay algunas incompatibilidades oficiales entre CUDA y OpenCL. Lo más notable es que CUDA admite plantillas de c ++, mientras que OpenCL aún no las admite oficialmente. Sin embargo, AMD está haciendo un esfuerzo para desarrollar una extensión de OpenCL con soporte para plantillas y otras características de C ++, más información en esta publicación de la central de desarrollo de AMD . Espero que una futura revisión de OpenCL pueda agregar este trabajo.
En este momento (principios de 2012), las impresionantes bibliotecas a las que @MattKnepley se vincula son de código cerrado o usan plantillas, por lo que no estarán disponibles para hardware que no sea NVIDIA, al menos mientras tanto.
Para alguien que está aprendiendo computación en gpu, diría que OpenCL C puede ser bastante difícil, ya que hay muchos detalles que distraen al alumno de las ideas básicas, mientras que CUDA es más simple y directo. Sin embargo, hay herramientas que hacen que OpenCL sea mucho más simple de aprender y usar como PyOpenCL (el envoltorio de python para opencl) que trae todo el azúcar de python a OpenCL (tenga en cuenta que también hay un PyCUDA). Por ejemplo, la demostración de PyOpenCL para agregar dos matrices tiene menos de 25 líneas e incluye: la creación de matrices en el host y el dispositivo, las transferencias de datos, la creación del contexto y la cola, el núcleo, cómo construir y ejecutar el núcleo , obteniendo los resultados de la GPU y comparándolos con numpy (ver enlaces a continuación).
PyOpenCL - http://mathema.tician.de/software/pyopencl
PyCUDA - http://mathema.tician.de/software/pycuda
Para los programadores de gpu experimentados, aquí estoy de acuerdo con @JonathanDursi, CUDA y OpenCL son básicamente los mismos y realmente no hay grandes diferencias. Además, el arduo trabajo de desarrollar un algoritmo eficiente para las GPU es muy independiente del lenguaje, y el soporte de OpenCL de los proveedores y la documentación ahora es mucho más maduro que hace 2 años. El único punto que todavía marca la diferencia es que NVIDIA realmente está haciendo un gran trabajo con su apoyo a la comunidad de CUDA.
OpenCL tiene el beneficio adicional de que puede ejecutarse en CPU y ya es compatible con Intel y AMD. Por lo tanto, no necesita cambiar su marco algorítmico si desea aprovechar los núcleos de CPU disponibles. No es mi opinión que OpenCL es la mejor solución para una sola aplicación orientada a CPU / multinúcleo, ya que un núcleo optimizado para CPU podría verse significativamente diferente a un núcleo optimizado para GPU. Sin embargo, en mi experiencia, el desarrollo de CÓDIGOS se beneficia al poder ejecutarse en la CPU.
fuente
Creo que OpenCL actualmente sufre de falta de un "campeón". Por ejemplo, si visita el sitio de NVIDIA en este momento (16/12/2011), tiene varias tomas de estilo "Ken Burns Effect" en la página de inicio que se enfoca en el lado científico / industrial de la computación GPU, y ~ 1 / El cuarto de sus opciones de navegación lo orienta hacia cosas que probablemente terminarán en CUDA. Los fabricantes que venden servidores y estaciones de trabajo "informática GPU" están vendiendo soluciones NVIDIA.
Las ofertas de la competencia de ATI se mezclan con el sitio general de AMD, son más difíciles de encontrar y no son tan importantes en las soluciones de terceros. Esas soluciones y la capacidad de hacer programación basada en OpenCL ciertamente existen, pero dejó una percepción, al menos en mi mente, pero en la mente de otras personas con las que he hablado, que los grandes patrocinadores corporativos de la plataforma OpenCL ya han " salir del campo ". Las personas que usan OS X, por ejemplo, probablemente estén demasiado ocupadas especulando sobre si una estación de trabajo de Apple existirá o no en un año como para tener fe en que impulsen la informática de GPU OpenCL.
fuente
El factor más importante es que CUDA seguirá siendo compatible solo con el hardware de NVIDIA.
Por lo tanto, si desea hacer un software robusto y portátil, OpenCL es la única opción. A lo sumo, puede construir en torno a algunas bibliotecas que funcionan actualmente con CUDA y esperar que se extiendan sobre OpenCL en el futuro arrastrando su código con él.
fuente