jueves, 2 de febrero de 2017

La microarquitectura de AMD Bulldozer. Actualizado - LowLevelHardware

Con Bulldozer AMD ciertamente ha roto moldes en el rígido diseño de un procesador X86. El concepto de módulo con dos cores de enteros y una FPU sobredimensionada es novedoso y ciertamente tiene algunas ventajas sobre los diseños más convencionales.

Bulldozer_manipulado630 Fotografía manipulada del die de AMD Orochi, el primer chip de arquitectura Bulldozer.

Esta organización de las unidades de proceso conlleva también cambios en el subsistema de caché y de memoria, en ellos me centraré en este artículo.

Las unidades de ejecución de Bulldozer

Como todos ya conocéis, Bulldozer combina dos INT cores junto con una FPU con capacidad FMAC para formar un módulo. Trabajando sobre el die manipulado por AMD y hecho público, podemos observar varios detalles, entre ellos los dos INT cores simétricos.

core_L2_L3_Bulldozer_etiq Organización de uno de los módulos Bulldozer con sus cachés externas L2 y L3.

Me remito a mi artículo anterior de LowLevelHardware:

Intel Core i7 SMT vs. AMD Bulldozer CMT – LowLevelHardware

En un módulo Bulldozer hay duplicadas algunas de las unidades de ejecución para conseguir con ello un aumento de prestaciones a la vez que se comparten algunas unidades que por su tamaño no es práctico duplicar.

BulldozerHotChips_August24_8pmET_NDA-3_575px

Diseño general de Bulldozer 32 nm.

En el caso de Bulldozer 32 nm, AMD ha diseñado un procesador dotado de dos cores de enteros (INT cores) compartiendo:

  • El hardware de Branch Prediction.

  • La caché L1i de instrucciones de 64 KB y 2 vías.

  • Las etapas de fetch (32 bytes / ciclo).

  • Los cuatro decoders X86.

BulldozerHotChips_August24_8pmET_NDA-7_575px

Componentes compartidos en el Front End.

  • La FPU dual de 128 bit FMAC con 2 pipelines FMAC 128 bit y 2 pipelines packed INT de 128 bit MMX.

BulldozerHotChips_August24_8pmET_NDA-9_575px La FPU compartida en Bulldozer 32 nm.

También son compartidos los siguientes componentes del die de Bulldozer:

  • El Data Prefetcher encargado de precargar datos en las caches.

  • La caché L2 compartida para cada dos INT cores con su L2 TLB.

BulldozerHotChips_August24_8pmET_NDA-10_575px

La L2 compartida de Bulldozer 32nm, probablemente de 1 o 2 MB y 16 vías.

BulldozerHotChips_August24_8pmET_NDA-8_575px Los dos cores discretos de enteros en Bulldozer 32 nm.

En Bulldozer, al haber dos cores de enteros completos, hay muchas estructuras duplicadas:

  • Un scheduler de enteros (INT scheduler) por core, unificado para ALUs y AGUs.

  • Dos ALUs. Unidades de proceso de enteros.

  • Dos AGUs. Unidades de generación de direcciones de memoria.

  • L1d de 16 KB y 4 vías de asociatividad.

  • L1 DLTB de 32 entradas fully associative.

  • Juego de registros y de registros alias con su hardware de renombramiento.

  • Unidad de Load - Store con procesamiento fuera de orden en lecturas y escrituras a memoria con sus colas de comandos.

Analizando el die observamos los dos INT cores dentro de cada módulo:

INTcores Los INT cores de Bulldozer.

Después de este repaso a sus unidades de ejecución, vamos a examinar su arquitectura de caché.

Las cachés de Bulldozer

En cada módulo de Bulldozer AMD integra dos INT cores, cada uno con su caché privada L1d (datos) de 16 KB y 4 vías de asociatividad, en cambio, la caché L1i (instrucciones) sigue siendo única y mantiene la tradición de AMD: 64 KB y 2 vías de asociatividad.

core_L2_L3_Bulldozer_etiqUn módulo Bulldozer con su L2 privada de 2 MB y su banco de 2 MB de L3.

El análisis de die (que podéis examinar en el principio del artículo) manipulado por AMD para ocultar su verdadera estructura ya arroja algo de luz sobre las primera implementación de Bulldozer: el octal core Orochi.

Ampliando los INT cores, observamos las cachés de nivel 1:

L1s  Las pequeñas L1d de 16 KB y la L1i de 64 KB compartida.

Observamos numerosos bloques de SRAM, su uso es el siguiente:

  • Una de ellas es el BHT (Branch History Tables) utilizadas por los mecanismos de Branch Prediction.
  • Dos son los Write Buffers (Buffers de Escritura Combinada) utilizados para crear un flujo ordenado de datos hacia la L2 compartida de 2 MB desde las dos pequeñas L1d de 16 KB y 4 vías.

Las SRAM de los Write Buffers son necesarias ya que las L1d han cambiado su política de exclusiva (como en los cores anteriores de AMD) a inclusiva (como en los microprocesadores Intel), por ello es necesario “copiar” a L2 los datos escritos en cada una de las dos pequeñas L1d.

Con alta probabilidad en la parte inferior del módulo se observa la doble FPU FMAC de 128 bit con 2 pipelines extra para MMX 128 bit y en la parte superior las etapas de Fetch y X86 Decoding que se alimentan de las instrucciones procedentes de la caché L1i de 64 KB y dos vías a razón de 32 bytes / ciclo.

Los bloques funcionales de la izquierda son principalmente circuitería relacionada con el Hardware Prefetching.

Modulo Esquema del módulo Bulldozer.

Las latencias de caché parece que serán bastante mediocres:

  • 4 ciclos para las L1d de 16 KB y 4 vías.
  • 18 ciclos para la L2 de 2 MB (seguramente de 16 ó incluso 32 vías)

Veremos si gracias al motor OOO avanzado de Bulldozer AMD consigue ocultar estas altas latencias al software encontrando al vuelo instrucciones suficientes para enviar a las unidades de ejecución (sin L2 misses).

Estoy deseando echar un vistazo en Noviembre al verdadero die de Bulldozer en alta resolución.

Bulldozer y la memoria

Los roadmaps de tecnologías de memoria no anuncian DDR5 hasta 2015, nos debemos conformar con DDR3 hasta entonces.

7 Roadmap RAM hasta 2015. Fuente: MEMCON10.

Bulldozer montará un dual channel DDR3 hasta 2.13 GHz para un ancho de banda agregado de 31.2 GB/s por die de 8 INT cores.

Para servidores, Interlagos, la versión MCM de Bulldozer con 2 dies de 8 INT cores en un chip para socket G34, contará con un quad channel DDR3 hasta 1.86 GHz para un ancho de banda total de 59.7 GB/s (!!) por socket.

Contemporáneamente, Sandy Bridge 8 cores (16 threads) contará con 4 canales DDR3 en socket 2011 probablemente con la misma frecuencia y ancho de banda que Interlagos (1.866 GHz y 59.7 GB/s).

Algo “raro” en Bulldozer

Veo una extraña y alarmante falta de ancho de banda de decodificación en Bulldozer (4 instrucciones / ciclo) para el anchísimo hardware de ejecución que tiene detrás:

  • 2 INT cores con 2 ALUs y 2 AGUs por core
  • 1 FPU con 2 pipelines FMAC de 128 bit y 2 pipelines packed integer MMX de 128 bit

En total, un módulo, es capaz de ejecutar en paralelo:

  • 4 INT (core 0) + 4 (FPU / MMX) + 4 INT (core 1)

Es decir 12 instrucciones por ciclo y solo son decodificadas 4 por ciclo (??).

Quizás AMD se esconda un as en la manga …

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

6 comentarios:

  1. Hola, dos preguntas de un neófito en estos temas, porqué parece que las latencias de las caché L1 y L2 serán bastante mediocres?, y la otra es que mucho se criticaba el posible desempeño en un único hilo de enteros por cada "núcleo" (por lo 2 ALUs + 2 AGUs), pero aquí pareciera que hay un anchísimo núcleo de ejecución.

    No contradigo ni refuto nada, de repente me perdí o hay cosas básicas que desconozco (recién estoy empezando a leer sobre estos temas).
    Muchas gracias por tus publicaciones y sigue adelante

    ResponderEliminar
  2. Buenos días JBCH,

    Las latencias L1d han ascendido hasta los 4 ciclos (como en Intel Nehalem o Atom), pero lo que es más alarmante es el incremento de la L2 hasta los 18 ciclos. 18 ciclos es quizás demasiado, tengamos en cuenta que la L2 de 6 MB de un Core 2 Duo de 45 nm tenía una latencia de 15 ciclos.

    Veremos como queda todo esto en los productos finales, pero a priori 18 ciclos parece basatnte alto.

    Sobre los cores de enteros (INT cores) con 2 ALUs + 2 AGUs, salta a la vista que en las etapas de ejecución Bulldozer ha perdido ancho de banda respecto a Shanghai (3 ALUs + 3 AGUs). Aunque Bulldozer ha ganado enormemente en las etapas de fetching y también, aunque más timidamente, en el decoding.

    En resumen, con los últimos datos a la vista espero de Bulldozer unas prestaciones similares a Shanghai core for core y clock for clock en enteros.

    Saludos,

    Carlos Yus.

    ResponderEliminar
  3. En opinion tuya de que se trataría ese as en la manga que oculta AMD.
    En el ejercicio de volar la imaginación y suponer algo, que crees podría ser, por que a la vista si bien el diseño es revolucionario, en latencia no ha evolucionado por lo visto

    ResponderEliminar
  4. Bueno, quizás tenga algo que ver con las etapas de decodificación y una asincronía o isocronía respecto a los pipelines de ejecución en su diseño...

    Carlos Yus.

    ResponderEliminar
  5. Hola

    Quizá pueda ser una cache 'extra' como la de trazas de los PIV que tiene copia de secuencias ya ejecutadas con anterioridad y no es necesario hacer Fetch a tantas instrucciones por ciclo (puesto que ya tiene posibles instrucciones a ejecutar pre-cargadas)

    Como ves?

    Saludos

    ResponderEliminar
  6. Anónimo, lo que comentas es posible.

    La mayor ventaja de un tal sistema consiste en que desacopla las etapas de Fetch y Decoding del resto del pipeline, haciendo que el Critical Path de ejecución sea más corto.

    La pega, como bien nos enseñó la arquitectura Netburst, es que acarrea muchísima complejidad adicional, lo que niega la mayoría de sus ventajas, además de ocupar más superficie de die y penalizar muchos ciclos adicionales en caso de Branch Misprediction...

    Una solución realmente elegante y eficaz es la uop Cache de Sandy Bridge; combina todas las ventajas y salva los inconvenientes... Excelente diseño.

    Un saludo,

    Carlos Yus.

    ResponderEliminar

Nota: solo los miembros de este blog pueden publicar comentarios.