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.
Etiquetas de Technorati:
SAT,
IT,
AMD,
Bulldozer,
CMT,
32 nm,
Orochi,
AMD FX,
Phenom III,
micro arquitectura,
CPU,
core
![SB_4C_630p_cores_thumb[1]](http://lh4.ggpht.com/-O3fSAL-6KGk/TvdWt9-FoQI/AAAAAAAAFKU/bTYFE2hJCJc/s1600-h/SB_4C_630p_cores_thumb%25255B1%25255D%25255B3%25255D.png "SB_4C_630p_cores_thumb[1]")
![SB_uopcache_thumb[1]](http://lh6.ggpht.com/-ijsUrfplNR8/TvdWztcI1DI/AAAAAAAAFKk/Aq8wf7AxyHQ/s1600-h/SB_uopcache_thumb%25255B1%25255D%25255B3%25255D.jpg "SB_uopcache_thumb[1]")
![die_thumb[1]](http://lh4.ggpht.com/--br4FVd9Eio/TvdW4Rt7YII/AAAAAAAAFK0/e1sG27Na1rA/s1600-h/die_thumb%25255B1%25255D%25255B3%25255D.png "die_thumb[1]")
El venerable y efectivo Nehalem de 45 nm.
