Portada
mis comunidades
otras secciones
#2:
Pero hay que entender que las GPU están optimizadas para labores concretas (cálculos con coma flotante, acceso a la memoria de la gráfica...).
Una CPU tiene propósito general. Aparte de tener que lidiar con el resto del hardware y la memoria, tiene que estar corriendo un sistema operativo. Hay que entender que para conseguir esto haya que perder velocidad.
Una CPU tiene propósito general. Aparte de tener que lidiar con el resto del hardware y la memoria, tiene que estar corriendo un sistema operativo. Hay que entender que para conseguir esto haya que perder velocidad.
#5:
#3 Yo tengo entendído que sí que va por ahi
Por lo poco que se da en la uni al respecto, las GPU's están especializadas en hacer cálculos masivamente paralelos y con pocas bifurcaciones (saltos condicionales). En algun comentario de no se donde ¿slashdot quizas? también comentaban que las GPU's vienen acompañadas de mucha RAM de acceso bastante más rápido que la memoria principial, pero traer y llevar datos de la RAM de sistema a la de vídeo también significar una penalización importante, por lo que los datos necesarios para las tareas que calcules en la GPU han de caber en la RAM de video. Esto sirve para trabajos concretos, como por ejemplo los algoritmos de renderizado en 3D. ¡Anda! ¡Justo para lo que están fabricadas!
Conclusión: nada nuevo bajo el sol. Una CPU de propósito general sigue siendo más rapida para tareas 'normalitas', por ejemplo correr el sistema operativo. Una GPU es más rapida para renderizar en 3D y operaciones similares.
Por lo poco que se da en la uni al respecto, las GPU's están especializadas en hacer cálculos masivamente paralelos y con pocas bifurcaciones (saltos condicionales). En algun comentario de no se donde ¿slashdot quizas? también comentaban que las GPU's vienen acompañadas de mucha RAM de acceso bastante más rápido que la memoria principial, pero traer y llevar datos de la RAM de sistema a la de vídeo también significar una penalización importante, por lo que los datos necesarios para las tareas que calcules en la GPU han de caber en la RAM de video. Esto sirve para trabajos concretos, como por ejemplo los algoritmos de renderizado en 3D. ¡Anda! ¡Justo para lo que están fabricadas!
Conclusión: nada nuevo bajo el sol. Una CPU de propósito general sigue siendo más rapida para tareas 'normalitas', por ejemplo correr el sistema operativo. Una GPU es más rapida para renderizar en 3D y operaciones similares.
#12:
#9 GPGPU es el nombre genérico de programación general (no graficos) en targetas gráficas
CUDA es un lenguaje de programación basado en C que simplifica un poco trabajar con una targeta gráfica, pero limita un montón los posibles algoritmos que se pueden hacer. De hecho mucha gente ignora CUDA y usa los shaders de OpenGL para hacer lo mismo, la única diferencia es que con los shaders tienes que tener una "ventana invisible" y por lo tanto estar corriendo algun entorno de ventanas. De hecho el software que he desarrollado últimamente tiene dos versiones, una CUDA y otra OpenGL, comparten el 90% del código, y la version OpenGL es un 10% más rápida.
OpenCL es solo un rename de CUDA. Es un acuerdo de caballeros para que ATI no admita que no ha sabido crear su propio lenguaje y se vea obligada a usar CUDA. Apple ha sacado partido de ello diciendo que lo ha inventado y que permite accelerar todo 100 veces, que es mentira.
Comparando GPU's y CPU's no tiene mucho sentido. Una GPU es un tren, puede mover miles de personas de A a B, siempre que todas salgan a la vez, lleguen a la vez, y tarden un montón en subir y bajar. La CPU es un coche, solo caben 4, pero es mucho más ágil.
Hay cosas (pocas) que van muy bien en GPUs, como la mayoria de procesos gráficos y algo de procesado de datos, pero decir que se pueden convertir todos los algoritmos a GPU es una tontería!
CUDA es un lenguaje de programación basado en C que simplifica un poco trabajar con una targeta gráfica, pero limita un montón los posibles algoritmos que se pueden hacer. De hecho mucha gente ignora CUDA y usa los shaders de OpenGL para hacer lo mismo, la única diferencia es que con los shaders tienes que tener una "ventana invisible" y por lo tanto estar corriendo algun entorno de ventanas. De hecho el software que he desarrollado últimamente tiene dos versiones, una CUDA y otra OpenGL, comparten el 90% del código, y la version OpenGL es un 10% más rápida.
OpenCL es solo un rename de CUDA. Es un acuerdo de caballeros para que ATI no admita que no ha sabido crear su propio lenguaje y se vea obligada a usar CUDA. Apple ha sacado partido de ello diciendo que lo ha inventado y que permite accelerar todo 100 veces, que es mentira.
Comparando GPU's y CPU's no tiene mucho sentido. Una GPU es un tren, puede mover miles de personas de A a B, siempre que todas salgan a la vez, lleguen a la vez, y tarden un montón en subir y bajar. La CPU es un coche, solo caben 4, pero es mucho más ágil.
Hay cosas (pocas) que van muy bien en GPUs, como la mayoria de procesos gráficos y algo de procesado de datos, pero decir que se pueden convertir todos los algoritmos a GPU es una tontería!
#9:
#5 No todo es la universidad ... de hecho la universidad es un sitio donde el alumno obtiene "saber preprocesado" y dada la velocidad de avance de la tecnología, carreras como informática, incluso en los planes de estudios más modernos suelen estar desfasados bastante rápido.
Las tecnologías GPGPU, como CUDA y OpenCL, permiten la computación de propósito general en entornos de GPU, de hecho OpenCL permite la bifurcación del proceso entre CPU y GPU en función del propósito a desempeñar.
Sobra decir que el uso de una GPU desde luego no es hacer un "hello world", pero sin duda la aplicación de la tecnología GPGPU es interesante en muchísimos campos donde hace falta capacidad de computación paralela y donde desde luego mejora muchísimo a las CPU, tanto en coste como en rendimiento.
Por citar algunos ejemplos interesantes:
- Gnort ( una evolución del IDS snort aplicando GPU )
- Optimización de operaciones en PostgreSQL usando CUDA
- EWSA, cracking de WPA/WPA2 usando GPU.
Las tecnologías GPGPU, como CUDA y OpenCL, permiten la computación de propósito general en entornos de GPU, de hecho OpenCL permite la bifurcación del proceso entre CPU y GPU en función del propósito a desempeñar.
Sobra decir que el uso de una GPU desde luego no es hacer un "hello world", pero sin duda la aplicación de la tecnología GPGPU es interesante en muchísimos campos donde hace falta capacidad de computación paralela y donde desde luego mejora muchísimo a las CPU, tanto en coste como en rendimiento.
Por citar algunos ejemplos interesantes:
- Gnort ( una evolución del IDS snort aplicando GPU )
- Optimización de operaciones en PostgreSQL usando CUDA
- EWSA, cracking de WPA/WPA2 usando GPU.
#6:
Por eso AMD va a hacer un "chip" que une ambas, lo ha llamado FUSION, y es el futuro inmediato, nenas.
Comentarios
Pero hay que entender que las GPU están optimizadas para labores concretas (cálculos con coma flotante, acceso a la memoria de la gráfica...).
Una CPU tiene propósito general. Aparte de tener que lidiar con el resto del hardware y la memoria, tiene que estar corriendo un sistema operativo. Hay que entender que para conseguir esto haya que perder velocidad.
#2 Realmente no van por ahí los tiros porque, como por ejemplo bien dice la noticia, puedes hacer correr software no optimizado también en las GPU's .
Yo me iría más a comparar el tamaño, consumo, TDP y, por lo tanto, temperatura, etc, etc. Si Intel se pasara por el forro todo eso también haría procesadores muchísimo más potentes.
#3 Yo tengo entendído que sí que va por ahi
Por lo poco que se da en la uni al respecto, las GPU's están especializadas en hacer cálculos masivamente paralelos y con pocas bifurcaciones (saltos condicionales). En algun comentario de no se donde ¿slashdot quizas? también comentaban que las GPU's vienen acompañadas de mucha RAM de acceso bastante más rápido que la memoria principial, pero traer y llevar datos de la RAM de sistema a la de vídeo también significar una penalización importante, por lo que los datos necesarios para las tareas que calcules en la GPU han de caber en la RAM de video. Esto sirve para trabajos concretos, como por ejemplo los algoritmos de renderizado en 3D. ¡Anda! ¡Justo para lo que están fabricadas!
Conclusión: nada nuevo bajo el sol. Una CPU de propósito general sigue siendo más rapida para tareas 'normalitas', por ejemplo correr el sistema operativo. Una GPU es más rapida para renderizar en 3D y operaciones similares.
#5 No todo es la universidad ... de hecho la universidad es un sitio donde el alumno obtiene "saber preprocesado" y dada la velocidad de avance de la tecnología, carreras como informática, incluso en los planes de estudios más modernos suelen estar desfasados bastante rápido.
Las tecnologías GPGPU, como CUDA y OpenCL, permiten la computación de propósito general en entornos de GPU, de hecho OpenCL permite la bifurcación del proceso entre CPU y GPU en función del propósito a desempeñar.
Sobra decir que el uso de una GPU desde luego no es hacer un "hello world", pero sin duda la aplicación de la tecnología GPGPU es interesante en muchísimos campos donde hace falta capacidad de computación paralela y donde desde luego mejora muchísimo a las CPU, tanto en coste como en rendimiento.
Por citar algunos ejemplos interesantes:
- Gnort ( una evolución del IDS snort aplicando GPU )
- Optimización de operaciones en PostgreSQL usando CUDA
- EWSA, cracking de WPA/WPA2 usando GPU.
#9 Vamos a ver, que estáis diciendo lo mismo, creo yo.
1 - Tenemos claro que las GPU están optimizadas para un tipo de tarea, y por eso son más rápidas en esas tareas.
2 - Eso no quiere decir que no sean capaces de hacer otras cosas, claro. Entre esas otras cosas hay algunas que se parecen (por la forma de ejecutarlas) a las de gráficos para las que han sido optimizadas. Por eso también son más rápidas en algunas otras cosas.
3 - Entonces... ¿es mejor una GPU en lugar de tu CPU normal para tu portátil? Pues no. Porque hay otras muchas cosas, hoy en día más frecuentes en un uso normal y cotidiano del ordenador, en las que el propósito general de las CPU es una ventaja.
EJEMPLO PARA TODOS LOS PÚBLICOS:
¿Es mejor coche un Ferrari que una Kangoo? Pues depende. ¿Para qué lo vas a usar? ¿Para correr mucho? El Ferrari. ¿Para hacer la compra todos los días, llevar la herramienta del trabajo, hacer la mudanza...? Pues la Kangoo, que además es más barata, consume menos gasolina, es más barato el seguro...
#11 ¿Ferrari vs Kangoo? Siempre puedes tener algo como esto:
#9 GPGPU es el nombre genérico de programación general (no graficos) en targetas gráficas
CUDA es un lenguaje de programación basado en C que simplifica un poco trabajar con una targeta gráfica, pero limita un montón los posibles algoritmos que se pueden hacer. De hecho mucha gente ignora CUDA y usa los shaders de OpenGL para hacer lo mismo, la única diferencia es que con los shaders tienes que tener una "ventana invisible" y por lo tanto estar corriendo algun entorno de ventanas. De hecho el software que he desarrollado últimamente tiene dos versiones, una CUDA y otra OpenGL, comparten el 90% del código, y la version OpenGL es un 10% más rápida.
OpenCL es solo un rename de CUDA. Es un acuerdo de caballeros para que ATI no admita que no ha sabido crear su propio lenguaje y se vea obligada a usar CUDA. Apple ha sacado partido de ello diciendo que lo ha inventado y que permite accelerar todo 100 veces, que es mentira.
Comparando GPU's y CPU's no tiene mucho sentido. Una GPU es un tren, puede mover miles de personas de A a B, siempre que todas salgan a la vez, lleguen a la vez, y tarden un montón en subir y bajar. La CPU es un coche, solo caben 4, pero es mucho más ágil.
Hay cosas (pocas) que van muy bien en GPUs, como la mayoria de procesos gráficos y algo de procesado de datos, pero decir que se pueden convertir todos los algoritmos a GPU es una tontería!
#12 ATI si tiene su propio lenguaje.
http://www.amd.com/US/PRODUCTS/TECHNOLOGIES/STREAM-TECHNOLOGY/Pages/stream-technology.aspx
#16 Perdon, no quería decir que ATI no tenga un lenguaje, digo que ATI fracasó en su intento de que la gente usara su lenguage.
ATI lo intentó primero con Close-To-Metal, luego AMD intentó relanzarlo llamándolo Stream el 2007, y como nadie lo usaba, el 2009 Ati lanzó Stream 2.0, que es un intérprete de OpenCL.
#12 Bueno hablas de mentiras y no das tu mismo ni una es irónico, por ejemplo mira lo que te ha dicho #16, OpenCL es un estándar propuesto por la Khronos Group y Apple está dentro de la misma, no se si será verdad lo que comentas que anda diciendo Apple, pero en ese caso sería una verdad, aunque lógicamente no son los únicos que han tenido que ver en ello y sería una afirmación desafortunada por su rotundidad, pero bueno, ya todo el mundo sabe que se puede esperar de Apple y como juega.
#6 Cuando me enteré de que va a haber versiones de bajo consumo, empecé a ansiar que salgan para probarlo y ver si se cumple la previsión, ese integrado solo lo ha podido hacer amd, intel le falta capacidad para desarrollar arquitecturas de hardware de gpu y a nvidia le falta el darle a las cpu.
#22 Apple en su nota de prensa de lanzamiento, dijo que con el nuevo Snow Leopard y OpenCL, los programas normales irían muchisimas veces más rapido que antes gracias a usar la GPU, sin recompilación ni nada.
Luego se han echado atras y lo han arreglado, per supuesto.
Apple, igual que microsoft y muchos otros, estan en la Khronos Group, básicamente para proteger su derecho a la tecnología. No tiene nada que ver con el grupo de video en que lo tienen todo patentado.
#22 Apple ha metido mano en el desarrollo de OpenCL quieras o no, deja de darle vueltas, a mi tampoco me gusta esa empresa por ciertas cosas pero a cada uno lo suyo (esto mismo tenía que afirmar cuando se hablaba sobre microsoft hace tiempo, curiosamente como se dice parece que apple empieza a ser la nueva microsoft)
Creo que esta comparativa es como decir que la diarrea es más rápida que la velocidad de la luz (como decía el chiste).
Cada uno se dedica a cosas distintas así que no son comparables. Cuando vea un S.O. corriendo en una GPU, hablamos.
Si hablamos de gráficos, física y cálculos matriciales en general, sí, las GPU ganan por goleada pero en procesamiento general, 480 stream-engines a 750Mhzs aprox. son muchíiiiiiiisimo más lentos que 4-6 cores (8-12 threads) a 3Ghzs, para el propósito general. Eso, siempre que fuese posible hace un port de un S.O. actual a esos procesadores (una parte de la interfaz debería ser procesada por un chip de placa base específico, puesto que las GPUs son casi exclusivamente procesadores matemáticos)
En resumen, churras con merinas.
#12 Gran comparación la de los trenes y los coches.
#3
Uno de los motivos por los que es un coñazo programar para el Cell de la PS3 es que aparte de ser una arquitectura heterogénea los SPEs son algo parecido a los stream processors de una GPU, lo que significa que para hacer código de propósito general es bastante mierda. Y por eso casi siempre los problemas de rendimiento están en PS3 cuando se trata de hacer un título multiplataforma (véase la Orange Box por ejemplo). Requiere mucho esfuerzo adicional que las productoras de videojuegos no quieren hacer cuando tienen el mercado de PC y Xbox 360.
Otro ejemplo es el nuevo MMORPG del Final Fantasy que llegará en septiembre a PC y en marzo del año que viene a PS3. Normalmente los retrasos suelen ser por desarrollo, más que decisiones estratégicas.
#9
OpenCL es un wrapper para facilitar un poco la tarea de ejecutar código de proposito general en procesadores totalmente paralelos (las GPUs).
#26
Normalmente los retrasos suelen ser por desarrollo, más que decisiones estratégicas.
Me explico: dan más tiempo a PS3 porque requiere más tiempo de desarrollo, y no porque sea una decisión estratégica para sacar primero toda la pasta posible en PC (al fin y al cabo el PC es el rey del online).
Vale #9 entonces, si en las universidades no vale lo que te enseñan sobre tecnología, que hacemos? Voy a mandar una carta al gobierno para que quiten ese tipo de estudios de las universidades, porque no sirven para nada!!! Donde hemos ido a parar eh... Habrá que avisar a los miles de estudiantes españoles de informática, electrónica y demás carreras tecnológicas!! Que están tirando los días de su vida a la basura!!
Menudo argumento muchacho... Que no estén actualizados los cursos a diario es lo más normal del mundo, el plan de estudios de toda una carrera no puede estar renovándose cada día, es algo simplemente imposible... Otra cosa es que los profesores y alumnos estén al día en cuanto a noticias, avances, etc.. y se comenten allí, que es lo normal no?
#38 Mi argumento, que por cierto, no sé muy bien de donde estimas que soy un muchacho, y no una muchacha o un perro con lunares, exclusivamente hace referencia a una apreciación del comentario #5, en la cual un alumno de una universidad comenta sobre su saber universitario entorno tecnología GPGPU. Y simplemente le matizo que el uso de la GPU tiene aplicaciones más allá del puro "procesamiento gráfico 3D" y que poco a poco aparecen tecnologías como openCL que permiten la integración de GPU/CPU, algo que a poco que estudiase "tecnología de computadores" hace 2 años, es posible que ni haya visto.
Por último, tu sarcasmo, no sé muy bien a cuento de qué, parece que intenta hacer por natural un hecho que a mi personalmente me parece nefasto: el docente español de una asignatura donde se ve tecnología aplicada, prefiere, en un número elevado de casos, reelaborar el temario cada 5 años, que actualizarlo y completarlo año a año, transmitiendo a su alumnado avances y mejoras, y descartando tecnologías obsoletas ( nunca, desde luego, principios básicos y fundamentales ).
Por ello una carrera debe tener, sin duda, un nucleo teórico sobre el que descansen los conceptos aplicados, pero desde luego, a mi nunca me parecerá de recibo que asignaturas aplicadas, como puedan ser redes, sistemas operativos, tecnología de computadores o ingeniería del software, por citar algunas, hayan seguido impartiendo cosas tan interesantes como "la norma v.34", "la arquitectura de un sistema operativo en modo real: msdos", "el ensamblador del 8086" o "métrica 2", hasta que Bolonia les ha obligado a cambiar planes y temarios.
Espero que al menos, tras este cambio, realmente cambie el espíritu de la universidad y sobre todo el grueso del profesorado universitario entienda la importancia del trabajo diario ( el mismo que van a exigir a sus alumnos ) y que dejen de una vez por todas de justificar que fuera de los principios teóricos tiene cabida mantener un temario sin actualizar durante 4, 5 o incluso 10 años.
#42 enseñan eso por que es lo más fácil didácticamente hablando.
De dónde viene la pila, el código ensamblador x86 (sin historias de SSE ni cosas raras), etc etc...
Justamente en la universidad no te enseñarán nada inmediatamente práctico. PAra eso está la FP donde te enseñan a programar en un lenguaje concreto o a administrar un sistema.
En la universidad te dan la base teórica a partir de la cúal deberías ser capaz de aprender cualquier cosa que esté basado en ello.
Es por eso por ejemplo que en los exámenes te dejan tener apuntes: te plantean un problema que tienes que resolver con las bases teóricas aprendidas. No tienes que memorizar como un loro.
Aunque luego está el profe que no cambia el temario porque le supone "demasiado" trabajo, pero bueno, ese es otro tema...
A mí por ejemplo me explicaron la estructura del 8086. Luego me mandaron un trabajo comparativo del Opteron contra el Xeon y luego un estudio del cambio de paradigma del Itanium.
saludos.
#43
Es por eso por ejemplo que en los exámenes te dejan tener apuntes: te plantean un problema que tienes que resolver con las bases teóricas aprendidas. No tienes que memorizar como un loro.
Oye, are you sure?
Hablando del tema, lo que yo he visto en mi facultad por norma general está bastante actualizado y cada año siempre andan modificando transparencias o añadiendo cosas nuevas (al menos en las asignaturas que tienen que ver más con el hardware).
#42 Pues bueno, si alguien de nick llamamepanete , que al menos de momento soy capaz de diseccionarlo y separarlo en "Llámame Panete",y me dicen que es mujer, o un perro con lunares que escribe en Internet, desde luego me sorprendería, no se a ti, y si eres lo segundo, me interesa conocerte más, creo que serías una rareza
Luego, sé perfectamente a que te referías con lo de responderle a #5, por eso te he contestado citándote, y como tengo una opinión diferente, pues la he expuesto, a demás de que sigo opinando igual. Y el sarcasmo venía por lo de que las universidades "se supone" que son el conocimiento, si no aprendes allí...
#1 Te vas de listo y no tienes ni idea. Toma nota de #2 y estudia un poco la arquitectura de los ordenadores antes de abrir esa bocaza.
#7 Joder tío, parece que #1 se haya cagado en toda tu familia y haya matado a tu gato. A ver, que simplemente ha hecho un comentario (desafortunado); no creo que el chaval se merezca ese desprecio por tu parte, no?
#27 Empleo el mismo tono que él emplea con #0.
#2 Lo has explicado en un lenguaje para profanos tan perfectamente que hasta yo lo he entendido
#2 en slashdot decian tb que un chip de un cisco de los tochos era capaz de mover tropecientos gb de datos por segundo, y millones de paquetes y filtrarlos y toda la pachanga en tiempo real, al mismo tiempo que consumen menos de 1W. Ni una GPU ni una CPU podrian hacerlo. Y es la diferencia entre tener un procesador programable capaz de correr muchos tipos de codigo diferente, a tener uno hecho a medida para una sola tarea. Cada uno tiene su espacio y hueco en el mercado
Por eso AMD va a hacer un "chip" que une ambas, lo ha llamado FUSION, y es el futuro inmediato, nenas.
#6 Cierto, salió hace no mucho en portada de esta misma web. Por lo tanto, relacionada: Fusion, la posible venganza de AMD
Fusion, la posible venganza de AMD
diegocg.blogspot.com#6 y #29 Tengo curiosidad por saber si realmente será tan bueno, y si tener una GPU integrada en la CPU permitirá tener una segunda GPU en la placa y aprovechar el rendimiento de ambas.
Si no es así, no será gran cosa, porque cualquier GPU realmente potente necesita muchos recursos (espacio, energía, y por tanto disipación) que no se pueden meter como un núcleo.
#32 Teniendo en cuenta el artículo de wikipedia: http://es.wikipedia.org/wiki/AMD_Fusion parece ser que la integración tendría lugar diferenciando cuatro aspectos:
obviamente, de momento se trata de un prototipo que, además, tiene las especificaciones cerradas para que sus competidores no puedan hacer nada.
* Propósitos generales.
* Centrado en datos.
* Centrado en gráficos.
* Centrado en medios.
Esto que significa? Pues sinceramente... no lo se
#6 #29 Intel lleva con Larrabee (http://es.wikipedia.org/wiki/Larrabee_(GPU)) que es un concepto similar y esta "aparcado" porque no tienen ninguna ventaja
#39 Larrabee es varpoware en si mismo. En teoría era una GPU hecha a base de poner CPU's en paralelo. Una idea ridícula que ha demostrado ser una tontería muy cara que no sirve para nada.
No es ni remotamente parecido a lo que hace AMD con Fusion, que es un chip que hace de CPU y GPU a la vez.
#39 Eso no será porque Intel no tiene una buena GPU??
Es como comparar que es más rápido para cortar un árbol 1000 tijeras o un hacha
Explicado para tontos como yo: http://www.genbeta.com/multimedia/que-es-eso-de-la-aceleracion-por-gpu
Simplemente GPU y CPU no son en absoluto competencia, las comparaciones son interesantes, pero hablar de que una es "mas rápida" que otra en general tiene poco sentido
Mi proyecto fin de carrera trata sobre eso mismo, la comparación de la velocidad de una GPU (en este caso trabajo con CUDA en una nVidia) y la CPU. En este caso, se trata de comparar el rendimiento a la hora de subdividr mallas en 3D.
Tal y como está organizada la GPU, la capacidad de paralelización de las operaciones le da mil vueltas a la CPU, aunque hacer un código optimizado no es nada fácil. Como he leído en algunos comentarios, mientras no haya saltos y se dedique a hacer operaciones matriciales masivas, la GPU gana por goleada de una forma apabullante (hace los mismos cálculos que la CPU en órdenes de magnitud 3, 4 ó más veces inferior) Pero en cuanto al trabajo de gestión de recursos, a escritura en memoria y demás, la CPU consume menos tiempo.
Obviamente, correr 64 threads por cada bloque de la GPU da una potencia muy basta, pero hacer código optimizado para sacarle provecho es harto difícil (hasta la anterior versión a la actual, la shared memory (algo así como la caché) había que manejarla sí o sí a mano, y os aseguro que es un antro-guión-infernal)
Así que sí, son mucho más rápidas en operaciones matemáticas básicas (sumas, restas, multiplicaciones) por el alto grado de paralelismo, pero en cuanto a manejo de memoria, temperatura, consumo y dificultad a la hora de programas para ellas, son un infierno.
Creo que lo importante es ser conscientes de que en las GPUs se consigue potencia a costa de flexibilidad.
paradógicamente...? :-m
En esencia, una GPU es una matriz de coprocesadores matemáticos en que hay una serie de fórmulas (aquellas que se utilizan en la creación de gráficos 3D) que están hardodeadas. Aquellos algoritmos que puedan utilizar estas fórmulas o trabajar en paralelo podrán ejecutarse a velocidades muy altas; en cambio, si el algoritmo no puede sacar partido de estas características, entonces no proporcionará una mejora apreciable de rendimiento.
Un buen ejemplo es el supercomputador chino Nebulae, un ordenador que combina CPUs con GPUs. Este ordenador consigue picos de 2984 TeraFlops, pero su rendimiento promedio es de 1271 TeraFlops.
No puede faltar el video de mythbusters en un meneo de este tema
Nadie más se ha mareado leyendo con ese tipo de letra??
Consulta ¿que GPU's vienen llevando las consolas de esta generación? ¿alguna nvidia?
#10 La PS3 monta el RSX de Nvidia, un chip muy similar a las 7800GTX de la época. No se qué capacidades GPGPU tiene pero debe ser difícil explotarlas en una consola. Otra cosa es el Cell.
http://en.wikipedia.org/wiki/RSX_%27Reality_Synthesizer%27
http://www.xataka.com/ordenadores/nvidia-tesla-procesadores-graficos-de-alto-rendimiento-para-calculos
http://www.nvidia.com/object/product_tesla_M2050_M2070_us.html
Para ampliar la noticia y hacerla menos amarillista:
http://www.pcworld.com/article/199850/battle_lines_drawn_over_parallel_processing.html
Hace un rato pense: "Voy a leer un rato meneame para distraerme, que estoy mareado con la practica de programacion en GPU con OpenCL"
Anda que si...
(no pongo acentos porque estoy en un ordenata aleman)
En cálculos cuánticos y de estructura electrónica, base de la química y física computacionales, las GPUs son sin duda el futuro. La preparación de algoritmos eficientes permiten obtener resultados hasta 600 veces más rápidos que calculando con el mismo número de CPUs en paralelo. Es cierto que hay problemas de espacio, refrigeración, etc. que hacen los clústeres más costosos, pero todo eso se ve compensado por la capacidad de trabajar con moléculas enormes a unos niveles de cálculo impensables en CPUs.
El grupo de química teórica del professor Todd Martínez, de la universidad de Stanford, es el pionero en la implementación de programas de cálculo en GPUs.
Algo más de información:
http://mtzweb.stanford.edu/research/gpu/
http://www.nsf.gov/discoveries/disc_summ.jsp?cntn_id=115176&org=CHE
y para quien tenga acceso al JCTC:
http://pubs.acs.org/doi/abs/10.1021/ct700268q
Yo no soy informático ni programador ni ingeniero. Pero esto no es normal ? Yo en mi curro tengo unidades donde solo hay tarjetas gráficas en SLI y esas unidades son las encargadas de procesar todos los cálculos de render. Mucho mas rápido que el antiguo server ( que era todo un bicho
)
¿No fastidies? ¿Igual es por eso que hace más tantos años que los ordenadores traen tarjetas gráficas potentes para hacer los cálculos necesarios para los juegos, en vez de hacer esos cálculos en la CPU?