Tema: Físicas por CPU: AVX vs SSE

oson... esto del avx fue un gran acierto, lo que me llega a la cabeza es como tomara esto Nvidia... y cini intentara con su marketing contrarrestar esto. esperando nuevas diapositivas fisicas por gpu de nvidia en 3..2 ...1...

Me esta tentando intel pasarme a su plataforma con sus sandy bitch xDDD, uta que son monstruosos xDD

Iniciado por 3k.mark.3k

Me esta tentando intel pasarme a su plataforma con sus sandy bitch xDDD, uta que son monstruosos xDD

Tentador, pero falta el golpe de AMD, depende de eso a ver quien se lleva la corona esta vez. (le tengo fe a AMD, vamos que estan haciendo un buen trabajo -No se dejen guiar por mi firma )

ahora los cpu de programacion general estan (estaran) haciendo la pega de un gpu (o su chip aliado) y los gpu estan haciendo parte de la pega de los cpu.
falta poco para que los computadores vengan con un SoC que reemplazandolo va a llegar un upgrade completo.
aparte, nvidia

Iniciado por virustec

oson... esto del avx fue un gran acierto, lo que me llega a la cabeza es como tomara esto Nvidia... y cini intentara con su marketing contrarrestar esto. esperando nuevas diapositivas fisicas por gpu de nvidia en 3..2 ...1...

Desde el lanzamiento de las instrucciones SSE no salia un cambio que potenciara el poder de cálculo vectorial en los CPU x86, AVX es el 1º cambio importante desde SSE y es de suponerse que en los próximos meses los nuevos softwares les saquen provecho, y viendo estas demos es obvio que Havok será uno de los primeros softwares compilados para aprovechar AVX y su mayor poder de cálculo, ello sumado al soporte de hasta 16 núcleos que ofreció Intel (actualmente Havok está limitado a 6 núcleos) podrían hacer de Havok un serio rival ante las físicas por CPU (PhysX y las próximas Bullet y DMM de AMD), a la vez que dejará en muy mala posición a PhysX por CPU el cual aún continua usando x87 (aunque el nuevo SDK con soporte a SSE debe salir dentro de poco, pero Nvidia nada ha mencionado sobre el soporte AVX).

En cuanto al marketing ya veremos, pero con su nuevo acuerdo dudo que Intel y Nvidia se muestren las uñas por un tiempo, aunque Intel ya tiene casi listo su OpenCL por AVX, aún se desconoce si gracias al acuerdo también implementará CUDA por AVX (aunque Nvidia CUDA x86 usará SSE), en fin con la evolución de los conjuntos de instrucciones vectoriales en los CPU x86 algunas aplicaciones GPGPU irán perdiendo sentido; aunque la idea de AMD de en un futuro reemplazar las instucciones vectoriales por implementaciones basadas en sus núcleos gráficos suena como una sólida apuesta a futuro, me imagino que ello algo tuvo que ver para que Intel decidiera realizar dicho acuerdo con Nvidia.


Saludos

Interesante ver como Intel sigue desarrollando sus tecnologías y las va homologando a otras para que mas aplicaciones hagan uso de estas, espero que Physx sea compilado para AVX y de esta forma mas desarrolladores de juegos se interesen en tomar esta herramienta y se atrevan a implementarlas en sus juegos.

Esto solo es valido para Intel Sandy Bridge y AMD Bulldozer?

De ser así significa que yo con mi Phenom IIX6 no voy a poder disfrutar de esto

El artículo parece salido del departamento de marketing de Intel. La diferencia en rendimiento absoluta entre SSE y AVX no es tan grande.

SSE 128-bits: 72 FPS
AVX 128-bits: 82 FPS
AVX 256-bits: 85 FPS

Lo de SSE 256-bits es una emulación, pero no un caso real ya que eso no existe. El mejor caso para ambos set de instrucciones se separa por sólo un 18%. AVX no es el doble de SSE. Y que no vengan con la falacia que el código del futuro va a venir optimizado para 256-bits, los CPUs que no soportan AVX sólo tienen registros de 128-bits, y estos requerirán un camino especial codificado para ellos. El que se de la lata de programar utilizando instrucciones especiales, se va a dar la lata de elegir el mejor camino para la arquitectura de destino. Siempre ha sido así hasta ahora y eso no cambiará. Las instrucciones AVX tienen ventajas, pero la diferencia es notoria en otros casos de uso, especialmente en el área que requiere cálculos con números de 64-bits de precisión como el trabajo científico, en donde probablemente sea más rápido usar una GPU Tesla, pero es debatible.

Los cálculos de física son principalmente en vectores de 4 componentes con matrices de transformación de 4x4 (Si no sabes por qué, estudia Álgebra Lineal). Dado que la precisión por defecto en la industria es de 32-bits (64-bits no tiene sentido en un juego ya que las tarjetas de video de consumidores soportan sólo 32-bits o son mucho más lentas con 64-bits de precisión, y ellas son las que dibujan estos vectores). Con 128-bits alcanza para meter un vector de 4 componentes justo. Como los cálculos se realizan entre vectores, no tiene mayor ventaja tener registros de 256-bits, cosa que vemos en los benchmarks (82 FPS vs 85 FPS, sólo un 4% de ventaja). Por el otro lado, si los números que componen los vectores son de 64-bits, ahí nos damos cuenta que nos conviene tener 256-bits, pero ese no es el caso con los motores de física para juegos.
----
@monaita dado que Physx no usa ni siquiera SSE ni multithreading automático, no veo en el futuro que utilicen AVX, claro que todo puede cambiar con Physx 3, pero dado que no se habla de ello desde hace meses, no sé... Le tengo más fe a Bullet.

Iniciado por Lugaidster

Las instrucciones AVX tienen ventajas, pero la diferencia es notoria en otros casos de uso, especialmente en el área que requiere cálculos con números de 64-bits de precisión como el trabajo científico, en donde probablemente sea más rápido usar una GPU Tesla, pero es debatible.

La diferencia no es tan clara. Las CPUs estan acercandose de forma considerable a las GPUs. Un Sandy Bridge o un Bulldozer de 8 cores a 3 GHz hace casi 100 GFlops de doble precision. La GTX 580 hace unos 200 GFlops. Pero en la CPU es mucho más fácil lograr una parte significativa de ese rendimiento. Y la generación posterior de CPUs probablemente volvera a doblar el rendimiento por core y muy posiblemente además incrementará el numero de cores por procesador.

Iniciado por Lugaidster

Los cálculos de física son principalmente en vectores de 4 componentes con matrices de transformación de 4x4 (Si no sabes por qué, estudia Álgebra Lineal). Dado que la precisión por defecto en la industria es de 32-bits (64-bits no tiene sentido en un juego ya que las tarjetas de video de consumidores soportan sólo 32-bits o son mucho más lentas con 64-bits de precisión, y ellas son las que dibujan estos vectores). Con 128-bits alcanza para meter un vector de 4 componentes justo. Como los cálculos se realizan entre vectores, no tiene mayor ventaja tener registros de 256-bits, cosa que vemos en los benchmarks (82 FPS vs 85 FPS, sólo un 4% de ventaja). Por el otro lado, si los números que componen los vectores son de 64-bits, ahí nos damos cuenta que nos conviene tener 256-bits, pero ese no es el caso con los motores de física para juegos.

No se de donde sacas lo de las cuatro componentes, depende del problema el tamaño de vectores que quieres usar. Pero siempre tienes que trabajar con mucho más de cuatro valores (aunque la unidad básica pueden ser 4 valores). Si ya puedes usar SSE, es muy posible que puedas fusionar dos operaciones en un vector AVX fácilmente.

De hecho, una GPU se puede pensar como un procesador vectorial de largo 32 (Nvidia) o 64 (AMD). Dificilmente lo llenas con 4 valores.

De todas formas la principal ventaja de AVX no es que los vectores sean más grandes, sino que el tiempo de procesar un vector el doble de largo es el mismo, duplicando el rendimiento máximo.

Iniciado por Lugaidster

@monaita dado que Physx no usa ni siquiera SSE ni multithreading automático, no veo en el futuro que utilicen AVX, claro que todo puede cambiar con Physx 3, pero dado que no se habla de ello desde hace meses, no sé... Le tengo más fe a Bullet.

Nvidia tiene que balancear la necesidad de vender sus tarjetas gráficas con la supervivencia de PhysX, si se va por lo segundo, es muy probale que usen AVX.

Un Sandy Bridge o un Bulldozer de 8 cores a 3 GHz hace casi 100 GFlops de doble precision.

Dado que los Bulldozer todavía no salen al mercado, sacarlos en este tema no tiene sentido. No puedes hablar sobre un producto que todavía no ha salido y de lo que sólo hay especulaciones de como va a rendir.

En cualquier caso, lo de 8 cores en el caso de los bulldozer sólo se aplica a las instrucciones de números entero. En un Bulldozer se comparte una unidad FPU por cada dos "núcleos":



Si se ejecutan instrucciones de 128-bits, cada "núcleo" puede ejecutar su propio hilo, pero en el caso de 256-bits, se comparten, o sea, 1 instrucción por cada dos núcleos.

La GTX 580 hace unos 200 GFlops. Pero en la CPU es mucho más fácil lograr una parte significativa de ese rendimiento. Y la generación posterior de CPUs probablemente volvera a doblar el rendimiento por core y muy posiblemente además incrementará el numero de cores por procesador.

Si nos ponemos a hablar a futuro, estoy seguro de que también habrán versiones nuevas con mejor rendimiento por parte de las GPU, pero tal y como dije, el tema es debatible. De cualquier forma, una Radeon 5870 ya tiene en forma teórica ~500 GFLOPS en DP y es de hace un año y medio. Me imagino que una Radeon 6970 tenga más. En cualquier caso, para que la CPU llegue a los números teóricos, se requieren condiciones especiales tal y como en el caso de la GPU. En la vida real, va a depender del programa. Pero hay algo que es casi seguro, para aplicaciones que tienen enormes cantidades de datos, casi siempre es mejor usar una GPU. La latencia con la GPU es mayor, pero esto se mitiga si la cantidad de datos es enorme y los cálculos son paralelizables.

No se de donde sacas lo de las cuatro componentes

Lo explico. Los motores físicos de hoy en día generalmente son para juegos en un espacio de tres dimensiones. Las posiciones en este espacio son representadas en tres coordenadas: x, y, z en el sistema de coordenadas cartesiano. Entonces tenemos 3 componentes. El punto es que para poder hacer transformaciones lineales en estos vectores, se necesitan matrices de 4x4 (existen versiones de 3x3, pero son simplificaciones). Además, los cuaterniones que se utilizan para representar la orientación, entre otras cosas, son de cuatro componentes (x, y, z, w). Por lo tanto, para poder realizar los cálculos correspondientes, generalmente la cuarta componente del vector es una constante. Ahí está. La unidad básica de las Radeon actuales (VLIW5) Tienen cuatro unidades simples para procesar un vector de 4 componentes. Las Radeones VLIW4 siguen teniendo 4 unidades de proceso para procesar un vector de 4 componentes con una instrucción.

Intel se la jugó por rendimiento con 256-bits. AMD se la jugó por 128-bits. A 256-bits Intel tiene el doble de rendimiento que AMD, a 128 AMD tiene el doble que Intel. De cualquier manera, si hablamos de rendimiento SP (El formato usado por los motores de física actuales) una GPU sobrepasa los 2 TFLOPS, un Sandy Bridge en comparación a 3.8 GHz no supera los 60,8 GFLOPS por núcleo (con cuatro son 243,2 GFLOPS), es grande la diferencia.

Si ya puedes usar SSE, es muy posible que puedas fusionar dos operaciones en un vector AVX fácilmente.

Posible sí. Fácil, definitivamente no. Es por eso que AMD y Intel hicieron cosas distintas.

Nvidia tiene que balancear la necesidad de vender sus tarjetas gráficas con la supervivencia de PhysX, si se va por lo segundo, es muy probale que usen AVX.

Si lo llegan a hacer, tienen que ir por SSE primero (Un tema de compatibilidad y mercado). Todavía no llegan ahí, así que no espero soporte para AVX en el futuro cercano.

Iniciado por Lugaidster

Dado que los Bulldozer todavía no salen al mercado, sacarlos en este tema no tiene sentido. No puedes hablar sobre un producto que todavía no ha salido y de lo que sólo hay especulaciones de como va a rendir.

Las especificaciones de Bulldozer ya fueron liberadas y podemos saber su rendimiento teorico.

Iniciado por Lugaidster

En cualquier caso, lo de 8 cores en el caso de los bulldozer sólo se aplica a las instrucciones de números entero. En un Bulldozer se comparte una unidad FPU por cada dos "núcleos":

http://images.anandtech.com/reviews/...zerthreads.jpg

Si se ejecutan instrucciones de 128-bits, cada "núcleo" puede ejecutar su propio hilo, pero en el caso de 256-bits, se comparten, o sea, 1 instrucción por cada dos núcleos.

Bulldozer tiene FMA, por lo que son dos operaciones de 128 bits por ciclo por nucleo.

Iniciado por Lugaidster

Si nos ponemos a hablar a futuro, estoy seguro de que también habrán versiones nuevas con mejor rendimiento por parte de las GPU, pero tal y como dije, el tema es debatible. De cualquier forma, una Radeon 5870 ya tiene en forma teórica ~500 GFLOPS en DP y es de hace un año y medio. Me imagino que una Radeon 6970 tenga más. En cualquier caso, para que la CPU llegue a los números teóricos, se requieren condiciones especiales tal y como en el caso de la GPU. En la vida real, va a depender del programa. Pero hay algo que es casi seguro, para aplicaciones que tienen enormes cantidades de datos, casi siempre es mejor usar una GPU. La latencia con la GPU es mayor, pero esto se mitiga si la cantidad de datos es enorme y los cálculos son paralelizables.

En una CPU cualquier implementacion razonable de DGEMM es capaz de alcanzar un rendimiento cercano al maximo teorico (y es probablemente la rutina mas usada en HPC).

Iniciado por Lugaidster

Lo explico. Los motores físicos de hoy en día generalmente son para juegos en un espacio de tres dimensiones. Las posiciones en este espacio son representadas en tres coordenadas: x, y, z en el sistema de coordenadas cartesiano. Entonces tenemos 3 componentes. El punto es que para poder hacer transformaciones lineales en estos vectores, se necesitan matrices de 4x4 (existen versiones de 3x3, pero son simplificaciones). Además, los cuaterniones que se utilizan para representar la orientación, entre otras cosas, son de cuatro componentes (x, y, z, w). Por lo tanto, para poder realizar los cálculos correspondientes, generalmente la cuarta componente del vector es una constante. Ahí está. La unidad básica de las Radeon actuales (VLIW5) Tienen cuatro unidades simples para procesar un vector de 4 componentes. Las Radeones VLIW4 siguen teniendo 4 unidades de proceso para procesar un vector de 4 componentes con una instrucción.

Pero tienes mucho mas de 4 valores para trabajar. Tu idea de que 4 es suficiente y los vectores mas largos no sirven esta errada.

Iniciado por Lugaidster

Intel se la jugó por rendimiento con 256-bits. AMD se la jugó por 128-bits. A 256-bits Intel tiene el doble de rendimiento que AMD, a 128 AMD tiene el doble que Intel.

AMD esta usando la misma tecnica que hizo antes con x87 y SSE2. Usar dos FPUs como una FPU del doble de largo, lo que le funciono bastante bien. A 256 bits el rendimiento es el mismo, por que AMD tendra FMA.

Iniciado por Lugaidster

De cualquier manera, si hablamos de rendimiento SP (El formato usado por los motores de física actuales) una GPU sobrepasa los 2 TFLOPS, un Sandy Bridge en comparación a 3.8 GHz no supera los 60,8 GFLOPS por núcleo (con cuatro son 243,2 GFLOPS), es grande la diferencia.

Y? Esa diferencia no se capitaliza en rendimiento real. Nvidia tuvo que usar x87 para hacer parecer que PhysX por GPU es mas rapido que por CPU.

Iniciado por x

Bulldozer tiene FMA, por lo que son dos operaciones de 128 bits por ciclo por nucleo. [...] AMD esta usando la misma tecnica que hizo antes con x87 y SSE2. Usar dos FPUs como una FPU del doble de largo, lo que le funciono bastante bien. A 256 bits el rendimiento es el mismo, por que AMD tendra FMA.

Eso no significa que lo que dije no sea cierto. Son cuatro unidades Flex-FP. Entonces tienes 2x128x4 = 256x4, en definitiva, lo mismo que dije aplica.

Si te quieres poner técnico:

Usando AVX:

Bulldozer: 256-bits / 64-bits * 4 unidades Flex-FP = 16 FLOPS DP x ciclo

Sandy Bridge: 256-bits / 64-bits * 4 unidades FPU * 2 puertos (uno para fadd y otro para fmul) = 32 FLOPS DP x ciclo.

Usando SSE:

Bulldozer: 128-bits / 64-bits * 4 unidades Flex-FP * 2 instrucciones simultaneas = 16 FLOPS DP x ciclo

Sandy Bridge: 128-bits / 64-bits * 4 unidades FPU * 2 puertos (uno para fadd y otro para fmul) = 16 FLOPS DP x ciclo

En donde AMD tiene la ventaja es que puede ejecutar 2 FADD o 2 FMUL de 128-bits por unidad Flex por ciclo mientras que Sandy Bridge puede sólo 1 FADD y 1 FMUL o cada uno por separado, pero dado que los cpus son OOO, existe la posibilidad para Sandybridge de mejorar su rendimiento al reordenar las instrucciones. La prueba de verdad va a ser cuando ambas arquitecturas estén puestas frente a frente, pero, al menos en papel, Sandybridge tiene más rendimiento. En el caso de que los cálculos sean de un tipo o de otro (FADD ó FMUL), tenemos lo siguiente:

SB: 128-bits / 64-bits * 4 unidades FPU = 8 FLOPS DP x ciclo.

O sea, mientras que Bulldozer va a 16 FLOPS, independiente de la carga, Sandy Bridge se mueve entre 8 y 32 FLOPS.

La información está ahí: The New Flex FP | Business Blog y aquí: Intel's Sandy Bridge Architecture Exposed - AnandTech :: Your Source for Hardware Analysis and News

Intel sigue teniendo rendimiento superior en un caso teórico para 256-bits.

Iniciado por x

Pero tienes mucho mas de 4 valores para trabajar. Tu idea de que 4 es suficiente y los vectores mas largos no sirven esta errada.

Nunca negué que existan muchos más valores. Sólo hablé de los vectores. Ventajas por tener registros más anchos, existen, pero no creo que se apliquen a todos los casos de uso, especialmente si hablamos de cálculos de precisión simple. Un ejemplo de ello, Flex-FP.

Iniciado por x

En una CPU cualquier implementacion razonable de DGEMM es capaz de alcanzar un rendimiento cercano al maximo teorico (y es probablemente la rutina mas usada en HPC).

Estoy tratando de encontrar los resultados de un Linpack ejecutado en un Tesla y compararlo con uno ejecutado en un Sandybridge. El otro día leí como 500 GFLOPS DP para el Tesla y como 120 GFLOPS DP para Sandybridge, cuando los encuentre los posteo aquí. El punto es que la diferencia sigue siendo bastante grande.

En cualquier caso, tomando el siguiente link como evidencia empírica:
CPU PhysX: x87, SSE and PhysX SDK 3.0 - 3D Tech News, Pixel Hacking, Data Visualization and 3D Programming - Geeks3D.com

Vemos que usando physx multi-core con x87 es cerca de 8 veces más lento que una Geforce gtx480. Metiendole AVX y asumiendo escalabilidad casi perfecta, llegamos a un rendimiento similar. Sin embargo, la GPU está dibujando mientras que el CPU no. Las GPUs son buenas para procesar grandes cantidades de datos, debido a la latencia que involucra mandar las instrucciones y recibir los resultados, a veces no conviene utilizarlas. Para una gran cantidad de datos, es irrefutable la ventaja que tienen las GPU. No en vano el supercomputador más rápido del mundo está basado en Nvidia Tesla (los números para el ranking se calculan usando el HPCC benchmark que incluye un componente DGEMM).

Aún así, el tema original era AVX vs SSE, y la realidad es que los números mostrados no muestran la ventaja descarada que se dice que AVX tiene por sobre SSE. La verdadera pelea va a ser cuando llegue Bulldozer, y viendo sus números, no me sorprendería la diferencia de rendimiento entre SSE 128-bits y AVX de 256-bits sea mucho más pequeña de lo que se dice en el presente artículo y se limite a la eficiencia del set de instrucciones más que el tamaño de los registros, nuevamente, sólo aplica a Bulldozer.

Iniciado por x

Y? Esa diferencia no se capitaliza en rendimiento real. Nvidia tuvo que usar x87 para hacer parecer que PhysX por GPU es mas rapido que por CPU.

Estoy de acuerdo en el caso de Physx, sin embargo eso no se aplica a todos los casos de uso. Los motores físicos no son buenos ejemplos de tareas paralelizables. El rendimiento no incrementa linearmente con el incremento en hilos de ejecución debido a interdependencias en los cálculos. Como se ve en el link posteado más arriba, cuando el número de partículas sube, los CPUs son mucho más lentos que los GPUs, pero cuando el número de partículas es pequeño, el CPU es más apto para ejecutar los cálculos.

Ahora, esa diferencia es notoria cuando hablamos de rendimiento gráfico... Nuevamente, depende del caso de uso y de que tan paralelizable sea ésta.

Iniciado por Lugaidster

Eso no significa que lo que dije no sea cierto. Son cuatro unidades Flex-FP. Entonces tienes 2x128x4 = 256x4, en definitiva, lo mismo que dije aplica.

Si te quieres poner técnico:

Usando AVX:

Bulldozer: 256-bits / 64-bits * 4 unidades Flex-FP = 16 FLOPS DP x ciclo

Sandy Bridge: 256-bits / 64-bits * 4 unidades FPU * 2 puertos (uno para fadd y otro para fmul) = 32 FLOPS DP x ciclo.

Antes de ponerte técnico deberias averiguar que es una FMA. Con eso Bulldozer duplica el numero de operaciones por ciclo e iguala a SB.

Iniciado por x

Antes de ponerte técnico deberias averiguar que es una FMA. Con eso Bulldozer duplica el numero de operaciones por ciclo e iguala a SB.

Compadre, John Fruehe de AMD y Anand Lal Shimpi de Anandtech lo dicen, dejé los links. ¿Tan siquiera te has informado? FMA es Fused Multiply Add y viene soportado en Bulldozer por el set de instrucciones FMA4. Yo hablo específicamente de AVX contra SSE (en todos mis post lo dice). FMA está sólo a través de otro set de instrucciones aparte, que no existe en Sandybridge, por lo tanto, no es comparable. Hemos estado hablando de AVX y de SSE desde el infinito y con esos sets no hay instrucciones FMA... Y la unidad FMAC sólo se usa en ese caso.
----
FMA4 está destinado a tener el mismo futuro que 3DNow en generaciones anteriores...

Iniciado por Lugaidster

Compadre, John Fruehe de AMD y Anand Lal Shimpi de Anandtech lo dicen, dejé los links. ¿Tan siquiera te has informado? FMA es Fused Multiply Add y viene soportado en Bulldozer por el set de instrucciones FMA4. Yo hablo específicamente de AVX contra SSE (en todos mis post lo dice). FMA está sólo a través de otro set de instrucciones aparte, que no existe en Sandybridge, por lo tanto, no es comparable. Hemos estado hablando de AVX y de SSE desde el infinito y con esos sets no hay instrucciones FMA... Y la unidad FMAC sólo se usa en ese caso.
----
FMA4 está destinado a tener el mismo futuro que 3DNow en generaciones anteriores...

Que demostración de ignorancia. Mostraste que no sabes que es FMA ni que es una instrucción.

FMA es una operación que hace una suma y una multiplicación en la misma operación, la mayoria de los procesadores la usan por que permite duplicar el rendimiento sin aumentar casi nada la complejidad del procesador y por que la mayoria de los codigos usan operaciones FMA. Los x86 son probablemente los unicos procesadores que no la usan, hasta ahora.

FMA4 es una instruccion que opera sobre los registros YMM de AVX, eso de que "no es parte" de ese set de instrucciones no tiene nada que ver. En bulldozer puedes usarla para calculo numerico y sería estupido no hacerlo solo por que no existe en Sandy Bridge. Para aplicaciones numericas intensivas normalmente se usa código especifico por procesador.

Dudo que FMA4 desaparezca, a lo mas se usara FMA3 que se supone Intel incluira en la proxima generación. Pero no hay duda que la FMA llego a x86 para quedarse.

Creo el tema se desvio hacia otra dirección, debido al tipo de cálculos que se requieren para las físicas, el simplemente recompilar el actual PhysX para que soporte AVX quizá no reporte grandes ganancias. Dado que Havok es de Intel, es muy probable que si lo optimize para sacar el mayor partido posible a AVX, ya veremos en su momento como se comporta esa futura versión optimizada ante las actuales.

En cuanto a FMA, AMD tiene ya algo de experiencia en dicho tipo de cálculos pues sus GPUs vienen usandolo desde sus Radeon HD 4000 Series, aunque no de forma nativa sino a travez de la combinación de sus ALUs/SFU (aunque en Cayman lo hacen en base a la combinación de sus 4 ALUs), y era tan sólo cosa de tiempo en que implementaran dicho avance en sus CPU, aunque hace tiempo leí que en futuros CPUs AMD usará una mayor integración de sus unidades de cálculo vectoriales presentes en sus CPU y GPUs.


Saludos.