jueves, 2 de febrero de 2017

Microarquitectura en imágenes (I) Execution Trace cache. Actualizado – LowLevelHardware

La Execution Trace Cache es uno de los signos identificativos de la antigua arquitectura Intel Netburst. Almacena instrucciones ya descodificadas en orden de programa (traces). Su tamaño era de 12k micro ops o unos 21 KB (según Intel).
 
Efectivamente daba una tasa de aciertos realmente baja cercana a un 80% en código real y en caso de muchos branches llegaba a un solamente 55%, por ello se erigió en un talón de Aquiles de la microarquitectura Netburst.
 

Trace cache de Willamette 180 nm (L2 256KB).

En sus cuatro encarnaciones (cinco si Tejas hubiese llegado al mercado), la Trace Cache (en adelante TC) de los Intel Pentium 4, mantuvo su organización. En Willamette (arriba, primera generación, 180nm, 256 KB L2) y Northwood (abajo, segunda generación, 130 nm, 512 KB L2) podemos ver que son prácticamente idénticas.

La TC sustituía a la típica cache de instrucciones L1 (L1i) de otros diseños. En lugar de almacenar instrucciones x86, almacena micro-operaciones nativas del core Pentium 4 ya decodificadas. Su tamaño efectivo era de 10k a 18k instrucciones (según su naturaleza) con unas tasas de acierto, según Intel, comparable a una L1i de 8 a 16 KB.

  Trace caché de Northwood 130 nm (L2 512KB).

Al almacenar secuencias de micro-operaciones, llamadas traces, libera así de trabajo a los decoders x86 cuando se ejecuta varias veces el mismo código (se encuentra almacenado listo para su uso). Esta estructura era capaz de enviar hasta 3 instrucciones/ciclo hacia el núcleo de ejecución OoO (Out of order).

La mayor limitación era la bajísima velocidad sostenida (througput) de decodificación de instrucciones cuando se daba un trace cache miss o fallo de la TC.

El x86 decoder del Pentium 4 en todas sus versiones sólo era capaz de traducir una instrucción IA32 en microinstrucciones por ciclo (!!).

Este era un grave factor limitante de la arquitectura Netburst. En ciertas condiciones un Pentium 4 se comportaba como un procesador single-issue.


Trace caché de Prescott 90 nm (L2 2048KB).

La TC contiene traces: secuencias de uops (micro operaciones) construidas en orden de programa, estas instrucciones están ordenadas en grupos de 6 por línea de TC. Además, la TC contiene un pequeño predictor de saltos (trace BTB, Branch Target Buffer) solamente para las instrucciones presentes en ella.

Para los tipos de instrucciones IA32 más complejos no se utilizaba el x86 decoder ni la trace cache, sino la Microcode ROM. Una memoria especializada que guarda secuencias de uops de las instrucciones x86 más complejas.

CedarMill65nm_TCTrace caché en Cedar Mill 65 nm (L2 2048 KB)

En un P4, las instrucciones x86 que acabarán siendo decodificada en más de 4 uops se envían a la Microcode ROM, siendo su proceso de decodificación mucho más lento. Prescott aportaba en este sentido mejoras, ya que eran menos las instrucciones que requerían su paso por la Microcode ROM.

Conclusiones:

La trace cache aporta mejoras pero también trae consigo grandes problemas:

  • Una mayor complejidad respecto a una L1i convencional.
  • Su gran (enorme) penalización en latencia en el caso de fallo (trace cache miss).
  • Su baja tasa de aciertos efectiva, normalmente sobre un 80% y a veces cercana al 55%.
  • Su limitado tamaño, unas 12k instrucciones, equivalente a unos meros 8 - 16 KB.

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

3 comentarios:

  1. Buen post. Consulta este también muy interesante enlace:
    http://www.tinker.ncsu.edu/ericro/publications/conference_MICRO-29_rbs.pdf

    ResponderEliminar
  2. Parece que el problema radica en el tamaño de la cache, puesto que si consultas papers acerca de TC (el concepto, no la implementacion en el PIV), siempre se obtienen buenos resultados.

    saludos

    ResponderEliminar
  3. El concepto de Trace caché es ciertamente elegante aunque plantea numuerosos problemas técnicos de cara a la implementación en diseños reales.

    Entre ellos añade muchísima complejidad a las etapas de decoding puesto que las desacopla del resto del pipeline y con ello alarga la longitud total de éste en muchas etapas.

    Recuerda que Willamette y Northwood tenían 20 - 21 etapas de pipeline tras la trace caché y muy probablemente unas 8 antes de ella (fetch y decode).

    Prescott llegó a 31 etapas tras la TC y unas 12 - 15 de Fetch y Decode para un total de 42 - 47 etapas de pipeline en enteros (muchas más en FPU).

    El problema principal de la TC en Netburst fue su bajísimo tamaño EFECTIVO y digo efectivo porque su capacidad era de unos 80 KB de datos pero esto se traducía solamente en unas 12 Kuops. Y dada la débil potencia del juego de instrucciones interno de los P4 (eran necesarias muchas instrucciones para comandos relativamente sencillos) no "cundía" su tamaño.

    Sobre estos problemas añadía un anémico decoder de una sola vía y un reloj de TC de la mitad del general.

    Un saludo,

    Carlos Yus.

    ResponderEliminar

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