
En este artículo voy a describir alguna de las mejoras micro arquitecturales implementadas por AMD en la primera evolución de la arquitectura Bulldozer que próximamente verá la luz en los APU Trinity 32 nm.
Al final del artículo comento la adopción de AMD para Piledriver de la nueva tecnología RCM (Resonant Clock Mesh) de distribución de señal de reloj de Cylos Semiconductor.
He modificado totalmente la sección de conclusiones con los cambios que considero necesarios a esta micro arquitectura para que algún día despliegue toda su potencia oculta. La arquitectura Bulldozer es capaz de mucho más.
Por cierto, echad un vistazo a los comentarios de este artículo, pues hay información muy interesante y respuestas a algunas preguntas comunes.
La fotografía de Piledriver muestra algunos cambios frente a Bulldozer.
Estos nuevos cores de procesamientos estarán disponibles en dos variantes no idénticas:
- Primero aparecerán en Trinity 32nm, el sustituto de los actuales Llano 32 (AMD A8, A6 y A4) con GPU Radeon integrada.
- En una segunda etapa, hacia Q3 2012, se actualizarán los cores Bulldozer de los chips AMD FX 32 nm con núcleos Piledriver de segunda generación derivados de los integrados en Trinity. Son los que considero más interesantes.
La nueva AMD
Tras la salida de Dirk Meyer, AMD ha cambiado de manera importante sus objetivos, ahora ya no pretende alcanzar a Intel en prestaciones puras por core (IPC). Dirk luchó por ello con los pocos recursos que le dejó la desastrosa gestión anterior de sus antecesores.
Fueron años de despilfarros que malgastaron los enormes beneficios de la época de gloria de los AMD Athlon, Athlon64 y Opteron.
La lucha en IPC se antojaba imposible y aunque lo pretendiesen es simplemente absurdo dado el altísimo perfeccionamiento alcanzado por Intel y su arrolladora cadencia de producción de nueva micro arquitectura y nuevo proceso de fabricación en años alternos (Intel Tick Tock). Sobretodo sabiendo que actualmente Intel ostenta de un 20 a un 50% de ventaja en IPC por core y a igualdad de reloj.
Roadmap de sobremesa 2012 – 2013. A finales de año llega Piledriver.
AMD con su nueva estrategia ve un futuro para sus procesadores con un diseño SOC, muchos de ellos fabricados en procesos Bulk (más dirigidos a bajos consumos y no tan altas frecuencias) y no los caros SOI HKMG actuales, pensando más en el rendimiento por watt que en rendimientos absolutos.
AMD Piledriver core
Toda la información expuesta a continuación ha sido extraída de la reciente revisión de la Guía de Optimización Software para la Familia 15h de AMD:
Software Optimization Guide for AMD Family 15h Processors.
Los integrantes de la micro arquitectura Bulldozer estan divididos en varias familias y estas a su vez en modelos:
- Los actuales cores Bulldozer (AMD FX 32 nm) son denominados familia 15h y modelos 00h - 0fh (0xh). Incluyen caché L3 de 8 MB:
- Los cores integrados próximamente en Trinity son familia 15h y modelos 10h - 1fh (1xh). No llevarán caché L3 e ira´n acompañados de una GPU integrada de la familia Radeon HD6000.
- Los cores integrados en el sustituto de AMD FX 32 nm serán familia 15h y modelos 20h - 2fh (2xh), contarán con caché L3, muy probablemente igual a la actual (8 MB).
Los modelos 10h - 1fh (1xh) y 20h - 2fh (2xh) incorporan cores Piledriver, de primera y segunda generación respectivamente, estos últimos con algunas mejoras adicionales.
Primera imagen de Trinity 32 nm, dos módulos Piledriver y GPU AMD serie 6000.
Las diferencias de Piledriver respecto a los actuales cores Bulldozer son las siguientes:
Mejoras micro arquitecturales en AMD Piledriver 32nm.
Entre las diferencias importantes puedo señalar las siguientes:
- El soporte para nuevos juegos de instrucciones, entre los más destacados el FMA3 de Intel.
- La ampliación de la cola de precarga de instrucciones (load queue) de la FPU de 40 a 44 entradas.
- El soporte para los formatos FPU de 16 bit.
- La ampliación del buffer L1 DTLB (el translation lookaside buffer de datos de nivel 1) de 32 a 64 entradas. 32 entradas era claramente insuficiente.
El resto de cambios serán menores y poco significativos prestacionalmente hablando.
También espero y digo espero porque no sé si AMD lo implementará o no, una sustancial mejora en la velocidad de escritura de las cachés L1d y L2 de Piledriver respecto a los horribles ratios de Bulldozer.
Esto exigiría un rediseño de las WCC (write combining caches) de Bulldozer, unos pequeños buffers de 4 KB por core (2 por módulo) que consolidan las escrituras desde las dos L1d de cada core (dentro del módulo) hacia la L2 compartida de 2 MB.
En la práctica es una caché L1.5d. El flujos de datos pasa desde la L1d de 16 KB a la WCC de 4 KB y de ahí a la L2 de 2048 KB.
Conclusiones e ideas generales
No me gusta Bulldozer. Es simplemente así, en 2012 la evolución de las micro arquitecturas sigue la dirección opuesta: pipelines cortos, cachés L1 de 32 KB con alta asociatividad (8 vías) y mecanismos branch prediction muy muy avanzados.
Bulldozer y Piledriver tienen un grave fallo, el Front End no es capaz de alimentar tres schedulers con 4 pipes cada uno (los dos INT cores y la unidad SIMD FMAC), nada menos que doce unidades de ejecución se alimentan de él.
Los Decoders sólo son capaces de descodificar 4 instrucciones/ciclo a partir de un fetch de 32 bytes/ciclo desde la L1i de 64 KB y dos vías, en el caso de ser instrucciones X86 simples que generen sólo una macro op.
Si hay una instrucción X86 más compleja que genera 2 macro ops, el ratio de decoding se reduce a 2 simples y una doble macro op y no 3 + 1 como sería deseable.
Y si son instrucciones X86 complejas que generen más de 2 macro ops y deban usar el microcode engine solamente se descodifica en pico una instrucción/ciclo y lo normal es que tarde bastantes ciclos en secuenciar una instrucción compleja X86 en macro ops. Y en ese tiempo no entran instrucciones en los pipes… Todo el front end se bloquea y los demás threads tienen que esperar.
Además, los decoders procesan instrucciones, hasta 4 en paralelo si son simples, pero NO pueden descodificar instrucciones de dos threads diferentes. El funcionamiento es en ciclos alternos (ciclo 1, thread 1; ciclo 2, thread 2; …) Si los dos INT cores están activos, los decoders sirven a cada INT core cada dos ciclos, dando un pico de 2 instrucciones por ciclo por INT core, insuficiente pues cada INT core posee 4 pipes.
Los INT cores poseen 4 pipes, dos de ejecución (EX0 procesa ALU y IDIV, EX1 procesa ALU, IMULT, JUMP) y dos para operaciones de lectura de memoria (AGLU0, AGLU1). En total 4 unidades de ejecución por INT core.
AMD debe trabajar en ensanchar los decoders, debería ir hacia un diseño de 6 instrucciones/ciclo y reducir el numero de instrucciones X86 que utilizan micro código. La tasa de Fetch actual (32 bytes/ciclo) es suficiente.
El diseño actual de la caché L1i (L1 de instrucciones) debe desecharse. 64 KB no son necesarios pero sí elevar su asociatividad a 8 vías (tened en cuenta que sobre ella se ejecutan 2 threads). 32 KB y 8 vías sería lo óptimo.
El diseño de las L1d me gusta pero debe aumentarse a 32 KB y sería bueno llegar a las 8 vías, aunque 4 es satisfactorio, suficiente.
Hay que trabajar en los anchos de banda en escritura, Bulldozer arroja resultados terribles en escritura o copia en L1d y L2. Hay que revisar el funcionamiento de las WCC de 4 KB por INT core.
La caché L2 debería reducirse a 1 MB o incluso 512 KB manteniendo las 16 vías y reduciendo el acceso load to use a 10 – 12 ciclos.
La política de acceso a L3 y su manejo de la coherencia deben modificarse. Los bits per core de Nehalem y Sandy Bridge deben de ser incorporados a su diseño. AMD debería ya de una vez desechar las cachés exclusivas.
También debe mejorarse la latencia de activación del Turbo Core y debe reducirse el voltaje cuando se activa. Ahora mismo un Phenom II X6 o un Bulldozer FX 8150 con Turbo core activado trabajan a voltajes de 1.35 a 1.50V, es absurdo.
En mis ensayos personales con multitud de CPUs de ambas familias consigo estabilidad absoluta a 0.10V, 0.15V o incluso 0.20V menos que los nominales a frecuencias iguales a las de Turbo Core reduciendo la temperatura y el consumo radicalmente.
Lo esencial de los modos Turbo es una respuesta instantánea de la subida de frecuencia, si no, muchas veces la frecuencia se incrementa cuando el proceso crítico ya ha concluido y lo peor, a frecuencia reducida y con sensación de lentitud para el usuario.
Se denomina Race To Idle y consiste en incrementar la frecuencia al máximo para acabar rápido el proceso y volver lo antes posible al estado mínimo de frecuencia y voltaje para ahorrar energía. AMD debería implementar esta técnica.
El Branch Prediction también reside en el Front End y es compartido por los dos INT cores y la SIMD FMAC. Carece de predicción para Loops por lo que los predice generalmente mal. Su precisión general es buena (mucho mejor que la de los antiguos Phenom II) pero le penaliza la longitud del el pipeline de enteros, la penalización tras un fallo de predicción Branch asciende de 19 a 22 ciclos (!!).
Una hipotética macro op cache implementada en las primeras etapas del pipeline de cada INT core haría milagros en Bulldozer, su efecto sería mayor que el de la micro code caché de Sandy Bridge.
Dos chips Orochi 32nm forman el nuevo Opteron Interlagos 16 cores.
De todos modos AMD está realizando progresos que quizás hagan que en un futuro próximo sea un core más equilibrado. La actualidad de Bulldozer es poca potencia de proceso single thread y un nivel de prestaciones aceptable solamente cuando el software carga los ocho threads por chip a fondo… un escenario que se da en pocas cargas de trabajo.
Nos guste o no, y estamos en 2012, el mundo sigue dominado por la velocidad de respuesta de la máquina a cargas de 1 thread. AMD debe mejorar en este sentido y en Bulldozer hay claras áreas mejorables sin mucha inversión.
Sigo siendo de la opinión de que AMD tiene un mejor core que Bulldozer, el venerable K10 de 65 nm, K10.5 de 45 nm y actualmente “K11” de 32 nm (el incluido en Llano). Con las lógicas mejoras, sobretodo en el terreno de Branch Prediction, mejora de la velocidad L2, aumento de ancho de la FPU a 256 bit y con las nuevas (y excelentes) controladoras de memoria de AMD.
Con sus pequeños cores (poco más de 9 mm2) sería factibles integrar 8 con 8 L2 de 512 KB y una L3 de 8 MB en un die con una superficie moderada… sería un muy competente rival para Intel Sandy Bridge.
El problema más grave de AMD continúa siendo el de siempre: Intel. Estoy asombrado de los progresos que llegan en alrededor de un año con Haswell 22nm… entre ellos la implementación de memoria transaccional.
Es una verdadera pesadilla para AMD tener a Intel como rival con sus agresivas políticas de desarrollo y su brutal gasto en I+D además de su ingente capacidad de ingeniería. Cada dos años lleva al mercado una nueva micro arquitectura (TOCK) que mejorar sustancialmente la anterior y encima en los años alternos, puntualmente, comercializa un nuevo proceso de fabricación (TICK) ( … 180nm > 130nm > 90nm > 65nm > 45nm > 32nm > 22nm > 14nm …) que deja prácticamente en ridículo al resto de la industria de semiconductores mundial…
AMD Piledriver RCM (Resonant Clock Mesh)
AMD y Cylos Semiconductor han informado que Piledriver integra una nueva metodología para la transmisión de la señal de reloj a todos los transistores del die.
Se denomina RCM (Resonant Clock Mesh) y permite una reducción de un 24% en el consumo de la red de distribución de reloj y globalmente un 10% global de reducción de consumo.
Sin duda es una excelente noticia, pues AMD, actualmente está limitada por disipación térmica y consumo en Bulldozer y un recorte sólo por la adopción de RCM junto con otro tanto por ciento debido al refinamiento del proceso de fabricación de 32nm HKMG SOI de Global Foundries puede dar a Piledriver una nueva vida tanto en Trinity como en el futuro AMD FX octal core.
Sin duda permitirá unas frecuencias mayores manteniendo el TDP y quizás pueda, un AMD FX basado en cores Piledriver, coquetear con los 4.6 – 4.8 GHz.
En fin… más en breve.
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:
![ip16_texto_300px_blanco[4][2][2] ip16_texto_300px_blanco[4][2][2]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhr4zGKIEfsy5h5HBnoPlN1hXYMNcjtWZXDCL5Eks7nD-IcRXWNp4NjEWUlhOBwuqq1KifmMv8RZYJhCw_cvRqUcZDowavkwXTHxUbJnS1mp6UOOrvY8e0YCMKi1bFknyCyXTzbtsEBwoM/?imgmax=800)
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:
![infromaticapremium-blog[4][2][2] infromaticapremium-blog[4][2][2]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhtbqtucFt0XZtciVrxs0rQSXaTD_w64_XTR-JjOqr9Ea3mpBVJi23wXJdw4PH43iLHRdyWgPvI6XRefEHkeRQtDwQB8w6lt5TTjUQJ19ICE5lDvxmn2MSMr32_rCT4qgvzpoORbyQg1s4/?imgmax=800)
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.