AMD Vishera FX 8350. Primeras impresiones – ProfessionalSAT

Siendo sincero debo admitir que me ha sorprendido gratamente el nivel de prestaciones de la nueva serie de CPUs FX de AMD basadas en el nuevo stepping dotado de cores Piledriver.

En un artículo de LowLevelHardware exploré detalladamente las mejoras que aportaba este core refinado, este nuevo stepping a la conocida micro arquitectura Bulldozer de AMD.

Piledriver module con sus 2 MB de caché L2.

Podríamos sintetizar las mejoras en dos fundamentales:

- Por un lado una menor disipación térmica por core y un menor voltaje mínimo estable a una frecuencia dada. A igual frecuencia menor consumo y temperatura.

- Por otro lado un aumento IPC de un 5 a 30% en función de la carga de trabajo (enteros, branches, coma flotante, SSE, AVX,…) A igual frecuencia más rendimiento.

Gracias a estas dos mejoras AMD ha conseguido incrementar la frecuencia base del FX 8350 en 400 MHz.

AMD FX8150 vs. FX8350. Bulldozer vs. Piledriver.

En modo Turbo Core Vishera aplica el Turbo máximo en todas las situaciones, es decir, en carga máxima de un thread (ST, single threaded) o de varios threads e incluso 8 threads simultáneos (MT, multi threaded):

Turbo Core en FX8150 Bulldozer.

Podemos decir, para simplificar, que en Vishera el estadio intermedio Turbo Core desaparece.

En la práctica, medido por mí mismo, un Vishera FX8350 a 4 GHz en Prime95 Blend 4 GB consume exactamente lo mismo a un Bulldozer FX8150 a 3.6 GHz a voltajes nominales.

Bulldozer module 32 nm SOI HKMG.

Como deduciréis fácilmente, Vishera aportará un 11% más de frecuencia en cargas paralelas y en cambio no incrementa nada en cargas single threaded. Por ello en cargas ST el rendimiento solo aumentará por el incremento de IPC y en cambio en cargas MT se sumará el 11% de frecuencia nominal al incremento IPC.

Undervolting

A esto debo añadir que tanto en los antiguos FX Bulldozer como en los nuevos Vishera AMD ha sido bastante exagerado en cuanto a los voltajes a los que vende sus CPUs. Normalmente son absolutamente estables a voltajes 0.100 – 1.150 V inferiores a los nominales. Con ello además ganamos unos 20 – 30 W en consumo y 10 – 15 ºC de temperatura. Merece la pena hacerlo aunque con ello perdamos horas o incluso a veces algunos días.

AMD debería hacer este proceso en fábrica pero resulta laborioso y por ello caro. De este modo saca al mercado las CPUs a un voltaje excesivamente prudente para asegurar su estabilidad sin probar individualmente en exceso cada uno de los chips para ajustar individualmente su voltaje.

Piledriver. Mejoras micro arquitecturales respecto a Bulldozer.

AMD ha mejorado Bulldozer en muchos aspectos aunque sin cambiar nada importante del diseño, de hecho Piledriver no es más que un stepping más avanzado del mismo core.

Se ha mejorado el Branch Prediction, algo crítico en este diseño debido a su larguísimo pipeline. Esto mejorará el rendimiento sobretodo en cargas de enteros.

Se ha activado la unidad de división de enteros (INT Div, iDiv) que estaba deshabilitada en Bulldozer por un fallo de diseño, como comenté en Abril de 2011 en mi artículo:

AMD AGLUs, Bulldozer INT cores. Actualizado – LowLevelHardware

“ EX0 contiene una unidad de división de enteros parcialmente pipelinizada y con latencia y capacidad de proceso variable en función de la precisión. Aunque examinando detenidamente la documentación parece que más bien se trata de una unidad “virtual” ya que la instrucción IDIV se decodifica en el Microcode Engine y se secuencia en instrucciones sencillas ALU que se ejecutan en EX0. Además incluye una unidad para LZCNT y POPCNT. “

Efectivamente, en Bulldozer, la unidad iDiv no estaba habilitada y por ello la latencia y velocidad de las divisiones de enteros eran tan decepcionantes. Por fin, en Piledriver se encuentra habilitada.

Se ha doblado el tamaño del L1 dTLB (TLB de datos de nivel 1). Para el que quiera amplia información sobre para que sirve un TLB le remito a algunos artículos pasados.

En total todas estas mejoras aumentan el IPC de un 5 a 30%, en general sobre un 10%. En el caso del 30% es más por un rendimiento terrible de Bulldozer en algunas tareas que por méritos de Piledriver.

En cualquier caso podríamos caracterizar las prestaciones de Piledriver en el AMD FX8350 del siguiente modo:

- Cargas de trabajo de enteros con excelente paralelización y con carga máxima en los 8 INT cores. Ejemplo: compresión de datos en WinRAR o 7zip LZMA2. Prestaciones generalmente muy superiores al Core i5 3570K y superiores al Intel Core i7 3770K.

- Cargas de trabajo de coma flotante con excelente paralelización y con carga máxima en las 4 FPUs FMACs con 8 threads.

  Ejemplo 1: Rendering, cálculo matemático. Prestaciones generalmente bastante superiores al Core i5 3570K y ligeramente inferiores al Core i7 3770K. En PovRay en cambio el más rápido y por buen margen es el FX8350.

   Ejemplo 2: Edición y codificación de video x264 / H264. Prestaciones generalmente superiores al Core i7 3770K y muy superiores al Core i5 3570K.

- Cargas de trabajo principalmente de enteros con baja paralelización y raras veces con carga máxima en 4 INT. Ejemplo: SysMark 2012, compilación y usos multitarea de la máquina en Windows con varias aplicaciones a la vez. Prestaciones muy similares o algo inferiores al Core i5 3570K (como mucho un 10%).

- Cargas de trabajo de enteros single thread o con paralelización muy leve. Ejemplo: instalaciones de software, instalación de sistema operativo, javascript. Prestaciones inferiores a Core i5 3570K hasta un 40% en proceso javascript.

Si hacemos la media el FX8350 nos da un rendimiento superior en un 5% al Core i5 más alto de gama, el i5 3570K que está situado por encima en precio (unos 20 – 30@ más).

El Core i7 3770K se sitúa en un nivel de prestaciones superior gracias al Hyper Threading como atestiguan sus más de 150€ extras de coste.

Conclusiones

Lo más positivo que puedo sacar de Vishera es su notable aumento de velocidad de trabajo en aplicaciones ofimáticas respecto a Bulldozer (ha mejorado más de un 20%) y el hecho de haberse convertido en el rey en prestaciones en temas de video, sobretodo en coding x264. En estos casos supera incluso al excelente y mucho más caro Core i7 3770K.

El die completo del procesador AMD FX 8350 32 nm.

Vishera mantiene exactamente los niveles de consumo y disipación térmica de los anteriores AMD FX con un rendimiento medio en cargas multithread de un 20% (ayudado por los 400 MHz extras) superior y un 5 – 10% en cargas single thread (con igual frecuencia).

Post Scriptum

Animo a los posibles compradores de estas CPUs a cambiar el funcionamiento nominal de Turbo Core. AMD ha dejado invariado el Turbo Core con carga single threaded o dual threaded a 4.2 GHz respecto a Bulldozer.

En Bulldozer FX8150 la disipación térmica y consumo era prácticamente igual con cargas MT de 8 threads (3.6 GHz) que en single o dual threaded (4.2 GHz) e igual a 125W.

En Vishera, en cambio, con cargas de 8 threads (4.0 GHz) llega a los declarados 125W en Prime95 pero con cargas single o dual threaded (4.2 GHz) se queda corto marcando unos 100 – 105W.

Los samples que he probado del AMD FX8350 son absolutamente estables en cargas single o dual threaded a voltaje nominal a 4.6 GHz y manteniendo siempre la disipación térmica por debajo de los 125W nominales. Para ello, en BIOS, cambio manualmente el funcionamiento de Turbo Core aumentando el multiplicador máximo a 46X.

En este caso conseguimos otro 9 – 10 % adicional de velocidad en casos ST (single threaded), el talón de Aquiles de esta micro arquitectura.

Echad un vistazo a la web de mi nueva empresa, un proyecto de gran envergadura que llevo preparando hace más de un año.

Os lo recomiendo para diseño de sistemas de altas prestaciones optimizados al límite:

Allí tenéis a vuestra disposición el formulario de contacto, para consultas sobre este artículo hacedlo más abajo en la sección de comentarios.

Y mi nuevo Blog de contenido muy técnico y actualizado donde encontraréis artículos míos sobre hardware, procesadores y sistemas y también otros posts de expertos programadores e informáticos sobre otros temas de actualidad:

Si consideras útil el contenido de este Blog, ayuda a mantenerlo ojeando algunas de las ofertas que consideres interesantes de nuestros anunciantes. Gracias de antemano.

El que tenga dudas o aportaciones tiene para ello la sección de comentarios, intentaré responder a todos y con la máxima claridad. Los Blogs deben de ser lugares de intercambio y agradezco vuestro feedback.

Carlos Yus Valero – informaticapremium     

Bulldozer 32 nm AMD FX. Parte 2. Actualizado – ProfessionalSAT

AMD FX ha llegado al mercado con una mezcla de sensaciones, en el lado positivo está teniendo unas ventas superiores a lo esperado y por otro lado, las prestaciones no han sido las esperadas para la prensa especulativa.

En primer lugar, teniendo en cuenta el diseño de los cores de procesamiento hay que ser muy ingenuo o poco ducho en cores de enteros para esperar unas altas prestaciones por ciclo (IPC) de Bulldozer respecto a un core Sandy Bridge de Intel e incluso comparándolo con un K10.5 de un Phenom II. No es este el objetivo de diseño de Bulldozer.

El módulo Bulldozer 32 nm, unos 210 M de transistores.

Las armas de Bulldozer son otras, pretende frecuencias superiores a todo lo conocido. Tengamos en cuenta que el proceso HKMG de 32 nm de Global Foundries está en sus inicios, claramente inmaduro y poco probado y con unos yields (tasa de CPUs defectuosas)  pobres siendo suaves…

Si hacemos memoria, AMD siempre ha tenido estos “problemas de juventud” al introducir un nuevo nodo de fabricación; incluso siendo justos, esta transición de los 45 a los 32 nm no ha sido de las peores… la verdaderamente horrible ocurrió con los 65 nm y AMD Barcelona, el antiguo Phenom de 2 MB de L3.

Conociendo todos estos hechos espero para Bulldozer una mejora importante con el paso de los meses y la maduración del proceso de 32 nm. A lo largo de 2012 veremos reducirse el TDP de las CPUs y incrementar su frecuencia paulatinamente.

En Q3 2012 está previsto el lanzamiento de las nuevas CPUs basadas en Piledriver, la segunda generación de Bulldozer. En principio, y según AMD, con un 10-15% de incremento IPC clock for clock respecto a Bulldozer y obviamente frecuencias superiores.

El módulo Bulldozer sin su L2 dedicada de 2 MB y 16 vías.

AMD ha elegido un camino con el diseño de Bulldozer, un camino valiente y arriesgado,  supongo que tendrán sus razones pensando en el futuro. Con los cores K8 – K10 de los Athlon64 hasta los Phenom II tenía una clara ventaja respecto a Intel y no era en  prestaciones sino en superficie por core.

Un core de 32 nm de un AMD Llano (AMD A8 APU) ocupa unos insignificantes 9.69 mm2 sin su L2 de 1024 KB, sería realmente fácil integrar ocho de ellos con cachés L2 de 512 KB en un procesador octal core, un Phenom III X8 de 32 nm.

Junto a los ocho cores se integrarían los 4 buses HT3, el North Bridge, las dos controladoras DDR3 y una cantidad de L3 de 8 a 12 MB. Sin duda alguna tendría un gran rendimiento (superior a Bulldozer) y ocuparía una superficie netamente inferior a los 315 mm2 de Zambezi con su abultado budget de transistores (1200M) y 16 MB de caché combinada.

Un módulo Bulldozer es gigantesco al lado de un core Llano 32 nm.

Los problemas de Bulldozer

Una clave que apoya el hecho del diseño “apresurado” de AMD FX 32 nm es la cantidad de espacio vacío de lógica en el die entre los cores, las cachés y el resto de componentes. Es espacio dedicado a interconexiones entre cores, cachés, North Bridge, controladoras DDR3 y buses HT3.

Y con apresurado no me refiero a falta de tiempo, recordemos que AMD no lanza una nueva micro arquitectura desde 2003 con el Athlon64 (AMD Barcelona 65 nm y Shanghai 45 nm han sido dos actualizaciones de dicho diseño).

Hay que tener en cuenta que AMD pensó y diseñó un K9 (el siguiente paso al K8 Athlon64) pero quedó en nada, fue cancelado. Era un diseño de alta frecuencia (muy alta) al estilo Intel Netburst (familia Pentium 4), se canceló y empezó la era multicore con los Athlon64 X2.

AMD no tenía un sustituto claro del exitoso Hammer Athlon64 y no tenía un plan B (como Intel con su Banias de 130 nm, el Pentium mobile, base de la plataforma Centrino, del que derivó el diseño original del excelente Conroe Core2 Duo 65 nm).

En ese momento se apostó por la arquitectura CMT y nació en las mesas de diseño el plan general de Bulldozer.

El problema fue sencillo: AMD había gastado demasiados recursos en proyectos cancelados y ni siquiera sus Opteron ya no vendían como años atrás, AMD Barcelona había sido una verdadera decepción en frecuencia y no había ventas (dinero contante y sonante) para apoyar a los departamentos de diseño…

1200 M transistores y 315 mm2 en 32 nm

En mi opinión, con mayores medios humanos y materiales, su superficie podría haber sido reducida en un 20% aterrizando en unos más discretos 260 mm2 simplemente (entre comillas) optimizando el enrutado de interconexión por otras capas metálicas en lugar de compartirla con la lógica.

Algo que una mega compañía como Intel hace en todos sus diseños, prefiere mayores costes de desarrollo a cambio de posteriores ahorros en costes de producción (menor superficie de silicio, más chips por wafer).

Conclusiones

Mi opinión personal para AMD habría sido mucho más conservadora: un Phenom III X8 basado en estos pequeños cores de 32 nm habría sido un diseño barato en todos los sentidos y rápido de llevar al mercado, habría dado a AMD el oxígeno que necesita para ultimar el diseño de Bulldozer y rediseñar desde el principio su extraña y anómala arquitectura de cachés.

Por otro lado su rendimiento habría sido superior a Bulldozer con la misma disipación térmica y a frecuencias inferiores y hablo de cualquier carga de trabajo.

Ahora solo cabe esperar que el plan Bulldozer funcione y escale en frecuencia de un modo notable y que sus derivativas de 2012 cumplan su promesa de incremento IPC de hasta el 15%, si se dan estas condiciones AMD tiene ante sí un brillante futuro y unas finanzas que le permitirán diseñar sus futuros productos con mayores garantías.

Si consideras útil el contenido de este Blog, ayuda a mantenerlo ojeando algunas de las ofertas que consideres interesantes de nuestros anunciantes.

En múltiples entregas de LowLevelHardware y ProfessionalSAT he analizado en detalle el diseño interno de AMD FX Orochi 32 nm. Cito los más destacables:

AMD Bulldozer. Mi opinión personal. Parte 1. Actualizado – ProfessionalSAT

AMD Bulldozer. Frecuencias finales. Actualizado – LowLevelHardware

AMD Bulldozer- HotChips23 – LowLevelHardware

AMD Bulldozer. Perspectivas – LowLevelHardware

La L3 cache multibanco en AMD Bulldozer. Actualizado – LowLevelHardware

AMD AGLUs, Bulldozer INT cores. Actualizado – LowLevelHardware

AMD Bulldozer. Primeros benchmarks. Actualizado – LowLevelHardware

AMD Bulldozer – ProfessionalSAT

La micro arquitectura de AMD Bulldozer. Actualizado – LowLevelHardware

Novedades y expectativas 2010. Actualizado – LowLevelHardware

AMD Bulldozer. Prestaciones estimadas – LowLevelHardware

Micro arquitectura AMD Bulldozer 2011. Actualizado – LowLevelHardware

Previo AMD Bulldozer. Actualizado – LowLevelHardware

Si consideras útil el contenido de este Blog, ayuda a mantenerlo ojeando algunas de las ofertas que consideres interesantes de nuestros anunciantes.

Carlos Yus Valero – informaticapremium     

AMD Bulldozer. Mi opinión personal. Parte 1. Actualizado – ProfessionalSAT

Ya ha llegado al mercado la nueva micro arquitectura AMD Bulldozer, su rendimiento final no ha sido el que muchos esperaban. A mí personalmente no me ha sorprendido en absoluto y sinceramente ha sido exactamente tal cual debía ser según lo que había sobre el papel. Viendo los diagramas de AMD era claro que iba a ser un chip por y para multi threading y poco pensado para impresionar en cargas single threaded.

El die de Orochi 32 nm, la primera implementación comercial de Bulldozer.

Este artículo es la primera parte, en el presento algunas ideas e impresiones sobre la micro arquitectura Bulldozer y algunos cambios imperativos. En sucesivos artículos iré ampliando esta discusión.

AMD Orochi 32 nm: 4 L2 de 2 MB y L2 compartida de 8 MB y 315 mm2 (!!)

Verdaderamente el equipo de marketing de AMD ha hecho un dudoso trabajo induciendo a pensar a muchos que Bulldozer iba a entrañar un salto cualitativo en prestaciones frente a sus refinados (aunque venerables, casi “antiguallas tecnológicas”) cores K10.5 de 45 nm (por ejemplo los integrados en los Phenom II X6 Thuban). En realidad no ha sido así y el déficit de Bulldozer clock for clock y core for core frente a un Phenom II X6 Thuban de 45 nm ronda el 25%.

Como expliqué en numerosas ocasiones en mis artículos pasados sobre esta micro arquitectura era probable, lógico y  a mi modo de ver seguro que Bulldozer fuese más lento clock for clock que su predecesor. Muchos me criticaron por ello pero a día de hoy los hechos son claros.

Al fin y al cabo, el procesador AMD FX Orochi de 32 nm HKMG SOI es en general más lento clock for clock y core for core que un Phenom II de 45 nm (misma frecuencia y mismo número de cores) excepto en algoritmos de compresión de datos (WinRAR, 7zip) y obviamente cuando utiliza AVX, XOP o FMA4 (los nuevos juegos de instrucciones de Bulldozer de los que carecen los cores de AMD anteriores).

Bulldozer intenta compensar con más cores y mayor frecuencia (debería haber llegado a un 30% más que Phenom II, ese era el objetivo) y modos Turbo más agresivos… Pero lamentablemente el actual estado del proceso de fabricación HKMG SOI de 32 nm de global Foundries no le ha permitido pasar de los 3.6 GHz nominales y los 4.2 GHz con Turbo y carga de 2 módulos (y los otros dos en estado CC6 IDLE).

Las cabezas pensantes de AMD soñaban con frecuencias nominales sobre los 4.2 GHz y Turbos en carga parcial de cores de hasta 5 o 5.2 GHz… era el plan de Bulldozer.

Hagamos un ejercicio de imaginación: ¿Qué habría hecho yo si fuese el encargado de la política comercial de AMD?

Habría trazado el plan que detallo a continuación a la vista de los pobres / insuficientes resultados prestacionales de los primeros stepping de Bulldozer y de la falta de escalado en frecuencia del core fabricado hoy día con el proceso de 32 nm de GloFo.

Obviamente y no nos engañemos, el staff ejecutivo de AMD conoce estos problemas hace años, fácilmente 4 años. De echo, Dirk Meyer en 2008, canceló toda la familia de CPUs Bulldozer en 45 nm y dio luz verde a Thuban 6 cores (el plan B) porque era conocedor de que habría sido un absoluto fracaso comercial (mucho pero que el actual Orochi de 32 nm).

Mi plan comercial para Bulldozer

Sigo en mi convencimiento de que mejor habría sido un simple Phenom III X8 con 8 cores reales idénticos a los de Llano 32 nm (con algunas mejoras micro arquitecturales) y 8 MB de caché L3 fabricado en 32 nm.

Sería, en mi opinión un excelente plan B, un plan seguro. Además un plan B con resultados prestacionales totalmente predecibles. Sin duda necesitaría un robusto sistema Turbo core, para cargas single threaded y parciales, pero no nos engañemos, core for core un Phenom II ya es más rápido que Bulldozer excepto en casos limitados que comento en este artículo.

El problema de Bulldozer, entre otros, es el impredecible rendimiento en el mundo real de una nueva micro arquitectura genuinamente diferente de todo lo demás y además fabricado en un proceso novedoso y poco probado hasta la fecha (Global Foundries 32 nm HKMG SOI).

En mi opinión, los primeros Bulldozer deberían haber sido retrasados (una vez más) y puestos en el mercado al final del periodo comercial del proceso de 32 nm de Global Foundries, en plena madurez. Habría esperado a Q2 o Q3 de 2012. Mientras tanto tendríamos el Phenom III X8 que fácilmente habría llegado a las estanterías 6 meses antes que Orochi.

Con ello AMD habría ganado en conocimiento del proceso de fabricación de 32 nm, habría podido optimizar el die de Bulldozer en busca de una drástica reducción de superficie (demasiado espacio muerto en Orochi 32 nm) y habría mejorado los speed path críticos consiguiendo un muy necesario aumento de frecuencia.

El espacio muerto, principalmente interconexiones, en AMD Orochi 32 nm.

En este caso habrían sido CPUs con menor consumo, sin duda, tanto en reposo como en carga máxima y fácilmente estaríamos hablando de 200 – 400 MHz más de frecuencia en el speed bin superior con lo que estarían más cercanos a las expectativas puestas en ellos por el “delirante” (JF AMD y compañía) departamento de marketing de AMD.

Mientras tanto tendríamos el citado Phenom III X8, con los mismos cores que el AMD A8 para socket FM1 pero con L2 de sólo 512 KB y 8 MB de L3. Simplemente funcionarían a mayor frecuencia, con 3.4 GHz nominales para 8 cores al 100% y un modo Turbo de 4 GHz con carga 100% en 4 de los cores. Sería claramente y de lejos más veloz que Bulldozer y podríamos tenerlo en el mercado hace meses.

La controladora de memoria y la caché L3 tomarían su diseño del actual Orochi 32 nm y sin duda habría sido necesario aumentar los data paths de la FPU para soportar AVX con unidades nativas de 256 bit. O como solución de compromiso, hacer simétricas las unidades FMUL y FADD de K10.5 y dotar a ambas de capacidad FADD , FMUL y FDIV dejando invariada FMISC excepto en su ancho de bits.

8 cores K10 en 32 nm ocupan unos 78 mm2 (9.69 mm2 por core) sin caché L2, hay que sumarle 8 cachés L2 de solamente (es más que suficiente) 512 KB (unos 32 mm2 en total) y una caché L3 de 8 MB unificada (no en 4 bancos como en Bulldozer por su alto consumo de superficie y los 4 HT3, controladoras DDR3 y demás interconexiones, fusibles…

La superficie total sería muy inferior a los 300 mm2 y el rendimiento sería absurdamente mejor que el de Orochi, en términos absolutos y en performance per watt.

A su vez, este retraso en el lanzamiento a 2012 habría proporcionado la ventaja de alinear la salida de Bulldozer con la de Windows 8, que con su scheduler mejorado (Bulldozer module aware scheduler) proporciona un aumento de prestaciones adicional de un 10% de media para chips Bulldozer.

En este caso se podría haber buscado una “fórmula mágica” (los señores de marketing son maestros en ello) para su nombre comercial como en el caso de los AMD Athlon XP (alineados con la comercialización de Windows XP).

Qué cambiaría en Orochi 32 nm

Un ejercicio de imaginación adicional: Si yo fuese el ingeniero jefe de proyecto de Orochi haría varios, bueno verdaderamente muchos cambios, algunos fundamentales y que se deberían de haber implementado años atrás ya en las mesas de diseño y en la presentación conceptual general, otros en cambio incrementales y que se pueden implantar vía steppings venideros.

Reducción de la latencia de la caché L2 en Orochi.

Siendo suave, es absurdo llegar a 27 ciclos y más teniendo en cuenta las abominables tasas de fallos de la pequeña L1d de solamente 16 KB y 4 vías (lógicamente un 41% más de fallos que en una L1d de 32 KB y misma asociatividad).

No entiendo como es posible… 27 ciclos, implica que el pipeline de L2 es de 23 etapas,restando los 4 ciclos que conlleva el acceso fallido a L1d (L1d miss).

Otra posibilidad, aunque algo improbable, es que la L2 de 2 MB y 16 vías en Orochi funcione a 1/2 de la frecuencia de los cores para reducir su consumo: En este caso su verdadera latencia sería la mitad, sobre 12 ciclos, funcionando a frecuencias nominales de 1.8 GHz y en Turbo máximo a 2.1 GHz en el FX 8150.

No es lógico que un simple K8 dual core Athlon64 X2 6400+ de 90 nm tuviese dos cachés L2 de 1 MB operando a 3.2 GHz (hablo de 2006 - 2007) con una latencia de 15 ciclos y ahora, 5 años después estemos en 27 ciclos para 2 MB y en un ultra avanzado proceso HKMG SOI de 32 nm, absurdo.

La masiva L2 de 2 MB supone un gran porcentaje del área del módulo, a la derecha.

Personalmente, incluso reduciría su tamaño a 1 MB para bajar el tiempo de acceso, este hecho conllevaría una importante reducción de superficie de cada módulo (menos mm2 de silicio) y reduciríamos notablemente el precio de fabricación del chip aunque aumentaría su tasa de fallos de caché.

Quizás AMD no tiene un algoritmo avanzado de sharing de caché L2 (como Intel implementó en Core2Duo 65 y 45 nm) y por ello mucho thrashing entre threads de los dos INT cores que comparten los 2 MB de L2 y por ello se ha decantado por el tamaño de 2 MB. No veo otra razón, en cualquier otro caso yo reduciría su tamaño a 1 MB como máximo.

Phenom III X8 8 MB L3 32 nm SOI HKMG <300mm2

Os propongo un nuevo ejercicio de imaginación: veamos cómo serían las latencias del subsistema de memoria de un Phenom III X8 (octal core) fabricado en el proceso de 32 nm de Global Foundries (el mismo de Orochi).

Latencias hipotéticas de un Phenom III X8 de 32 nm:

Latencias de un K10.5 simulado en 32 nm vs. Orochi 32 nm.

Latencias de un K10.5 simulado en 32 nm vs. Orochi 32 nm.

En verde Orochi 32 nm y en rojo al hipotético Phenom III X8 de 32 nm.

Sin duda el aspecto del gráfico es muchísimo más equilibrado para el Phenom III X8 y muy poco ortodoxo (siendo técnicamente educado) en el caso de Bulldozer.

Está claro que hasta tamaños de acceso de 512 KB un Phenom III X8 tendría un acceso a datos con una latencia brutalmente inferior a Bulldozer (más de un 100% de mejora media) y en el caso de 32 y 64 KB la comparación es imposible: AMD FX incrementa la latencia desde 3 los tres ciclos de Phenom a unos absurdos 25 - 27 (!!!). Sin comentarios.

Caché L1d ¿A quién se le ocurrió dejarla en 16 KB?

El tamaño típico de caché L1d hace años (muchos años, podemos decir que sobre una década) es de 32 KB o más (Intel con 32 KB hace varias generaciones después de Netburst y AMD con 64 KB desde el anciano Athlon 250 nm de finales del siglo XX).

El ecosistema software actual está diseñado para que sus critical loops, es decir, el código y datos crítico del programa quepa en la caché L1, sea de datos o instrucciones.

Bulldozer, con sus L1d de 16 KB y 4 vías, viola este echo conocido por cualquier arquitecto de procesadores.

Si se dan cache misses (fallos de caché) de nivel 1 (L1 miss) es una tragedia para las prestaciones, pues en Bulldozer debemos esperar 25-27!! ciclos para encontrar el dato o instrucción en L2 (seguro prácticamente que está puesto que son 2MB).

Ya sé que el motor OOO (ejecución fuera de orden) de Bulldozer ha sido mejorado pero debería de ser casi milagroso para enmascarar 27 ciclos de latencia continuamente (dado el excesivo número de cache misses) en el flujo de ejecución.

Por estos motivos no entiendo porqué se tomo la decisión de los 16 KB. Si tuviese 2 ciclos de latencia (como en Intel Northwood: 8 KB L1d 2 ciclos apoyada por una L2 de 512 KB y 18 ciclos de latencia) quizás podríamos hablar del tema; aunque me inclino en todo caso por 32 KB y 4 ciclos y una L2 menor (1 MB) y de unos 12 – 18 ciclos.

La única excusa para los 16KB reside en el ahorro de superficie y de consumo, aunque 8 cachés L1d de 32 KB no son tanto más grandes que 8 de 16 KB, se compensaría con creces con los cambios en L2 apuntados (reducción a MB).

En cuanto a la disipación térmica de 8 L1d de 32 KB, sin duda es mayor que la de 8 L1d de 16 KB pero, hay que ser corto de miras para no ver el mucho mayor ahorro energético que aportan las L1d de 32 KB por su menor tasa de fallos (L1d miss) seguida de multitud de accesos a L2.

Conclusiones parciales

Estas son algunas de las consideraciones que me vienen rápidamente al ver el actual diseño de Orochi, en próximos artículos apuntaré otras y me extenderé más sobre estas.

En cualquier caso, está claro que los núcleos de ejecución de Orochi no son tan malos si consiguen unas prestaciones razonables contando con un subsistema de caché con un diseño nefasto para cargas de trabajo de sobremesa, portátil o estación de trabajo.

Quizás con cargas de servidor (en versiones Opteron) de enteros para desplegar el poder de sus 16 INT cores por socket (2 dies Orochi por chip) y pueda destacar el tamaño total de caché por chip (16 MB) y responda mejor prestacionalmente.

Más en siguientes entregas…

Si consideras útil el contenido de este Blog, ayuda a mantenerlo ojeando algunas de las ofertas que consideres interesantes de nuestros anunciantes.

En múltiples entregas de LowLevelHardware he analizado en detalle el diseño interno de AMD FX Orochi 32 nm. Cito los más destacables:

AMD Bulldozer. Frecuencias finales. Actualizado – LowLevelHardware

AMD Bulldozer- HotChips23 – LowLevelHardware

AMD Bulldozer. Perspectivas – LowLevelHardware

La L3 cache multibanco en AMD Bulldozer. Actualizado – LowLevelHardware

AMD AGLUs, Bulldozer INT cores. Actualizado – LowLevelHardware

AMD Bulldozer. Primeros benchmarks. Actualizado – LowLevelHardware

AMD Bulldozer – ProfessionalSAT

La micro arquitectura de AMD Bulldozer. Actualizado – LowLevelHardware

Novedades y expectativas 2010. Actualizado – LowLevelHardware

AMD Bulldozer. Prestaciones estimadas – LowLevelHardware

Micro arquitectura AMD Bulldozer 2011. Actualizado – LowLevelHardware

Previo AMD Bulldozer. Actualizado – LowLevelHardware

Si consideras útil el contenido de este Blog, ayuda a mantenerlo ojeando algunas de las ofertas que consideres interesantes de nuestros anunciantes.

 

Carlos Yus Valero – informaticapremium     

AMD 6990 CrossFireX. Dinámica de fluidos y disipación térmica – ProfessionalSAT

La semana pasada entregué uno de mis Sistemas de Altas Prestaciones especializado en proceso OpenCL mediante dos tarjetas AMD 6990 con 4 GPUs Cayman y 8 GB de GDDR5 a 5 GHz.

AMD 6990 CrossFireX.

Me ha llevado unas cuatro semanas todo el proceso, desde la elección de los componentes hasta el diseño de la refrigeración y la validación del sistema para asegurar su estabilidad total en cargas máximas sostenidas OpenCL.

En este artículo detallaré el diseño de la exigente refrigeración del sistema y los resultados térmicos de su implementación, siendo una refrigeración por aire para un total de casi 1000W de consumo máximo.

Optimización del consumo eléctrico

El primer paso en la refrigeración de cada uno de mis Sistemas de Altas Prestaciones consiste en minimizar el consumo eléctrico de cada componente. Esto se consigue mediante la modulación independiente de los voltajes en BIOS.

La excelente Cooler Master Silent Pro Gold 80+ Gold alimenta el sistema.

Siempre empiezo marcando manualmente los voltajes mínimos estables (según los Data Sheets del fabricante, en este caso Intel) de cada parte del chipset. Hago lo mismo con la memoria, esta máquina se ha entregado con la DDR3 a 1.500 V.

Posteriormente entramos en la regulación de voltajes del procesador. Primero el voltaje en reposo en su estado de frecuencia mínima. En procesadores Sandy Bridge 2500K y 2600K escogidos he validado como estable los 0.712 V a 1.6 GHz.

Ahora llega la parte más dificultosa, el voltaje en carga máxima de CPU con los 4 cores al 100 %. En función del “sample que nos toque” estaremos sobre los 1.28 - 1.34 V a 4.4 GHz en un 2600K con 8 threads al 100% con absoluta estabilidad.

En las tarjetas AMD 6990 con dos GPUs Cayman cada una, los voltajes de core son 0.900 V en reposo a 250 MHz y 1.120 V en carga a 830 MHz (ajustes nominales).

En los dos ejemplares utilizados a este voltaje es posible llegar a los 900 MHz fuera de especificación con absoluta precisión en las cargas de trabajo OpenCL en carga 100% con la refrigeración utilizada a unos 80 – 82º C pico tras 24 h de cálculo con usos de GPU mínimos del 98%.

En reposo en el escritorio de Windows 7 Ultimate X64 el consumo del sistema en el enchufe es de unos 145W.

Debido a esta minimización del consumo eléctrico de cada componente he conseguido disminuir el consumo pico total desde los casi 1100W iniciales hasta los 939W finales en carga 100% sostenida.

Dual AMD 6990 CrossFireX: 939W en pico a 880 MHz, a velocidad de AMD 6790.

El consumo de la refrigeración.

Un dato a resaltar en un sistema de estas características dotado de muchos ventiladores y alguno de ellos de alto rendimiento es el consumo puro de la refrigeración.

Solamente variando del mínimo al máximo los 4 ventiladores regulables de este sistema y las dos turbinas de las dos tarjetas AMD 6990 arroja una diferencia de consumo de 40W debida al incremento de rpm de los motores de 12V. Nada despreciable.

Por otro lado recordar que los semiconductores incrementan su disipación térmica y consumo en función de la temperatura debido al incremento en el leakage de los transistores (pérdidas de corriente cuando está en off, en caso extremo degenera en electromigración). Por ello es conveniente controlar las temperaturas y no entrar en rangos peligrosos.

Diseño de la refrigeración del sistema AMD 6990 CrossFireX.

Desde el primer momento en que el cliente me encargó la máquina tuve claro que debía separar totalmente los flujos térmicos provenientes de la 4 GPUs del resto del sistema para evitar problemas en otras áreas.

Además era crítico extraer inmediatamente los 850+ W disipados en las GPUs de la torre evitando crear realimentaciones de aire caliente a otras partes del sistema.

Para ello dividí la máquina en tres alturas o zonas térmicas independientes, cada una de ellas con sus flujos de aire separados y diferenciados y rutas independientes de entrada y salida de aire.

Las tres áreas de refrigeración.

En la zona superior y la intermedia (zonas 1 y 2) la salida de aire se efectúa por la parte frontal de la torre mediante ventiladores de 12 cm, en cambio en la zona inferior la salida es a través de la fuente de alimentación y del panel trasero de la torre.

Las tres zonas diferenciadas de refrigeración.

Zona 1. CPU, parte superior de placa base y memoria DDR3.

En esta zona se produce una disipación térmica estimada pico de unos 130 – 150 W.

La verdad es que refrigerar un Core i5 2500K a 4.2 GHz no es tarea difícil, un simple Arctic Cooling Freezer 7 PRO 2 modificado para socket 1155 basta.

Esta CPU disipa unos 110W a la frecuencia objetivo de 4.2 GHz. Esta frecuencia ha sido seleccionada en función de la carga de trabajo OpenCL ejecutada en las 4 GPUs. La carga de CPU media es del 80% en los cuatro cores con el software elegido.

He creado un diseño de refrigeración absolutamente desproporcionado para esta zona queriendo así crear un exceso neto de presión dentro de la torre pensado en refrigerar con este excedente la Zona 2, la más crítica.

La salida de aire de la Zona 1 antes de montar su ventilador de salida.

He situado tres ventiladores de entrada en esta zona, uno de 14 cm y dos de 12 cm, el refrigerador de CPU lo he montado en dirección inversa a la normal (hacia el frontal de la torre). El aire “caliente” (medido en salida frontal está a unos meros 28º C en carga máxima) de esta zona se evacúa por el frontal.

Durante varios días fui variando la colocación del divisor de flujo superior.

Zona 2. AMD 6990 CrossFireX.

En esta zona se produce una disipación térmica estimada continua en carga máxima de unos 800 – 850 W.

La inyección de aire frío del exterior se produce por dos entradas independientes, la primera es desde la parte superior, desde la Zona 1.

Entrada doble superior para aumentar la presión interna.

La segunda y más importante entrada se produce a alta presión mediante dos ventiladores Scythe de 12 cm de alto flujo colocados a 8 mm de las tarjetas AMD 6990, el aire viene del panel lateral perforado.

Los dos Scythe evitan los excesos térmicos en el sistema CrossFireX.

Su función es inyectar aire en el espacio inter GPUs y evitar el estancamiento de aire evitando los Hot Spots.

Sin estos ventiladores Scythe no comerciales la temperatura en tests OpenCL con carga 100% en las 4 GPUs alcanzaba los 92º C en sólo un minuto…

Gracias a “mis contactos” tengo acceso a componentes no comerciales.

Con ellos el pico máximo obtenido tras 24h en carga máxima OpenCL con relojes a 880 MHz (a frecuencias de AMD 6790) es de solamente 82ºC y con frecuencias nominales de 830 MHz nos quedamos en menos de 80ºC.

A modo de referencia en Furmark con carga 100% en las 4 GPUs en modo Extreme Burning alcanza 61ºC en la GPU más caliente tras 2h.

Estos ventiladores llevan reguladores de rpm montados en la parte trasera de la torre.

La salida del aire caliente procedente de las GPUs 1 y 3 (las GPUs a la izquierda de las tarjetas AMD 6990) sale de la torre a través del panel trasero y gracias al exceso de presión interno no vuelve a entrar (no hay reflujo) ya que en el canal entre las dos tarjetas soplan sendos ventiladores Scythe.

En la configuración final minimicé la turbulencia consolidando el cableado.

La evacuación de aire de las GPUs 2 y 4 es más complicada. Se  realiza por su diseño dentro de la torre amenazando a otros componentes con su potente chorro de aire a 60ºC.

Una de las pruebas que realicé. Tapar el final del espacio entre las tarjetas.

El objetivo en este caso consiste en crear mayor succión que la presión de salida de las turbinas de ambas tarjetas. Para ello monté otro Scythe de 12 cm justo delante de la salida de las GPUs 2 y 4 auxiliado por otro ventilador de 12 cm en la salida frontal.

El panel divisor de flujo en su posición final con los flujos de aire identificados.

El resultado es excelente pues no se aprecia incremento alguno (cero ºC) en ninguna temperatura interna (disco duro, placa base,…) cuando las cuatro GPUs con sus se ponen a trabajar al 100% indicando que todo el calor producido por ellas sale antes de calentar ningún componente o el chasis.

La configuración final.

De hecho, todos los paneles de la torre aparecen fríos al tacto en carga 100%, no así los dos chorros de aire que emergen de la parte trasera del sistema que con unos 60ºC hacen imposible mantener mucho tiempo la mano en ellos.

Por el panel frontal se aprecia una clara diferencia de temperatura en la salida de la Zona 1 y la Zona 2. La Zona 1 evacúa por el ventilador superior a unos 28 – 30ºC, en cambio la Zona 2 evacúa por el central con un flujo mucho más potente a unos 42ºC.

Zona 3. Disco duro, fuente de alimentación y parte inferior de placa base.

En esta zona apenas se produce consumo eléctrico, quizás 100 W en pico entre el disco duro, el ventilador frontal y las pérdidas por efecto Joule en la excelente fuente Cooler Master PRO Gold 1200.

La entrada de aire se produce por el frontal gracias al ventilador de 25 cm y sale por el panel trasero y la fuente de alimentación. La fuente recibe la mayoría del aire por el panel inferior.

Probé el ventilador en ambas configuraciones, entrada y salida.

Con el ventilador en entrada se consiguen mejores temperaturas, eso sí, tras aislar el frontal del caudal de salida de la Zona 2.

La Zona 3 al completo.

Echad un vistazo a la web de mi nueva empresa, un proyecto de gran envergadura que llevo preparando hace más de un año.

Os lo recomiendo para diseño de sistemas de altas prestaciones:

Allí tenéis a vuestra disposición el formulario de contacto, para consultas sobre este artículo hacedlo más abajo en la sección de comentarios.

Y mi nuevo Blog de contenido muy técnico y actualizado donde encontraréis artículos míos sobre hardware, procesadores y sistemas y también otros posts de expertos programadores e informáticos sobre otros temas de actualidad:

Si consideras útil el contenido de este Blog, ayuda a mantenerlo ojeando algunas de las ofertas que consideres interesantes de nuestros anunciantes. Gracias de antemano.

El que tenga dudas o aportaciones tiene para ello la sección de comentarios, intentaré responder a todos y con la máxima claridad. Los Blogs deben de ser lugares de intercambio y agradezco vuestro feedback.

Carlos Yus Valero – informaticapremium     

AMD 6990 CrossFire Parte 2. Sistemas de Altas Prestaciones – ProfessionalSAT

Entre ayer y hoy he completado el montaje de una máquina absolutamente excepcional, se trata de uno de mis Sistemas de Altas Prestaciones pero, en este caso, debo reconocer que he tenido que echar el resto en el diseño del sistema de refrigeración.

Está dirigida a un cliente que la va a dedicar a cálculos OpenCL acelerado por las 4 GPUs Cayman con 2 GB cada una. El procesador es un Core i5 2500K Sandy Bridge de 32 nm configurado a 4.2 GHz. Su uso, como de costumbre en mis Sistemas de Altas Prestaciones va a ser continuo e ininterrumpido, aunque en este caso creo que van a haber frecuentes paradas técnicas para limpiar las tarjetas AMD 6990.

El diseño de la refrigeración de esta máquina ha representado un reto extremo.

1100 W de consumo continuo

Ciertamente de un equipo que cuenta con dos AMD 6990 no puede esperarse una gran economía eléctrica en su utilización y menos si se va a utilizar para proceso OpenCL en carga 100% continua e ininterrumpida.

Más de 800 W de consumo y disipación térmica entre las dos AMD 6990.

He llegado a medir 1100 W de consumo en el enchufe a 220 V… lo realmente difícil es extraer todo este calor de la torre y no solo hacerlo sino hacerlo rápidamente y consiguiendo que el calor que genera un componente no afecte a los demás.

Y hay únicamente una manera, extraer ese aire caliente de cada componente por separado por rutas independientes directamente al exterior de la gigantesca torre NOX Hummer.

Para lograr refrigerar dos AMD 6990 en CrossFire he tenido que invertir el giro de los dos ventiladores que vienen de serie en la Hummer, el trasero ha quedado metiendo aire y el delantero de 25 cm extrayéndolo hacia el panel frontal.

Además he añadido cuatro ventiladores de 12 cm a unas 1300 rpm:

• Dos en el panel frontal extrayendo el aire proveniente de las GPUs 2 y 4 directamente al exterior por el panel frontal.

Los dos ventiladores frontales de 12 cm extraen el aire proveniente de las GPUs 2 y 4.

• Dos en la parte superior inyectando aire fresco sobre la zona del procesador y memoria DDR3.

Los ventiladores superiores introducen aire para crear exceso de presión interna.

Exclusivamente para refrigerar  las 4 GPUs Cayman he destinado además tres ventiladores Scythe Slip Stream de 12 cm de alto flujo de aire y regulables por el usuario. Sus rpm máximas rondan las 3000, se trata de una serie especial que no se haya a la venta:

• Dos de ellos están sobre las AMD 6990 inyectando aire frío sobre ellas y en el espacio por el que toma aire la turbina de la primera tarjeta. Con esta adición he reducido en 25 ºC la temperatura de la primera tarjeta AMD 6990.

• El tercero se sitúa en la salida de aire frontal de ambas AMD 6990 y dirige el flujo de salida de las GPUs 2 y 4 hacia los dos ventiladores frontales superiores que rápidamente lo expulsan de la torre.

La torre, la enorme NOX Hummer:

Viendo como queda una placa base ATX en el interior de la Hummer nos hacemos una idea de su tamaño:

Parece que sobra espacio por todos lados, pero todavía no están las AMD 6990…

La verdad es que el diseño de la torre es excepcional pero no es en absoluto suficiente para poder diseñar con ella un sistema con dos AMD 6990 en CrossFire. Con la torre de serie más los dos ventiladores superiores adicionales de 12 cm las GPUs llegaban a 90ºC (concretamente la tarjeta superior que incluye las GPUs 1 y 2) en solamente un minuto de test OpenCL (!!) con el ventilador tarado la 100% y un nivel de ruido increíble.

Vista inferior.

Realmente alarmante… menos mal que tengo un extenso surtido de ventiladores de altas prestaciones y una de mis aficiones es la física y en concreto la dinámica turbulenta de fluidos…

Vista frontal, todo perforado para favorecer el flujo de aire.

Vista trasera antes de retirar las tapas perforadas.

Espacio, más espacio…

NOX Hummer: gigantesca, a su lado una torre ATX de tamaño medio.

El ventilador frontal de 25 cm, antes de darle la vuelta.

La parte superior contiene una tapa perforada que se puede retirar.

Con la tapa retirada.

Por esta zona se enrutan todos los cables para dejar libre la parte interior.

Las bahías de discos de 3.5” de color blanco. Para mejorar el flujo de aire la he retirado.

Perspectiva trasera.

Perspectiva frontal.

Vista interior.

La tapa lateral perforada.

Modificación de la torre:

En primer lugar procedí a la inversión del flujo de los dos ventiladores que trae de serie, estamos buscando un flujo de aire de atrás hacia adelante.

El gran ventilador de 25 cm frontal.

En segundo lugar, y contrariamente al sentido común, monté los dos ventiladores superiores de 12 cm metiendo aire sobre la zona de la CPU y hacia las AMD 6990. Interesa alejar el calor de las 4 GPUs del resto de componentes…

Flujo de entrada sobre CPU y memoria en dirección a las 4 GPUs Cayman.

Esta zona está realmente “fría” con temperaturas en carga máxima en la chapa blanca sobre los 30ºC.

En tercer lugar retiré todos los “accesorios” de la torre que pudiesen obstruir el flujo de aire, entre ellos las bahías de discos duros (excepto la inferior), las tapas traseras de los slots PCI y PCIex y los curiosos sistemas de sujeción de las tarjetas (que yo sustituyo por los clásicos y más robustos y fiables TORNILLOS).

Muy bonitos pero más prácticos y estables son los clásicos tornillos.

Vía libre al aire, y con él al polvo. La limpieza del sistema será crítica, avisado queda el cliente…

Por mí podían ahorrarse accesorios de este tipo…

También he eliminado todos los filtros anti polvo que incluía la torre y lo he hecho por dos razones:

• En primer lugar para aumentar el flujo de aire y disminuir las temperaturas.
• En segundo lugar porque solamente hay filtros en las bahías de 5.25” del panel frontal y en el ventilador inferior (al lado de la fuente de alimentación (no lo he utilizado), Por todos los demás huecos entra polvo libremente incluyendo toda la tapa lateral, el ventilador frontal de 25 cm, los ventiladores superiores y resto de ranuras de ventilación.

Para poner filtros de ese modo, es mejor no hacerlo pues son inútiles.

Continuará en la tercera entrega…

Si consideras útil el contenido de este Blog, ayuda a mantenerlo ojeando algunas de las ofertas que consideres interesantes de nuestros anunciantes.

Carlos Yus Valero – informaticapremium