La técnica GPGPU (General Purpose computing on Graphics Processing Units) lleva muy poco tiempo en el mercado, y aunque su despegue es aún muy lento (y no acabo de ver porqué) parece evidente que está destinada a convertirse en todo un éxito. Y se lo merece. Hace mucho ya que se sabe que la potencia de los procesadores gráficos es muy superior a la de los procesadores de propósito general. Así, las GPUs de las nuevas ATI Radeon HD 4870 o las NVIDIA GTX 280 disponen de micros que dejan a la altura del betún a cualquier Intel Core Quad Extreme, y no digamos ya a micros dual-core modestitos.
Esta diferencia en potencia bruta era conocida, pero no aprovechable en la práctica: la GPU, para gráficos y listo, era el lema. Sin embargo, NVIDIA comenzó a poner en práctica la idea y saltó a la palestra con CUDA, un conjunto de herramientas de programación que permiten «adaptar» código de aplicaciones convencionales para que estas se puedan ejecutar en una GPU. AMD/ATI está tratando de hacer lo propio con su «Close To Metal«, mucho menos evolucionado y que está acompañado de desarrollos más prometedores, entre los que destaca sobre todos OpenCL, en el que Apple ha tenido mucho que decir.
Sea como fuere, la idea del procesamiento GPGPU es tan sencilla como increíble: poder utilizar la dantesca potencia bruta de las GPUs para procesar todo tipo de tareas convencionales, y no sólo juegos. Los primeros desarrollos CUDA ya demuestran esta potencia, y yo he probado recientemente uno, Badaboom,(este es el enlace de descarga directo de NVIDIA, con el autoinstalable de 7,90 MB) un conversor de vídeo muy limitado en opciones pero que demuestra de lo que estamos hablando.
Con este programa es posible convertir una película de DVD a formatos MP4 (perfectos para mi iPhone) en tiempos asombrosamente reducidos. Yo hice la prueba con la película «Camino a la Perdición«, que dura casi dos horas. Cogí el DVD, lo pasé a disco duro con DVDShrink, y luego cargué ese «DVD en disco» en Badaboom, que es una de las opciones recomendables para esta tarea. Después de elegir el formato y algún parámetro más, ¿sabéis lo que tardó en convertir la película gracias a mi GeForce 9600GT?
20 minutos.
¡20 minutos! Con suerte, el mismo proceso realizado por la CPU (no lo he hecho en mi Intel Core 2 Duo E8400, pero esa era la idea) llevaría, más o menos, 120 minutos, ya que la tasa de conversión de estos micros es casi casi la de «tiempo real», es decir, 25 fps, que equivalen a convertir la película en un tiempo idéntico al que dura ese film. Si con Badaboom podemos reducir ese tiempo 6 veces y la herramienta aún no está del todo pulida, no quiero ni imaginar lo que nos depara el futuro.
Actualización (14/10/2008): Manuel ha hecho la comparativa completa en su blog y ha llegado a la misma conclusión que yo, aunque en realidad la diferencia no es tanta como yo pensaba: mientras que la codificación de la película Iron Man de DVD a H.264 ha tardado 25 minutos con BadaBoom, con su Core 2 Duo 6300 le ha tardado 46 minutos usando el programa AVS Video Converter 6. Aún así, la diferencia es importante, ¿no creéis?
Lo cierto es que Badaboom no es lo que se dice una herramienta demasiado completa: no da soporte a formatos muy importantes, y las posibilidades de personalización de la compresión son casi nulas. De hecho, también lo indican así en AnadTech (son tan listos como yo), por lo que si la cosa avanza pronto deberíamos tener un software mucho más pulido y potente. Y aunque así no fuera, yo no me preocuparía demasiado: no creo que los desarrolladores tarden demasiado en darse cuenta de que sus aplicaciones pueden «volar» gracias al uso de la GPU.
Iros preparando, que la cosa promete.
Tu idea es como la de muchos: creer que las GPU son muy superiores a las CPU. Siendo sinceros, sí son superiores, pero porque están optimizados.
Si te fijas, verás que todo lo que sea instrucciones multimedia o cálculo intensivo (muy parecidos) vuelan literalmente, pero son peores en interrupciones (acceso a todo lo que es el hardware, coordinación…).
Hace poco me preguntaron por qué no se hacían ordenadores sólo con «nvidias» o «atis» (porque leyeron cosas como esta). Te animo a un artículo en el que lo expliques.
Jeje, nada más que decir. Sólo que la verdad nunca se me hubiera ocurrido que se podría usar una GPU para otra cosa que no fuera para lo que están hechas y ahora que leo esto suena bastante lógico.
En este mundillo se tiende siempre a optimizar todo al máximo y a no desperdiciar recursos, y esta era una potencia que estaba «desaprovechada», se podría decir, hasta ahora.
Buen artículo!!.
Wenas… tengo una nvidia 8600GT, y no puedo utilizar el Badaboom… me dice que no tengo un sistema compatible CUDA… solo funciona con serie 9000 o que? Gracias
No os fiéis del Badaboom, está muy, muy verde. Yo tengo una geforce 8400M GS, que es compatible con CUDA (probado en linux). Pues he instalado en Vista dos versiones beta de badaboom y no logro que funcione. He probado como entradas DVD, «carpeta dvd», y fichero, y en ninguno de los casos consige arrancar la codificación, el programa se queda sin responder y hay que forzar su cierre.
¡La leche, y yo que comentaba justo con el propósito contrario!
Perdón si te he ofendido, comentaba con el interés de que expusieses un artículo informal (es lo que me gusta de tu blog) con las ventajas e inconvenientes reales de ambas vertientes.
Y lo de Tesla no lo conocía ni de oídas, la primera noticia que tengo es esta.
Caray, espero que tu último artículo no venga por mi.
edge, pues igual tuve un momento crítico ;), pero entendí el comentario de otro modo. Me quedo con la idea del arti para el futuro, perdona pues por mi respuesta cortante, todo aclarado 🙂
Las gráficas han dado un salto BRUTAL en los últimos años… aún recuerdo mi vieja S3 por PCI, a la que sustituí por una Asus con el Riva 128 en AGP… luego vino una Voodoo 4 (que aún funciona y tengo guardada), más tarde una Geforce 4 MX 440, una ATI 9600XT (que me vendieron como Pro y resultó ser superior… 😀 ), otra ATI 1950Pro (gran tarjetón que guardo como oro en paño) y por ultimo una NVidia 9600GT (la Asus Glaciator)…
Y cuando me pongo a pensar en los juegos que ejecutaba en cada una, es para flipar con la evolución que han llevado a cabo…
La idea de usar la GPU para algo más que los gráficos es sencillamente genial, y de hecho ya se empiezan a ver ejemplos en los que se usa una vieja gráfica para Físicas con Physx por su potencia aprovechable…
Y ahora esto, usar la GPU para tareas del día a día en el PC… una forma de aprovechar mejor el HW que ya tenemos.
Tan solo me queda una duda con tu ejemplo… cuando dices que pasaste la película a MP4, ¿a qué formato fue? ¿h.264? ¿DivX? ¿Xvid?…
Lo digo porque me has despertado el gusanillo… 😀 … y como también tengo una 9600GT, estaba pensando en hacer yo también la comparativa entre este programa y pasar a DivX un DVD usando el DVDX en mi C2D 6300…
Sobre que las GPUs den patadas a las CPUs… no lo voy a poner en duda, aunque como son arquitecturas distintas las comparativas no son fáciles. Estaría bien ver una comparativa del mismo sistema con CPU y con GPU… con tareas del día a día, por ver las diferencias…
Un saludo. 🙂
Voy a dar una de cal y otra de arena, intentando ser lo mas educado posible.
Javipas, eres sabio, porque rectificar es de sabio y lo has hecho con Edge, felicidades.
Pero creo que deberias de investigar un poco mas el tema de las gráficas. Yo si conocia, algo, lo de Tesla y te digo mas o menos como Edge, las gráficas tienen mucha potencia en calculo numérico con cierto tipo de números, no sabria decirte ahora si con enteros o con coma flotante, obviamente, si en un proceso se utilizan ese tipo de números pues la gráficas ganan. Supongo que te acordaras cuando a los procesadores centrales no hacian los calculos rapiditos y se les ponia un coprocesador matemático, en definitiva un hard especializado en cálculos, y obviamente, si se escribia un programa para usar el «copro», pues volaba, comparado con la cpu principal, tambien puedes hacer programas aprovechando ciertos juegos de instrucciones de las cpu principales, aquello de las mmx, los sse o como se llamen, pero no se hace mucho, porque hay que empezar a preguntar al hard que tipo de instrucciones soporta, crear distinto código en función del juego de instrucciones especiales que usen, en fin, un follón.
Por otra parte ten en cuenta que tu procesador central, cuando le dices que te pase la «peli» a mp4, esta haciendo bastante mas cosas aparte de esto, en el caso de la gráfica supongo que no hace solo lo de la peli pero casi.
Cuando dicen que el código esta optimizado es cierto, tambien es verdad como tu lo dices, adaptado, si lo prefieres, pero es que esta adaptación es pensando en las especificadiones del hardware que tiene debajo, o sea, la gráfica y su especialización en cierto tipo de cálculos y su arquitectura. Probablemente esta adaptación sea a medias entre el programador y el compilador, a ti te parece C, vamos es C, pero el compilador (no creo que sea un interprete), hara virguerias para adaptarlo a código de la gráfica, o sea, que lo optimiza.
En hard siempre se da la lucha entre especializacion y generalizacion, una máquina que se apoyó en la especializacion fue el Amiga y ahi lo tienes, muerto de asco, (te vendo mi Amiga 500), eso si, increible lo que hacia, llegaron los pc con su «cutre-hard» generalista y se lo comieron. En las consolas, la ps3 es un poco mas especializada y por tanto mas dificil de programar y la xbox 360 se la esta merendando con un hard mas general (PPC(+ o -) y grafica). Lo mismo paso, si no me equivoco, con la sega dreamcast y las consola de su generación, por eso te digo que siempre ocurre. Al final lo que ha pasado es que estas especialidades se integran en la cpu, y por lo tanto, pasa a generalizarse y se acabo el problema. En la actualidad no se que ocurrira por que el hard de las gráficas es tan potente que no se si volverá a pasar.
Un saludo.
Por ahí anda un programa que usa tarjetas Nvidia para acelerar la búsqueda de contraseñas. No tengo el enlace a mano, pero salió en kriptopolis. Lo que no me quedó claro es si usan cuda, pero los tipos logran incluso usar varias tarjetas en paralelo y dejan muy atrás a un Core Duo.
Hola, creeis que seria factible sacar password WPA con el progrema «elcomsoft password recovery «, y varias GTX280 en SLI? Segun la pagina de elcomsoft con este software y usando las Nvidia se pueden sacar.
¿Algun documento o prueba de que esto es posible?, toy buscando pero no encuentro nada.
Un saludo
Pues haré la prueba, cuenta con ello… en cuanto me quite un marrón del curro.
Sobre lo que comenta LC, efectivamente las arquitecturas son distintas… y las GPUs ganan en manejo de coma flotante por todas las unidades shader que montan. Por eso lo ideal sería un PC con CPU y otro con GPU y una buena tanda de test que pasarles… 😀
Sobre lo del Amiga… no estoy de acuerdo, más que por la especialización, yo creo que al Amiga se lo cargaron por el enfoque que le dieron. Del Amiga recuerdo que te lo vendían para ‘jugar’ (aunque pudiese hacer más), y del PC que te lo vendían para trabajar (más serio).
Además, en el mundo PC empezó a haber un gran desarrollo… del 8088 pasamos al 8086, de ahí al 286 y un año o dos ya estábamos en el 386… y al poco los 486, que en comparación con los primeros PCs eran mucho más potentes.
Si el Amiga se hubiese enfocado para más que juegos, buscando un uso profesional, y hubiese mejorado tanto su HW en tan poco tiempo, otro gallo le hubiese cantado…
Manuel, genial tu comparativa, enhorabuena, la enlazo en el post para actualizarlo. La verdad es que la CPU tarda bastante menos de lo que pensaba, pero aún así, ahorras la mitad de tiempo. ¡Buen trabajo!
Gracias por el enlace Javi, en realidad el mérito es tuyo por la idea… 🙂
Nah, nah, te has currado las pruebas, así que ole con ole 😉
Hago un inciso tardío del comentario de JaviPas del 10 de Octubre de 2008 (perdón por el retraso) {
El proceso de «traducción» de un lenguaje de alto nivel (pongamos C/C++) se lleva a cabo por un conjunto de procesadores de lenguaje y herramientas que a grosso modo se pueden dividir en:
1. El preprocesador: se encarga de parsear el código fuente y resuelve las macros, defines, includes (librerías estáticas), inlines, que puede haber.
2. El compilador: se encarga de traducir a código ensamblador nativo de la arquitectura el código de alto nivel. En este proceso, se realizan optimizaciones, reordenaciones de código, desenrrollado de bucles, sin alterar el significado semántico obviamente. La salida es el código objeto (instrucciones binarias).
3. El linkador: se encarga de recoger todos los ficheros objeto (código objeto), introducir los stubs para acceso en tiempo de ejecución a librerías dinámicas y crear el ejecutable.
}
Moraleja: el compilidador SI que optimiza código para la GPU.
Ala, a pasarlo bien.