El día 14 de septiembre de 2016, 5:22, Rafa Griman
Wenas :)
2016-09-14 6:47 GMT+03:00 Carlos Ayala
: 2016-09-13 16:51 GMT-05:00 Rafa Griman
: [...]
Obviamente, no todo son ventajas: - CUDA es propietario y NO es multiplataforma como OpenCL - CUDA es complicado - CUDA no es un estándar
[...]
haciendo un poco de off-topic. Justo escuche CUDA en un proyecto de investigación sobre Deep Learning acerca de música. =|
Es lo más "in"/"trending"/"you name it" del momento. Ahora todo el mundo hace Deep Learning (salvo el Ser Humano >;)
Se usa para todo y en todos los campos ... o eso quieren. Ya sabes: "cuando tienes un martillo en la mano ... todo son clavos". Con eso no quiero decir que Deep Learning no sea útil, sino que es la última moda y todo el mundo quiere (o dice) que usan/hacen Deep Learning.
Pero primero lo primero, lo escuché en este podcast [Software Engineering Daily - Music Deep Learning with Feynman Liang](http://softwareengineeringdaily.com/2016/09/02/music-deep-learning-with-feyn...) el repositorio de su proyecto [GIT - Bach Bot](https://github.com/feynmanliang/bachbot) y la web de su proyecto [Bach Bot Challenge](http://bachbot.com/#/?_k=smfllq)
En el repositorio incluyen la imagen docker para CUDA 7.5 =| Si lo están usando, algo de bueno habrá de tener.
Como decía más arriba, CUDA no es malo. Lo que ocurre es que tiene algunas cosas a tener en cuenta (ver más arriba). Lo cierto es que CUDA ofrece mejor rendimiento que OpenCL, OpenACC y/o las Intel Phi y eso es lo que ha llevado a la gente a CUDA. CUDA fue el primero en salir y tienes muchas herramientas d edesarrollo, muchas librerías, soporte para muchos lenguajes de desarrollo, ... En segundo lugar está Intel con sus Phi ya que tiene muchas herramientas, es compatible con x86 (en teoría basta con recompilar ... la realidad es que tienes que paralelizar el código si quieres realmente mejorar el rendimiento, igual que con CUDA), pero el rendimiento es menor. En último lugar está AMD porque carecía de las herramientas de desarrollo ... hasta ahora que ha sacado lo de GPUOPEN. Tengo los dedos cruzados esperando que ganen algo de terreno/mercado.
Hay mucho SW de terceros ya migrado a CUDA y ya sabes: da pereza cambiar/migrar/soportar OpenCL, es costoso económicamente mantener ambas opciones, si el rendimiento es peor ... el cliente no lo usará y es mala prensa, han firmado acuerdos que tendrán cláusulas determinadas, ... Por último, el cliente oye CUDA y NVIDIA en Internet, AMD casi no se oye ... ¿qué va a pedir el cliente? Lo que se oye.
Hoy en día, los que entendemos de hardware, y tambien los fabricantes de computadoras de escritorio, buscamos armar equipos con buen rendimiento, al mas bajo costo posible, terminamos eligiendo un APU de AMD. Pero parece ser, que quienes diseñan el software no se enteran de eso, y te quieren obligar a usar librerías y drivers de Nvidia, cuando en el hardware de tu computadora, no hay ni un solo chip de Nvidia. Habría que echar un vistazo a los tiempos en que las granjas de renderizado, sebasaban en procesadores AMD64: http://www.linuxjournal.com/article/6783 Pero con la diferencia en cantidad de nucleos entre GPU y CPU, obviamente, se han decantado por los GPU con el correr de los años. Pero una cosa es una granja de renderizado, y otra cosa es una computadora de escritorio. A la hora de que una empresa desarrolla software para computadoras de escritorio, debería tener en cuenta cual es el hardware que tienen esas computadoras de escritorio. No por nada, los fabricantes de consolas de juegos de primeras marcas eligen los APUs de AMD. Pero sin embargo, si una busca cual es el hardware recomendado para una estación de renderizado casera, el GPU parece ser lo que menos importa: http://blog.digitaltutors.com/building-a-home-render-farm-without-breaking-t... -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org