INDICE - unizar.eswebdiis.unizar.es/gaz/biblio/pdfs/1998_tesis_Pablo.pdf · 2.3.4 Coherencia basada...

Gestión Multinivel y Prebúsqueda Hardware en Memorias Cache Integradas i

INDICE

Introducción 1

0.1 Memorias cache multinivel ...................................................................................... 3

0.2 Prebúsqueda ............................................................................................................. 4

0.3 Referencias ............................................................................................................... 6

CAPÍTULO 1 Metodología: Técnicas de muestreo y selección de traza 9

1.1 Introducción ............................................................................................................. 9

1.2 Estado actual .......................................................................................................... 11

1.2.1 Técnicas de muestreo 131.2.2 Fuente de la traza 131.2.3 Grado de multiprogramación del sistema simulado 15

1.3 Warm Time Sampling............................................................................................. 15

1.3.1 Implementación de WTS 161.3.2 Posibles fuentes de error 171.3.3 Resultados 191.3.4 Trabajos relacionados 23

1.4 Selección de la muestra .......................................................................................... 23

1.4.1 Caracterización previa 241.4.2 Selección de la muestra en base al comportamiento 281.4.3 Validación y rendimiento de la selección basada en comportamiento 281.4.4 Representatividad de la muestra 291.4.5 Tiempo de simulación 33

1.5 Conclusiones .......................................................................................................... 35

1.6 Referencias ............................................................................................................. 36

INDICE

ii Gestión Multinivel y Prebúsqueda Hardware en Memorias Cache Integradas

CAPÍTULO 2 Gestión de Contenidos en Memorias Cache Multinivel Integradas 39

2.1 Introducción ........................................................................................................... 39

2.2 Funcionamiento básico de la Inclusión, Exclusión y Demanda............................. 41

2.2.1 Gestión de L2 en Inclusión 432.2.2 Gestión de L2 en Exclusión 442.2.3 Gestión de L2 en Demanda 45

2.3 El problema de la coherencia ................................................................................. 45

2.3.1 Inclusión y coherencia 462.3.2 Exclusión y coherencia 462.3.3 Demanda y coherencia 462.3.4 Coherencia basada en actualización y gestión de bloques sucios 47

2.4 Metodología de trabajo........................................................................................... 48

2.4.1 Modelos de área y tiempo de ciclo 492.4.2 Descripción del simulador 492.4.3 Carga de trabajo 52

2.5 Resultados .............................................................................................................. 52

2.5.1 Resultados en SPEC92 532.5.2 Resultados en SPEC95 57

2.6 Ejecución superescalar y fuera de orden ................................................................ 63

2.7 Conclusiones .......................................................................................................... 64

2.8 Referencias ............................................................................................................. 65

CAPÍTULO 3 Prebúsqueda Hardware de Datos: clasificación y análisis de mecanismos 67

3.1 Introducción ........................................................................................................... 67

3.2 Trabajo previo ........................................................................................................ 68

3.2.1 Prebúsqueda secuencial 693.2.2 Prebúsqueda con stride constante 703.2.3 Prebúsqueda en listas encadenadas [MH96] 723.2.4 Prebúsqueda markoviana (correlación) [PG95, JG97] 74

3.3 Modelo de Prestaciones.......................................................................................... 75

3.4 Mecanismos de prebúsqueda: espacio de diseño ................................................... 80

3.4.1 Que bloque se prebusca? 803.4.2 Cuando se inicia la prebúsqueda: distancia de prebúsqueda 823.4.3 Dónde se deposita el bloque prebuscado 843.4.4 Espacio de diseño 85

3.5 Análisis de coste y prestaciones ............................................................................. 87

3.5.1 Sistema de referencia 873.5.2 Implementación de los mecanismos de prebúsqueda 883.5.3 Carga de trabajo y metodología de traceo 893.5.4 Análisis de prestaciones 903.5.5 Análisis de coste 92

3.6 Conclusiones del capítulo....................................................................................... 93

3.7 Referencias ............................................................................................................. 94

Gestión Multinivel y Prebúsqueda Hardware en Memorias Cache Integradas iii

CAPÍTULO 4 Prebúsqueda Hardware de Datos de Bajo Coste 97

4.1 Introducción ........................................................................................................... 97

4.2 Caracterización....................................................................................................... 98

4.2.1 Metodología y carga de trabajo 984.2.2 Fallos en LSC 994.2.3 Patrones de acceso 994.2.4 Correlación entre frecuencias de ejecución y de fallo 101

4.3 Prebúsqueda mediante análisis de código ............................................................ 103

4.3.1 Patrones en el código 1034.3.2 SPAR 1054.3.3 Análisis de coste de SPAR 1074.3.4 Análisis de prestaciones de SPAR 107

4.4 Prebúsqueda LSC con inserción on-miss............................................................. 111

4.4.1 Inserción on-miss 1114.4.2 Análisis de prestaciones de la inserción on-miss 1124.4.3 Análisis de prestaciones: LSCmi + OBLst 1154.4.4 Resultado en programas con patrones regulares 1174.4.5 Análisis de coste de la inserción on-miss 119

4.5 Ejecución superescalar y fuera de orden.............................................................. 119

4.6 Conclusiones ........................................................................................................ 120

4.7 Referencias........................................................................................................... 121

CAPÍTULO 5 Conclusiones y líneas abiertas 123

5.1 Memorias cache multinivel integradas................................................................. 124

5.2 Prebúsqueda ......................................................................................................... 124

5.3 Aportaciones metodológicas ................................................................................ 125

5.4 Lineas abiertas...................................................................................................... 126

Apéndice A 127

Apéndice B 133

INDICE

iv Gestión Multinivel y Prebúsqueda Hardware en Memorias Cache Integradas

Gestión Multinivel y Prebúsqueda Hardware en Memorias Cache Integradas 1

Introducción

Una condición necesaria para conseguir rendimientos elevados en un computador es elsuministro de datos e instrucciones a la velocidad de consumo del procesador, sin em-bargo, el desnivel de velocidad entre procesadores y sistemas de memoria construidoscon RAM dinámica es grande. Observando la tendencia pasada y presente podemosafirmar que el desnivel seguirá aumentando, a no ser que se produzca algún gran saltoen la tecnología de memorias [BD94,HP96, BGK96].

Una memoria cache (Mc) es una memoria rápida, cara y pequeña, situada entre proce-sador y memoria principal (Mp) y diseñada para servir la mayoría de sus peticiones ala velocidad del procesador. El éxito de la Mc y las claves para su diseño, se basan en lalocalidad temporal y espacial que exhibe en mayor o menor grado la secuencia de acce-sos a memoria de cualquier programa en ejecución. Cuando una referencia no se en-cuentra en Mc (fallo), se carga junto con otras referencias vecinas (bloque) desdememoria principal. El tiempo necesario para resolver el fallo se denomina

latencia de fa-

llo

. El tiempo durante el cual el procesador no puede avanzar se denomina

penalización

de fallo

. Actualmente las latencias de fallo se encuentran en 10-50 ciclos, pero en un futu-ro próximo pueden esperarse latencias de 100-200 ciclos, especialmente en sistemasmultiprocesador [Boo93].

En consecuencia, existen un elevado número de técnicas para minimizar el impacto dela latencia. Algunas de ellas actúan principalmente sobre el sistema de memoria, bienpor el camino de reducir el número de fallos (reestructuración y prebúsqueda), bien porel camino de disminuir la latencia del fallo (memorias cache multinivel). Otro grupo ac-túa principalmente sobre el procesador, intentando que realice trabajo útil mientras seestá sirviendo un fallo en cache (ejecución en desorden, arquitecturas desacopladas,cambios rápidos de contexto).

Introducción

2 Gestión Multinivel y Prebúsqueda Hardware en Memorias Cache Integradas

La reestructuración de datos [AA95] o código [Car93] intentan transformar un progra-ma desde compilación para adaptar su conjunto de trabajo a un nivel determinado dela jerarquía de memoria (registros, cache, TLB, etc). La aplicación con éxito de estas téc-nicas en el nivel cache disminuye la tasa de fallos "por construcción" pero su aplicaciónautomática está limitada a casos particulares.

La prebúsqueda persigue cargar en cache los datos/instrucciones antes de que el proc-esador los pida. De esta forma disminuye el número de fallos en cache y se evita la pér-dida de tiempo que conllevan. Para conseguirlo es preciso adivinar el comportamientofuturo del procesador analizando cada programa, bien sea durante su compilación(prebúsqueda software) o durante su ejecución (prebúsqueda hardware).

Una de las soluciones más obvias al problema de la creciente latencia consiste en inter-poner más de un nivel de Mc entre procesador y Mp, de forma que el desnivel de tiem-pos se cubra progresivamente. Con este método, un fallo en la cache de primer nivel (lamas cercana al procesador) es servido por otra cache en lugar de por la memoria prin-cipal, disminuyendo la latencia media de fallo. El gran atractivo de esta organizaciónjerárquica es que parece escalable, es decir una solución estable a la divergencia cre-ciente de tiempos.

Recientemente se ha propuesto incluir dentro del chip no sólo los niveles de cache sinotambién la memoria principal, en previsión de la capacidad de integración que se al-canzará en la próxima década. Superado el problema tecnológico de la integración con-junta de lógica, SRAM y DRAM, aparecerá pues un nuevo grado de libertad en larelación entre procesador y memoria principal, debido al fuerte acoplo que supone lacoexistencia en el mismo chip. Las propuestas IRAM [PAC+97] y PIM [BKG97] apun-tan en esta dirección.

El resto de técnicas intentan ocultar la latencia en lugar de eliminarla, permitiendo queel procesador realice trabajo útil mientras se resuelve el fallo. La primera consiste en nobloquear al procesador cuando falla la cache, retardando la detención hasta que la ins-trucción que utiliza la variable entre en la etapa de ejecución, o hasta más tarde, cuandoel procesador quede completamente bloqueado por una cadena de dependencias o porfalta de recursos. La latencia se solapa así con la ejecución de las instrucciones siguien-tes. Para que el método sea efectivo la memoria cache debe ser también no bloqueante,es decir, aceptar peticiones mientras está en progreso la resolución de uno o más fallosanteriores. En la actualidad los procesadores que lanzan instrucciones fuera de ordenmediante cualquier método de renombre se diseñan junto con caches no bloqueantes alefecto de tolerar los primeros ciclos de la latencia de fallo del primer nivel decache[FJC95, FCJ+97]

La segunda solución son las llamadas

Arquitecturas desacopladas.

Consiste en dividir elprocesador en dos grandes bloques funcionales casi independientes y separados porcolas. Uno de ellos se encarga de intercambiar datos entre la memoria y los registrosdel procesador, el otro está formado por el resto de unidades funcionales. Esta organi-zación es eficiente cuando el flujo de datos depende poco de las operaciones que se rea-lizan sobre ellos, situación típica de aplicaciones numéricas. En estos casos, el bloque

Memorias cache multinivel


encargado de transferir datos con memoria puede adelantarse al de cálculo guardandolos datos en las colas. En caso de fallo, el tiempo de latencia se solapa con trabajo útil enlas unidades de cálculo, que consumen los datos acumulados en las colas [KHC94,EV96].

Las dos técnicas anteriores esconden la latencia de fallo utilizando este tiempo para eje-cutar otras instrucciones del propio proceso, son soluciones complejas debido a que sedeben respetar las dependencias del flujo de datos y control del proceso. La tercera yúltima técnica busca trabajo útil en un proceso distinto del que ha provocado el fallo,con lo que se asegura que las instrucciones a ejecutar son independientes de la que pro-vocó el fallo. Consiste en realizar un

Cambio rápido de contexto

cada vez que se produceun fallo. Para que sea efectivo se requiere un cambio de contexto con coste temporalprácticamente nulo, lo que implica disponer de varios contextos hardware (p.e. variosconjuntos de registros) [TEL96, EE97].

En esta tesis se estudian las dos soluciones que actúan principalmente sobre el sistemade memoria para reducir bien el número de fallos, bien su latencia.

0.1 Memorias cache multinivel

En el diseño de una jerarquía de memoria con un solo nivel de cache existe un impor-tante compromiso entre el tamaño y la velocidad de ésta. Ayudándonos de un simplemodelo de prestaciones podemos aclarar en que consiste. Expresamos el tiempo mediode acceso a memoria como:

T

acceso

= T

acierto

+ (P

fallo

* Prob(fallo))

donde

T

acierto

es el tiempo necesario para acceder a cache,

P

fallo

es la penalización de re-emplazo del bloque víctima y de carga del bloque deseado y

Prob(fallo)

es la probabili-dad de que un acceso a cache sea fallo. Al aumentar el tamaño o la complejidad de lamemoria cache disminuye

Prob(fallo)

, pero aumenta

T

acierto

.

Durante la última década la velocidad de los procesadores ha crecido entre un 50% yun 100% cada año, mientras la de la RAM dinámica crece en torno al 10% [HJ91,HP96].En consecuencia aumenta constantemente el término

P

fallo

si se mide en ciclos. Por otraparte, la continua evolución de las cargas de trabajo típicas incrementa

Prob(fallo)

simantenemos un tamaño de cache constante. Estas tendencias obligan a un aumentodel tamaño de cache, incompatible con el mantenimiento del tiempo de acierto.

Desde mediados de los 80, este desnivel de velocidad procesador/RAM dinámica estápromoviendo un diseño en dos niveles, con tiempos de acierto iguales al tiempo de ci-clo del procesador en un primer nivel integrado y tasas de aciertos muy elevadas en elsegundo. Con esta organización, la mayoría de los fallos del primer nivel son servidosdesde el segundo y no desde memoria principal, con una penalización (

P

fallo

) muchomenor. Hoy en día es frecuente encontrar un primer nivel dividido (p.e. Alpha 21064

Introducción


[DEC92]) o unificado (p.e. Power PC 601[BAM+93]) dentro del chip y un segundo nivelunificado de elevada capacidad fuera del chip.

Si la escala de integración hace posible dedicar suficiente espacio a la memoria cache,puede ser interesante usar dentro del chip una organización en dos niveles, el primeropartido en datos e instrucciones y el segundo unificado[JW94]. Ya existe un procesadorcon estas características, el Alpha 21164, que incorpora un primer nivel de caches sepa-radas de 8KB + 8KB, y el segundo unificado de 96KB.

Baer y Wang han sido los pioneros en la definición de las propiedades que debe presen-tar una jerarquía multinivel para exhibir simultáneamente buenas prestaciones y con-trol sencillo de la coherencia de las variables compartidas [BW88]. La mayoría de lostrabajos relacionados con este tema suponen el segundo nivel fuera del chip, por lo queno aprovechan las posibilidades ni consideran las limitaciones impuestas por la inte-gración.

En el capítulo 2 asumimos que el nivel de integración y/o el tiempo de ciclo aconsejanel uso de dos niveles de cache en el chip. Se asume también un procesador tipo RISCcapaz de trabajar tanto en un entorno monoprocesador como en uno multiprocesadorde memoria compartida. Debido a las restricciones de espacio impuestas por la integra-ción conjunta de los dos niveles, mostramos que la relación entre sus contenidos puedetener una importante influencia en las prestaciones del sistema. Nuestro propósito esdeterminar esa influencia en un espacio de diseño suficientemente amplio y represen-tativo, proponiendo técnicas de gestión de contenidos que faciliten el mantenimientode la coherencia y a la vez ofrezcan un buen rendimiento.

0.2 Prebúsqueda

Generalmente, la decisión de cargar un bloque en cache se toma en el momento que elprocesador lo necesita , es decir, los bloques se copian en la cache bajo demanda delprocesador.

El tiempo perdido durante la resolución de un fallo se puede evitar cargando los blo-ques en cache antes de que el procesador los pida. Esta técnica se conoce comoprebúsqueda. Para realizarla es necesario conocer qué bloques pedirá el procesadorcon la suficiente antelación.

El procesador genera dos flujos de peticiones a memoria: instrucciones y datos. El flujode instrucciones es muy previsible y varios procesadores ya incorporan prebúsquedapara él. Por el contrario el flujo de datos suele ser mucho mas complejo. Se puedenmezclar en él flujos de acceso a varias estructuras de datos, que además pueden o noseguir patrones regulares e identificables.

La prebúsqueda software se basa en el estudio del comportamiento del programa du-rante el proceso de compilación [Mow94]. Cada vez que el compilador detecta la inme-

Prebúsqueda


diata necesidad de un bloque, inserta en el código del programa una instrucción queprovocará la carga anticipada de ese bloque. La mayoría de las arquitecturas de len-guaje máquina actuales ya incorporan una instrucción de este tipo, y cada vez son máslos compiladores que la usan. Sin embargo, la prebúsqueda software presenta dos in-convenientes [CB94, WL97]:

• El compilador no siempre es capaz de adivinar el comportamiento futuro de unprograma analizando el código estáticamente.

• Las instrucciones que inserta el compilador aumentan el tamaño del código y ocu-pan recursos en el procesador al ser ejecutadas.

La prebúsqueda hardware estudia el comportamiento del programa durante su ejecu-ción, casi siempre analizando la secuencia de direcciones que genera. Si se detectan pa-trones regulares en esta secuencia, que permiten prever accesos futuros, se lanzan laspeticiones de los bloques correspondientes sin intervención del procesador. Tanto elanálisis como el lanzamiento de las prebúsquedas requieren hardware específico, a ve-ces de complejidad y coste significativos.

Probablemente los dos ataques al problema sean complementarios y no excluyentes, ylas condiciones exactas en las que una técnica supera claramente a la otra todavía nohan sido establecidas. En el capítulo 3 efectuamos una revisión en profundidad de losmecanismos hardware de prebúsqueda de datos, con el objeto de establecer dimensio-nes básicas de diseño. De esta identificación se presentan muchas posibilidades no ex-perimentadas, que nacen del cruce de todas las dimensiones. A continuaciónrealizamos una comparación -no realizada hasta el momento- entre varios mecanismosde prebúsqueda hardware de datos, aplicables a entornos monoprocesador con memo-rias cache integradas. Hasta el momento, solo el más sencillo ha sido alguna vez incor-porado a un procesador comercial: la prebúsqueda secuencial. Del estudio realizado eneste capítulo se desprende que la razón puede ser la pobre relación coste/rendimientoque los demás mecanismos ofrecen frente al secuencial.

En el capítulo 4 realizamos una caracterización de comportamiento de los flujos de da-tos en un conjunto muy amplio de programas de muestra, que pone de relieve qué frac-ción de los accesos siguen patrones conocidos y qué importancia tiene capturar uno uotro comportamiento. Inspirados por estos datos de caracterización, presentamos dospropuestas de prebúsqueda hardware de bajo coste. La primera es un mecanismo nue-vo y la segunda una mejora de otro ya existente. Las dos ofrecen una relación coste/rendimiento mucho mejor que los mecanismos propuestos en la actualidad, y puedencontribuir a una incorporación más rápida de la prebúsqueda hardware en los micro-procesadores de propósito general.

Antes, en el capítulo 1 presentamos las técnicas que hemos desarrollado para efectuarmuestreo y selección de carga de trabajo para la simulación ciclo a ciclo de procesa-dores y jerarquías de memoria. Estas técnicas permiten reducir drásticamente el tiempode simulación sin restar credibilidad a los resultados obtenidos y han sido usadas, enmayor o menor grado, en todos los experimentos presentados en esta tesis.

Introducción


0.3 Referencias

[AA95] J. M. Anderson, S. P. Amarasinghe, M. Lam. "Data and Computation Transformations for Multi-processors". Fith ACM Sigplan Symp. on Principles and Practice of Parallel Programming(PPoPP’95), July 1995.

[BAM+93] M.C. Becker, M.S. Allen, C.M. Moore, and D.P. Tuttle. “The PowerPC 601 Microprocessor”. IEEEMicro, October 1993, pp.54-68.

[BD94] K. Bolland and A. Dollas. “Predicting and Precluding Problems with Memory Latency“. IEEEMicro, vol. 14, no. 4, Aug. 1994, pp.59-67.

[BGK96] D. Burger, J.R. Goodman and A. Kägi. “Memory Bandwidth Limitations of Future Microproces-sors“. In Proc. of 23th Int. Symp. on Computer Architecture, pp.78-89, May 1996.

[BKG97] D. Burger, S. Kaxiras and J.R. Goodman. "DataScalar Architectures". In Proc. of the 24th

Int. Symp. on Computer Architecture, 1997.

[Boo93] R.F. Boothe. “Evaluation of Multithreading and Caching in Large Shared Memory Parallel Com-puters”. PhD thesis, University of California, July 1993.

[BW88] J. L. Baer and W. H. Wang. " On the Inclusion Properties for Muti-Level Cache Hierar-chies".

In Proc. of 15th Int. Symp. on Computer Architecture, pp. 73-80, 1988.

[Car93] S. Carr. Memory-Hierarchy Management . PhD Thesis, Rice University, Feb. 1993.

[CB94] T.F. Chen and J.-L. Baer, “A Performance study of Software and hardware Data PrefetchingSchemes”, Proc. 21st Int. Symp. Computer Architecture, IEEE CS Press, Los Alamitos, Calif.,1994, pp. 223-232.

[DEC92] DEC Chip 21064-AA RISC Microprocessor, Preliminary Data Sheet. Digital Equipment Corpora-tion, 1992.

[EE97] S. Eggers et al. "Simultaneous Multithreading: A Platform for Next Generation Processors". IEEEMicro Journal, October 1997.

[EV96] R. Espasa and M. Valero. "Decoupled Vector Architectures". In HPCA-2, pp. 281-290. IEEE Com-puter Society Press, Feb. 1996.

[FCJ+97]

K.I. Farkas, P. Chow, N.P. Jouppi and Z. Vranesic. "Memory-System Design Considerations forDynamically-Scheduled Processors". In Proc. of 24th Int. Symp. on Computer Architecture, pp.133-143, 1997.

[FJC95] K. Farkas, N. Jouppi and P. Chow, “How useful are non-blocking loads, stream buffers and spec-ulative execution in multiple issue processors”, Proc. first IEEE Symp. High-Performance Com-puter Architecture, IEEE CS Press, Los Alamitos, Calif., 1995, pp. 78-89.

[HJ91] J.L. Hennessy and N.P. Jouppi. "Computer technology and architecture: An evolving interaction.IEEE Computer, vol. 24, 1991.

[HP96] J. L. Hennessy and D. A. Patterson. Computer Architecture: A Quantitative Approach, 2nd Ed.,Morgan Kaufmann, 1996.

[JW94] N.P. Jouppi and S.J.E. Wilton. "Tradeoffs in Two-Level On-Chip Caching". In Proc. of 21th Int.Symp. on Computer Architecture, pp. 34-45, 1994.

[KHC94] L.Kurian, P.T. Hulina and L.D. Coraor. "Memory Latency Effects in Decoupled Architectures".IEEE Transactions on Computers, 43(10): pp. 1129-1139, Oct. 1994.

[Mow94] T. C. Mowry. Tolerating Latency Through Software-Controlled Data Prefetching. PhD Thesis,Stanford University, 1994.

[PAC+97] D. Paterson, T. Anderson, N. Cardwell, R. Fromm, K. Keaton, C. Kozyrakis, R. Thomas, and K.Yelick. "A Case for Intelligent RAM". IEEE MICRO, pp. 34-44, March-April 1997.

Referencias


[TEL96] D. M. Tullsen, S. J. Eggers, and H. M. Levy. "Simultaneous multithreading: Maximizing on-chipparallelism". In Proc. of 23rd Int. Symp. on Computer Architecture, pp. 191-202, May 1996.

[WL97] S. VanderWiel and D.J. Lilja. “When Caches Aren´t Enough: data prefetching techniques”. IEEEComputer, Vol. 30, No. 7, july 1997, pp. 23-30.

Introducción



C A P Í T U L O 1

Metodología: Técnicas de muestreo y selección de traza

A lo largo de esta tesis se llevan a cabo varios estudios basados en la estimación deprestaciones de diversas alternativas de diseño. Esta estimación se realiza siempre me-diante simulación detallada de los sistemas en estudio, simulación guiada por traza.

Los recursos consumidos por este tipo de simulación son enormes, principalmente entiempo de procesador. Por ello, durante todo el desarrollo de la tesis, y en paralelo conel trabajo central, se ha prestado especial atención al desarrollo de técnicas para la dis-minución de este coste.

Partiendo de las propuestas existentes sobre muestreo temporal aplicado a simulaciónde fallos, en este capítulo se presentan dos aportaciones dirigidas a extender su uso a si-mulaciones de ciclo y mejorar el proceso de selección de la muestra. El objetivo final esconseguir un método que permita obtener resultados fiables, simulando detalladamen-te una pequeña porción representativa de cada programa de prueba.

1.1 Introducción

El estudio de sistemas de memoria que incluyen caches se ha basado tradicionalmenteen el análisis de las tasas de fallos obtenidas mediante simulación guiada por traza. Lasecuencia de direcciones (

traza

) obtenida al ejecutar un programa de prueba (

benchmark

)se usa como entrada de un programa que simula el comportamiento de la jerarquía dememoria (

simulador

). Los algoritmos de pila son ampliamente utilizados para un estu-dio exhaustivo del espacio de diseño, ya que en una única simulación calculan tasas defallos para muchos tamaños o configuraciones de cache [MGS+70].

En procesadores con poca actividad paralela se puede calcular una buena aproxima-ción al número medio de ciclos por instrucción (CPI) a partir de la tasa de fallos. Sinembargo, conforme se incrementa el paralelismo en el procesador y en la jerarquía de



memoria, aumenta la inexactitud de cualquier modelo analítico para el cálculo de CPI.Aunque se puedan reunir distribuciones estadísticas más precisas para corregir par-cialmente estos resultados, si se desea calcular un CPI realista es necesario considerar afondo los detalles del sistema propuesto mediante una simulación ciclo a ciclo.

Los inconvenientes de la simulación en detalle son el (muy) elevado tiempo de compu-tador necesario para cada experimento y la necesidad de repetirlo para cada dimensio-nado de cache que se desee analizar. Como ejemplo, simular ciclo a ciclo un solo puntodel espacio de diseño en nuestro entorno es entre 3 y 4 veces más costoso que una si-mulación de fallos. Además, con muy poco coste temporal añadido la simulación de fa-llos obtienen resultados para varios puntos de diseño, mientras en el simulador ciclo aciclo esta solución no es aplicable.

Los programas de prueba utilizados para generar la traza conforman la llamada

cargade trabajo

. Esta carga ha de ser similar a las que soportará el sistema que se está diseñan-do, de forma que la respuesta del sistema ante la carga seleccionada se pueda suponersimilar a la que se obtendrá ante la carga real [Smi85]. En el estudio de jerarquías dememoria, como en el de otras partes del sistema computador, se han usado varios tiposde programas de prueba: aplicaciones reales, núcleos de cálculo, cargas sintéticas, etc.Los más utilizados son las aplicaciones reales, son los más representativos por ser unsubconjunto de los programas que realmente ejecutará el sistema.

Un ejemplo de aplicaciones reales usadas como carga de trabajo son los SPEC (89, 92,95). En la versión usada en este momento consta de 18 programas (8 de enteros y 10 depunto flotante). Compilados para una arquitectura SPARC con un nivel deoptimización O3, y ejecutando con los ficheros de entrada de referencia proporciona-dos por la organización SPEC, suponen una carga global de

1 ,2

Tera instrucciones.Una simulación ciclo a ciclo de esta carga de trabajo en una máquina del año 1995 cues-ta unos 250 días (a unas 54000 inst/sg).

Como consecuencia de este enorme coste de simulación todos los estudios que usancargas de trabajo reales realizan algún tipo de reducción drástica del número de ins-trucciones a simular. El tamaño típico de una carga de trabajo es de unos pocos milesde millones de instrucciones, que tomada de SPEC95 supondría una porción menor del1% de todo el conjunto de programas. Al realizar una reducción tan importante existeel riesgo de una pérdida considerable de representatividad. Si no se escoge con cuida-do, la carga de trabajo seleccionada puede comportarse de forma muy diferente a comolo haría la carga original.

Son muchos los métodos usados para conseguir esta reducción, repasaremos algunosen el apartado 1.2. Sin embargo, son raros los que dedican el esfuerzo necesario al pro-blema de la representatividad. Existen algunas propuestas de técnicas de muestreoaplicadas a simulación de jerarquías de memoria para obtener tasas de fallos [Puz85,LPI88, LP93, KHW94], pero no han sido trasladadas al entorno de la simulación ciclo aciclo de procesadores y jerarquías.

Estado actual


En este capítulo se presentan dos mejoras a las técnicas de muestreo temporal existen-tes que permiten su aplicación a simuladores ciclo a ciclo. En el apartado 1.2 se descri-ben los métodos más frecuentemente usados para reducir el tamaño de la carga detrabajo, y se plantea la posibilidad de aplicar muestreo. En el apartado 1.3 se estudia unnuevo método para la reducción del error de medición debido al arranque en frío decada observación. En el apartado 1.4 se propone una técnica original para la selecciónde la muestra, que permite reducir el tiempo de simulación y aumentar a la vez la rep-resentatividad. Se termina en el apartado 1.5 con la valoración global de las técnicas in-troducidas.

1.2 Estado actual

En la selección de una carga de trabajo los objetivos a cumplir son los siguientes:

1.

conseguir una carga de

tamaño

razonable, en función de la potencia de simulaciónde que se dispone y del número de experimentos a realizar. El alto coste de simu-lación impone un número máximo de instrucciones en cada experimento, deforma que el tiempo global de simulación tenga un límite razonable.

2.

conseguir una carga

representativa

. La carga de trabajo escogida para la simulacióndebe ser representativa del mayor número posible de distintos comportamientosque se dan en los programas reales. Además, estos comportamientos deben darseen la carga seleccionada en la misma proporción que se dan en una carga real.

Repasando los artículos publicados en el último ISCA (97) que usan simulación ciclo aciclo del procesador para estimar prestaciones, encontramos los métodos de selecciónde traza que a continuación describimos. Todos ellos están orientados a conseguir untamaño razonable, pero descuidan la representatividad de su carga de trabajo:

• Selección de un

número reducido de benchmarks

. Se llegan a hacer experimentos conuno o dos programas. La selección de estos programas es un punto crítico en estosestudios. Los conjuntos de programas de prueba son en si una selección que intentarepresentar al conjunto de todas las aplicaciones. Seleccionar uno de ellos que searepresentativo del conjunto es una tarea muy dificil.

• Uso de

programas de prueba obsoletos

. La evolución de los programas de prueba estan rápida como la de los sistemas informáticos. Los programas que suponen unacarga típica de un determinado momento, para las máquinas de ese momento, de-jan de serlo en muy pocos años. Como ejemplo, la organización SPEC publica unconjunto de

benchmarks

cada 3 años (89, 92, 95, ... 98?). El número de programas, sucomplejidad, el número de instrucciones que ejecutan, el tamaño de las estructurasde datos que usan, y otros muchos parámetros varían enormemente entre una yotra versión. El número de instrucciones medio entre las versiones de SPEC92 y deSPEC95 varía en un orden de magnitud (por encima del incremento de presta-ciones de la estaciones de trabajo en 3 años).



•

Reducción del tamaño del problema

resuelto por cada

benchmark

. Junto a cada progra-ma de prueba se distribuyen ficheros de entrada. El uso de estos ficheros asegura laposibilidad de repetir los experimentos desde grupos de investigación independi-entes. En algunos trabajos se usan otros ficheros (a veces suministrados tambiénjunto al

benchmark

bajo el nombre de

test

o

train

) que provocan una ejecución máscorta. El inconveniente de este tipo de ejecuciones es que a veces siguen patronesmuy distintos de los originales, debido a que usan estructuras de datos muy redu-cidas.

• Ejecución de un

reducido número

de instrucciones consecutivas al

principio

de cada

benchmark

. Típicamente se trabaja con unas decenas de millones de instrucciones decada programa. Muchos programas emplean estas primeras instrucciones en lainicialización de sus estructuras de datos. Su comportamiento es distinto al del res-to de la aplicación y por tanto no se puede considerar representativo.

• Ejecución de un

reducido número

de instrucciones consecutivas de cada

benchmark

,tras

eliminar una posible etapa transitoria

. Se elimina un número fijo de instruccionesen el inicio de cada programa, típicamente unos cientos de millones. Se supone queestas instrucciones son las encargadas de ejecutar la inicialización. Tras ellas setoma una única muestra de unas decenas de millones de instrucciones como fuentede la simulación. Siendo un método mucho más eficaz para capturar el compor-tamiento típico de cada aplicación, sigue teniendo dos inconvenientes: i) Por de-spreciar un número fijo de instrucciones en el inicio, no se asegura haber saltadotoda la etapa transitoria. ii) Por tomar una única muestra de instrucciones consecu-tivas no se asegura la captura del comportamiento general del programa.

De los 30 artículos publicados en el ISCA97, 11 usan simulación ciclo a ciclo para el cál-culo de prestaciones de un sistema monoprocesador. En la Tabla 1.1 se presentan losmétodos usados por cada uno de ellos para la selección/reducción de la carga de traba-jo. La cabecera de cada columna indica la página de inicio del artículo en los "

Procee-dings of the 24th Annual ISCA

".

La columna encabezada con 252 corresponde a un estudio sobre prebúsqueda usandocadenas de Markov [JG97]. Usa 8 programas de prueba, la mayoría no pertenecientes acargas de trabajo de uso común. Dice escogerlas entre programas comerciales de habi-

Tabla 1.1

Métodos de reducción de traza usados en artículos del 24th ISCA.

1 13 121 133 181 194 206 252 274 284 315

Pocos programas

X

Programas obsoletos

X X X X X

Entrada reducida

X X X X X ? X X

N instrucciones al inicio

X X X X

N instr. tras un salto

X X

Estado actual


tuales en la industria. No explica si se han simulado por completo o se ha usado unaentrada reducida. Sin embargo, el número de instrucciones ejecutadas varía entre 31millones y 77 millones por programa.

De los 10 estudios restantes 6 seleccionan un grupo de instrucciones consecutivas dediversos tamaños, bien al principio o tras saltar un cierto transitorio. Sólo uno de ellosparece analizar previamente el tamaño del transitorio para saltarlo con seguridad (el121). La mayoría, además, usan entradas reducidas y/o programas obsoletos.

1.2.1 Técnicas de muestreo

Existen técnicas de muestreo para obtener tasas de fallos en jerarquías sencillas de me-moria. Estas técnicas son ortogonales con los métodos de selección de carga comenta-dos en el apartado anterior, y para una carga dada pretenden examinar muestrasrepresentativas de la misma que conduzcan a medidas precisas de la tasa de fallos. Lasdos propuestas básicas son

set sampling

[Puz85, LP93] y

time sampling

[LPI88, KHW94].En

set sampling

la muestra está formada por todas las referencias a unos pocos conjun-tos de cache; una de las formas de seleccionar conjuntos es al azar.

Time sampling

selec-ciona una muestra con las referencias lanzadas por varias ráfagas de instruccionesconsecutivas.

Creemos que estas técnicas aplicadas a la simulación ciclo a ciclo aumentan la repre-sentatividad de la carga de trabajo, y por tanto la fiabilidad de las conclusiones.

En una simulación ciclo a ciclo las influencias entre instrucciones consecutivas en cuan-to a dependencias de datos, ocupación de recursos, etc. son determinantes. Al formaruna muestra con los accesos a memoria cuyo destino son unos pocos conjuntos decache se pierde la secuencia temporal, y con ella las relaciones entre instrucciones con-secutivas. Por ello,

set sampling

no es aplicable en simulación ciclo a ciclo.

En

time sampling

se seleccionan varias ráfagas de instrucciones consecutivas para for-mar la muestra. Llamaremos intervalo a cada ráfaga y hueco al conjunto de instrucciones(no simuladas) que quedan entre dos intervalos. Los intervalos se seleccionan unifor-memente a lo largo de toda la vida del programa. Las instrucciones pertenecientes a unintervalo aparecen en el mismo orden en que son ejecutadas, por lo que se pueden si-mular con exactitud todas sus interdependencias. El conjunto de intervalos es la mues-tra de simulación.

La implementación de time sampling presenta diversos problemas según el entorno desimulación. Analizaremos dos aspectos que influyen de forma decisiva en dichaimplementación: la fuente de la traza y el grado de multiprogramación del sistema si-mulado.

1.2.2 Fuente de la traza

La secuencia de direcciones generada por la ejecución del programa de prueba es la en-trada del programa simulador. En ocasiones no basta con la secuencia de direcciones, y



la traza incluye otras informaciones como la propia instrucción ejecutada. Este es elcaso si se desea simular el comportamiento del procesador y no sólo el del sistema dememoria.

La extracción de la secuencia de direcciones puede realizarse mediante diversos méto-dos que atacan distintos niveles del sistema [UM97]: 1) hardware externo espiando elbus de direcciones, 2) añadidos al microprograma para almacenar cada dirección quese genera, 3) emulación de una arquitectura ejecutando el programa de prueba, 4) con-taminación del ejecutable del programa de prueba para que genere la traza y 5) ejecu-ción paso a paso del programa de prueba extrayendo las direcciones. Cada uno de losmétodos enumerados tiene sus ventajas e inconvenientes y su discusión está fuera delalcance de esta tesis.

El generador de traza puede conectarse directamente al simulador o a un almacén parasu posterior uso en múltiples pruebas. La elección de una u otra alternativa depende dedos factores: i) el tiempo de generación de la traza vs. el tiempo de lectura y ii) el espa-cio necesario para almacenarla. Además existe un compromiso entre estos dos factoresya que se puede reducir el espacio de almacén (mediante técnicas de compresión) au-mentando el tiempo de lectura (con el tiempo requerido para descomprimir).

Existe un tercer factor que obliga a generar la traza en directo, y es la necesidad de si-mular procesadores con especulación de algún tipo (en saltos, en accesos a memoria),ya que la secuencia de direcciones puede variar tanto con cambios en el procesadorcomo en la propia jerarquía de memoria. Si este es el caso, el único medio válido para laextracción de la secuencia de direcciones es la emulación (interpretación) del programade prueba.

En simuladores alimentados con traza almacenada, aplicar time sampling consiste encrear una traza muestreada de menor dimensión. Se consigue por tanto un factor de re-ducción igual al de la muestra, tanto en tiempo de ejecución como en espacio de alma-cenamiento. Sin embargo, cuando la traza se produce al mismo tiempo que se consumepor el simulador, la implementación de time sampling no es tan sencilla ni eficiente. Paragenerar la traza de las instrucciones pertenecientes a los intervalos es necesario ejecutartambién todas las instrucciones de los huecos. La implementación de time sampling esmás compleja porque se deben implementar dos modos de trabajo. También es menoseficiente, el factor de reducción del tiempo de simulación no será igual al de la muestradebido a que la porción de traza descartada en los huecos no tiene coste cero.

El método de extracción de traza usado en esta tesis es el de emulación. Se usa la herra-mienta SHADE [CK94], creada por SUN para emular las distintas versiones de la ar-quitectura SPARC. El tiempo de generación de traza mediante esta herramienta es delos menores de su categoría, y mucho más bajo (hasta un factor 10) que el requeridopara leer la traza de un dispositivo de almacenamiento [CK94, UM97]. Por tanto, la tra-za se vuelve a generar en cada simulación.

En SHADE se puede programar dinámicamente la información que se desea extraer decada instrucción ejecutada. Esto permite simular la ejecución de los huecos con la míni-

Warm Time Sampling


ma sobrecarga posible. Aún así, y dado el gran tamaño de los programas, es muchomayor el tiempo invertido en la simulación de los huecos que el de los intervalos. En elapartado 1.4 se presenta una solución a este problema.

1.2.3 Grado de multiprogramación del sistema simulado

Supongamos que cada uno de los programas de prueba se ejecuta en un sistema dedi-cado exclusivamente a él, sin interferencia de otros procesos ni tan siquiera del sistemaoperativo. En estas condiciones todas las instrucciones del programa se ejecutarían deforma continua, sin interrupciones. El estado del sistema al iniciar la ejecución de unainstrucción sería siempre el producido por las instrucciones anteriores.

Al añadir time sampling a un sistema como el descrito aparece un grave problema: eldesconocimiento del estado del sistema al principio de cada intervalo. En la simulaciónde una jerarquía de memoria se desconoce el contenido de cada memoria cache al prin-cipio de cada intervalo, por lo que el simulador comete un cierto error al estimar la tasade fallos o el tiempo de ejecución de dicho intervalo. Se han propuesto varias solucio-nes a este problema de arranque en frío [KHW94, UM97]. En el apartado 1.3 se presen-ta una nueva solución aplicable a simuladores ciclo a ciclo.

Podemos suponer por el contrario que en el sistema se están ejecutando varios proce-sos, y que todos ellos y el sistema operativo compiten por los recursos. Cada procesotoma el control del procesador durante un cierto quantum de tiempo, pasado el cual lodeja en manos de otro. Tras un cierto tiempo necesario para atender en turno a todoslos procesos presentes, el procesador vuelve a ejecutar instrucciones del mismo proce-so. En este momento, el estado del sistema ha cambiado respecto al instante en que esteproceso dejo de ejecutarse. Desde el punto de vista de la jerarquía de memoria, si el nú-mero de procesos y/o el quantum son suficientemente grandes, los contenidos de lascaches puede ser totalmente inútiles para el proceso.

En un sistema de este tipo es mucho más sencillo implementar time sampling. Si se hacecoincidir el tamaño del intervalo con el tamaño en instrucciones del quantum, el estadode la jerarquía en el inicio de cada intervalo es conocido: caches vacías. En un sistemacon poco grado de multiprogramación y/o grandes caches, pueden existir restos delconjunto de trabajo al reanudarse la actividad del proceso; suponer en este caso la je-rarquía vacía es una aproximación pesimista al rendimiento del sistema.

1.3 Warm Time Sampling

La técnica presentada en este apartado sirve para reducir el coste de una simulación ci-clo a ciclo en un sistema no multiprogramado, y puede considerarse una extensión delas técnicas de time sampling.



Consiste en tomar medidas del rendimiento del procesador (CPI en nuestro caso) envarios intervalos de instrucciones consecutivas. Todas estas medidas (observaciones)forman una muestra. Con esta muestra se estima el CPI de la traza completa. La princi-pal aportación de este método consiste en mantener actualizadas las caches entre dosintervalos consecutivos. El estado de las caches al inicio de cada intervalo es el correcto,y por tanto desaparece el error por arranque en frío; de ahí el nombre del método:muestreo temporal en caliente, Warm Time Sampling o WTS [JIV96].

Para mantener el estado de las caches es necesaria una simulación a nivel de fallos detodas las instrucciones de cada hueco. Esta simulación es de mucho menor coste que laque trabaja a nivel de ciclo, permitiendo un ahorro considerable en tiempo. El resulta-do es una simulación ciclo a ciclo con un coste temporal similar al de la simulación defallos.

1.3.1 Implementación de WTS

El objetivo de WTS es acelerar la ejecución de un simulador ciclo a ciclo, al que llamare-mos simulador de referencia. Usualmente, la implementación de WTS partirá de estesimulador. En la parte experimental que presentaremos, el simulador de referencia mo-dela una jerarquía de memoria como la del capítulo 2 [IV96]. Consta de un procesadorSPARC segmentado en 5 etapas que lanza en orden una instrucción por ciclo con termi-nación de punto flotante fuera de orden, dos niveles de cache en el chip procesador, untercer nivel externo y una memoria principal. A diferencia del simulador usado en elcapítulo 2 se guía por eventos y está escrito en C++ con técnicas orientadas a objeto[Jim96].

Las instrucciones pertenecientes a un intervalo deben ser simuladas a nivel de ciclopara obtener los valores de CPI que servirán para estimar el CPI de la traza completa.Esta simulación la lleva a cabo el simulador de referencia, que a partir de ahora llama-remos modo tiempos de nuestro simulador WTS.

Figura 1.1 Los dos modos de simulación en WTS.

En una simulación con time sampling convencional las instrucciones de los huecos sonignoradas, lo que provoca problemas de arranque en frío al principio del siguiente in-tervalo. En WTS han de ser simuladas a nivel de fallos, para mantener el estado de las

intervalos:

huecos:

simulación en "modo tiempos"

simulación en "modo fallos"

Muestra: conjunto de intervalos

Traza del programa

Warm Time Sampling


caches. Esto requiere un nuevo modo de simulación, mucho más simple que el modotiempos, que llamaremos modo fallos. En este modo queda desconectado todo el meca-nismo de eventos, no se simula el procesador ni la memoria principal. En cada cachedel sistema se añade una simple función encargada de detectar acierto/fallo y modifi-car el estado consecuentemente. Para cada referencia de la traza se realiza una llamadaa la función de la cache de primer nivel correspondiente, que se propaga al segundo ni-vel sólo en caso de fallo. Este modelo de simulación puede provocar desorden en la eje-cución de ciertos eventos respecto al simulador de referencia, lo que puede llevar apequeñas diferencias en el estado final de las caches.

El tiempo de simulación resultante es mayor que el de una simulación convencionalcon time sampling, debido a que es necesario procesar las instrucciones de los huecos.Sin embargo, la precisión del nuevo simulador será mucho mayor, y su tiempo de si-mulación será en todo caso mucho menor al de una simulación completa en modo tiem-pos.

Los cambios del modo tiempos al modo fallos y viceversa no pueden ser directos, han depasar por modos transitorios que aseguren la corrección en las estructuras de datoscompartidas. Al final de un hueco, el modo fallos asegura unos contenidos en las cachesmuy parecidos a los reales. Sin embargo, el simulador de eventos ha estado parado y lacola de eventos está vacía. Este estado equivale al de un sistema vacío, sin carga previa,que no se corresponde con la realidad. Es necesario un modo de simulación transitorioque inserte instrucciones en el simulador de eventos hasta crear un estado de carga tí-pico. Llamaremos a éste modo arranque. Por otro lado, al final de un intervalo se debedetener el simulador de eventos para dar paso al modo fallos. En este momento puedenquedar eventos pendientes en la cola que afecten al estado de las caches. Es necesarioun nuevo modo que sin insertar nuevas instrucciones en el simulador permita la com-pleta descarga de la cola de eventos. Es el modo parada.

Figura 1.2 Modos transitorios (arranque y parada) y modos básicos (tiempos y fallos). Las medidas de prestaciones sólo se hacen en el modo tiempos.

1.3.2 Posibles fuentes de error

Nuestra estimación del CPI de la traza completa no es exactamente el CPI verdadero (elde una simulación completa en modo tiempos). Hay que tener en cuenta tres posiblesfuentes de desviación: 1) el error estadístico debido al muestreo, 2) errores por desor-den de referencias y 3) imprecisión en la medida del CPI de cada intervalo. Los siguien-tes subapartados se dedican a analizar y corregir estos errores.

modoparada

modotiempos

modofallos

modoarranque



ERROR ESTADÍSTICO

Para estimar el CPI de la traza hemos recogido los CPIs medidos en cada intervalo.Cada medida es una observación, y el conjunto de observaciones disponibles constitu-ye nuestra muestra del CPI. Podemos usar la media muestral como estimador no ses-gado de la media poblacional, esto es, del verdadero CPI de la traza.

Sin embargo, si el número de observaciones es demasiado pequeño la media muestralpuede alejarse apreciablemente de la media poblacional. Por ello tenemos en cuenta losintervalos de confianza al 90% y 99% para la media poblacional que se calculan a partirde la media y varianza muestrales. Estos intervalos se calculan desde dos supuestos:distribución gaussiana y muestreo aleatorio. Aunque nuestro muestreo no es aleatoriosino sistemático, esta suposición lleva a una estimación conservadora y permite cálcu-los mucho más sencillos [KHW94].

ERROR POR DESORDEN DE REFERENCIAS

Teóricamente, la simulación WTS evita los errores de arranque en frío manteniendo loscontenidos de las caches actualizados en todo instante. Sin embargo, en el apartado1.3.1 se menciona la posibilidad de cierto desorden al procesar las peticiones a memo-ria en modo fallos. Por ello, los contenidos de las caches al comienzo de cada intervalono serán exactamente los mismos que si la simulación completa no se hubiera deteni-do. Las diferencias son pequeñas, y hemos observado que el error que introducen esmenor que el producido por una mala elección de los parámetros de la simulación (co-mo la longitud del intervalo o la fracción de traza considerada).

Una fuente muy importante de desorden son los buffers de escritura retardada entre ni-veles. Si nos limitamos a suprimir los buffers, la serialización introducida por la simula-ción en modo fallos hará que las escrituras adelanten a las lecturas. Esto puede llevar aimportantes imprecisiones. Por ello, al programar el modo fallos las escrituras retarda-das deben ser forzadas a esperar hasta que la actividad asociada al fallo ha concluido;de algún modo, se sigue simulando un buffer de una posición.

ERROR EN LA MEDIDA DEL CPI DE CADA INTERVALO

En el subapartado 1.3.1 hemos descrito cómo conmutar entre modos de simulaciónpara obtener una estimación correcta del CPI de cada intervalo. Antes de comenzar acontabilizar un intervalo es necesario esperar hasta que el sistema ha recibido suficien-te trabajo originado por las instrucciones insertadas durante el modo arranque. Si estenúmero de instrucciones no es suficiente, esto es, si la cantidad de trabajo precargadaes menor que la que se desecha al final del intervalo, se estará cometiendo un error pordefecto cada vez que se calcule el CPI de un intervalo.

El número mínimo de instrucciones del modo arranque depende de 1) la complejidad dela jerarquía de memoria, 2) la complejidad del procesador y 3) el programa que se esté

Warm Time Sampling


traceando. En nuestro contexto, hemos observado que no es suficiente con esperar aque se llene el pipeline del procesador (insertar 5 instrucciones), pues se sigue subesti-mando el CPI. Con 20 instrucciones se obtienen resultados mucho mejores: no se obser-va error y el incremento de tiempo de simulación es inapreciable.

Es importante señalar que los intervalos de confianza sólo nos previenen de la primerade estas tres causas de error, ya que tiene que ver con cómo se estima la media pobla-cional a partir de las observaciones de la muestra. Los otros dos errores nos dan obser-vaciones imprecisas, esto es, nos hacen obtener una medida que no es el verdadero CPIdel intervalo considerado. Por ello tenemos que ser cuidadosos al implementar elmodo-fallos y al fijar el número de instrucciones del modo arranque para minimizar estasdos causas de error.

1.3.3 Resultados

Se presentan a continuación los resultados obtenido mediante simulación WTS encuanto a tiempo de simulación y en cuanto a error que se introduce al medir CPI. Losexperimentos se realizan con dos benchmarks de SPEC92: Gcc y Spice.

La Figura 1.3 muestra el tiempo de simulación de los modos básicos como tanto porciento del tiempo de una simulación completa en modo tiempos. El modo obtener traza re-presenta el tiempo necesario sólo para obtener la traza del programa. Aunque es unas100 veces el tiempo necesario para ejecutar el programa, representa una pequeña frac-ción del tiempo de simulación, típicamente menos del 5%. El modo memoria ideal mues-tra el tiempo empleado para simular el procesador, esto es, el tiempo de simulación deun sistema cuyas caches de primer nivel no fallan nunca.

El dato importante es el tiempo empleado en una simulación en modo fallos. El valorque se obtiene en los dos benchnmarks que presentamos (cercano al 30%) puede consi-derarse como el límite inferior del tiempo de una simulación WTS. Mayores reduccio-nes exigirían acelerar el modo fallos.

Figura 1.3 Comparación del tiempo de simulación de los modos básicos.

0%

20%

40%

60%

80%

100%

obtener

traza

memoria

ideal

modo

fallos

modo

tiempos

Tiempo

gcc

spice



La Figura 1.4 y la Figura 1.5 muestran cuatro series para cada benchmark: correspondena las longitudes de intervalo constantes (il) de 100, 1000, 10000 y 100000 instruccionesrespectivamente. Para cada serie se han realizado siete experimentos, simulando el 1, 5,10, 20, 40, 60 y 80% de la traza en modo tiempos. Las gráficas se completan con el tiempode simulación del modo fallos (0% en modo tiempos) y el tiempo de simulación completaen modo tiempos (0% en modo fallos).

Se observa que el tiempo de simulación varía de forma lineal con la fracción de trazaque se simula en modo tiempos. La diferencia entre las series de il es muy pequeña.

Figura 1.4 Tiempo de simulación WTS (Gcc) en función del porcentaje en modo tiempos.

Figura 1.5 Tiempo de simulación WTS (Spice) en función del porcentaje en modo tiempos.

La Figura 1.6 y la Figura 1.7 muestran el error relativo en el CPI de una simulación WTS.Puede observarse que las series que corresponden a los intervalos más cortos (il=100,1000 instrucciones) presentan errores mucho más pequeños que los más largos. Para un

Tiempo de simulación WTS (Gcc)

0,00%

20,00%

40,00%

60,00%

80,00%

100,00%

0 2 0 4 0 6 0 8 0 100

Porcentaje de la traza en modo tiempos

Tie

mp

o

de

s

imu

lac

ión

i l=100i l=1000

i l=10000

i l=100000

Tiempo de simulación WTS (Spice)

0,00%

20,00%

40,00%

60,00%

80,00%

100,00%

0 2 0 4 0 6 0 8 0 100


Tie

mp

o

de

s

imu

lac

ión

i l=100i l=1000i l=10000

i l=100000

Warm Time Sampling


porcentaje dado de instrucciones en modo tiempos (%mt) cuanto más cortos son los inter-valos más observaciones tomamos. Así, la muestra puede capturar más variación de CPIa lo largo de la traza y es más representativa de la traza completa. Los intervalos cortosdarían peores resultados si se introdujeran errores significativos en las conmutacionesentre modos, ya que cuanto más corto sea el intervalo más veces habrá que conmutar.

De esta forma, si elegimos intervalos suficientemente cortos (menos de 1000 instrucciones)obtenemos el CPI de Gcc con un error de 0.21% siempre que simulemos al menos el 5% dela traza en modo tiempos. Los resultados para Spice son aún mejores: para estas longitudesde intervalo, y simulando el 5% de la traza, los errores son menores del 0.05%. Nótese queincluso simulando sólo el 1% de la traza los errores se mantienen por debajo del 1%. Sinembargo, no es muy interesante hacerlo, ya que los errores, aunque aceptables, son muchomayores que los de %mt=5%, y el tiempo de simulación no es mucho menor.

Figura 1.6 Error de CPI en una simulación WTS (Gcc) en función del porcentaje en modo tiempos para cuatro longitudes de intervalo.

Figura 1.7 Error de CPI en una simulación WTS (Spice) en función del porcentaje en modo tiempos para cuatro longitudes de intervalo.

Resultados de WTS (Gcc)

0,00%

0,50%

1,00%

1,50%

2,00%

2,50%

3,00%

0 2 0 4 0 6 0 8 0 100


Err

or

en

C

PI

i l=100i l=1000

i l=10000

i l=100000

Resultados de WTS (Spice)

0,00%1,00%

2,00%3,00%4,00%

5,00%6,00%

7,00%8,00%

0 2 0 4 0 6 0 8 0 100


Err

or

en

C

PI

i l=100i l=1000

i l=10000

i l=100000



Por fin, la Figura 1.8 y la Figura 1.9 muestran los límites superior e inferior de los inter-valos de confianza para el CPI estimado a los niveles de confianza 90% y 99%. En el in-terior de los intervalos queda la línea del CPI realmente medido.

Figura 1.8 Intervalos de confianza para CPI al 90% y 99%, y valores medidos (Gcc)

Figura 1.9 Intervalos de confianza para CPI al 90% y 99%, y valores medidos (Spice)

Puede verse cómo los intervalos de confianza representan una estimación conservado-ra del error de nuestras medidas usando WTS. Podría deberse a nuestras suposicionesde muestreo sistemático y distribución gaussiana.

Otro hecho destacable es que la línea que representa el CPI medido unas veces sube yotras baja respecto a la horizontal del CPI verdadero. Es alentador, ya que significa queno se introducen errores sistemáticos apreciables en las conmutaciones entre modos.De ser así, esta línea tendería a ir de forma sistemática hacia abajo (o hacia arriba) delverdadero CPI.

Intervalos de confianza (Gcc, il=100)

1 ,95

1 ,96

1 ,97

1 ,98

1 ,99

2

2 ,01

0 2 0 4 0 6 0 8 0 100


CP

I

99%

90%

medido

90%99%

Intervalos de confianza (Spice, il=100)

1,7451 ,75

1 ,7551 ,76

1 ,7651 ,77

1 ,7751 ,78

1 ,7851 ,79

0 2 0 4 0 6 0 8 0 100


CP

I

99%

90%

medido

90%99%

Selección de la muestra


En resumen, simulando en modo tiempos sólo el 5% de la traza, se consigue una reduc-ción del tiempo de simulación por un factor 3 con un error relativo en la estimación delCPI típicamente menor del 0.25%. Como observación final, creemos que la gananciapuede ser superior si se consideran configuraciones procesador/memoria con técnicasagresivas para el incremento del ILP, debido al mayor ahorro en tiempo de simulaciónde una gran cantidad de actividades paralelas.

1.3.4 Trabajos relacionados

En un entorno más general de simulación de procesadores con paralelismo a nivel deinstrucción la extensión de las técnicas de muestreo no se ha realizado apenas. T.M.Conte es una excepción, pero sus trabajos no han tenido gran difusión. En un trabajoque coincide en el tiempo con el presentado en esta tesis [CHM96] propone dos técni-cas para reducir el error cometido al aplicar muestreo temporal. La primera trata de re-ducir el error cometido en la medición de cada intervalo (que llama cluster) debido a lapérdida de información que produce el muestreo (arranque en frío). Es un método si-milar a WTS aplicado a las estructuras que almacenan información dentro del procesa-dor, como la tabla de saltos. La segunda intenta reducir el error estadístico, debido a laselección misma de la muestra. Estrictamente no propone una técnica específica paraseleccionar la muestra, que siempre realiza de forma uniforme sobre el total de la po-blación, sino para controlar el error cometido en la selección mediante el análisis de ladesviación estandar de la muestra.

1.4 Selección de la muestra

Como vimos en el apartado 1.2.2, al aplicar time sampling a un simulador que consumela traza al mismo tiempo que se genera aparece un problema que afecta al coste tempo-ral de la simulación: para conseguir la traza de los intervalos es necesario ejecutar todoel programa de prueba.

Esto es así porque la traza se extrae durante la ejecución (real o emulada) del programade prueba. Por lo tanto, para poder extraer la traza de todos los intervalos hay que eje-cutar sus instrucciones. Los intervalos se distribuyen de forma uniforme a lo largo detoda la vida del programa de prueba, por lo que ejecutar sus instrucciones implica eje-cutar todo el programa.

La herramienta usada en esta tesis para la extracción de traza es SHADE [CK94], unemulador de la arquitectura SPARC. Permite programar dinámicamente la informaciónque se desea extraer de cada instrucción ejecutada. Esto permite simular la ejecución delos huecos con la mínima sobrecarga posible: SHADE sólo emula la ejecución del pro-grama, no extrae ninguna información. Llamaremos a esta forma de trabajo simulaciónen vacío.



Aún con este modo de trabajo, cuando los programas de prueba ejecutan muchas ins-trucciones, el tiempo necesario para simular las instrucciones de los huecos es impor-tante. Como ejemplo, la velocidad de ejecución en vacío en nuestra máquina dereferencia1 es de 1,709 Minst/sg; ejecutar las 21.294 Minst de spice en vacío (saltar loshuecos) cuesta unas 3 horas y media. Posiblemente este tiempo se mantiene constante oaumenta al considerar años venideros, ya que los programas de prueba que se seleccio-nan en cada época exigen a los computadores del momento lo mismo o más que losprogramas de prueba anteriores exigían a los computadores antiguos.

El método que se presenta en este apartado consiste en limitar el tiempo sobre el que seaplica muestreo. En lugar de distribuir las observaciones con uniformidad a lo largo detoda la vida del programa de prueba, las distribuiremos sobre una parte de esa vida.Para asegurar la representatividad de la parte seleccionada realizaremos una caracteri-zación previa de cada programa de prueba.

1.4.1 Caracterización previa

Típicamente un programa estará compuesto por una etapa inicial de mayor o menorduración dedicada a la inicialización de estructuras de datos, seguida de un bucle prin-cipal que se ejecutará un número determinado de veces, y una etapa final de recogida/escritura de resultados. Este esquema puede dar origen a comportamientos cíclicos enla etapa más larga del programa (la del bucle), que pueden resultar interesantes desdeel punto de vista del muestreo.

El objetivo de la caracterización previa es conocer el comportamiento de un programaen función del tiempo. Es decir, conocer la evolución temporal del comportamiento deun programa, sus etapas transitorias, sus ciclos. Para estudiar este comportamiento ob-servaremos la evolución de algunas métricas derivadas de su ejecución, como las tasasde fallos en instrucciones y datos. Estas tasas son fáciles de conseguir (se requiere unasimple simulación a nivel de fallos), y afectan directamente a la parte del sistema quemás nos interesa, la jerarquía de memoria.

Para estudiar la evolución temporal de las tasas de fallos discretizaremos la ejecuciónde un programa, la dividiremos en quanta de un millón de instrucciones. En cada unode estos quanta partiremos de caches vacías y calcularemos las tasa de fallos como elnúmero de fallos producidos por los accesos lanzados en el quantum dividido por elnúmero de accesos.

En la Figura 1.10 se muestran las series correspondientes a las tasas de fallos en datosde algunos programas de nuestra carga de trabajo en punto flotante: spice, wave5,fpppp y go. Sólo se representa para los 7000 primeros millones de instrucciones, ya queel comportamiento en el resto de la serie no varía. Las gráficas del resto de programasde SPEC95 se presentan en el Apéndice 1.

1. SUN SPARCstation-20



En las dos primeras series de la Figura 1.10 se observan los comportamientos descritosen párrafos anteriores. Los dos pasan por una etapa transitoria, que varía entre unos700 millones para wave5 y unos 4000 para spice. Los dos se comportan de forma regu-lar tras su etapa transitoria. Aunque no se observa con claridad en la Figura 1.10, lasdos series son periódicas tras su etapa transitoria, con periodos de 18 y 1000 Minst. res-pectivamente.

Como vemos, la etapa transitoria puede ser de un tamaño considerable, y con un com-portamiento totalmente distinto al del resto del programa. Tomar unos pocos cientosde millones de instrucciones al comienzo del programa, o incluso tras haber saltado al-gunos cientos de millones, es una mala política de selección en muchos casos. Por otraparte, el comportamiento periódico sugiere nuevas formas de selección de carga de tra-bajo que aprovechen esta característica.

En la tercera serie, la de fpppp, se observa un comportamiento no periódico. Mantieneuna amplitud constante, sin transitorio, pero la frecuencia de la señal es alta y no cons-tante.

Por último, la serie correspondiente a go muestra un comportamiento totalmente irre-gular, con variaciones tanto en frecuencia como en amplitud.



Figura 1.10 Evolución de la tasa de fallos de datos durante los 7000 primeros millones de instrucciones, para spice (SPEC92), wave5, fpppp y go (SPEC95). Se simula una cache de 8KB con mapeo directo y bloques de 16 bytes.

0 1000 2000 3000 4000 5000 6000 70000

0,1

0,2

0,3

0,4

0,5

0 1000 2000 3000 4000 5000 6000 70000

0,1

0,2

0,3

0,4

0,5

0,6

0,7

0 1000 2000 3000 4000 5000 6000 70000

0,1

0,2

0 1000 2000 3000 4000 5000 6000 70000

0,1

0,2

Spice

Wave5

Fpppp

Go



La Tabla 1.2 recoge algunos datos espectrales que caracterizan los programas deSPEC95. Se añade spice de SPEC92 por ser muy utilizado en estudios previos y porcontar con un número de instrucciones similar al de los SPEC95. De los 16 programasanalizados, 9 cuentan con una etapa transitoria que varía entre 82 y 6280 Minst.

Durante su etapa resolutiva (no transitoria) 11 presentan un comportamiento claramen-te periódico, con periodos que van de 18 a 5280 Minst. Otros 2 programas (fpppp yperl) presentan un comportamiento regular. Es decir, la tasa de fallos varía con ampli-tud constante pero con frecuencia muy alta y variable. Sólo 3 programas presentancomportamiento irregular: apsi y m88ksim pasan por varias fases de ejecución de tama-ños comparables y con comportamientos muy distintos. En go la amplitud varía a lolargo de toda la ejecución, con una frecuencia alta y también variable (en el Apéndice 1se muestra este comportamiento para todos los programas).

Tabla 1.2 Comportamiento temporal de nuestros benchmarks . Número de instrucciones, comportamiento y tamaños de periodo y etapa transitoria si procede (en millones).

Minst. Comportamiento Periodo Transitorio

spice 21.294 periódico 18 3.935

applu 63.221 periódico 215 82

apsi 45.555 irregular, 3 etapas

fpppp 291.203 regular 0

hydro 58.599 periódico 141 420

mgrid 91.586 periódico 91 0

su2cor 50.458 periódico 5.280 6.280

swim 40.569 periódico 44 138

tomcatv 50.730 periódico 61 4.420

turb3d 259.940 periódico 2.126 0

wave5 42.750 periódico 1.000 728

go 30.714 irregular, 1 etapa 0

ijpeg 40.597 periódico 650 0

m88ksim 75.884 irregular, 2 etapas

perl 17.518 regular 300

vortex 72.661 periódico 4.820 2.700



1.4.2 Selección de la muestra en base al comportamiento

Tras el análisis de la evolución temporal de cada programa podemos seleccionar unaparte de su vida que sea representativa de la ejecución completa. Para ello, despreciare-mos el transitorio y repartiremos las observaciones sobre un trozo de tamaño múltiplo del perio-do.

En algunos programas la etapa transitoria es de un tamaño importante, no despreciablefrente al tamaño total. En estos casos se puede dar al transitorio la importancia que me-rece, reservándole en la muestra el número de observaciones que proporcionalmente lecorrespondan. Sin embargo, para simplificar el análisis, en el estudio que presentamosen este capítulo hemos optado por despreciarlo completamente.

Dado un tamaño de muestra, que vendrá determinado por la potencia de cálculo dis-ponible y por el número de experimentos a realizar, podemos encontrar dos situacio-nes distintas:

1. El tamaño del periodo es menor que el tamaño de la muestra. Tomaremos unaúnica observación, de tamaño igual al múltiplo del periodo más cercano al tamañode la muestra. Por ejemplo, supongamos que el tamaño de muestra que deseamoses de 200 Minst. Dado que tomcatv tiene un periodo de 61 Minst., formaríamosuna muestra con 183 Minst. consecutivas a partir del transitorio (183=61*3).

2. El tamaño del periodo es mayor que el tamaño de la muestra. Repartiremos las ob-servaciones de la muestracon uniformidad a lo largo de todo un periodo. Si los dos tamaños son muy parecidos se hace difícil el reparto uniforme. En estecaso se hace coincidir el tamaño de la muestra con un divisor del periodo. Porejemplo, supongamos que el tamaño de muestra que deseamos es de 50 Minst.Dado que tomcatv tiene un periodo de 61 Minst., formaríamos una muestra con 30Minst. (30=61/2). La muestra se formaría con 30 observaciones de 1 Minst. con unhueco entre dos observaciones consecutivas de 1Minst.

Aplicaremos este método sólo a los programas con comportamiento periódico. En elresto se puede optar por cualquiera de los métodos convencionales, tomando una solaobservación contigua para minimizar tiempo, o repartiendo varias observaciones a lolargo de toda la ejecución del programa para minimizar error. En todo caso, en los pro-gramas en los que no existe comportamiento periódico pero si regular, se podría usaruna solución de compromiso que repartiese las observaciones a lo largo de un trozocuya dimensión se debería ajustar experimentalmente.

1.4.3 Validación y rendimiento de la selección basada en comportamiento

Para estudiar las propiedades de nuestro método de selección de traza lo comparare-mos con algunos de los enumerados en el apartado 1.2:

1. Tomar muestras de una sola observación del tamaño predeterminado, saltando unpequeño transitorio, menor que el real, que variaremos entre 0 y 1000 Minst. Lollamaremos contiguo inicial.



2. Tomar muestras de una sola observación del tamaño predeterminado, una vezeliminado el transitorio completo. Lo llamaremos contiguo tras transitorio.

3. Tomar muestras repartiendo las observaciones de forma uniforme, a lo lago detoda la vida del programa de prueba, una vez eliminado el transitorio. Lo llamare-mos muestreo convencional.

De cada uno de ellos analizaremos en que grado cumple los dos objetivos planteadosen el apartado 1.2: mínimo tiempo de simulación y máxima representatividad de la muestraconseguida.

1.4.4 Representatividad de la muestra

Para medir la representatividad de los diferentes métodos de selección de muestra usa-remos el error cometido en la estimación del CPI. Para estudiarlo nos ayudamos de losintervalos de confianza al 90%. Para cada método de selección tomamos 100 muestrasdiferentes. Calculamos la media del CPI en cada una de ellas. Entre todas las mediascalculadas desechamos el 5% de los valores más altos y el 5% de los más bajos. El máxi-mo y el mínimo de los valores que quedan son los límites del intervalo de confianzapara ese método de selección. La amplitud del intervalo de confianza nos da una ideadel error típico que estamos cometiendo al estimar CPI con este método y con este ta-maño de muestra. Con el 90% de probabilidad, una muestra tomada con este métodocomete un error menor a la amplitud del intervalo. A menor error más representativaes la muestra del comportamiento global.

En la Figura 1.11 se muestran los intervalos de confianza al 90% y el error máximo al es-timar CPI, para cada uno de los 4 métodos aplicados a tomcatv (periodo de 61 Minst.).Los tamaños experimentados de muestra son de 20, 50, 100, 200, 500 y 1000 Minst.



Figura 1.11 Métodos de selección de muestra: Intervalos de confianza (arriba) y porcentaje de error máximo (abajo) para tomcatv. La métrica estimada es el CPI en un sistema con caches separadas de 8KB en primer nivel y unificada de 64 KB en segundo.

El valor real de CPI se encuentra dentro de los intervalos de confianza para todos losmétodos de selección salvo para el primero (contiguo inicial). En presencia de etapatransitoria de tamaño significativo, las muestras tomadas del inicio de la ejecución deun programa no son representativas del comportamiento general. En tomcatv esto serefleja en porcentajes de error cercanos al 50% para cualquier tamaño de muestra.

2

3

4

5

2 0 5 0 100 200 500 1000

Tamaño de la muestra (Minst.)

CP

I

Contiguo inicialContiguo tras transitorioMuestreo convencionalMuestreo comportamiento

CPI real = 3,84

0 , 1

1

1 0

100

2 0 5 0 100 200 500 1000


%

Err

or Contiguo inicial

Contiguo tras transitorio

Muestreo convencional

Muestreo comportamiento



El segundo método (contiguo tras transitorio) toma muestras de una sola observacióndel tamaño predeterminado, una vez saltado el transitorio. Si el tamaño de la muestraes menor que el periodo (Figura 1.12 muestra a) en cada muestra sólo se recoge unafracción del comportamiento del programa. Si el tamaño de la muestra es mayor que elperiodo, y no es un múltiplo exacto (Figura 1.12 muestra b), en cada muestra hay unaparte del periodo con más representación que otras.

Figura 1.12 Selección de muestra contigua: relación con el periodo.

Como vemos en la figura Figura 1.11 este comportamiento lleva a errores relativamentealtos, que llegan hasta el 16% para muestras de 20 Minst. Este error pierde importanciacuando el tamaño de la muestra es mucho mayor que el periodo.

El tercer método (muestreo convencional) consigue errores mucho menores para cual-quier tamaño de muestra (menores del 2%), y es especialmente bueno para muestrasgrandes. Como veremos en el apartado siguiente su principal inconveniente es el tiem-po de simulación, ya que requiere la ejecución completa del programa de prueba. Otroproblema que presenta es la irregularidad de sus resultados. Como muestra la Figura1.11 la serie que representa el error cometido por este método de muestreo no siemprees decreciente. En ocasiones, al aumentar el tamaño de muestra aumenta el error, y estees un comportamiento no deseado. Esta irregularidad puede deberse a la distancia en-tre observaciones. Si esta distancia es un múltiplo o un divisor alto del periodo sólo seestá considerando una pequeña porción del comportamiento.

El muestreo guiado por comportamiento comete un error similar al muestreo conven-cional, aunque parece especialmente bueno para tamaños pequeños de muestra.Parainterpretar correctamente la gráfica hay que considerar que, en algunos casos, el tama-ño de muestra con muestreo guiado por comportamiento es menor del deseado. Los ta-maños reales de la muestra buscan múltiplos o divisores del periodo y en el caso detomcatv son los que muestra la Tabla 1.3.

Tabla 1.3 Tamaños de muestra usados por el muestreo basado en comportamiento para tomcatv

Tamaño de muestra teórico 20 50 100 200 500 1000

Tamaño de muestra real 20 30 61 183 488 976

periodo

a

b



El muestreo guiado por comportamiento es además muy regular. La serie que repre-senta su error en la figura Figura 1.11 es siempre decreciente.

En la figura Figura 1.13 se muestran los mismos datos para vortex. Este programa pre-senta un transitorio menor (de 2700 Minst.) y un periodo mucho mayor (de 4820Minst). El tamaño del periodo parece un parámetro importante al aplicar nuestro méto-do de muestreo y por ello incluimos este experimento.

Figura 1.13 Métodos de selección de muestra: Intervalos de confianza (arriba) y porcentaje de error máximo (abajo) para vortex.

El porcentaje de error es muy alto para el muestreo contiguo sin transitorio incluso congrandes tamaños de muestra. Esto es debido al mayor tamaño del periodo.

1 , 3

1 , 4

1 , 5

1 , 6

1 , 7

2 0 5 0 100 200 500 1000


CP

I

Contiguo inicialContiguo tras transitorioMuestreo convencionalMuestreo comportamiento

0 , 1

1

1 0

100

2 0 5 0 100 200 500 1000


%

Err

or Contiguo inicial


Muestreo convencional

Muestreo comportamiento

CPI real = 1,406



Entre los dos métodos con muestreo, se mantienen las mismas relaciones. El convencio-nal parece conseguir mejor resultado para grandes tamaños de muestra, y el guiadopor comportamiento para tamaños pequeños. En todo caso, las diferencias entre ellosson mucho menores que con el resto.

Concluimos el análisis de representatividad diciendo que:

• En gran parte de los programas de prueba, las muestras tomadas del inicio de suejecución no son representativas del comportamiento general.

• La presencia de periodos influye de forma determinante en en la representatividadde las muestras tomadas por cualquier método de selección.

• El muestreo basado en comportamiento consigue errores similares al convencional,y mucho menores a los del resto de métodos.

1.4.5 Tiempo de simulación

Para analizar el tiempo de simulación requerido por cada uno de los métodos de selec-ción partimos de dos medidas de velocidad básicas: la velocidad de simulación en va-cio (en los huecos) y la velocidad de simulación en modo tiempos (en los intervalos). Sisimulásemos bajo el supuesto de un sistema monoprogramado habría que sustituir lavelocidad en vacio por la velocidad en modo fallos.

Las velocidades con que trabajamos son de nuestro simulador y en nuestra máquina.La máquina es una SUN SPARC típica del año 95, al igual que los benchmarks usados.En todo caso, las conclusiones serán válidas siempre que se mantenga la relación entrelas dos velocidades básicas. Usaremos los siguientes valores:

Vintervalo = 53.900 inst/sg, ==> Ci = 18,55 sg/Minst.

Vhueco = 1.709.000 inst/sg, ==> Ch = 0,585 sg/Minst.

donde V son velocidades y C son costes temporales de simulación.

El tiempo de simulación de cada métodose calcula en general como:

T = Ci * Ni + Ch * Nh

donde Ni es el número de instrucciones simuladas en vacio (en millones) y Nh el de lassimuladas en modo tiempos. Para unos tamaños de muestra (Nm), de transitorio (Nt),de periodo (Np) y global de la traza (Nz) tenemos las siguientes expresiones para cadauno de los 4 métodos:

1. Contiguo inicialT1 = Ch * Nt * f + Ci * Nm

siendo f la fracción del transitorio que se simula

2. Contiguo tras transitorioT2 = Ch * Nt + Ci * Nm



3. Muestreo convencionalT3 = Ci * Nm + Ch * (Nz - Nm)

4. Muestreo por comportamientoT4 = Ch * Nt + Ci * Nm + Ch * max(0, Np - Nm)

En la Figura 1.14 se muestran los tiempos de simulación para cada uno de los métodosy en función de los tamaños de la muestra (20, 50, 100, 200, 500 y 1000 Minst.).

Figura 1.14 Métodos de selección de muestra: Tiempo de simulación para tomcatv. En el método contiguo inicial se considera f=0.

El tiempo necesario para la simulación con muestreo convencional es mucho mayorque el del resto debido a la necesidad de simular todo el programa de prueba. La simu-lación en vacio de tomcatv completo cuesta 29677 sg. (unas 8 horas), y este es el tiempoque predomina para muestras de pequeño tamaño. Suponiendo una muestra de 100Minst. el 94% del tiempo se dedica a saltar huecos y sólo el 6% a simular instruccionespara estimar el CPI.

Entre los otros tres métodos las diferencias son mucho menores. Sólo destaca el conti-guo inicial que, para muestras pequeñas, requiere mucho menos tiempo de simulación.Esta ventaja se debe a que no simula el transitorio (simularlo en vacio impone a losotros métodos un tiempo mínimo de 2585 sg., unos 43 minutos), y se pierde progresiva-mente al aumentar el tamaño de muestra, ya que el tiempo necesario para simular envacio el transitorio va perdiendo importancia relativa. En todo caso, este método sepuede considerar descartado tras el análisis del apartado anterior.

El tiempo del muestreo guiado por comportamiento es similar al necesario para simu-lar una única observación de tamaño fijo pasado el transitorio. Suele ser menor debidoa que el tamaño de la muestra en el primero de los métodos se ajusta siempre por deba-jo del tamaño deseado.

0

5000

10000

15000

20000

25000

30000

35000

40000

45000

50000

2 0 5 0 100 200 500 1000


Tie

mp

o

de

s

imu

lac

ión

(s

g.)

Contiguo inicial


muestreo convencional

muestreo comportamiento

Conclusiones


En la figura Figura 1.15 se muestra el tiempo de simulación para vortex. Cabe destacardos diferencias importantes:

• El transitorio es menor que en tomcatv y se refleja en una menor diferencia entremuestreo contiguo inicial y el resto.

• El periodo es mucho mayor que en tomcatv y se refleja en un aumento del tiempode simulación del muestreo guiado por comportamiento, que debe simular en va-cio todo el periodo. Aún así, las diferencias con los métodos contiguos (con o sintransitorio) no son muy elevadas. Como ejemplo, para una muestra de 100 Minst.los tiempos de simulación serían de 31 minutos para contiguo inicial, 57 minutospara contiguo tras transitorio y 103 minutos para muestreo por comportamiento.

Figura 1.15 Métodos de selección de muestra: Tiempo de simulación para wave5.

Como resumen, el tiempo necesario para la simulación con muestreo convencional esmucho mayor que el del resto debido a la necesidad de simular todo el programa deprueba. La relación de tiempos entre los otros métodos depende del tamaño del transi-torio y del periodo, pero las diferencias son mucho menores en cualquier caso.

1.5 Conclusiones

Partiendo de las propuestas existentes sobre muestreo temporal aplicado a simulaciónde fallos, en este capítulo se presentan dos aportaciones dirigidas a extender su uso asimulaciones de ciclo y mejorar el proceso de selección de la muestra. El objetivo finales conseguir un método que permita obtener resultados fiables, simulando detallada-mente una pequeña porción representativa de cada programa de prueba.

0

10000

20000

30000

40000

50000

60000

70000

2 0 5 0 100 200 500 1000


Tie

mp

o

de

s

imu

lac

ión

(s

g.)

Contiguo inicial


muestreo convencional

muestreo comportamiento



La primera aportación es aplicable a simulaciones ciclo a ciclo de sistemas monoproce-so. En estos sistemas, al implementar muestreo surge el problema del arranque en fríoen el inicio de cada observación. Para eliminarlo se propone mantener actualizado elestado de las caches entre dos observaciones consecutivas mediante una simulación defallos. El resultado es un método que permite obtener los resultados de una simulaciónciclo a ciclo en un tiempo similar al de una simulación de fallos. El error cometido almuestrear se limita al propio error estadístico, ya que el error por arranque en frío seelimina.

La segunda aportación es aplicable a cualquier tipo de simulación en la que se generala traza en el mismo momento que se consume. Es un nuevo método de selección de lamuestra, basado en las carácterísticas propias de la ejecución de un programa: presen-cia de transitorio y comportamiento periódico. Requiere un análisis previo de la evolu-ción temporal del programa de prueba para detectar esas características. Tras esteanálisis se propone distribuir las observaciones que componen la muestra a lo largo deun periodo, por supuesto una vez eliminado el transitorio. Se consiguen muestras tanprecisas como las conseguidas con los métodos convencionales de muestreo, pero concoste temporal mucho menor, similar al de los métodos de reducción de traza sinmuestreo.

1.6 Referencias

[CK94] B. Cmelik and D. Keppel, "Shade: A Fast Instruction-Set Simulator for Execution Profiling", in Proc.1994 SIGMETRICS, vol 22, number 1, pp. 128-137, May 1994

[CHM96] T.M. Conte, M.A. Hirsch and K.N. Menezes. "Reducing State Loss for Effective Trace Samplingof Superscalar Processors", in Proc. 1996 Int. Conf. on Computer Design, Oct 1996.

[IV96] P.E. Ibañez and V. Viñals, "Performance Assessment of Contents Management in Multilevel On-ChipCaches", to appear in Proc. 22nd. Euromicro Conference, Sept. 96

[JG97] D. Josephand D. Grunwald, “Prefetching Using Markov Predictors“, Proc. of 24th Int. Symp.Computer Architecture, pp.252-263, June 1997.

[Jim96] L.M. Jimeno-Ochoa, "Simulación Avanzada de Jeraquías de Memoria", Proyecto Final de Carrera,CPS, Univ. of Zaragoza, Apr. 1996

[JIV96] L. Jimeno, P. Ibáñez and V. Viñals. “Warm Time-sampling: Fast and Accurate Cycle-level Simula-tion of Cache Memory”. In Proc. of the 22nd Euromicro Conf. Short Contrib. pp: 39-44, Sept.1996.

[KHW94] R.E. Kessler, M.D. Hill and D.A. Wood, "A Comparison of Trace-Sampling Techniques for Multi-Megabyte Caches", IEEE Tansactions on Computers, vol. 43, no. 6, pp. 664-675, Jun. 1994

[LP93] L. Liu and J.K. Peir, "Cache Sampling by Sets", IEEE Transactions on VLSI Systems, vol. 1, no. 2,pp. 98-105, Jun. 93

[LPI88] S. Laha, J.H. Patel and R.K. Iyer, "Accurate Low-Cost Methods for Performance Evaluation of CacheMemory Systems", IEEE Transactions on Computers, vol. 37, no. 11, pp. 1325-1336, Nov. 1988

[MGS+70] R.L. Mattson, J. Gecsei, D.R. Slutz, I.L. Traiger. "Evaluation Techniques for Storage Hierarchies", IBMSystems Journal, 9(2):78-117, 1970

[Puz85] T.R. Puzak, "Analysis of Cache Replacement Algorithms", Ph.D. disertation, Univ. Massachusetts,Amherst, Feb. 1985

Referencias


[Smi85] A.J. Smith, "Cache Evaluation and the Impact of Workload Choice", in Proc. of 12th Int. Symp. onComp. Architecture, pp. 64-75, Jun. 1985

[UM97] R.A. Uhlig and T.N. Mudge. "Trace-Driven Memory Simulation: A Survey". ACM ComputingSurveys. Vol. 29, No. 2, pp. 128-170, June 1997.


C A P Í T U L O 2

Gestión de Contenidos en Memorias Cache Multinivel Integradas

En este capítulo comparamos varias alternativas de gestión de los contenidos de dos ni-veles de cache integrados en el chip procesador, con respaldo en un tercer nivel exte-rior. Se repasa el concepto de Inclusión multinivel y supapel en el mantenimiento de lacoherencia. Proponemos dos alternativas de gestión de contenidos: Exclusión y De-manda, desarrollando para las mismas nuevos protocolos coherentes y sus necesidadeshardware. Por último realizamos un análisis cuantitativo de coste y prestaciones decada alternativa. El análisis de prestaciones se realiza en base a tasa de fallos, ciclos porinstrucción y tiempo por instrucción en el entorno específico de integración en el chip.La experimentación se ha realizado mediante un simulador ciclo a ciclo desarrollado alefecto y ejecutando un conjunto de programas de enteros y punto flotante pertenecien-tes a SPEC'92 y SPEC'95. La estimación de coste y de tiempo de ciclo se realiza median-te conocidos modelos analíticos.

2.1 Introducción

Los tiempos de ciclo de memoria principal y procesador continuan divergiendo progre-sivamente, en gran parte debido a la creciente escala de integración y al uso de nuevastécnicas organizativas como la supersegmentación. Los expertos preveen el crecimientode esta divergencia, el uso de múltiples niveles de cache, y la replicación de procesa-dores dentro de un mismo chip [GGP+89]. Si la creciente escala de integración hace po-sible dedicar suficiente espacio a la memoria cache, parece interesante usar dentro delchip una organización en dos niveles, el primero partido en datos e instrucciones y elsegundo unificado. Esta organización presenta las siguientes ventajas frente a la clásicade un solo nivel partido:

1. Generalmente tiene una mejor tasa de aciertos, debido a la reasignación dinámicade espacio en el segundo nivel entre datos e instrucciones [RVL+89].



2. Cada nivel puede dedicarse a conseguir distintos objetivos y puede ser diseñadode forma específica. Por ejemplo el tamaño y asociatividad del primer nivel puedelimitarse, consiguiendo tiempos de acceso menores, y permitiendo el acceso condirecciones virtuales (la traducción se puede realizar en paralelo). Todo esto ayudaa disminuir el tiempo de ciclo y/o la latencia de las instrucciones de acceso a me-moria. Por otro lado, para conseguir altas tasas de aciertos, el segundo nivel puedediseñarse con alta asociatividad e incluso usar alguna forma de prefetch hardware.

3. El segundo nivel puede espiar el bus de sistema o responder a los comandos de co-herencia enviados por un tercer nivel de cache externa. Esto permite una reduc-ción de la complejidad y del tiempo de ciclo del primer nivel. Por otra parte, ydependiendo de la implementación, una cache de un solo nivel puede tener unamayor latencia respondiendo a comandos de coherencia debido a su alta utiliza-ción por el procesador.

En este trabajo asumimos que el nivel de integración o el tiempo de ciclo aconsejan eluso de dos niveles de cache en el chip [JW94, WO97, BGK96]. Se asume también unprocesador tipo RISC capaz de trabajar tanto en un entorno monoprocesador como enuno multiprocesador de memoria compartida. El procesador Alpha 21164 de DECcuenta con una jerarquía dentro del chip de estas características, con caches de 96KB ensegundo nivel y 8KB+8KB en primero [ERP95].

Debido a las restricciones de espacio impuestas por la integración conjunta de los dosniveles, creemos que la relación entre sus contenidos puede tener una importante in-fluencia en las prestaciones del sistema. Nuestro propósito es determinar esa influenciaen un espacio de diseño suficientemente amplio y representativo.

Hasta el momento se han definido tres relaciones entre los contenidos de dos nivelesconsecutivos de memoria cache, Li (más próximo a la memoria principal) y Li-1 (máspróximo al procesador):

1. El nivel i (Li) es un superconjunto del nivel i-1 (Li-1).

2. El único criterio que determina los contenidos de Li es el orden temporal de las de-mandas de Li-1, como consecuencia un bloque muy reutilizado por Li-1 puede serexpulsado de Li independientemente del tamaño y configuración de Li.

3. Los contenidos de Li y Li-1 son disjuntos.

Llamaremos a estas tres estrategias Inclusión, Demanda y Exclusión. La estrategia de In-clusión fue sugerida por Baer y Wang con el nombre de "multilevel inclusion property".Estos autores presentan las ventajas de la inclusión para resolver el problema de la co-herencia y establecen las condiciones necesarias y suficientes para su implementaciónen mono y multiprocesadores [BW87, BW88]. Asimismo realizan una evaluación deprestaciones usando modelos estocásticos y analíticos, asumiendo que la relación deinclusión penaliza la tasa global de fallos. La estrategia de Demanda ha sido utilizadaen una serie de estudios cuantitativos encaminados a optimizar los parámetros de sis-temas con dos niveles de cache [SL88, WBL89, Prz90, BKB90, EE93, SAN93]. En todosellos se considera L2 externa al chip y por tanto con parámetros muy alejados de nues-

Funcionamiento básico de la Inclusión, Exclusión y Demanda


tro entorno. Por otra parte no se estudian los mecanismos y costes del mantenimientode la coherencia. La estrategia de Exclusión fué sugerida por Jouppi y Wilton para con-seguir una mejor utilización del espacio del chip [JW94]. El mismo concepto fue inde-pendientemente propuesto en [Viñ93].

El objetivo de este trabajo es la comparación de las tres estrategias de gestión de conte-nidos en un entorno monoprocesador de propósito general -procesado simbólico y nu-mérico- con dos niveles integrados de cache. El sistema deberá mantener la coherenciacon un tercer nivel de cache externa (que asegura accesos por DMA correctos o permitela incorporación a un entorno multiprocesador). Para ello ampliaremos la definición delas estrategias de Demanda y Exclusión con los mecanismos necesarios para el mante-nimiento de la coherencia. Definiremos un espacio de diseño (tamaños, latencias, …)acorde con las restricciones impuestas por la integración, analizando las prestacionesde las tres estrategias en ese espacio de diseño. Este análisis se realizará a través de me-didas independientes de la tecnología obtenidas mediante simulación detallada: tasasde fallos y ciclos por instrucción.

El siguiente apartado describe el entorno hardware que hemos seleccionado para expe-rimentar, efectuando un recordatorio de la estrategia de Inclusión y prestando especialatención a nuestras definiciones básicas de Demanda y Exclusión. El apartado 2.3 pre-senta el problema de la coherencia y nuestras soluciones originales para Demanda yExclusión en este tema. En el apartado 2.4 se describe la metodología usada para lacomparación de las distintas alternativas. En el apartado 2.5 se presentan y analizan losresultados en cuanto a coste y prestaciones. En el 2.6 se analiza la validez del estudio enun entorno superescalar y fuera de orden. Acabamos en el apartado 2.7 con nuestrasconclusiones.

2.2 Funcionamiento básico de la Inclusión, Exclusión y Demanda

En esta sección presentamos los protocolos básicos para gestionar los contenidos de lacache integrada de segundo nivel por Inclusión, Exclusión y Demanda. En todo el tra-bajo supondremos escritura retardada (copy-back) y el mismo tamaño de bloque paratodas las caches del chip (la unidad de coherencia).

Para comparar las tres gestiones de contenidos definimos un Módulo de Referencia enel que todas pueden ser incorporadas (Figura 2.1). Los componentes y su interconexiónson esencialmente los mismos para las tres gestiones, por lo que el coste y las velocida-des permanecen invariables, permitiendo aislar la influencia de la gestión en las presta-ciones.



Figura 2.1 Módulo de Referencia utilizado para comparar alternativas de gestión del contenido de la cache de nivel 2. Sólo se muestran los caminos de datos.

El primer nivel de memoria se compone de una cache de datos y otra de instruccionesde igual tamaño: L1iC y L1dC, de N1 conjuntos, S1 bloques por conjunto (asociativi-dad) y B bytes por bloque. El segundo nivel es unificado: L2uC, con parámetros N2, S2y B. Un tercer nivel exterior al chip y unificado incluye todos los bloques presentes enel chip. L3uC se incluye en el Módulo de Referencia debido a que la mayoría de loscomputadores actuales la incorporan.

Para acelerar las transferencias de información se añaden varios buffers: xbuf2 y

xbuf3 ensamblan los trozos de bloque que llegan a los niveles 2 y 3, permitiendo pos-teriormente su escritura de una sola vez; ubuf, tbuf y sbuf guardan bloques y susdirecciones como resultado de copy-backs o expulsiones. La letra inicial de cada bufferindica el tipo de bloque que contiene: los bloques-x: tienen la palabra accedida por elprocesador (y que puede causar fallo) y los bloques u, t y s son los expulsados respecti-vamente de los niveles 1, 2 y 3. Los tamaños de ubuf, tbuf y sbuf son E1, E2 y E3respectivamente.

ubuf

E1

CHIP

WM3

L1iC

N1, S1,B

L1dC

N1, S1,B

TLB

TLB

instr.fetch.

mem

Bus Interno

L2uC

N2, S2,B

L3uC

N3, S3,B3

xbuf2

xbuf3

Memoria Principal

CPU

Bus de Sistemasbuf

tbuf

ubuf

E3

E2

E1

W32

W21= B

xblock xblock

Funcionamiento básico de la Inclusión, Exclusión y Demanda


Cuando varios módulos acceden a un bus compartido el orden de servicio se decidemediante prioridades estáticas. La anchura de bus entre L1 y L2, W21, es siempre igualal tamaño de bloque aprovechando que las dos caches están dentro del mismo chip (Unejemplo de bus de 128 bits es PowerPC 604 [SDC94]).

Las caches L1 se direccionan virtualmente pero guardan marca (tag) física. Esto ofrecetodas las ventajas del direccionamiento físico sin el coste de la traducción en el caminoentre L1 y procesador, pero impone un tamaño maximo a las caches L1 igual al tamañode página multiplicado por la asociatividad)[WBL89]. Por otra parte, L2 y L3 se direc-cionan físicamente y guardan marca física. Suponemos una correspondencia uno a unoentre direcciones virtuales y físicas ya que nuestro sistema de traceo sólo nos propor-ciona las virtuales.

2.2.1 Gestión de L2 en Inclusión

Como se mencionó en el apartado 2.1, la gestión de L2 en Inclusión es exactamente lapropuesta por Baer y Wang denominada "space inclusion" [BW87]: L2 debe contenersiempre un superconjunto de L1 – no necesariamente actualizado –. Para conseguirloproponen el siguiente protocolo:

a. Si se produce un fallo en L1 y L2, el bloque fallado x se copia en las caches de losdos niveles.

b. En caso de fallo en L1 y acierto en L2 se copia el bloque de L2 a L1.

c. Debido a la política de escritura usada en L1 cuando un bloque que ha sido escritodeba reemplazarse es necesario un copy-back sobre L2.

d. En la cache L1 puede usarse cualquier algoritmo de reemplazo, pero en L2 sólo sepueden reemplazar los bloques no presentes en L1.

El último punto requiere que L2 añada a cada uno de sus bloques un bit de presenciaen L1, este bit se activa al entregar el bloque al nivel inferior y se desactiva cuando esenivel lo reemplaza. Es imprescindible pues que L1 notifique todos sus reemplazos a L2,tanto los de bloques limpios como los de sucios.

Para que la inclusión pueda cumplirse se debe respetar una restricción entre losparámetros de L1 y L2, que en nuestro caso se resume en:

S2 ≥ 2 * S1 * max(1, N1/N2)

Si existen buffers entre L1 y L2 la inclusión también debe actuar sobre los bloques quecontengan dichos buffers, lo que obliga a sumar sus tamaños (suponemos que existe unbuffer en instrucciones y otro en datos) a la asociatividad mínima de L2:

S2 ≥ 2 * ( S1 * max(1, N1/N2) + E1 )

Como ejemplo, podemos calcular la asociatividad mínima necesaria en L2 para incluirdos caches separadas en L1 con mapeo directo (S1=1), igual número de conjuntos en



los dos niveles (N1=N2 ), y dos buffers de tamaño 1 en la salida de las caches de primernivel (E1=1). La asociatividad de L2 debe ser 4.

2.2.2 Gestión de L2 en Exclusión

Exclusión trata de mantener contenidos disjuntos en L1 y L2 de forma que la informa-ción útil contenida entre los dos niveles sea la máxima. Para conseguirlo, un fallo en L1y acierto en L2 se intenta resolver con un intercambio de bloques entre los dos niveles:el bloque fallado x se mueve de L2 a L1, mientras que el expulsado de L1 u se mueve(esté limpio o sucio) al lugar dejado por x en L2. El bit de sucio debe siempre viajar concada bloque; este bit será consultado cuando el bloque se expulse de L2 para saber sihay que modificar la copia de L3. Un fallo en los dos niveles se resuelve con la copiadel bloque x sólo en L1, desplazando el bloque u de L1 a L2 (sea u de instrucciones odatos, sucio o limpio). Por tanto, los bloques contenidos en L2 son siempre bloques víc-timas de L1. El bloque que llega a L2 expulsado de L1 puede provocar una nueva ex-pulsión en L2. Los algoritmos de reemplazo en L1 y L2 no tienen restricciones.

Según Jouppi y Wilton la exclusión estricta sólo se consigue si N1≥N2, en otro caso losconjuntos donde se mapean x y u en L2 pueden ser distintos, haciendo imposible el in-tercambio. En este caso asumen explícitamente que un bloque puede residir en los dosniveles simultáneamente.

En nuestro protocolo de Exclusión, un fallo en L1 y acierto en L2 provoca siempre la co-pia del bloque sobre L1 y su invalidación en L2, manteniendo de esta forma la exclu-sión estricta bajo cualquier configuración. Como veremos en el siguiente apartado, lainvalidación del bloque leído permite mecanismos de coherencia más sencillos y la re-ducción del tiempo de recepción de bloque en L2 desde L1.

Además, puede aumentar la tasa de aciertos del nivel 2 ya que el hueco creado por lainvalidación puede impedir la expulsión de otro bloque útil. Como ejemplo suponga-mos N1=N2, S1=1 y S2=2. La Figura 2.2 muestra los bloques presentes en un conjuntodeterminado en todas las caches on-chip. Si no se usa invalidación, un fallo del bloquex en L1iC que acierta en L2uC puede dejar el contenido de las caches como el de la Fi-gura 2.2.a. Un posterior acceso al bloque de datos c puede causar el reemplazo del blo-que b, como muestra la Figura 2.2.b. Asi, la capacidad efectiva de este conjunto en losdos niveles de cache queda reducida a tres bloques: x, a y c. Sin embargo, con exclusiónestricta, el bloque a se coloca en el hueco dejado por x en L2uC, resultando una capaci-dad efectiva de 4 bloques.

Figura 2.2 Gestión en Exclusión no estricta de L2uC

ax

x c

L2uC

L1iC L1dC

bx

x a

L2uC

L1iC L1dC

( 2.2a ) ( 2.2b )

El problema de la coherencia


2.2.3 Gestión de L2 en Demanda

Nuestra gestión de contenidos por Demanda se basa en una de las organizaciones pro-puestas por Baer y Wang [BW87] para uniprocesadores: "Write-back and no MLI". Elprotocolo que sugieren es idéntico al de Inclusión salvo en el último punto:

d. En Demanda cualquier bloque en L2 es reemplazable, sea o no parte de L1. Por lotanto no es necesario ningún aviso de L1 a L2 en caso de reemplazo de un bloquelimpio de L1, ni tampoco la existencia de bits de presencia en L2.

Esto provoca otro cambio en el punto c. Cuando un bloque sucio en L1 es reemplazadose produce un copy-back hacia el nivel superior como en Inclusión. Sin embargo, eneste caso la escritura en L2 puede ser fallo, requiriendo un nuevo reemplazo en L2.Para esta situación proponemos enviar el bloque directamente a L3 en lugar de escribirloen L2; llamamos a esta política de escritura en L2 block write-around (por su similitudcon la word write-around con copy-back descrita en [Jou93] y previamente usada en[Prz90].

Con el estudio de la gestión por Demanda tenemos en cuenta la forma más sencilla degestionar los contenidos de L2. Es una interesante opción intermedia, ya que a prioripuede comportarse mejor o peor que Inclusión o Exclusión: puede conseguir tasas defallos menores que Inclusión y comportamientos temporales mejores que Exclusión.

2.3 El problema de la coherencia

Se asume que el Bus de Sistema usa un protocolo snoopy que asegura la corrección delas operaciones de E/S por DMA sin la intervención del S.O. Además, si el Módulo deReferencia se usa para construir un sistema multiprocesador de memoria compartida,este protocolo: 1) garantiza el correcto y eficiente tratamiento de variables compartidasy, 2) permite migración de procesos sin que el S.O. tenga que vaciar las caches. En estecontexto, la gestión por inclusión de los tres niveles de cache (L3⊃L2⊃L1) garantiza lacorrección y es eficiente: los comandos de coherencia lanzados al bus son capturados ytratados por el nivel de cache más alejado posible del procesador. Por ejemplo, la difu-sión de palabras (en protocolos de actualización) o la invalidación de bloques (en los deinvalidación) no molestan a los niveles de cache más cercanos al procesador que ya hanreemplazado al bloque correspondiente. Por otra parte, si el protocolo requiere transfe-recias de bloque entre procesadores, Inclusión permite el servicio con la mínima laten-cia posible desde la cache más cercana al Bus de Sistema.

En esta sección mostramos como adaptar los protocolos de gestión de los contenidosde L1 y L2 en Exclusión y Demanda para que sean tan correctos y eficientes como In-clusión. Para el nivel más alto de la jerarquía (L3) la única política posible es algún tipode inclusión de los contenidos de L1 y L2. En nuestro caso (Space MLI), un bit de pre-sente-en-chip se añade a cada bloque de L3uC; se gestiona como se indica en 2.2.1.



Además, L3 debe recibir un aviso de reemplazo cada vez que un bloque sea expulsadodel chip.

2.3.1 Inclusión y coherencia

Una expulsión de bloque en L2 equivale a una expulsión del chip. Esta expulsión debeser notificada, por tanto, a L3. Los comandos dirigidos a bloques presentes en L1 pue-den ser filtrados por L2 ya que todos ellos están marcados como tal en L2.

2.3.2 Exclusión y coherencia

Debido a la exclusión estricta que impone nuestro protocolo, cuando un bloque es ex-pulsado de L2 sabemos que tampoco está en L1 por lo que de nuevo la expulsión de L2equivale a la expulsión del chip. Por tanto, L3 debe ser avisado sólo en cada reemplazode L2. Por otra parte, un comando de coherencia enviado de L3 a L2 puede ser acierto ofallo en L2. En caso de acierto el comando no debe ser enviado a L1 pues la exclusiónasegura que el bloque no existe en ese nivel. En caso de fallo el comando debe ser en-viado a L1 donde será acierto (debido a la exclusión entre L1 y L2 y a la inclusión de L1y L2 en L3).

Si la exclusión no fuese estricta, como admitían Jouppi y Wilton en su protocolo paraN1<N2, el esquema anterior no sería válido, y estaríamos obligados a añadir a L2 unacopia del directorio de L1 para poder cumplir los objetivos que nos hemos marcado,tanto de servicio rápido de copias a otros procesadores como de captura de comandospara no molestar a los niveles cercanos al procesador.

2.3.3 Demanda y coherencia

Con Demanda y asumiendo "block write around", un bloque es expulsado del chip y porconsiguiente hay que avisar de ello a L3 en las siguientes ocasiones:

1. Un bloque que sólo existía en L1 es reemplazado. Pero, si L1 no conoce los conteni-dos de L2 no puede decidir si hay que pasar aviso a L3 o no.

2. Un bloque que sólo existía en L2 es reemplazado. Pero, si L2 no conoce los conteni-dos de L1 no puede decidir si hay que pasar aviso a L3 o no.

Por otro lado, si L2 no conoce los contenidos de L1 no puede filtrar los comandos deL3.

La solución más inmediata es añadir a L2 un directorio replicado de las caches deL1("mapping inclusion"). Una solución mucho más sencilla (reducción de espacio y decomplejidad de control) consiste en añadir un bit de presencia en L1 a cada bloque de L2.Esta es una información parcial puesto que existen bloques en L1 no presentes en L2 ypor tanto sin posibilidad de ser marcados, sin embargo es suficiente para cumplir nues-tros objetivos. Veamos los casos que presentaban problemas:

El problema de la coherencia


1. Una expulsión de bloque de L1 puede ser acierto o fallo en L2. En caso de aciertose modifica el bit de presencia y si el bloque estaba sucio se incorpora a L2. En casode fallo se pasa aviso a L3 (si el bloque estaba sucio el aviso se pasa junto albloque).

2. Cuando un bloque es reemplazado de L2 sólo se avisa a L3 si el bit de presencia enL1 no está activo. Puede ocurrir que el bloque reemplazado esté sucio en L2 y pre-sente en L1, en este caso un nuevo comando es necesario para entregar a L3 unbloque advirtiendo que sigue estando presente en el chip. Si la copia del bloque enL1 no es modificada de nuevo durante su estancia en ese nivel, sólo habrá un avisode reemplazo en el momento de su expulsión, si por el contrario se vuelve a escri-bir sobre ella la primera copia sobre L3 habrá sido inútil.

3. Un comando de coherencia enviado desde L3 a L2 puede ser acierto o fallo. Encaso de acierto sólo se retransmitirá a L1 si el bit de presencia está activo. En casode fallo el comando debe ser pasado a L1 donde será acierto.

2.3.4 Coherencia basada en actualización y gestión de bloques sucios

Si un cierto protocolo de coherencia requiere copias de bloque entre caches de distintosprocesadores, se puede añadir algún mecanismo para minimizar el tiempo de transfe-rencia de bloque.

Debido al uso de copy-back en toda la jerarquía, un nivel puede contener bloques queresiden modificados en niveles inferiores. Para disminuir la latencia de servicio al proc-esador demandante y minimizar la molestia al procesador suministrador es necesarioañadir a cada bloque de L3 un bit de modificado que indica si su contenido está al día (bitno activo) o por el contrario ha sido modificado y la copia buena está en las caches delchip (bit activo). Este bit se activa al recibir del chip un comando de primera escritura yse desactiva al recibir el bloque sucio expulsado desde el chip1. Obviamente L1 no ne-cesita este bit, pues el bit de sucio tiene el mismo significado.

En cuanto a L2, la gestión de contenidos con L1 determina algunos matices sobre laexistencia o manipulación de los bits de sucio y modificado:

• En Inclusión y Demanda, igual que en L3, es necesario añadir a L2 un bit de modi-ficado que se activa y desactiva según las normas anteriores.

• En Exclusión sólo existe una copia de cada bloque, no es necesario pues un bit demodificado. La gestión del bit de sucio como vimos en el apartado 2.2.2 es sufi-ciente para mantener la corrección y la eficiencia.

En resumen, para todas las gestiones de contenidos conseguimos un servicio de copiade bloques modificados, desde el nivel más alejado posible del procesador modificante.

1. Modificado es un estado diferente a sucio para L2 y L3. Un bloque puede estar sucio y modificado (la copia buenaestá en niveles inferiores) o sucio y no modificado (el bloque es incoherente con niveles superiores pero coherentecon los inferiores).



2.4 Metodología de trabajo

El estudio de coste y prestaciones de las tres alternativas de gestión de contenidos pre-sentado en este capítulo parte de un trabajo publicado en 1996 [IV96]. En este trabajo,con una carga de 8 programas de SPEC92, se comparan las prestaciones de inclusióndemanda y exclusión en cuanto a tasa de fallos y CPI. Se usa para ello un simulador ci-clo a ciclo, que modela toda la jerarquía descrita en el apartado 2.2 dando servicio a unprocesador SPARC V7 que lanza en orden una instrucción por ciclo y termina en desor-den las instrucciones de punto flotante. Se varían parámetros como el tamaño de losdos niveles de cache, la penalización del fallo de L2, la asociatividad de L2, el tamañode L3 y el tamaño de bloque. No se considera ni el área ocupada ni la influencia en eltiempo de ciclo de cada diseño; por tanto la comparación entre gestiones de contenidossólo es válida en cada punto aislado del espacio de diseño ya que, para unos tamañosde caches determinados, las tres gestiones de contenidos ocupan la misma área y re-quieren el mismo tiempo de ciclo.

Las conclusiones de este trabajo se resumen en:

– Demanda consigue prestaciones muy parecidas a inclusión, tanto en tasa defallos como en CPI. Dada la complejidad añadida para soportar coherencia sedescarta como alternativa.

– Exclusión siempre consigue tasas de fallo menores que inclusión y demanda.Las diferencias son mayores cuanto más parecidos son los tamaños de L1 y L2.Pese a ello, y debido al incremento de escrituras de bloque desde L1 hacia L2,en ciertos puntos de diseño puede ofrecer peor CPI.

– Aprovechando las características especiales de exclusión se mejoran dos aspec-tos de su temporización. Con estas mejoras la nueva exclusión consigue mejorCPI en todos los puntos de diseño. La mejora media es de un 7,9% para los pro-gramas de punto flotante y de un 4,12% para los de enteros.

En este capítulo se añaden modelos de área y de tiempo de acceso que permiten reali-zar un análisis global de coste y prestaciones (en tiempo por instrucción, TPI). En fun-ción del area disponible se estudia la configuración que menor TPI consigue,considerando la influencia de cada diseño en el tiempo de ciclo. Se comparan diseñoscon un solo nivel de cache y con dos niveles en exclusión e inclusión.

En cuanto a la metodología, se amplia la carga de trabajo considerando también variosprogramas de SPEC95 y se usan algunas de las técnicas de muestreo presentadas en elcapítulo 2. En concreto, se elimina la parte transitoria de cada programa mediante elanálisis previo de su evolución temporal.

Metodología de trabajo


2.4.1 Modelos de área y tiempo de ciclo

El modelo usado para calcular el tiempo de ciclo de cada cache es el de Wilton y Jouppi[WJ93], basado en el de Wada, Rajan y Przybyllski [WRP92]. Este modelo ofrece una se-rie de ecuaciones que predicen los tiempos de acceso y de ciclo de una cache en funciónde ciertos parámetros de entrada.

Entre los parámetros considerados por el modelo están las dimensiones de la cache (ca-pacidad, asociatividad, tamaño de bloque, ...), otros propios de su organización (núme-ro de submatrices en que se divide la cache para su implementación, número de filas ycolumnas de cada submatriz), y otros del proceso CMOS utilizado en su fabricación (ennuestro estudio suponemos un proceso con 0,5μm en lugar de los 0,8μm usados en[WJ93]).

A partir de estos datos de entrada se calculan los retardos de cada elemento que com-pone una cache, tanto en el camino de acceso a las marcas como en el de contenidos:decodificador de direcciones, wordlines, bitlines, amplificadores diferenciales, compara-dores, drivers de los multiplexores de salida, drivers de salida de datos y drivers de sali-da válida.

Por último, uniendo estos retardos se calculan los tiempos de ciclo y de acceso, consi-derando el retardo máximo entre las rutas de contenidos y de marcas. En todo el estu-dio supondremos que el tiempo de ciclo del procesador se adapta al de la cache deprimer nivel. El tiempo de ciclo de una cache de segundo nivel será siempre unmúltiplo de la de primer nivel, por lo que el tiempo calculado mediante el modelo seredondeará por exceso al primer múltiplo del tiempo de ciclo de primer nivel.

Para la estimación del área ocupada por cada configuración se usa el modelo de Mul-der, Quach y Flynn[MQF91, Fly95]. La unidad en que se expresa el área ocupada porcada configuración es el RBE (Register Bit Equivalent), el espacio ocupado por un celdabásica de almacenamiento de un bit en un registro.

En el modelo se determinan empíricamente los tamaños de los componentes básicos deuna cache. Se calcula que cada celda para almacenar un bit ocupa 0,6 RBE, y con estevalor se calcula el espacio ocupado por contenidos, marcas y bits de estado. Se asignancostes también a comparadores, drivers y amplificadores; el coste global de este hard-ware se aproxima añadiendo una fila y una columna a cada una de las submatrices enque se han dividido las celdas de memoria. La anchura de estas filas y columnas esconstante y de valor equivalente a 6 celdas (3,6 RBE). El coste del hardware de controlse supone fijo, de 130 RBE.

2.4.2 Descripción del simulador

Para el estudio de esta tesis se usa el mismo simulador que en [IV96]. Es un simuladorde eventos discretos guiado por tiempo, que se acopla a Shade [CK94], modela cadaelemento de la jerarquía y extrae, entre otras, medidas de CPI y tasas de fallos en cadanivel.



El simulador incluye un procesador SPARC V7 que lanza en orden una instrucción porciclo. Su unidad de enteros está segmentada en 5 etapas, y dispone de dos unidades depunto flotante: una de suma/multiplicación con latencia de 4 ciclos y totalmente seg-mentada (cuatro etapas) y otra de división/raiz cuadrada con 4 etapas, la segunda deellas multiciclo (4/7 ciclos para la división y 6/10 para la raiz cuadrada, en simple/do-ble precisión respectivamente). La terminación de las instrucciones de punto flotante esfuera de orden.

Para cada nivel de cache i se define un tiempo base o tiempo característico TLi expresa-do en ciclos de procesador. TLi es siempre el Tiempo de acierto en lectura para cada ni-vel i de cache.

TL1 = 1 en todos los experimentos; se supone que el tiempo de ciclo de las caches deprimer nivel impone el ciclo del procesador. El tiempo en segundos a que equivale TL1se calcula mediante el modelo de tiempos descrito en el apartado 2.4.1. TL2 tambiénviene determinado por el modelo temporal por estar integrado en el chip procesador.L3uC y MP se fabrican con su propia tecnología, independiente de la del procesador.Sus tiempos de acceso por tanto también son independientes y no se pueden calcularcon el mismo modelo. Por otra parte, durante la experimentación no se varía su estruc-tura, por lo que sus tiempos son constantes si los medimos en segundos, y se han elegi-do consultando tiempos de memorias estáticas y dinámicas típicos del momento enque se simularon. El tiempo de ciclo de L3uC (TL3) es de 20 nsg y el de MP (Tlat) de 70nsg. A estos tiempos se ha añadido un 25% de sobrecarga debida a la lógica de control.

En laTabla 2.1 y la Tabla 2.2 se muestran los tiempos de ciclo del procesador para losdistintos tamaños de caches L1, y el valor de TL2 en función de los tamaños de L1 y L2obtenidos por el modelo de tiempos.

Tabla 2.1 Tiempos de ciclo del simulador en nsg. y frecuencia de reloj, en función del tamaño de cache de primer nivel.

Tamaño de L1 (KB) 1 2 4 8 16 32 64 128 256

Tiempo de ciclo(nsg) 3,871 4,072 4,425 4,937 5,407 5,961 6,875 7,900 9,358

Frecuencia CPU (MHz) 258 245 226 202 185 168 145 127 107

Metodología de trabajo


A continuación se resume el modelo temporal de cada componente.

L1iC, L1dC: Tiempo de acierto en lectura = TL1. Tiempo de acierto en escritura = 2*TL1, unTL1 para probar y otro para escribir la palabra. Tiempo de carga de bloque = TL1, es eltiempo necesario para cargar un bloque en L1 después de una lectura en el nivel supe-rior.

L2uC Inclusión: Igual que L1dC cambiando TL1 por TL2. L2uC Demanda: igual a In-clusión salvo por la posiblidad de un fallo en una escritura de bloque desde L1dC; eneste caso el bloque es copiado en tbuf con un coste de TL2 ciclos necesarios para detec-tar el acierto/fallo en L2uC. L2uC Exclusión: Tiempo de acierto en lectura = TL2, Tiempode carga de bloque desde L1 = 2 * TL2, el primer TL2 para leer y reemplazar, si es necesa-rio, el bloque víctima t, y el segundo TL2 para cargar el bloque u. Además, en Inclusión,tiempo para cambiar el estado de un bloque (al recibir un comando de aviso de reemplazo oprimera escritura) = TL2 + TML2, donde en los TL2 primeros ciclos se prueba y en losTML2 siguientes se modifica el estado (TL2 ≥ TML2). En demanda: igual en caso deacierto, en caso de fallo el aviso se pasa a tbuf con un coste de TL2 ciclos.

L3uC: Tiempo de acierto en lectura = ß32 (Tbus32 + TL3 + Tbus32), número de ciclos des-de que se lanza la dirección hasta que se ha cargado xbuf2. Se supone una cache exter-na L3 que puede ofrecer W32 bits por acceso siendo ß32 = B2 / W32. Para cada trozo debloque leído se emplea un ciclo de bus (Tbus32) para enviar dirección, un tiempo de ac-ceso a cache (TL3 ) y un nuevo ciclo de bus para devolver datos. Tiempo de acierto en es-critura = Tbus32 + TL3+ ß32 ( Tbus32 + TL3), donde se separa el primer acceso (Tbus32+ TL3) para comprobar tags, y ß32 accesos para escritura. Ambas temporizaciones si-guen el modelo del interface entre el 21064 y su cache externa en el sistema DEC 7000/10000 [AI92]. Tiempo de modificación de estado (aviso de reemplazo, de primera escritura)= Tbus32 + TL3+ TML3 (TL3 ≥ TML3).

Tabla 2.2 TL2 expresado en ciclos de procesador, en función de los tamaños de L1 y L2. Sólo se muestran los valores en los puntos que han sido simulados

Tamaño de L1i,d (KB)

2 4 8 16 32 64 128

4 2

8 2 2

Tamaño 16 2 2 2

de L2 (KB) 32 2 2 2 2

64 3 2 2 2 2

128 3 3 2 2 2 2

256 3 3 3 2 2 2 2



El tiempo de bus entre L3 y L2 (Tbus32) se supone siempre igual al ciclo del procesa-dor. Es un bus dedicado ya que L3uC sólo sirve al chip procesador.

Memoria Principal: Tiempo de lectura= TbusM3 + Tlat + ßM3 TbusM3 : número de ci-clos desde que se lanza la dirección hasta que se ha cargado xbuf3, donde se supone unciclo de bus para enviar dirección, un tiempo de acceso a memoria (Tlat) y ßM3 transfe-rencias a ritmo de bus. Tiempo de escritura = ßM3 TbusM3 + Tlat. Corresponde a un mo-delo convencional de Memoria principal entrelazada o un modo optimizado en RAMDinámica.

El tiempo de bus entre L3 y MP (TbusM3) se supone independiente del ciclo de proce-sador. Se ha tomado un valor típico de los buses del momento, 20 nsg.

Buffers de salida (ubuf, tbuf and sbuf): Tiempo de escritura = 0 ciclos si el buffer no estálleno, debido a que se solapa la escritura en el buffer con la resolución de fallo. Si el bu-ffer está lleno,Tiempo de escritura = 1 a partir del momento en que se libera una entra-da. Un acierto en buffer bloquea el nivel en que se encuentra el buffer hasta que laentrada objeto de acierto se descarga en el nivel superior. El bloque será leido más tar-de del nivel superior de la forma convencional.

2.4.3 Carga de trabajo

Como carga de trabajo se han escogido 12 programas pertenecientes a SPEC92 ySPEC95, buscando altas tasas de fallo. Los datos se presentarán por separado para cadauno de los 4 grupos siguientes:

SPEC92int: gcc, xlisp, espresso

SPEC92fp: doduc, swm256, fpppp

SPEC95int: gcc, go, vortex

SPEC95fp: fpppp, tomcatv, wave5

En cada uno de estos programas se ha despreciado en el inicio el número de instruccio-nes equivalente a su etapa transitoria (ver capítulo 1). Una vez saltada esta fase se hansimulado 180 Minst. en SPEC92 y 100Minst. en SPEC95 en modo fallos (tan sólo se lle-nan las caches). A partir de este punto se han simulado 20Minst. en SPEC92 y100Minst. en SPEC95 en modo tiempos, donde ya se hace la simulación completa deprocesador y jerarquía y se miden las tasas de interés.

2.5 Resultados

En este apartado se comparan varios diseños para una jerarquía de cache on chip anali-zando su coste en área y sus prestaciones en tiempo de ejecución. El diseño base consis-

Resultados


te en implementar un solo nivel de cache que ocupa toda el área disponible. Losdiseños alternativos dividen este espacio en dos niveles de cache, de diferentes tama-ños y con distintas gestiones de contenidos: inclusión y exclusión.

Todas las gráficas de este apartado tienen el mismo formato. La magnitud representadaes TPI en función del área del integrado ocupada por las caches.

En cada gráfica aparecen varias curvas que corresponden a distintos tamaños de L2.Dentro de una curva los puntos que se representan corresponden a distintos tamañosde L1iC y L1dC. El punto situado más a la izquierda de cada curva corresponde a unnivel 1 de 2KB + 2KB, y este tamaño se va duplicando en los puntos sucesivos de lamisma curva hasta alcanzar el máximo tamaño permitido. Dado que las dos caches deprimer nivel siempre son iguales, en lo que resta de capítulo expresaremos el tamañodel primer nivel de cache indicando el de una de las dos.

En cada gráfica aparece una curva especial que se extiende a lo largo de todo el eje deáreas. Son los datos correspondientes a un sistema con un solo nivel de cache on-chip,que varía desde 2KB hasta 128KB. El punto de 2KB no suele ser visible en esta curva alsalirse del área de dibujo. En estos casos aparece una etiqueta que identifica el primerpunto visible de esta curva.

Mediante esta representación podremos comparar facilmente las distintas alternativasde diseño de la jerarquía de memoria en función del área de chip disponible.

2.5.1 Resultados en SPEC92

La Figura 2.3 y la Figura 2.4 muestran el comportamiento de SPEC92 ejecutándo sobresistemas en inclusión y exclusión respectivamente.



Figura 2.3 TPI para SPEC92 (int+fp) en Inclusión para dimensionados distintos de L1 y L2. En el eje horizontal aparece el área suma (en RBEs) de las dos caches de primer nivel (L1iC y L1dC) y de la cache de segundo nivel (L2uC).

La curva que representa al sistema con un solo nivel de cache muestra un mínimo en elpunto correspondiente a un tamaño de 64 KB, unos 800.000 RBEs. Este mínimo se debeal compromiso existente entre la disminución en la tasa de fallos y el aumento en eltiempo de ciclo provocados al aumentar el tamaño de cache. Tamaños mayores de 64KB provocan pérdida de prestaciones debido a que la pérdida originada por el aumen-to en el tiempo de ciclo no se compensa con la disminución de la tasa de fallos. El au-

8

9

1 0

1 1

1 2

1 3

1 4

1 5

1 6

1 7

1 8

0 500000 1000000 1500000

No L2

8 KB

16 KB

32 KB

64 KB

128 KB

4 + 4 KB

TPI

L1size (rbe)

64 + 64 KB

L1= 2+2 KB

L1= 32+32 KB

L2size

Resultados


mento de rendimiento al aumentar el tamaño de primer nivel es mucho más acusadopara tamaños pequeños de cache. Para caches mayores de 16KB (unos 200K RBEs) lapendiente de la curva disminuye de forma significativa, haciendo cada vez menosatractivo el aumento de su tamaño.

La implementación de un segundo nivel de cache gestionado en inclusión (Figura 2.3),produce beneficios significativos precisamente en esos grandes tamaños. Con peque-ños incrementos en el área dedicada a cache se consiguen mejoras significativas deprestaciones respecto a un solo nivel en todo el espacio de diseño, salvo para tamañosglobales menores de 16KB. Como ejemplo se puede observar la gran disminución enTPI conseguida al pasar de un único nivel de 32 + 32 KB a un primer nivel de 4 KB res-paldado por un segundo de 64 KB, que en términos relativos supone una reducción del16,5% del TPI.

Como resultado, se hace más atractivo aumentar el espacio global dedicado a cache porencima de los 200K RBEs (16+16 KB). Si dibujamos una nueva curva uniendo los pun-tos mínimos de todas las configuraciones de dos niveles, podemos observar como lapendiente se mantiene muy elevada hasta el entorno de los 500K RBEs. A partir de los900K RBEs la curva empezaría a subir, indicando que es inútil dedicar más espacio acache. Este comportamiento sugiere la posibilidad de incorporar un tercer nivel on-chip si se desea dedicar un mayor espacio a la jerarquía de memoria.

Para cada tamaño de L2 existe un mínimo local que corresponde a tamaños de L1 dis-tintos. Este mínimo está en L1= 4KB para L2 entre 16 y 64 KB, y en L1= 8KB para L2=128 KB. El fenómeno es similar al que ocurre con un solo nivel de cache. Con dos nive-les, la penalización del fallo en el primero viene marcada por el tiempo de servicio delsegundo, en lugar del tiempo off chip cuando sólo disponemos de un nivel. Esta menorpenalización desplaza los mínimos locales de TPI hacia caches de primer nivel de mu-cho menor tamaño.

Existe una segunda causa que acentúa este comportamiento. En inclusión, el tamañoefectivo del que se dispone en L2 para guardar bloques distintos de los de L1 desciendea medida que el tamaño de L1 aumenta, ya que todos los bloque presentes en L1 debenestar también en L2.

LaFigura 2.4 muestra los mismos datos para un sistema en exclusión. En todos los pun-tos simulados exclusión consigue menor TPI que inclusión. La diferencia varía entre un20,4% en L1= 2KB con L2= 8KB, y un 0,9% en el punto del mínimo absoluto (L2=128KBy L1=8KB). La diferencia media, considerando sólo los puntos en los que es posible lacomparación, es de 6,02%; en acuerdo con los resultados en cuanto a CPI presentadosen [IV96].



Figura 2.4 TPI para SPEC92 (int+fp) en Exclusión para dimensionados distintos de L1 y L2. En el eje horizontal aparece el área suma (en RBEs) de las dos caches de primer nivel (L1iC y L1dC) y de la cache de segundo nivel (L2uC).

El espacio de diseño con exclusión es más amplio que con inclusión. Para cada tamañode L2 disponemos de una configuración más en L1, con tamaño global igual al de L2.Esta configuración no es posible en inclusión porque violaría las reglas de dimensiona-do presentadas en el apartado 2.2.1 de este capítulo. Esto proporciona mayor libertadde elección a la hora de dimensionar la jerarquía: como vemos en la Figura 2.4 existenconfiguraciones de 2 niveles para cualquier área, y en algunos puntos hay más de una.

8

9

1 0

1 1

1 2

1 3

1 4

1 5

1 6

1 7

1 8

0 500000 1000000 1500000

No L2

8 KB

16 KB

32 KB

64 KB

128 KB

4 + 4 KB

TPI

L1size (rbe)

64 + 64 KB

L2size

L1= 2+2 KBL1= 32+32 KB

Resultados


Los mínimos locales de las curvas que representan a cada L2 se han desplazado haciala derecha, hacia tamaños de L1 mayores. Para caches L2 de 8, 16 y 32 KB los tamañosde L1 óptimos son los mayores posibles, lo que no ocurría en inclusión. Esto se debe almejor aprovechamiento del espacio on-chip que proporciona la gestión en Exclusión.

2.5.2 Resultados en SPEC95

SPEC95 presenta tasas de fallos mucho mayores que SPEC92. El aumento de la presiónsobre la cache externa obliga a aumentar su tamaño para disminuir su influencia en losresultados. Nuestro objetivo es la comparación de dos alternativas en la gestión de con-tenidos entre los dos niveles de cache on chip. La cache de tercer nivel proporciona unapenalización media al fallo razonable, pero para conseguirlo debe estar bien dimensio-nada. En todas las gráficas de este apartado aparece una curva más para L2 = 256KB,que es posible debido al aumento en L3 de 0,5 a 1 MB. El eje de área llega hasta los2.500.000 RBEs en lugar de los 1.500.000 de SPEC92.

Dada la gran diferencia de comportamiento entre los benchmarks de enteros y los depunto flotante, se presentan sus datos por separado. En la Figura 2.5 y la Figura 2.6aparecen los resultados de SPEC95int en inclusión y exclusión respectivamente.



Figura 2.5 TPI para SPEC95int en Inclusión para dimensionados distintos de L1 y L2. En el eje horizontal aparece el área suma (en RBEs) de las dos caches de primer nivel (L1iC y L1dC) y de la cache de segundo nivel (L2uC).

Cualitativamente, estos datos no presentan diferencias significativas respecto a los deSPEC92. La nueva curva con L2=256KB verifica que con 2 niveles de cache no es renta-ble pasar de los 1000K RBEs dedicados a cache en el chip. Si los contenidos se gestionanen Exclusión se consigue el punto de mayores prestaciones en L2=256KB con L1=16KB,pero su relación coste prestaciones es mucho peor que la del punto con L2=128KB yL1=8KB.

7

9

1 1

1 3

1 5

1 7

1 9

0 500000 1000000 1500000 2000000 2500000

No L2

8 KB

16 KB

32 KB

64 KB

128 KB

256 KB

4 + 4 KB

TPI

L1size (rbe)

64 + 64 KB

L2size

L1= 2+2 KB

L1= 32+32 KB

Resultados


Exclusión presenta mejores prestaciones que Inclusión en todo el espacio de diseño,con mejoras relativas entre un 17% (con L2=8KB y L1=2KB) y un 1,17% (con L2=32KB yL1=256KB). La diferencia media es del 6,29%, algo mayor que la de SPEC92.

Figura 2.6 TPI para SPEC95int en Exclusión para dimensionados distintos de L1 y L2. En el eje horizontal aparece el área suma (en RBEs) de las dos caches de primer nivel (L1iC y L1dC) y de la cache de segundo nivel (L2uC).

Los datos referentes a SPEC95fp se presentan en la Figura 2.7 y la Figura 2.8. Las tasasde fallos para los tres programas de SPEC95fp son muy elevadas incluso para cachesgrandes, lo que provoca elevados TPIs. Las formas de las curvas son más complejas

7

9

1 1

1 3

1 5

1 7

1 9

0 500000 1000000 1500000 2000000 2500000

No L2

8 KB

16 KB

32 KB

64 KB

128 KB

256 KB

4 + 4 KB

TPI

L1size (rbe)

64 + 64 KB

L2size

L1= 2+2 KB L1= 64+64 KB



que en los programas analizados hasta el momento. Para analizar los resultados es ne-cesario considerar dos efectos que actúan de forma simultánea:

Figura 2.7 TPI para SPEC95fp en Inclusión para dimensionados distintos de L1 y L2. En el eje horizontal aparece el área suma (en RBEs) de las dos caches de primer nivel (L1iC y L1dC) y de la cache de segundo nivel (L2uC).

1. Las tasas de fallos en primer nivel de los tres programas tienen una gran caida alpasar de 8KB a 16KB. En dos de ellos, tomcatv y wave5, no se consigue mejora sig-nificativa de la tasa de fallos al variar la cache L1 entre 2KB y 8KB. En tomcatv ade-mas tampoco al aumentar por encima de 32KB.

1 2

1 4

1 6

1 8

2 0

2 2

2 4

2 6

2 8

0 500000 1000000 1500000 2000000 2500000

No L2

8 KB

16 KB

32 KB

64 KB

128 KB

256 KB

4 + 4 KB

TPI

L1size (rbe)

64 + 64 KB

L2size

L1= 2+2 KBL1= 32+32 KB

Resultados


Por tanto, en todas las curvas se observa un fuerte incremento de prestaciones alpasar de L1=8KB a L1=16KB (del tercero al cuarto punto de cada curva). Por otraparte, si al variar el tamaño de L1 entre 2 y 8 KB no mejora de forma significativa latasa de fallos, el aumento en tiempo de ciclo producirá un aumento casi proporcio-nal de TPI.

Figura 2.8 TPI para SPEC95fp en Exclusión para dimensionados distintos de L1 y L2. En el eje horizontal aparece el área suma (en RBEs) de las dos caches de primer nivel (L1iC y L1dC) y de la cache de segundo nivel (L2uC).

1 2

1 4

1 6

1 8

2 0

2 2

2 4

2 6

2 8

0 500000 1000000 1500000 2000000 2500000

No L2

8 KB

16 KB

32 KB

64 KB

128 KB

256 KB

4 + 4 KBTPI

L1size (rbe)

64 + 64 KB

L2size

L1= 2+2 KB

L1= 64+64 KB



2. Las tasas de fallos en primer nivel de los tres programas son muy elevadas inclusopara grandes tamaños de cache. La penalización que sufre cada uno de estos falloscobra por tanto mayor importancia que en los otros grupos de programas. Para uncierto tamaño de L2 mayor de 32KB, la penalización al fallo de L1 varía entre 2 y 3ciclos como muestra la Tabla 2.3. Para pequeños tamaños de L1 la penalización esde 3 ciclos. A partir de un cierto tamaño de L1 pasa a ser de 2 ciclos.

Los puntos con penalización al fallo de 3 ciclos se ven especialmente castigados por laalta tasa de fallos en el primer nivel. En cada curva, el paso de 3 a 2 ciclos de penaliza-ción provocara una disminución significativa del TPI.

Una vez explicados los puntos más oscuros de estas figuras pasamos a estudiar los ra-zonamientos generales, que son similares a los de apartados anteriores.

Tanto en Inclusión como en Exclusión se consigue el punto de mayores prestaciones enel entorno de los 2000K RBEs, con 256 KB en segundo nivel. Sin embargo, el punto conmejor relación coste/prestaciones se situa en torno a los 1000K RBEs, con L1=16KB yL2=128KB.

Exclusión consigue menor TPI en todos los puntos simulados salvo en uno, L1=16KB yL2=128KB, donde es ligeramente peor (0,55%). Esto sucede porque las ventaja relativade Exclusión desaparece cuando L2 se hace muy grande respecto a la carga de trabajo orespecto al primer nivel de cache, ya que el aumento del espacio útil conseguido porExclusión puede no tener influencia en la tasa de fallos. En estos puntos, variar la ges-tión de contenidos es irrelevante.

En el punto de máxima ventaja, Exclusión es un 15,8% mejor que Inclusión. En media,la diferencia es del 5,66%, ligeramente inferior a las que presentan SPEC92 ySPEC95int.

Tabla 2.3 TL2 expresado en ciclos de procesador, en función de los tamaños de L1 y L2. Sólo se muestran los valores en los puntos que han sido simulados

Tamaño de L1i,d (KB)

2 4 8 16 32 64 128

4 2

8 2 2

Tamaño 16 2 2 2

de L2 (KB) 32 2 2 2 2

64 3 2 2 2 2

128 3 3 2 2 2 2

256 3 3 3 2 2 2 2

Ejecución superescalar y fuera de orden


En el Apéndice B se muestra para SPEC92, SPEC95int y SPEC95fp una selección depuntos prácticos de diseño: aquellos que ofrecen un mínimo de prestaciones o bien cu-bren un área determinada con unas prestaciones adecuadas. En ella se observan conmás claridad algunas de las conclusiones ya comentadas: El diseño en dos niveles hacemucho más rentable el incremento de área entre 200 y 500 RBEs para SPEC92 y hasta1000 RBEs para SPEC95, Exclusión siempre consigue mejor TPI que Inclusión, y Exclu-sión ofrece mayor libertad de elección a la hora de dimensionar la jerarquía.

2.6 Ejecución superescalar y fuera de orden

Todas las conclusiones de este capítulo se basan en la simulación de una jerarquía dememoria alimentando a un procesador que lanza en orden una instrucción por ciclo.En nuestros días, la mayoría de los procesadores en el mercado ejecutan con un ciertogrado de desorden varias instrucciones por ciclo. Es necesario razonar hata qué puntose pueden extrapolar esas conclusiones a la nueva situación.

La ejecución fuera de orden es un método, complementario a los presentados en estatesis, para disminuir el impacto de la latencia en el acceso a memoria. Una de las razo-nes básicas para el uso de dos niveles de cache dentro del chip, expuestas en la intro-ducción de este capítulo, era la necesidad de servir al procesador a su mismavelocidad. Esta necesidad obliga a diseñar una cache de primer nivel pequeña y senci-lla. Esta cache tendrá por tanto una alta tasa de fallos que, si son servidos desde fueradel chip, producirán importantes pérdidas por las altas latencias del siguiente nivel.

La ocultación de latencia que lleva consigo la ejecución fuera de orden puede permitirdiseños con caches de primer nivel más lentas, más grandes y complejas, que sean ca-paces de servir la mayoría de los accesos del procesador. De hecho, la incorporación delos dos niveles a los procesadores actuales, que parecía ser inminente hace unos pocosaños, se ha ido retrasando; posiblemente con este razonamiento.

Sin embargo, hay tres razones que nos hacen pensar que el diseño en dos niveles volve-rá a ser una buena alternativa en muy poco tiempo:

1. La divergencia en los tiempos de acceso dentro y fuera del chip sigue creciendo.Esta tendencia lleva inevitablemente al diseño multinivel.

2. Ya hay estudios que muestran que las pequeñas latencias de las caches de primernivel presentes en los procesadores actuales no son totalmente ocultadas por elmecanismo de ejecución fuera de orden. En [WO95] se trata este problema y seapunta como posible solución la incorporación de un nuevo nivel de cache (nivel0) entre el procesador y la cache de primer nivel.

3. La ejecución fuera de orden suele ir acompañada de lanzamiento de varias instruc-ciones por ciclo. Entre otras necesidades, el lanzamiento múltiple requiere variospuertos de acceso al primer nivel de cache. Multiplicar el número de puertos en



una cache grande y compleja es demasiado caro. Este problema también ha sidoestudiado por los mismos autores en [WOR96, WO97].

Suponiendo la presencia de dos niveles dentro del chip, la relación de contenidos entrelas dos caches cobra incluso mayor importancia que en el entorno estudiado en este ca-pítulo. La gestión de contenidos influye en la tasa de fallos del segundo nivel. Estos fa-llos se ven penalizados con un acceso fuera del chip, con latencias que son difíciles deocultar con la ejecución fuera de orden. Cada ciclo de detención del procesador en esteentorno implica dejar de lanzar varias instrucciones, una penalización mayor que la su-frida por un procesador que lanza una sola instrucción por ciclo.

2.7 Conclusiones

En este capítulo comparamos varias alternativas de gestión de los contenidos de dosniveles de cache integrados, con respaldo en un tercer nivel exterior. Los estudios cuan-titativos previos sobre multinivel siempre suponen el nivel dos externo, y/o no tienenen cuenta el mantenimiento de la coherencia y/o no comparan entre sí modelos alter-nativos de gestión de contenidos. Hasta este trabajo la única solución coherente multin-ivel estudiada era la inclusión entre niveles.

Manteniendo la inclusión en un tercer nivel externo se han desarrollado nuevos proto-colos para gestionar los dos niveles inferiores en Exclusión y Demanda de forma cohe-rente. El algoritmo para Exclusión y sus necesidades hardware han resultado serincluso más sencillos que en Inclusión.

El análisis cuantitativo de las prestaciones de cada alternativa parte de un trabajo pre-vio que se puede resumir en los tres puntos siguientes: i) Demanda consigue prestacio-nes muy parecidas a inclusión, tanto en tasa de fallos como en CPI. Dada lacomplejidad añadida para soportar coherencia se descarta como alternativa. ii) Exclu-sión siempre consigue tasas de fallo menores que inclusión y demanda. Las diferenciasson mayores cuanto más parecidos son los tamaños de L1 y L2. Pese a ello, y debido alincremento de escrituras de bloque desde L1 hacia L2, en ciertos puntos de diseño pue-de ofrecer peor CPI. iii) Aprovechando las características especiales de exclusión se me-joran dos aspectos de su temporización. Con estas mejoras la nueva exclusión consiguemejor CPI en todos los puntos de diseño. La mejora media es de un 7,9% para los pro-gramas de punto flotante y de un 4,12% para los de enteros.

En el trabajo presentado en esta tesis se comparan varios diseños para una jerarquía decache on chip analizando su coste en área y sus prestaciones en tiempo de ejecución.Para llevar a cabo el estudio se usan dos conocidos modelos analíticos para la estima-ción del área y del tiempo de ciclo de las diferentes alternativas. El diseño base consisteen implementar un solo nivel de cache que ocupa toda el área disponible. Los diseñosalternativos dividen este espacio en dos niveles de cache, de diferentes tamaños y condistintas gestiones de contenidos: inclusión y exclusión. Las nuevas conclusiones se re-sumen en:

Referencias


• Incluyendo un solo nivel de cache, las mejores prestaciones (tanto en SPEC92 comoen SPEC95) se consiguen con un tamaño de 64KB, lo que equivale a unos 800KRBEs. Entre 16 KB (200KRBEs) y 64 KB la curva de prestaciones es muy plana, in-dicando una mala relación coste/prestaciones.

• Al incluir dos niveles, las mejores prestaciones se consiguen dedicando a cache 900KRBEs para SPEC92 y en torno a 2000KRBEs para SPEC95. Esto equivale a unacache L2 de 128KB y L1 de 8KB para SPEC92 y a una cache L2 de 256KB y caches L1entre 16 y 32 KB para SPEC95. Por otra parte, la ganancia en prestaciones es muyclara hasta los K500RBEs para SPEC92 y hasta 1000 KRBEs para SPEC95.

• La gestión de contenidos en exclusión consigue mejor TPI que la gestión en In-clusión prácticamente en todos los tamaños de cache analizados, y para todos losgrupos de programas de prueba. Las ganancias medias para los programas deSPEC92, SPEC95int y SPEC95fp son de 6%, 6,3% y 5,7% respectivamente.

2.8 Referencias

[AI92] B.R. Allison and C. van Ingen. "Technical Description of the DEC 7000 and DEC 10000 AXP Fam-ily". Digital Technical Journal Vol. 4 No. 4 Special Issue 1992, pp. 1-11.

[BGK96] D. Burger, J.R. Goodman and A. Kägi. “Memory Bandwidth Limitations of Future Microproces-sors“. In Proc. of 23th Int. Symp. on Computer Architecture, pp.78-89, May 1996.

[BKB90] H.O. Bugge, E.H. Kristiansen, and B.O. Bakka. “Trace Driven Simulations for a Two-level CacheDesign in Open Bus Systems”. In Proc. of the 17th Ann. Int. Symp. on Computer Architecture.pp.250-259, May. 1990.

[BW87] J.L. Baer, and W.H. Wang. “Architectural Choices for Multi-level Cache Hierarchies”. In Proc.14th International Conference on Parallel Processing, pp. 258-261, 1987.

[BW88] J.L. Baer, and W.H. Wang. “On the Inclusion Properties for Multi-level Cache Hierarchies”. InProc. of 15th Int. Symp. on Computer Architecture, pp. 73-80. IEEE 1988.

[CK94] B. Cmelik and D. Keppel, "Shade: A Fast Instruction-Set Simulator for Execution Profiling", in Proc.1994 SIGMETRICS, vol 22, number 1, pp. 128-137, May 1994

[EE93] B.J. Ewy, and J.B. Evans. “Secondary Cache Performance in Risc Architectures”. In Computer Ar-chitecture News.Vol. 21, Nº 3, pp.34-39,June 1993.

[ERP95] J.H. Edmondson, P. Rubinfeld and R. Preston. "Superscalar Instruction Execution in the 21164 Al-pha Microprocessor". IEEE Micro, April 1995, pp.33-43.

[Fly95] M.J. Flynn. Computer Architecture. Pipelined and Parallel Processor Design. Jones and Bartlett Pub-lishers, Boston 1995.

[GGP+89] P. P. Gelsinger, P. A. Gargini, G. H. Parker, and A. Y. C. Yu. "Microprocessors Circa 2000", IEEESpectrum, Vol. 26, pp. 43-47, October 1989.

[IV96] P.E. Ibañez and V. Viñals, "Performance Assessment of Contents Management in Multilevel On-Chip Caches", to appear in Proc. 22nd. Euromicro Conference, Sept. 96

[Jou93] N.P. Jouppi. “Cache Write Policies and Performance”.In Proc. of 20th Int. Symp. on ComputerArchitecture, pp. 191-201, May. 16-19, 1993

[JW94] N.P. Jouppi and S.J.E. Wilton. "Tradeoffs in Two-Level On-Chip Caching". In Proc. of 21th Int.Symp. on Computer Architecture, pp. 34-45, 1994.



[MQF91] J. Mulder, N. Quach and M. Flynn. "An Area Model for On-Chip Memories and its Application".Journal of Solid-State Circuits, 26 (2), Feb. 1991.

[Prz90] S. Przybylski. Cache Design: A Performance Directed Approach. Morgan-Kaufmann, San Mateo, CA,1990.

[RVL+89] C. Rodríguez, V. Viñals, J. Labarta and R. Beivide. “Cache Memory Reasignation Models andtheir Impact on Multiprocessor Performance”. Int. Journal of Mini & Microcomputers, Vol. 11, Nº1, 1989, pp. 9-12.

[SAN93] R. B. Smith, J. K. Archibald and B. E. Nelson. “Evaluating Performance of Prefetching SecondLevel Caches”. ACM Performance Evaluation Review, Vol. 20, No. 4, May. 1993, pp. 31-42.

[SDC94] S.P. Song, M. Denman and J. Chang. "The PowerPC 604 RISC Microprocessor". IEEE Micro, Octo-ber 1994, pp.8-17.

[SL88] R. Short and H. Levy. "A Simulation Study of Two-Level Caches". In Proc. of 15th Int. Symp. onComputer Architecture, pp. 81-89, 1988.

[Viñ93] V. Viñals. "Diseño de Memoria Cache Multinivel con Restricción de Capacidad". Proyecto DGA,convocatoria 1993 de proyectos de investigación.

[WBL89] W.H. Wang, J.L. Baer, and H. Levy. “Organization and Performance of a Two-level Virtual-RealCache Hierarchy”. In Proc. of 16th Int. Symp. on Computer Architecture,pp.140-148, May 28-June 1, 1989.

[WJ93] S.J.E. Wilton and N.P. Jouppi. "An Enhanced Access and Cicle Time Model for On-Chip Caches".DEC Western Research Lab, Technical Report 93/5.

[WO95] K.M. Wilson and K. Olukotun. "High Performance Cache Architectures to Support Dynamic Su-perscalar Microprocessors". Technical Report: CSL-TR-95-682, Stanford University, June 1995.

[WOR96] K.M. Wilson, K. Olukotun and M. Rosenblum. "Increasing Cache Port Efficiency for Dynamic Su-perscalar Microprocessors". In Proc. of 23th Int. Symp. on Computer Architecture, pp. 147-157,1996.

[WO97] K.M. Wilson and K. Olukotun. "Designing High Bandwidth On-Chip Caches". In Proc. of 24thInt. Symp. on Computer Architecture, pp. 121-132, 1997.

[WRP92] T. Wada, S. Rajan and A. Przybylski. "An Anallytical Access Time Model for On-Chip CacheMemories". IEEE Journal of Solid-State Circuits, 27 (8), pp:1147-1156, August, 1992.


C A P Í T U L O 3

Prebúsqueda Hardware de Datos: clasificación y análisis de mecanismos

En este capítulo se resumen, clasifican y analizan los mecanismos existentes paraprebúsqueda hardware de datos. La clasificación permite centrar y delimitar el espaciode diseño en el que se moverá el resto del trabajo. El objetivo es mejorar los mecanis-mos de prebúsqueda propuestos para caches dentro del chip en entornos monoprocesa-dor. Nuestro trabajo se centra en los métodos de prebúsqueda para recorridossecuenciales, con stride constante y de listas.

Se propone un nuevo modelo de prestaciones basado en tasa de fallos que integra lasmás importantes métricas que influirán en las prestaciones finales de un mecanismo deprebúsqueda. Con la ayuda de este modelo se analizan en detalle los mecanismos exis-tentes para el entorno en que se mueve la tesis y se detectan posibles puntos de mejora.

3.1 Introducción

En el capítulo anterior hemos analizado una solución a la creciente discrepancia de ve-locidades entre el procesador y la memoria RAM dinámica. Un solo nivel de cache pue-de no ser suficiente para cubrir la cada vez mayor diferencia de tiempos. La soluciónestudiada consiste en interponer tantos niveles de cache como sea necesario, de formaque la diferencia de tiempos se cubra de forma escalonada.

Esta solución presupone la validez del principio de localidad en todos los niveles de lajerarquía. Es decir, supone que los programas a ejecutar también estructuran tanto sucódigo como sus datos de forma jerárquica, dividiendo sucesivamente cada problemaen subproblemas de menor tamaño. Esta división reiterada daría origen a problemascon tamaños decrecientes, y cada uno de ellos cabría en un nivel de la jerarquía. Las téc-nicas de programación estructurada llevan muchas veces a diseños de este tipo, pero nosiempre. Además, no siempre se programa de forma estructurada.



Por otra parte, aún suponiendo la estructura jerárquica de un problema, el tamaño desus componentes puede no coincidir con el de la jerarquía de memoria en alguno desus niveles. Esto provocará importantes pérdidas de eficiencia. Como ejemplo basta su-poner lo que ocurre si el tamaño de la tarea mínima en que se divide un problema, su-pongamos el bucle más interno de una aplicación, no cabe en el nivel más bajo de lajerarquía de memoria, en la cache de instrucciones de primer nivel. Este problema apa-rece con frecuencia al tratar grandes estructuras de datos en algoritmos numéricos, lastécnicas de bloqueo intentan solucionarlo a nivel de compilación.

La existencia de problemas con patrones que no son bien tratados por las jerarquías dememoria obliga a buscar soluciones alternativas o complementarias. Una de ellas es laprebúsqueda, que consiste en cargar en cache con cierta antelación los bloques que elprocesador va a necesitar. Si la prebúsqueda tiene éxito la memoria cache de primer ni-vel experimentará una reducción efectiva en el número de fallos.

La prebúsqueda de instrucciones ha sido implementada con éxito en diferentes tiposde computadores. No ha ocurrido lo mismo con la prebúsqueda de datos, cuya eficien-cia depende de un mayor número de factores de diseño y es muy sensible a la carga detrabajo. Son muchos los mecanismos propuestos pero son raros los microprocesadoresque incorporan algún tipo de prebúsqueda hardware de datos (p.e. PA7200 [WL97]).

La mayoría de los trabajos sobre este tema suele comparar las prestaciones de un nue-vo sistema con las de un sistema similar sin prebúsqueda, o con otro tipo de solucionescomo la prebúsqueda software o las caches no bloqueantes. Es raro encontrar compara-ciones con otros métodos de prebúsqueda hardware.

Es obvio que la selección e incorporación de un mecanismo de prebúsqueda requiereun estudio global, que presente datos relativos entre mecanismos. En este capítulo serepasan y clasifican los métodos existentes de prebúsqueda hardware de datos. Tras laclasificación se escogen los más apropiados al entorno estudiado en la tesis y se compa-ran sus costes y prestaciones. Para el estudio de prestaciones se define un nuevo mode-lo que permite analizar la influencia de cada mecanismo sobre las principales métricasde un sistema con prebúsqueda, como ocupaciones de los distintos niveles de cache,tasa de fallos, precisión en la predicción, etc. Tras este análisis, y ya en el siguiente capí-tulo, se proponen dos nuevos mecanismos que mejoran a los ya existentes.

3.2 Trabajo previo

El primer mecanismo hardware de prebúsqueda para datos fue el secuencial, pensadopara explotar la localidad espacial que en mayor o menor grado presentan todos losprogramas. En los últimos años (91-98) se han propuesto varios mecanismos hardwarepara detectar patrones distintos del secuencial en el acceso a datos. Se han sugerido di-versas implementaciones y se han estudiado sus prestaciones de diversas maneras. Re-pasamos a continuación todos estos mecanismos divididos en cuatro grupos: i)

Trabajo previo


prebúsqueda secuencial, ii) prebúsqueda con stride constante, iii) prebúsqueda en lis-tas encadenadas, y iv) prebúsqueda markoviana.

3.2.1 Prebúsqueda secuencial

PREBÚSQUEDA SECUENCIAL (ALWAYS, ON-MISS, TAGGED) [SMI78, SMI82]

Partiendo de la secuencia completa de direcciones de datos lanza prebúsquedas sobrelos siguientes bloques en secuencia. Para una cierta dirección (a) de la secuencia generauna prebúsqueda de

â = a + Blocksize.

donde â representa la estimación de un acceso futuro.

Los bloques prebuscados se almacenan en la propia memoria cache. En prebúsquedasecuencial (PS) always se lanza una prebúsqueda para cada dirección de la secuenciagenerada por el procesador. En PS on-miss sólo se lanza prebúsqueda para las direccio-nes generadas por el procesador que fallan en la memoria cache. En PS tagged sólo selanza prebúsqueda la primera vez que se accede a un bloque de cache. Para implemen-tar este último se añade a cada bloque de cache un bit (tag) que indica si el bloque hasido accedido por el procesador durante su estancia en cache. Este bit se pone a cerocuando el bloque se carga en cache por prebúsqueda y a uno cada vez que es accedidopor el procesador. Se lanza prebúsqueda cada vez que un bit pasa de cero a uno.

PREBÚSQUEDA SECUENCIAL (STREAM BUFFERS) [JOU90]

Parte de la secuencia de fallos de una cache de primer nivel y lanza prebúsquedas so-bre los siguientes bloques en secuencia. Para una cierta dirección (a) de la secuencia ge-nera prebúsquedas sobre

â1 = a + Blocksize, â2 = a + 2 * Blocksize, ..., âN = a + N * Blocksize

Los bloques prebuscados se guardan en uno o varios almacenes especiales con estruc-tura FIFO. Cada vez que el procesador lanza una dirección que falla en cache se asignaun buffer (de tamaño N>1, con N=4 en [Jou90]) a esta dirección y se lanzanprebúsquedas para los N bloques siguientes en secuencia. Los bloques se almacenan eneste buffer conforme van llegando, en orden ascendente de sus direcciones. Cada vezque el procesador falla en cache y acierta en la cabeza de un buffer se mueve el bloquede buffer a cache, liberando una entrada del buffer. Para rellenar esta entrada se lanzauna prebúsqueda en secuencia con la dirección de bloque siguiente a la última guarda-da en el buffer. En régimen permanente esto equivale a adelantar el lanzamiento de laprebúsqueda de cada bloque. En lugar de lanzar la prebúsqueda del bloque i cuando sereferencia al i-1, se lanza cuando se referencia al i-N .



PREBÚSQUEDA SECUENCIAL (PREBÚSQUEDA ADAPTATIVA) [DDS93, DDS95]

Similar a stream buffers salvo que i) los bloques prebuscados se almacenan en la propiamemoria cache, y ii) la antelación con que se prebusca un bloque varía según el com-portamiento del sistema. Cada vez que el procesador lanza una dirección que falla encache se lanzan prebúsquedas para los N bloques siguientes en secuencia. Los bloquesprebuscados se almacenan en cache y se marcan como prebuscados. Cada vez que elprocesador acierta en cache en un bloque marcado como prebuscado se lanza unaprebúsqueda en secuencia a distancia N: â = ai + N * Blocksize. En régimen permanenteesto equivale a adelantar el lanzamiento de la prebúsqueda de cada bloque. En lugarde lanzar la prebúsqueda del bloque i cuando se referencia al i-1, se lanza cuando se re-ferencia al i-N (con N>1).

Se mantiene dinámicamente un contador global de 4 bits que indica el número de blo-ques (N) a prebuscar en secuencia cuando se produce un fallo en cache (LookaheadCounter). Este contador varía entre 0 y 15 en función de dos medidas calculadasdinámicamente:

• La eficiencia de la prebúsqueda, calculada como el cociente entre el número debloques prebuscados que son usados al menos una vez y el número de prebÚsque-das. Se mantienen dos contadores de 4 bits. El primero se incrementa cada vez quese lanza una prebúsqueda (Prefetch Counter). El segundo se incrementa cada vezque se accede por primera vez a un bloque que ha llegado a cache por prebúsqueda(Useful Counter). Cada vez que Prefetch Counter llega a su tope se compara UsefulCounter con dos valores umbrales máximo y mínimo. SiUseful Counter es mayorque el máximo se incrementa Lookahead Counter y si Useful Counter es menor que elmínimo se decrementa Lookahead Counter.

• La pérdida potencial debida a la ausencia de prebúsqueda. Cuando LookaheadCounter tiene valor 0 la prebúsqueda queda desactivada. Para volver a ser activadase requiere un nuevo mecanismo que, usando los mismos contadores, registra elnúmero de veces que se falla al acceder a un bloque i estando el bloque i-1 en cache.

3.2.2 Prebúsqueda con stride constante

Al recorrer por filas una matriz almacenada por columnas o viceversa la diferencia en-tre dos direcciones consecutivas es una constante (stride) de tamaño mayor que el blo-que, igual al tamaño en bytes de una columna (o fila) de la matriz. Lo mismo ocurre alrecorrer de forma secuencial un vector cuyos elementos son de tamaño mayor que elbloque. La detección de este patrón requiere comparar las diferencias entre direccionesconsecutivas de acceso a una cierta estructura de datos. Si definimos:

Si = ai - ai-1

donde ai y ai-1 son direcciones consecutivas de acceso a una estructura de datos, el pa-trón se cumple cuando:

Trabajo previo


Si = Si-1 = Si-2 = ... = Si-k

donde k es un índice de confianza, cuanto mayor sea k más seguros estaremos de queel patrón se está cumpliendo. Un algoritmo basado en la detección de patrón de stridecalcula:

âi+1 = ai + Si

Una de las diferencias entre los métodos que intentan detectar este patrón de strideconstante es la forma en que se extraen las referencias a estructuras particulares, divi-diendo la secuencia global de referencias en varias secuencias a distintas estructuras. Acontinuación repasamos cuatro de ellos, que clasifican las referencias según la instruc-ción ld/st que las lanza, la zona de memoria a que van dirigidas, la diferencia mínimacon referencias anteriores y la frecuencia de aparición del stride.

DETECCIÓN DE PATRONES STRIDE EN INSTRUCCIONES LD/ST [BC91, FPJ92, JT93]

Analiza la secuencia de parejas (t, ai). Donde t es el contador de programa (PC) de unainstrucción ld/st y ai es la dirección i-ésima que esta instrucción ld/st produce. Paracada instrucción analizada se mantiene la historia necesaria para determinar si se cum-ple el patrón de stride. Por tanto, en cuanto se genera una pareja se procede a la detec-ción de patrón: LSC.detectar_patrón(t, ai), donde Detectar_patrón es una función queaccede según el índice t a la estructura de datos LSC (Load/Store Cache) y aplica el al-goritmo de detección de patrón de stride al conjunto (ai, historia de la instrucción t). Enpresencia de patrón detectado la predicción se refiere a la próxima dirección generadapor cada instrucción de forma individual. Es frecuente asociar i a la iteración i-ésimadel bucle que contiene la instrucción ld/st.

Los mecanismos propuestos en [BC91, FPJ92] almacenan los bloques prebuscados en lamemoria cache de datos, el propuesto en [JT93] los guarda en un pequeño almacénauxiliar con estructura de cache (prefetch cache).

En los mecanismos de [FPJ92, JT93] las prebúsquedas se lanzan cuando se ejecuta lainstrucción ld/st para la que se detecta patrón, es decir, con una iteración de adelanto.En [BC91] se propone una forma distinta para determinar el momento en que se lanzala prebúsqueda. Se mantiene un contador de programa adelantado (LAPC, LookAhead Program Counter) que recorre la secuencia de instrucciones con algunos ciclosde adelanto sobre el PC real. LAPC se mantiene mediante una tabla de predicción desaltos y su distancia máxima respecto al PC real es una constante que debe sintonizarascon la latencia del siguiente nivel de la jerarquía de memoria. En cada ciclo LAPC in-dexa la estructura de datos LSC, que almacena las instrucciones ld/st. Si la direcciónse encuentra en la tabla (la instrucción apuntada por LAPC es un ld/st) y se ha detec-tado patrón para ella, se lanza la prebúsqueda correspondiente.

En presencia de bucles largos el mecanismo LAPC permite retrasar el lanzamiento dela prebúsqueda respecto al método convencional, que siempre la lanza con una itera-ción de adelanto, reduciendo la posible polución. Sin embargo, al trabajar con bucles



excesivamente cortos la prebúsqueda no funciona correctamente si LAPC intenta ade-lantarse más de una iteración. En [CB95] se presenta una mejora a este método parapermitir este modo de trabajo.

DETECCIÓN DE PATRONES STRIDE DENTRO DE ZONAS DE MEMORIA [PK94]

Parte de la secuencia de fallos de la memoria cache de primer nivel. Divide la memoriaen zonas de tamaño constante, seleccionado por el diseñador del mecanismo. Se estu-dian tamaños de zona entre 64 Bytes y 64 Mbytes, descartándose los menores de64KBytes. Para cada zona de memoria mantiene la historia necesaria para determinarsi se cumple un patrón stride en el acceso a esa zona. En presencia de patrón detectado,la predicción se refiere a la próxima dirección que hará referencia a esa zona.

Este mecanismo es una ampliación de los stream buffers con prebúsqueda secuencial.Los bloques prebuscados se guardan en uno o varios almacenes especiales con estruc-tura FIFO.

DETECCIÓN DE PATRONES STRIDE POR MÍNIMAS DIFERENCIAS [PK94]

Parte de la secuencia de fallos de la memoria cache de primer nivel. Toma como stridela mínima diferencia entre la dirección actual y las n últimas direcciones que han pro-vocado fallo (con n=16).

Como el mecanismo anterior, este es una ampliación de los stream buffers conprebúsqueda secuencial. Los bloques prebuscados se guardan en uno o varios almace-nes especiales con estructura FIFO.

DETECCIÓN DE PATRONES STRIDE POR FRECUENCIA [DS95]

Parte de la secuencia de fallos de la memoria cache de primer nivel. Cada vez que seproduce un fallo en cache calcula las diferencias entre la dirección fallada y las últimasn direcciones que han provocado fallo (como el método anterior). Con estos n strides ac-tualiza una tabla de frecuencia de strides. Si un stride aparece con una frecuencia mayorque un cierto umbral se almacena en una tabla de strides comunes. Si alguno de los nstrides calculados en cada fallo se encuentra en la tabla de strides comunes se generauna prebúsqueda basada en ese stride. En el estudio presentado en [DS95] el valor den, y las dimensiones de las tablas de frecuencias y de strides comunes se fijan en 16.

3.2.3 Prebúsqueda en listas encadenadas [MH96]

En [MH96] se propone ampliar el método de detección de patrones de stride en ins-trucciones ld/st para hacerlo capaz de detectar otros patrones. En particular se propo-ne detectar i) Recorridos de listas encadenadas por dirección y ii) Recorridos devectores de índices encadenados.

Trabajo previo


i) Recorridos de listas encadenadas por dirección. Supongamos una lista encadenadade registros, donde cada registro contiene un campo siguiente que guarda la direcciónde comienzo del siguiente registro. El recorrido de esta lista se basa en una instrucciónload que lee el campo siguiente del registro actual. Con este valor leido más una cons-tante, en la siguiente iteración ese mismo load calculará la nueva dirección a lanzar, ladel campo siguiente del registro actual. La constante (>=0) es el desplazamiento desdeel principio de registro hasta el campo siguiente (Desp). Llamaremos di al valor leidopor un load en su instancia i, y ai a la dirección lanzada en esa misma instancia, defini-mos Despi como:

Despi = ai - di-1

el patrón se cumple cuando:

Despi = Despi -1 = Despi -2 = ... = Despi -k

donde k es un índice de confianza, cuanto mayor sea k más seguros estaremos de queel patrón se está cumpliendo (k=2 en [MH96]). La dirección a prebuscar se calcula co-mo:

âi+1 = di + Despi

ii) Recorridos de vectores de índices encadenados. En algunos métodos de almacena-miento de vectores y matrices dispersas es frecuente utilizar vectores encadenados deíndices. Es el caso de los formatos LE (Lista Encadenada) y LEC (Lista Encadenada Ci-clicamente), ambos extensiones del formato CRS (Compressed Row Storage) [Ueb97].En estos métodos de almacenamiento, junto al vector de datos se usa otro de índices enel que se encadenan todos los elemento no nulos.

La Tabla 3.1 muestra los elementos de un vector disperso. En la Tabla 3.2 aparece elmismo vector almacenado según el formato LE. Sólo se almacenan los elementos nonulos en el vector DATOS. En el vector COLUMNA se guarda la columna del vectororiginal en la que se encuentra cada elemento del vector DATOS. Para permitir recorri-dos en orden se encadenan estos elementos mediante el vector INDICES, en orden as-cendente de columna. La lista empieza en el elemento 0. El siguiente elemento seencuentra en la entrada INDICES[0], en la 2. El siguiente en INDICES[2], y así sucesiva-mente.

Tabla 3.1 Ejemplo de vector disperso

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

DATOS 0 0 0 71 84 0 86 27 0 0 48 0 0 0 66 0 0 0 0 45



El recorrido de este tipo de estructuras se basa en un load que lee el índice del siguienteelemento no nulo (el vector INDICES). Este índice multiplicado por el tamaño del índi-ce y sumado a la dirección inicial del vector de índices será la dirección lanzada por elload en la siguiente iteración. Llamaremos IV a la dirección inicial del vector de índicesy Isize al tamaño de un índice (integer) en bytes, este último valor lo supondremosconstante. Para cada load definimos IVi como:

IVi = ai - di-1 * Isize

el patrón se cumple cuando:

IVi = IVi -1 = IVi -2 = ... = IVi -k

y la dirección a prebuscar se calcula como:

âi+1 = IVi + di * Isize

Los bloques prebuscados se almacenan en la memoria cache de datos. Lasprebúsquedas se lanzan cuando se ejecuta la instrucción ld/st para la que se detectapatrón, es decir, con una iteración de adelanto.

En este trabajo se presentan teóricamente los detectores para los tres patrones: strides,listas encadenadas y vectores de índices. El diagrama de estados que dicen implemen-tar considera los tres detectores. Sin embargo, la estructura de datos que almacena lainformación asociada a cada instrucción ld/st ( la Reference Prediction Table) no incluyeel campo IV. Este campo es necesario para la detección de recorridos de vectores de ín-dices encadenados, y así en los resultados presentados en su trabajo, no se observa in-cremento de prestaciones para spice, que usa este patrón.

3.2.4 Prebúsqueda markoviana (correlación) [PG95, JG97]

Parte de la secuencia de direcciones lanzadas por el procesador o de la secuencia de fa-llos generados en una memoria cache de primer nivel. Para cada bloque analizado semantiene una lista de bloques sucesores, ordenada de más (cabeza) a menos (cola) pro-babilidad de sucesión. La probabilidad de sucesión se supone proporcional al númeroacumulado de veces que después del bloque analizado se ha accedido a cada uno de

Tabla 3.2 Ejemplo de vector disperso almacenado mediante el formato LE

0 1 2 3 4 5 6

COLUMNA 3 6 4 10 14 19 7

DATOS 71 86 84 48 66 45 27

INDICES 2 6 1 4 5 -1 3

Modelo de Prestaciones


los guardados en la lista. Así pues la predicción â es una lista â = markov(a) = (â1, â2,â3,..., âz) en una implementación con z sucesores por bloque.

En [PG95] se propone una implementación externa al procesador, basada en los fallosde la cache interna. En una estructura de datos externa se guarda información de cadabloque de memoria principal. Esta estructura supone un 6,25% del tamaño de la me-moria, para bloques de 16 palabras y guardando un sólo sucesor por bloque. Lasprebúsquedas se lanzan desde el procesador. Este accede a la estructura de datos du-rante los ciclos de espera del servicio al fallo, usando el bus de direcciones.

En [JG97] se propone una implementación más racional, completamente integrada enel procesador. Sólo se guarda información de los últimos bloques accedidos, en una ta-bla de dimensiones finitas. También se basa en el flujo de fallos de la cache de primernivel.

En los dos casos se proponen simplificaciones que eviten guardar la cadena de Markovcompleta: se ordenan los sucesores mediante LRU. Cada vez que se accede a un bloquese consulta por las direcciones de todos los sucesores almacenados. La consulta se haceempezando por la cabeza, que se supone con mayor probabilidad de ser accedida. Losbloques prebuscados se almacenan en la propia memoria cache.

3.3 Modelo de Prestaciones

En un sistema dado la medida definitiva de comparación entre alternativas es el tiem-po de ejecución, pero para exportar conclusiones a otros sistemas son de ayuda métri-cas auxiliares que iluminen aspectos independientes del mecanismo de prebúsquedabajo estudio.

Para ello son útiles los modelos basados en tasas de fallos, ya que permiten fijar una lis-ta de objetivos, contrapuestos en ocasiones, que cada sistema pesará de forma diferen-te. Entre los propuestos hasta el momento citamos tres que nos parecen interesantes: elde Smith por ser el primero, el de Tullsen y Eggers por ser el más completo y el de Jose-ph y Gruwald por ser simple e intuitivo.

[SMI82] A.J. SMITH, "CACHE MEMORIES"

Normaliza todos los números calculando tasas relativas al número de accesos lanzadospor el procesador.

Estudia la presión sobre la cache definiendo actual references to cache (accesos a cache de-bidos al procesador), prefetch lookups (accesos a cache lanzados por el mecanismo deprebúsqueda) y access ratio (actual + prefetch lookup).

Estudia la presión sobre el siguiente nivel de memoria definiendo: demand miss ratio (fa-llos del sistema sin prebúsqueda), prefetch miss ratio (fallos del sistema conprebúsqueda), prefetch ratio (peticiones de prebúsqueda) y transfer ratio (prefetch ratio +prefetch miss ratio).



De forma intuitiva indica que un sistema de prebúsqueda sólo será efectivo si:

D * demand miss ratio >

D * prefetch miss ratio + P * prefetch ratio + A * (access ratio -1 )

Donde D, P y A son las penalizaciones temporales sufridas cuando se produce un fallodel procesador, una prebúsqueda o un acceso a cache por prebúsqueda respectivamen-te. Estos valores no son constantes y sólo pueden ser determinados mediante simula-ción ciclo a ciclo. El modelo sólo sirve para poner de manifiesto algunos de losparámetros más importantes que influyen en la eficiencia de un sistema deprebúsqueda.

[TE95] TULLSEN Y EGGERS, "EFFECTIVE CACHE PREFETCHING ON BUS-BASED MULTIPRO-

CESSORS"

Normalizan todos los números calculando tasas relativas al número de accesos lanza-dos por el procesador. Llaman fallos a todos los accesos que fallan en cache, bien seangenerados por el procesador o por el mecanismo de prebúsqueda. Este número de fa-llos dividido por el número de accesos de la CPU es la total miss rate. La CPU miss ratecorresponde al número de fallos provocados por accesos de la CPU. De estos fallos al-gunos ya están siendo servidos por el nivel superior de memoria en el momento que seproducen; son los prefetch-in-progress misses. Definen la Adjusted CPU miss rate a partirdel número de fallos de la CPU sin contar los prefetch-in-progress misses.

Este modelo sólo cuantifica la presión sobre el siguiente nivel de la jerarquía, no estu-dia el sobre-uso de la propia cache. (tampoco da idea de cobertura ni precisión, ya queno se conoce la tasa original de fallos y no se descomponen las prebúsquedas en útiles/inútiles).

[JG97] JOSEPH Y GRUWALD, "PREFETCHING USING MARKOV PREDICTORS"

Definen vagamente tres factores que influyen de forma importante en las prestacionesde un sistema de prebúsqueda: coverage, accuracy y timeliness. (cobertura, precisión ypuntualidad).

Normalizan todos los números con el número de fallos que habría en un sistema sinprebúsqueda.

Partiendo de un sistema sin prebúsqueda, la cobertura se define como el número de fa-llos de este sistema que son eliminados por un mecanismo de prebúsqueda. La defini-ción sólo es consistente si los bloques prebuscados se guardan en un almacén auxiliarhasta que se accede a ellos, de forma que no provocan conflictos en el almacén princi-pal.

La imprecisión de un mecanismo de prebúsqueda se define como el incremento de acce-sos al siguiente nivel de memoria que aparecen al añadir el mecanismo de



prebúsqueda, aunque en su introducción define precisión como la fracción de los blo-ques prebuscados que llegan a ser usados por el procesador.

La puntualidad indica si los bloques prebuscados están disponibles antes de que el proc-esador los necesite, pero no tan pronto que sean despreciados antes de su uso. Sólo ex-plica esta idea, no dice como cuantificarla.

Las ideas que expresan estos tres factores son muy claras y ese es su mérito. Sin embar-go, al intentar cuantificarlas aparecen imprecisiones que pueden llegar a confundir másque a aclarar el comportamiento del modelo que se está simulando. Como ejemplo, unsistema que prebusca con demasiada antelación (baja puntualidad) provoca conflictosen el almacén auxiliar de prebúsquedas, eliminando bloques que habían sido prebus-cados correctamente. Esto disminuye el número de fallos eliminados por prebúsqueda,lo que aparecerá engañosamente en el modelo como baja cobertura. También provocauna disminución del cociente (prebúsquedas útiles / total prebúsquedas) lo que apare-ce como una disminución de la precisión.

DESCRIPCIÓN DEL MODELO DE PRESTACIONES

Nuestro modelo es aplicable a subsistemas de prebúsqueda que:

• Comprueban en el primer nivel de cache la existencia de la dirección a prebuscar(prefetch lookup).

• Permiten la existencia de peticiones pendientes en los siguientes niveles de la jerar-quía, tanto iniciadas por el procesador como por el mecanismo de prebúsqueda.

• Almacenan los bloques prebuscados en la propia cache o en un almacén auxiliar.

Las cantidades que consideramos son las siguientes (Figura 3.1):



Figura 3.1 Modelo de prestaciones basado en tasa de fallos

• N, P: número total de referencias y de prebúsquedas, respectivamente. Los aciertosde ambos en L1 data cache no progresan hacia L2. Las direcciones pedidas por elprocesador y el mecanismo de prebúsqueda que no se encuentran en la cache dedatos de primer nivel se buscan en ORL. Si no están pendientes de ser leidos sepropagan definitivamente hacia el siguiente nivel de la jerarquía y se apuntan enORL.

• α: fallos de CPU que ya se están buscando en L2. Estos fallos no sufren toda la la-tencia del siguiente nivel; los llamamos por ello fallos rápidos. Un fallo del procesa-dor puede estar en servicio por: a) una prebúsqueda previa. b) un fallo delprocesador previo ha iniciado ese acceso. Esta última posibilidad implica un com-portamiento no bloqueante de la cache de datos. En nuestro modelo esta segundaposibilidad no se da.

• β: fallos del mecanismo de prebúsqueda que ya se están buscando en L2. Puedenproducirse en los mismos casos que los fallos α.

• A: Número de peticiones a L2 iniciadas por fallos de CPU. Llamamos a estos fallosfallos por demanda.

• B: Número de peticiones a L2 iniciadas por fallos del mecanismo de prebúsqueda.

• D, δ: Descomposición del número de bloques traídos por el mecanismo deprebúsqueda en útiles (usados por la CPU) e inútiles (reemplazados antes de serusados)

A partir de estas cantidades definimos:

CPU

Mecanismo dePrebúsqueda

aciertos

ORLLista de bloques

pedidos a L2

aciertos

aciertosα

β

cache L2

N refs.

P prebs.

Generador dedirección

Acceso a cachede datos L1

Consulta depeticiones pendientes

Acceso a siguiente nivel

B + βBfallos por

prebúsqueda

A fallos pordemanda

A + α

CacheL1 Datos

D + δ

to L1 cacheand CPU

aciertos



– Número de prebúsquedas por referencia ( P/N )

– tasa de fallos con latencia completa ( md = A fallos por demanda /N )

– tasa de fallos con latencia reducida ( mf = α fallos rápidos /N )

– tasa de fallos convencional ( m = (A+α)/N = md + mf )

– tasa de fallos de prebúsqueda ( mp = B /N )

La meta genérica de un sistema de prebúsqueda es disminuir la tasa convencional defallos (m, y en especial la fracción md) mediante la presión mínima sobre la cache de L1(mínimo P/N) y el incremento mínimo de tráfico con L2 (mínimo mp + md). Como pue-de intuirse, los tres objetivos pueden no satisfacerse simultáneamente, y en cada siste-ma concreto se premiará más o menos la consecución de cada objetivo. Como ejemplos,la importancia del primer objetivo (mínimo m) depende de la penalización al fallo en elsiguiente nivel de la jerarquía, la del segundo (mínimo P/N) del número de puertos enMc y la del tercero (mínimo mp + md) del ancho de banda del nivel superior.

Representaremos gráficamente nuestro modelo tal como indica la Figura 3.2. La partederecha de la gráfica muestra la actividad del procesador mientras la izquierda mues-tra la del mecanismo de prebúsqueda. El porcentaje de prebúsquedas por acceso (%P/N) lo indicamos numéricamente a la izquierda. En la parte derecha aparecen los ciclospor instrucción empleados en el acceso a datos en nuestro sistema (dataCPI). Un buensistema de prebúsqueda debe desplazar el máximo número de fallos de la zona dere-cha a la izquierda (ocultando su latencia al procesador), sin aumentar demasiado el ta-maño total de la barra (ocupación del siguiente nivel de la jerarquía), ni el número deaccesos a cache por referencia (1+ P/N).

Figura 3.2 Representación gráfica del modelo de prestaciones.

En la figura Figura 3.3 se presenta el modelo aplicado a un sistema sin prebúsqueda.Como puede observarse, desaparece toda la actividad debida a prebúsqueda:prebúsquedas útiles e inútiles, tasa de fallos con latencia reducida y % P/N tienen va-

010 5 5 10

54.7 0.146

tasa de fallos convencionaltasa de fallos de prebúsqueda

tasa de acceso a L2

CPI de datos%P/N

Prebúsquedasinútiles

Prebúsquedasútiles

Tasa de fallos con latencia reducida

Tasa de fallos con latencia completa

δ / N D / N md mf

mp m



lor cero. La tasa de fallos convencional es igual a la tasa de fallos con latencia completae igual a la tasa de acceso al nivel superior de la jerarquía.

Figura 3.3 Representación gráfica del modelo de prestaciones aplicado a un sistema sin prebúsqueda.

En esta representación también aparecen las ideas de cobertura, precisión y puntuali-dad:

– cobertura: prebúsquedas útiles vs. tasa de fallos convencional (D/m).

– precisión: prebúsquedas útiles vs. prebúsquedas inútiles (D/δ).

– puntualidad: tasa de fallos con latencia reducida vs. prebúsquedas útiles (mf/D).

3.4 Mecanismos de prebúsqueda: espacio de diseño

Para simplificar el proceso de selección de un mecanismo de prebúsqueda hemos con-siderado tres grandes dimensiones de diseño: 1) La más importante, cómo se calcula ladirección de prebúsqueda, 2) Cuándo se inicia la prebúsqueda, y 3) Dónde se depositael bloque prebuscado. En las tres influye de forma determinante el entorno al que vadirigido el mecanismo: sistema mono o multiprocesador y nivel de la jerarquía sobre elque actuará.

Fijados estos componentes, todavía es necesario especificar, i) aspectos deimplementación: buffers intermedios, prioridades de servicios entre demanda yprebúsqueda, y ii) relaciones de competencia y colaboración con el subsistema de me-moria. Es decir, añadir al mecanismo de prebúsqueda los detalles de implementación ylas condiciones de contorno necesarias para convertirlo en un sistema de prebúsqueda.

3.4.1 Que bloque se prebusca?

Un buen mecanismo de prebúsqueda debe identificar el mayor número posible de fu-turos fallos en cache para lanzar prebúsquedas sobre ellos. Para ello, en primer lugarha de predecir correctamente las direcciones que lanzará el procesador, minimizando

010 5 5 10

0 0.247

tasa de fallos convencional

tasa de acceso a L2

CPI de datos%P/N





δ / N D / N md mf

m

Mecanismos de prebúsqueda: espacio de diseño


las prebúsquedas de bloques que nunca se usarán (δ, prebúsquedas inútiles). Además,debe discriminar en lo posible las peticiones de bloques que ya están en cache, para mi-nimizar el número de prebúsquedas (B/N, tasa de fallos de prebúsqueda).

El calculo de la dirección a prebuscar se basa en la suposición o la detección de ciertospatrones regulares en la traza de direcciones lanzadas por el procesador. Clasificamoslos mecanismos de prebúsqueda en cuatro grupos que coinciden con los expuestos enlos trabajos previos: i) prebúsqueda secuencial, ii) prebúsqueda con stride constante,iii) prebúsqueda en listas encadenadas, y iv) prebúsqueda markoviana.

La prebúsqueda secuencial se basa en la alta localidad espacial de la mayoría de losprogramas. No usa mecanismo de detección, supone que el patrón se da con elevadafrecuencia. Da buenos resultados en instrucciones [Smi82,Jou90 ] y con ligeras variacio-nes se aplica en algunos microprocesadores (p.e. PA7200 [WL97]). Es el mecanismomás sencillo y barato. Lo usaremos como referencia.

La prebúsqueda basada en cadenas de Markov trabaja sobre la secuencia de fallos en lacache de primer nivel. Produce varias prebúsquedas por cada elemento de la secuen-cia.Si actuase sobre la secuencia lanzada por el procesador necesitaría demasiados re-cursos, el número de prebúsquedas sería demasiado alto. Descartamos estemecanismo.

Los demás mecanismos identifican patrones regulares de acceso a ciertas estructurasde datos, los intentan detectar y si los encuentran lanzan prebúsquedas basadas enellos.

En la traza de direcciones que lanza el procesador suele haber varias secuencias inde-pendientes que acceden a diferentes estructuras de datos. Cada una de ellas puede se-guir un patrón regular de acceso, pero no tiene porque existir ninguna relación entrelas direcciones de diferentes secuencias. Por tanto, un mecanismo de detección debe sercapaz de clasificar las referencias del procesador según la secuencia a la que pertene-cen. Posteriormente debe comparar entre si las direcciones pertenecientes a una se-cuencia para detectar el tipo de patrón que siguen. Una vez detectado el patrón, elmecanismo será capaz de predecir la siguiente dirección dentro de la secuencia. En elapartado 3.2 hemos repasado tanto los patrones para los que se han descrito algoritmosde detección (stride, listas encadenadas por dirección y listas encadenadas por índice),como los métodos para dividir la secuencia global de referencias en secuencias (porload/store, por zonas de memoria, ...).

Si se puede acceder al contador de programa el método más sencillo para clasificar ac-cesos en secuencias es por dirección de load/store. El resto de los métodos se propu-sieron como sustitutos, para entornos en los que no se disponía de dicha información.En esta tesis estudiamos la jerarquía de memoria dentro del chip. Suponemos por tantoque siempre podemos acceder al contador de programa, y clasificamos los accesos aso-ciándolos a la dirección de la instrucción que los lanza.



3.4.2 Cuando se inicia la prebúsqueda: distancia de prebúsqueda

Tan importante como adivinar qué bloques va a necesitar el procesador en el futuro essaber en qué momento los necesitará. Desde que se lanza una petición de prebúsquedahasta que el bloque está disponible para el procesador pasa un tiempo mínimo igual ala latencia del siguiente nivel de la jerarquía de memoria, que puede verse incrementa-do si el bloque no se encuentra en las caches cercanas o según la ocupación de cada ele-mento de la jerarquía. Llamaremos a este tiempo latencia media (L). Lanzar unapetición de prebúsqueda demasiado tarde implica perder tiempo esperando la llegadadel bloque (disminuyen los fallos por demanda A, pero no se convierten en aciertossino en fallos rápidos α. Esto provoca una disminución del CPI menor de la esperable).Lanzar una petición demasiado pronto aumenta la polución, ya que para hacer sitio albloque que llega hay que expulsar antes de lo necesario a un bloque que podría ser útil(aumenta m, tasa de fallos convencional).

Llamaremos distancia de una secuencia (Ds) al tiempo (en ciclos) transcurrido entredos accesos consecutivos pertenecientes a dicha secuencia. Esta distancia depende delnúmero de instrucciones entre dos accesos consecutivos (algoritmo en ejecución, com-pilador, tamaño de bucle, ...) y del CPI conseguido por el procesador (a menor CPI me-nor distancia en ciclos). Llamaremos distancia de prebúsqueda (Dp) al tiempotranscurrido desde que se lanza una petición de prebúsqueda hasta que el procesadorusa el bloque prebuscado; idealmente este tiempo debe coincidir con la latencia media,en general suele coincidir con la distancia de secuencia.

En los métodos básicos de prebúsqueda cada vez que el procesador lanza una direc-ción se clasifica en secuencias, se analiza su comportamiento y si se detecta patrón selanza la prebúsqueda del siguiente elemento de la secuencia. La distancia deprebúsqueda coincide por tanto con la distancia de secuencia (Figura 3.4).

Figura 3.4 Distancia de prebúsqueda = Distancia de secuencia. La prebúsqueda de ai+1 (âi+1) se lanza en el momento de acceder al elemento ai.

En entornos con distancia de secuencia mucho menor que la latencia media (procesa-dores con alto grado de paralelismo a nivel de instrucción –bajo CPI– ejecutando algo-ritmos con pequeños bucles, multiprocesadores con redes de interconexión de altalatencia, ...) las peticiones de prebúsqueda se lanzan demasiado tarde, los bloques pre-

ai-2 ai-1

tiempoai ai+1

âi+1Dp

Ds



buscados nunca llegan a tiempo. Se han propuesto varios mecanismos que intentanabordar este problema (stream buffers, adaptive prefetching, ...). Todos ellos se basan enuna misma idea básica: en lugar de lanzar la petición de prebúsqueda para el elementoi+1 de una secuencia cuando se referencia el elemento i, se lanzan cuando se referenciael i-V (Figura 3.5). De esta forma se consigue una distancia de prebúsqueda igual a Vveces la distancia de secuencia. Aumentando V se puede conseguir una distancia deprebúsqueda tan grande como se desee, hasta igualarla a la latencia media. El más gra-ve problema de este método es que al aumentar V disminuye la precisión de la predic-ción (aumenta δ, prebúsquedas inútiles).

Figura 3.5 Distancia de prebúsqueda > Distancia de secuencia. La prebúsqueda de ai+1 (âi+1) se lanza en el momento de acceder a un elemento anterior al ai. Para sistemas con L> Ds.

Por el contrario, cuando la distancia de secuencia es mucho mayor que la latencia me-dia (estaciones de trabajo con jerarquías de memoria cuyas latencias no son muy altas,programas con bucles grandes,...) las prebúsquedas se lanzan demasiado pronto, losbloques llegan mucho antes de ser usados por el procesador produciendo polución.Para solucionar este problema se debe retrasar el lanzamiento de las prebúsquedas has-ta L ciclos antes de la petición del procesador, siendo L la latencia media (Figura 3.6).Esto se consigue manteniendo un PC adelantado L ciclos al PC real, el LA-PC. Este mé-todo sólo es aplicable si la dirección de un ld/st nos permite conocer la secuencia a laque está accediendo.

Figura 3.6 Distancia de prebúsqueda < Distancia de secuencia. La prebúsqueda de ai+1 (âi+1) se lanza en algún momento entre los accesos ai y ai+1. Para sistemas con L< Ds.

El mecanismo LAPC con una pequeña modificación (presentada en [CB95]) tambiénsirve para entornos con distancia de secuencia menor que la latencia media. Para con-

ai-2 ai-1

tiempoai ai+1

âi+1Dp

Ds

ai-2 ai-1

tiempoai ai+1

âi+1Dp

Ds



seguirlo se permite que LAPC se adelante varias iteraciones al PC real. El problema deesta aproximación es que la probabilidad de error en la predicción de LAPC es propor-cional a la distancia de prebúsqueda, que en estos entornos es grande.

3.4.3 Dónde se deposita el bloque prebuscado

Las dos opciones excluyentes principales que se han descrito son: a) situar el bloque enun almacén auxiliar con una organización más o menos flexible, desde una FIFO[Jou90] hasta una pequeña Mc [JT93], o bien, b) situar el bloque en la propia memoriacache, desplazando al bloque víctima correspondiente.

En la primera opción, un bloque demandado que está en el almacén auxiliar y puedeser extraído -según la disciplina de acceso del almacén auxiliar- se suministra a proce-sador y memoria cache con una latencia similar a la de un acierto. En ambas opciones,un bloque prebuscado que recibe una demanda mientras está en tránsito se carga direc-tamente en Mc con una latencia menor que la de un fallo convencional.

La carga de los bloques prebuscados en un almacén auxiliar busca disminuir la polu-ción en la cache de datos. Los bloques sólo pasan del almacén auxiliar a la cache cuan-do el procesador accede a ellos, por lo que los bloques no útiles nunca llegan a residiren la cache. Además, los bloques prebuscados útiles no ocupan sitio en la cache hasta elmomento en que son demandados, retardándose al máximo la expulsión del bloquevíctima. Sin embargo, aparecen nuevos problemas que hacen que esta opción no seatan atractiva como parece: 1) problemas temporales, y 2) polución en el almacén auxi-liar.

1. Problemas temporales. El almacén auxiliar (Pc) puede colocarse al mismo nivelque la memoria cache (Figura 3.7 izquierda), y servir al procesador en el mismotiempo que un acierto en cache. Para conseguirlo será necesario colocar un multi-plexor entre cache y procesador que aumentará el tiempo de acierto y posible-mente el ciclo del procesador. Una alternativa más razonable consiste en colocar elalmacén auxiliar detrás de la memoria cache (Figura 3.7 derecha), de forma que yano aparezca en el camino crítico. Con esta organización un acierto en el almacénauxiliar tiene una cierta penalización, que como mínimo será de un ciclo.



Figura 3.7 Colocación del almacén auxiliar (Pc) para bloques prebuscados

2. Polución en el almacén auxiliar. Para limitar el coste de este diseño, el almacénauxiliar suele ser de pequeño tamaño (8, 16 bloques). Esta pequeña cache debe al-macenar los bloques prebuscados desde el momento que llegan del siguiente nivelhasta que el procesador accede a ellos. Desde otro punto de vista, debe ser capazde almacenar todos los bloques prebuscados durante un tiempo igual a la distan-cia de prebúsqueda. Si este tiempo es grande o la frecuencia de prebúsquedas esmuy alta, el almacén puede ser insuficiente y se deberán expulsar unos bloquespara almacenar otros, apareciendo polución en el almacén auxiliar.

3.4.4 Espacio de diseño

En la Tabla 3.3 presentamos el espacio de diseño resultante de la combinación de lastres dimensiones enumeradas en este apartado. Sólo algunas opciones han sido proba-das en la literatura, que a continuación reseñamos:

Tabla 3.3 Espacio de diseño en la prebúsqueda hardware de datos

Secuencial Stride Listas Markov

Dp=n*Ds memoria cache DDS93 DS95

almacen auxiliar Jou90 PK94

Dp=Ds memoria cache Smith82 FPJ92 MH96 PG95

almacen auxiliar JT93 JG97

Dp<Ds memoria cache BC91

almacen auxiliar

CPU

MP

Mc Pc

MUX

CPU

MP

Pc

Mc



BC91 Preloading scheme (LAPC)

DDS93 Adaptive sequential prefetching

DS95 Adaptive prefetching con detección de strides

FPJ92 Stride directed prefetching

PG95, JG97 Markov predictors

Jou90 Stream buffers

JT93 Speculative prefetching

MH96 Indirect reference buffer

PK94 Stream buffers con detección de strides

Smith82 Sequential prefetching

El objetivo de nuestro estudio es mejorar los mecanismos de prebúsqueda propuestospara caches on-chip en entornos monoprocesador. Nuestro trabajo se centra en los mé-todos de prebúsqueda para recorridos secuenciales, con stride constante y de listas. Eneste capitulo estudiamos las prestaciones y coste de los mecanismos ya propuestos. Enel capítulo siguiente proponemos dos nuevos mecanismos que mejoran la relación cos-te/prestaciones de los ya existentes.

En todos los experimentos lanzamos las prebúsquedas con Dp=Ds. En entornos mono-procesador como el que estudiamos las latencias de la jerarquía de memoria no son de-masiado altas. En principio no parece necesario usar antelación en el lanzamiento delas prebúsquedas (Dp=n*Ds). En todo caso, nuestro modelo de prestaciones pondráclaramente de manifiesto la necesidad de esta antelación (si existe) en forma de altosvalores de tasa de fallos de latencia reducida (mf). En presencia de bucles largos podríaser necesario el lanzamiento retardado de las prebúsquedas (Dp<Ds). Este hecho se re-flejaría en nuestro modelo en un incremento del número de prebúsquedas inútiles (δ/N).

Siempre almacenamos los bloques prebuscados directamente en Mc. Además, en nues-tro sistema de referencia incluimos una Victim Cache (VC) para evitar conflictos. La VCcumple en cierto modo el papel de Prefetch Cache, reducir la polución de la cache enpresencia de prebúsquedas erróneas o demasiado tempranas. En lugar de colocarse enla entrada de Mc se coloca en la salida y almacena temporalmente a todos los bloquesexpulsados, de forma que puede ser útil incluso en ausencia de prebúsqueda para re-ducir los conflictos por baja asociatividad, motivo por el que fue propuesta [Jou90]. Lapresencia de VC resta importancia a los problemas derivados del posible lanzamientoadelantado de las prebúsquedas.

Análisis de coste y prestaciones


3.5 Análisis de coste y prestaciones

En este apartado se comparan el coste y las prestaciones de un mecanismo deprebúsqueda con detección de patrones stride y lista frente al secuencial. En contra delo esperado, esta comparación nunca se ha realizado en entornos monoprocesador yaque los estudios que presentan estos mecanismos los comparan sólo con sistemas sinprebúsqueda. El único estudio que realiza una comparación en este sentido es [DS95],en un entorno multiprocesador y con unos supuestos muy diferentes a los nuestros.

3.5.1 Sistema de referencia

Usaremos una simulación ciclo a ciclo de un sencillo sistema procesador-memoria dereferencia para extraer todas las medidas de nuestro modelo de prestaciones. Añadi-mos al sistema de referencia los dos mecanismos de prebúsqueda que deseamos com-parar: la prebúsqueda secuencial marcada de [Smi82] y un detector de patrones stridey lista similar al de [MH96].

La Figura 3.8 muestra el sistema modelado. El procesador es un SPARC con lanzamien-to en orden de una instrucción por ciclo y terminación fuera de orden en punto flotan-te, similar al usado en otros estudios [DS95]. Incluye una cache separada de primernivel dentro del chip, y una unificada de segundo nivel fuera del chip. El tamaño debloque es de 32 bytes para las dos. En todos los experimentos la cache de instruccioneses de 32 KB, mapeo directo y prebúsqueda secuencial marcada [Smi82]. La cache de se-gundo nivel es ideal en el sentido de que nunca falla, y se define un interface segmenta-do con la de primer nivel con 1:7:2 ciclos para transferencia de dirección, acceso a cachede segundo nivel y transferencia de datos respectivamente.

Figura 3.8 Modelo del Sistema.

CPU

InstructionCache

DataCache

L2 Cache

VictimCache

InstructionPrefetch

lookupbuffer

ORL

DataPrefetch

lookupbuffer

ORL

DataAddress

write-backbuffer



La cache de datos es también de mapeo directo, pero su tamaño se varía entre 8 KB, 32KB y 128 KB. A esta cache se añaden los mecanismo de prebúsqueda en estudio. Peti-ciones del procesador y del mecanismo de prebúsqueda compiten por un único puertode esta cache, por lo que una alta tasa de prebúsquedas introduce una cierta penaliza-ción.

Los bloques prebuscados se añaden directamente a la cache de primer nivel. Como enotros trabajos [TE95, JG97], añadimos a la cache de datos una pequeña victim cache de16 entradas para eliminar en lo posible los fallos de conflicto y centrar el estudio en losfallos de carga y de capacidad. Algunos de los benchmarks que usamos (applu, apsi,su2cor, swim, tomcatv y wave5 de los SPEC95-fp) tienen una gran cantidad de fallos deconflicto.

ORL (Outstanding Request List) es un pequeño almacén de direcciones que guarda lasprebúsquedas pendientes de ser lanzadas e informa sobre los bloques que están siendobuscados en la cache de nivel dos por peticiones precedentes.

3.5.2 Implementación de los mecanismos de prebúsqueda

Como ya hemos indicado el mecanismo de prebúsqueda secuencial que se implementaes el secuencial marcado de [Smi82]. Como mecanismo con detección de patronesstride y lista se usa el de Mehrotra y Harrison [MH96] con ciertas variaciones:

Detectamos 5 patrones distintos:

1. ESCalar: ai = ai-1

2. SECuencial: ai = ai-1 + s ; 0 < s < Bsize

3. STRide: ai = ai-1 + S ; S > Bsize || S < 0

4. lista DIReccion: ai = di-1 + Desp

5. lista INDice: ai = 4 * di-1 + IV ; 4 = tamaño del entero índice

En el mecanismo de [MH96] se da prioridad absoluta al patrón stride. Si un ld/st cum-ple varios patrones y uno de ellos es el de stride se le clasifica como tal, independiente-mente del que viniera cumpliendo en instancias anteriores.

En el mecanismo que implementamos, si una instrucción ld/st cumple varios patronesen una misma instancia se le clasifica según el patrón que viene cumpliendo en las ins-tancias precedentes. Si cumple constantemente varios patrones se le clasifica según unaprioridad predefinida: escalar, lista (por dirección o índice) y stride (secuencial o no).Estas prioridades buscan clasificar a un ld/st según el patrón real que cumple (no elcasual). En ocasiones, durante el recorrido de una lista se cumple (temporal y casual-mente) un patrón de stride, por ejemplo cuando varios elementos de una lista están al-macenados consecutivos en memoria, en etapas de inicialización. Con el mecanismo de[MH96] la instrucción ld/st pasaría a ser clasificada temporalmente como de strideconstante, y cuando perdiera esta condición requeriría algunas ejecuciones hasta vol-ver a generar prebúsquedas con patrón de lista. Por otra parte, no hemos descubierto



ningún caso práctico en el que se cumpla temporalmente un patrón de lista sin serlo enrealidad.

El tamaño de la tabla que almacena las instrucciones ld/st (LSC, Load Store Cache) sevaría entre 8 y 512 entradas con mapeo directo, analizando su influencia en las presta-ciones del mecanismo.

3.5.3 Carga de trabajo y metodología de traceo

La carga de trabajo escogida para los experimentos de este capítulo y el siguiente es unconjunto de 25 programas pertenecientes a SPEC95 (8 de enteros y 10 de punto flotan-te), SPEC92 (spice) y Perfect Club (6 de punto flotante). Estos programas han sidocompilados para una arquitectura SPARC V7. Las trazas de su ejecución en modousuario se obtienen dinámicamente mediante Shade, una utilidad de SUN Microsys-tems [CK94].

Para cada uno de estos programas se ha estudiado su evolución temporal y se han de-tectado transitorios y periodos con las técnicas expuestas en el capítulo 1. En la Tabla3.4 se presenta toda la carga de trabajo, el número de instrucciones, loads y stores, lostransitorios detectados y el número de instrucciones saltadas.

Tabla 3.4 Benchmarks usados y caracterización (Números en millones)

PERFECT entrada instr. loads stores transit. Saltadas

QCD lg perfect 1 165 195 113 ~0 0

MDG lw perfect 18.593 5.754 2.207 ~0 0

BDNA na perfect 3.340 1.085 535 350 1.000

ARC2D sr perfect 7.990 3.175 1.291 ~0 0

FLO52 tf perfect 1.746 538 211 450 1.000

TRFD ti perfect 2.458 926 453 ~0 0

SPEC95-int

go 5stone21.in 30.714 5.886 1.571 irreg. 4.000

gcc stmt.i 545 92 28 ~0 0

compress in (SPEC92) 91 14 7 ~0 0

ijpeg penguin.ppm 40.598 5.244 2.013 ~0 2.000

xlisp li-input.lsp(92) 5.176 1.057 462 ~0 0

m88ksim ctl.big 75.885 11.337 5.295 irreg. 10.000

perl scrabbl.in 17.518 4.511 1.972 300 1.000

vortex vortex.big 72.662 14.962 5.263 3.200 4.000



Dado el alto coste temporal de la simulación ciclo a ciclo y el gran número de pruebas arealizar, dentro de la zona de estudio de cada programa se han tomado muestras de 20observaciones con un millón de instrucciones por observación, siempre suponiendo unentorno multiprogramado.

3.5.4 Análisis de prestaciones

En la Figura 3.9 se comparan las prestaciones de un sistema con prebúsqueda secuen-cial frente al mismo con prebúsqueda basada en LSC de distintos tamaños. Los datoscorresponden a un sistema con 32KB de cache, 32 bytes de bloque y mapeo directo. Sepresentan valores medios de SPEC95fp, Perfect Club y SPEC95int de arriba a abajo.

En cada gráfica se varía el tamaño de LSC entre 512, 128, 32 y 8 entradas. Las dos pri-meras barras presentan los datos del sistema sin prebúsqueda (No prefetch) y conprebúsqueda secuencial marcada (OBLst, One Block Lookahead Secuential Tagged).

SPEC95-fp

applu applu.in 63.222 14.993 4.642 82 3.000

apsi apsi.in 45.556 10.840 3.632 irreg. 8.000

fpppp natoms.in 291.203 66.805 24.024 0 1.000

hydro2d hydro2d.in 58.599 13.896 3.391 420 1.000

mgrid mgrid.in 91.587 32.074 2.445 0 1.000

spice2g6 greycode.in(92) 21 294 4.826 906 3.935 4.000

su2cor su2cor.in 50.458 12.764 3.300 6.280 7.000

swim swim.in 40.570 12.781 3.086 138 1.000

tomcatv tomcatv.in 50.730 12.709 3.726 4.420 5.000

turb3d turb3d.in 259.940 24.565 12.615 0 1.000

wave5 wave5.in 42.750 11.178 4.585 728 2.000

Tabla 3.4 Benchmarks usados y caracterización (Números en millones)



Figura 3.9 Prebúsqueda LSC vs. Prebúsqueda Secuencial en SPEC95fp, Perfect Club y SPEC95int.

Como muestra la figura, el número total de bloques pedidos al segundo nivel con y sinprebúsqueda LSC es muy parecido, los bloques pedidos que no llegan a usarse sonmuy pocos. Esto implica dos hechos: i) el mecanismo LSC es muy preciso, se equivocapocas veces al predecir una dirección, y ii) el mecanismo no provoca polución en lacache, las prebúsquedas no se piden con demasiada antelación.

Por otra parte, la proporción de bloques prebuscados que llegan tarde a cache (tasa defallos con latencia reducida vs. prebúsquedas útiles) es siempre pequeña, lo que indica

0,082

0,087

0,115

0,191

0,105

0,250

61,2

59,4

40,7

15,0

7,3

0,0

48,1

42,7

25,5

7,0

3,2

0,0

0,096

0,098

0,118

0,152

0,065

0,164

18,3

17,6

15,1

8,4

4,0

0,0

0,078

0,078

0,078

0,082

0,087

0,091

8 4 0 4 8

4 2 0 2 4

4 2 0 2 4

512

128

32

8

OBLst

No prefetch

512

128

32

8

OBLst

No prefetch

512

128

32

8

OBLst

No prefetch

SPEC95fp

Perfect

SPEC95int





δ / N D / N md mf

% P/N CPI de datos



que no es necesario prebuscar con más antelación. En resumen, la decisión de lanzarlas prebúsquedas con Dp=Ds parece correcta.

Un importante hecho a destacar es la diferencia de comportamientos entre la carga depunto flotante y la de enteros. SPEC95int es casi insensible a las variaciones en el siste-ma de prebúsqueda, la reducción en tasa de fallos media está entre el 7,1% de laprebúsqueda secuencial y el 18,5% de una LSC de 512 entradas. SPEC95fp por el con-trario es muy sensible, la reducción en tasa de fallos media varia del 29,5% (LSC 8) al81% (LSC 512). El comportamiento de Perfect Club es muy similar al de SPEC95fp, lareducción en tasa de fallos media varia del 10,6% (LSC 8) al 77% (LSC 512).

En general podemos observar una gran diferencia en la presión sobre el primer nivelde cache (P/N). La prebúsqueda LSC genera muchas más prebúsquedas que la se-cuencial. Por ejemplo, en SPECfp LSC512 genera 61,2 peticiones de prebúsqueda porcada 100 accesos a datos, mientras secuencial sólo genera 7,3. Esta diferencia se mantie-ne en los tres grupos de programas.

Sin embargo, el número de bloques pedidos al siguiente nivel (B/N) por laprebúsqueda secuencial es similar al de una LSC de 512 entradas, incluso mucho ma-yor en SPECint. La prebúsqueda secuencial es menos precisa que LSC, el número debloques prebuscados que nunca se llegan a usar (δ) es mayor. Esto es especialmentegrave en SPECint donde secuencial busca 2,4 bloques no útiles por cada 100 accesos delprocesador, mientras LSC512 sólo 0,16.

El resultado en cuanto a la tasa de fallos depende del grupo de programas. En SPECfpLSC requiere tamaños mayores de 128 para mejorar a secuencial. En Perfect Club siem-pre es mejor secuencial. En SPECint las diferencias son muy pequeñas y siempre a fa-vor de LSC. Globalmente, la prebúsqueda secuencial elimina el 54% de los fallosmientras LSC512 elimina el 66%.

Como resultado de los datos anteriores, el valor del CPI de datos del sistema con se-cuencial es sólo mejorado con LSC de 128 y 512 entradas. LSC512 consigue bajar en un6,7% el CPI de datos de secuencial, LSC128 un 3,7%.

Se podría meter aquí un experimento con LAPC, que fundamente la decisión de noconsiderarlo en adelante.

3.5.5 Análisis de coste

La implementación de la prebúsqueda secuencial marcada requiere añadir un bit acada bloque de la cache de datos, el bit de marca. En una cache como la usada en elapartado anterior de 32 KB con bloques de 32 bytes supone incrementar el tamaño dela cache en torno al 0,4% —100* 1/(32*8)—. No se añade complejidad a la cache ya queeste bit es consultado junto al resto del bloque, cada vez que el procesador accede a él.Además, necesita un sumador para calcular la dirección del bloque siguiente al que seestá accediendo.

Conclusiones del capítulo


El mecanismo LSC requiere la implementación de una tabla y del hardware para el cál-culo de los distintos campos y para el control del mecanismo. Por cada patrón a detec-tar se necesita al menos un sumador y un comparador. Para el cálculo de la direcciónde prebúsqueda se requiere otro sumador.

La ejecución de una instrucción ld/st requiere al menos dos accesos a LSC. El primeracceso lee la información almacenada sobre la instrucción ld/st, que será usada para ladetección de patrones y el cálculo del nuevo estado. El segundo acceso escribe la infor-mación actualizada una vez la instrucción ha sido ejecutada. En un segmentado clásico,la lectura podría realizarse en la etapa de ALU, cuando la instrucción ya ha sido decod-ificada e identificada. El cálculo para el reconocimiento de patrones y del nuevo estadose podría realizar durante la etapa de memoria. En la última etapa se escribiría la tablacon la información actualizada.

Esta simple implementación requiere un puerto de lectura y otro de escritura en LSC.Si las prebúsquedas son lanzadas por un LA-PC, un tercer puerto es necesario. En cadaciclo, se debe consultar a través de este puerto si la instrucción apuntada por LA-PC esun ld/st y si cumple algún patrón.

Cada entrada en LSC contiene un número variable de campos, dependiendo de los pa-trones que se desean reconocer. Si sólo se pretende detectar strides constantes, cuatrocampos son necesarios: PC, Ai, Si y estado. Con direcciones de 32 bits esto supone 12bytes (estado es insignificante). Si se desea detectar recorridos de listas encadenadaspor dirección o índice, debemos añadir otros tres campos (Despi, di y IVi), y cada entra-da tendría 24 bytes.

En resumen, una LSC con 512 entradas almacena entre 6KB y 12KB, usa decodifica-dores de 512 entradas (similares al de una cache de 8KB con bloques de 16 bytes), ydebe disponer como mínimo de 2 puertos ya que puede ser consultada y actualizadaen cada ciclo. Por lo tanto, una LSC ocupa un espacio considerable, similar al de unacache de primer nivel. Mientras, el coste de implementación del mecanismo secuenciales prácticamente nulo.

3.6 Conclusiones del capítulo

En este capítulo se resumen, clasifican y analizan los mecanismos existentes paraprebúsqueda hardware de datos. La clasificación permite centrar y delimitar el espaciode diseño en el que se moverá el resto del trabajo. El objetivo es mejorar los mecanis-mos de prebúsqueda propuestos para caches on-chip en entornos monoprocesador.Nuestro trabajo se centra en los métodos de prebúsqueda para recorridos secuenciales,con stride constante y de listas.

Se propone un nuevo modelo de prestaciones basado en tasa de fallos que integra lasmás importantes métricas que influirán en las prestaciones finales de un mecanismo de



prebúsqueda. Con la ayuda de este modelo se analizan en detalle los mecanismos exis-tentes para el entorno en que se mueve la tesis y se detectan posibles puntos de mejora.

Una parte importante de los mecanismos existentes son pequeñas variaciones de otros,variaciones que intentan optimizar el momento en que se lanzan las prebúsquedas o ellugar donde se almacenan los bloques prebuscados hasta que son usados. En todosnuestros experimentos los bloques se cargan en Mc. Además, usamos una Victim Cachepara evitar el problema de la polución. Las prebúsquedas se lanzan con Dp=Ds, y se-gún los resultados obtenidos no parece necesario retrasar ni adelantar este lanzamien-to.

El análisis de coste concluye que los mecanismos LSC son muy caros en área, muchomás que el secuencial. Una tabla de 512 entradas ocupa un espacio similar al de unacache de datos de 8 KB.

La prebúsqueda LSC genera mayor número de prebúsquedas que el secuencial, sobre-cargando la cache de datos. Sin embargo, genera menos fallos y por tanto menos peti-ciones al siguiente nivel de la jerarquía. Para conseguir tasas de fallos y CPI de datosmenores que los de secuencial, un mecanismo LSC requiere una tabla de al menos 128entradas. El aumento medio en prestaciones es modesto y no parece justificar el altocoste de este mecanismo. Sin embargo, en algunos programas la mejora conseguida esconsiderable, por lo que parece prematuro desecharlo definitivamente.

3.7 Referencias

[BC91] J.L. Baer and T.F. Chen. “An Effective On-chip Preloading Scheme to Reduce Data Access Penal-ty”. In Supercomputing 91, pp.176-186, 1991.

[CB95] T.F. Chen and J.L. Baer. “Effective Hardware-Based Data Prefetching for High-Performance Pro-cessors”. IEEE Transactions on Computers, Vol. 44 No. 5, May 1995, pp. 609-623.

[CK94] B. Cmelik and D. Keppel,"Shade: A Fast Instruction-Set Simulator for Execution Profiling". Proc.of ACM SIGMETRICS Conf. on Measurement and Modeling of Comp. Systems, May 1994,pp.128-137.

[DDS93] F. Dahlgren, M. Dubois and P. Stenström, “Fixed and Adaptive Sequential Prefetching in Shared-Memory Multiprocessors”, Proc. 1993 Int´l Conf. Parallel Processing, CRC Press, Boca Ratón,Fla., 1993, pp. 156-163.

[DDS95] F. Dahlgren, M. Dubois and P. Stenström, “Sequential Hardware Prefetching in Shared-MemoryMultiprocessors”, IEEE Trans. Parallel and Distributed Systems, July 1995, pp. 733-746.

[DS95] F. Dahlgren and P. Stenström, “Effectiveness of Hardware-Based Stride and Sequential Prefetch-ing in Shared Memory Multiprocessors”, Proc. first IEEE Symp. High-Performance ComputerArchitecture, IEEE CS Press, Los Alamitos, Calif., 1995, pp. 68-77.

[FPJ92] J.W.C. Fu, J.H. Patel and B. L. Janssens. “Stride Directed Prefetching in Scalar Processors”. InProc. of 25th Int. Symp. on Microarchitecture (MICRO-25), ACM, pp.102-110, December 1992.

[JG97] D. Josephand D. Grunwald, “Prefetching Using Markov Predictors“, Proc. of 24th Int. Symp.Computer Architecture, pp.252-263, June 1997.

Referencias


[Jou90] N.P. Jouppi. “Improving Direct-Mapped Cache Performance by the Addition of a Small Fully-associative Cache and Prefetch Buffers”. In Proc. of 17th Int. Symp. on Comp. Architecture,pp.364-373, May 1990.

[JT93] Y. Jegou and O. Temam. “Speculative Prefetching”. Proc. of ICS-93, pp.1-11, December 1992.

[MH96] S. Mehrotra and L. Harrison. “Examination of a Memory Access Classification Scheme for Point-er-Intensive and Numeric Programs”. Proc. of ICS-96, pp.133-140, 1996.

[O+95] T. Ozawa Y. Kimura and S. Nishizaki, “Cache miss heuristics and preloading techniques for gen-eral-purpose programs“. Proc. 28th Int. Symp. Microarchitecture, IEEE CS Press, Los Alamitos,Calif., 1995, pp. 243-248.

[PG95] V. Phalke and B. Gopinath. "A Miss History-based Architecture for Cache Prefetching". Interna-tional Workshop Memory Management, Lecture Notes in Computer Science, Vol. 986, pp. 381-398. Springer-Verlang, Sept. 1995.

[PK94] S. Palacharla and R.E. Kessler, “Evaluating Stream Buffers as secondary cache replacement“,Proc. of 21th Int. Symp. Computer Architecture, IEEE CS press, Los Alamitos, Calif., pp.24-33,April 1994.

[Smi78] A.J. Smith. “Sequential Program Prefetching in Memory Hierarchies”. IEEE Computer 11,12. pp7-21, December 1978.

[Smi82] A.J. Smith. “Cache Memories”. Computing Surveys, 14(3):473-530, September 1982.

[TE95] D.M. Tullsen and S.J. Eggers,"Effective Cache Prefetching on Bus-Based Multiprocessors". ACMTransactions on Computer Systems, Vol. 13, No. 1, February 1995, pp. 57-88.

[Ueb97] Christoph W. Ueberhuber. “Numerical computation. Methods, software and analysis”. Volumen 2.Springer-Verlag, Berlin Heidelberg, 1997.

[WL97] S. VanderWiel and D.J. Lilja. “When Caches Aren´t Enough: data prefetching techniques”. IEEEComputer, Vol. 30, No. 7, july 1997, pp. 23-30.


C A P Í T U L O 4

Prebúsqueda Hardware de Datos de Bajo Coste

El análisis de coste y prestaciones realizado en el capítulo anterior indica que los nue-vos mecanismos de prebúsqueda son mucho más caros que el secuencial y ofrecen in-crementos de prestaciones modestos en el contexto de una carga de trabajorepresentativa del procesado simbólico y numérico. En este capítulo se realiza una ca-racterización de los programas buscando las causas del pobre resultado obtenido conlos mecanismos basados en tablas de ld/st.

Tras la caracterización se proponen y analizan dos mecanismos alternativos de bajo cos-te. Ambos combinan un mecanismo nuevo con la prebúsqueda secuencial. El objetivode ambos es mantener las prestaciones del mecanismo secuencial en los programas quesiguen este patrón (la mayoría), y conseguir mejoras significativas en los que siguen pa-trones de stride constante o recorrido de listas.

Como resultado se consiguen dos mecanismos capaces de conseguir prestaciones simi-lares a los basados en tablas de ld/st pero con un coste mucho menor.

4.1 Introducción

En el capítulo anterior se ha puesto de manifiesto que en los últimos años se han pro-puesto bastantes mecanismos de prebúsqueda hardware de datos. Muchos de ellos in-tentan superar la prebúsqueda secuencial analizando nuevos patrones de acceso. Sinembargo, la última generación de procesadores no incorpora ninguno de estos meca-nismos, y sólo alguno de ellos implementa prebúsqueda secuencial.

El análisis de coste y prestaciones realizado en el capítulo anterior explica este hecho:los nuevos mecanismos de prebúsqueda son mucho más caros que el secuencial y ofre-cen incrementos de prestaciones modestos (o altos pero en muy pocas aplicaciones). Noparece razonable invertir un área equivalente a la de la cache de primer nivel para con-



seguir incrementos de prestaciones apreciables sólo en un pequeño grupo de progra-mas.

En este capítulo se estudian dos mecanismos alternativos de bajo coste, capaces de con-seguir parecidas prestaciones en los pocos programas que lo permiten, pero con uncoste mucho más reducido. Empezaremos caracterizando la carga de trabajo con dosobjetivos: i) explicar el bajo rendimiento de la prebúsqueda no secuencial y ii) buscarcaracterísticas que permitan nuevas propuestas. Después se presentan y analizan losdos nuevos mecanismos. El primero, totalmente distinto a los existentes, se basa en elanálisis dinámico de los códigos de operación y de los registros usados para calculardirecciones. El segundo, mejora de la prebúsqueda mediante tabla de load/stores, me-diante la eliminación en la tabla de las instrucciones que no aportan prebúsquedas úti-les.

4.2 Caracterización

Para que un mecanismo de prebúsqueda mediante tabla de ld/st pueda sacar benefi-cio por almacenar un cierto ld/st se deben dar las condiciones siguientes:

• C1. Que la instrucción ld/st permanezca en LSC un cierto periodo de tiempo, yaque son necesarias varias ejecuciones de la instrucción para detectar su patrón deacceso.

• C2. Que la instrucción ld/st acceda a memoria con un cierto patrón regular, quepertenezca al conjunto de los detectados por el mecanismo.

• C3. Que los datos accedidos por la instrucción ld/st no estén en cache, ya que de locontrario la prebúsqueda sería innecesaria.

En los siguientes subapartados pondremos de manifiesto los problemas que presenta eluso de una LSC típica, tal como ha sido formulada hasta ahora. Veremos que los tama-ños usados son insuficientes aun ocupando mucho espacio, que los ld/st que cumplenlos patrones detectados son muy pocos, y que la mayoría de los ld/st almacenados enla LSC nunca provocan fallos y por tanto es inútil guardarlos [IVB+98]. Antes presenta-mos la carga de trabajo que hemos usado y la metodología de traceo.

4.2.1 Metodología y carga de trabajo

En todos los experimentos de este capítulo se utiliza la misma carga de trabajo presen-tada en el capítulo anterior, apartado 3.5.3.

Para los datos presentados en el este apartado hemos simulado 2000 Minst. consecuti-vas a partir del final de la etapa transitoria. Los benchmarks que ejecutan en total menosde 2000 Minst. han sido simulados en su totalidad.

Caracterización


4.2.2 Fallos en LSC

Se define la tasa de fallos en LSC como:

mLS = (#fallos en LSC) / N

donde N es el número de referencias, y un fallo se produce cada vez que la dirección (elContador de Programa) de una instrucción ld/st no es encontrada en LSC. Esta tasa defallos está relacionada con la condición C1, ya que el número de veces en media queuna instrucción ld/st se ejecuta antes de ser expulsada de LSC es el inverso de mLS.

En la Tabla 4.1 presentamos valores de mLS para tamaños de LSC entre 16 y 8192 entra-das con mapeo directo. La tabla muestra los valores medios de mLS para las tres cargasde trabajo: Perfect, Spec95-int y Spec95-fp. Si analizamos el comportamiento individualde los benchmarks vemos que para conseguir una tasa de fallos menor del 10% son nece-sarias al menos 1024 entradas en 10 de los 25 benchmarks. Con LSCm=10%, un ld/stpermanece en LSC durante 10 instancias consecutivas en media. Cada vez que la ins-trucción es expulsada, son necesarias tres ejecuciones para detectar un patrón. Duranteeste tiempo no se generan prebúsquedas.

A pesar de que no conocemos la relación entre mLS y la reducción del tiempo efectivode acceso debido a prebúsqueda, los datos que acabamos de analizar sugieren un nú-mero de entradas en LSC mayor que el usado en otros trabajos [BC91, FPJ92, JT93,MH96].

4.2.3 Patrones de acceso

Incluso suponiendo un comportamiento ideal de LSC (mLS=0), es necesaria la presen-cia de algún patrón regular de acceso para que actúe el mecanismo de prebúsqueda(condición C2). En este apartado se analiza la carga de trabajo buscando los 5 patronesde acceso para los que se han descrito métodos hardware de detección. Se estudia cadald/st del programa comparando las direcciones que lanza en ejecuciones consecutivasy clasificando cada uno de sus accesos según el patrón que cumple:

1. ESCalar: ai = ai-1

2. SECuencial: ai = ai-1 + s ; 0 < s < Bsize

3. STRide: ai = ai-1 + S ; S > Bsize || S < 0

4. lista DIReccion: ai = di-1 + Desp Desp es un desplazamiento en un registro

Tabla 4.1 Tasa de fallos en LSC en función de su número de entradas.

16 32 64 128 256 512 1024 2048 4096 8192

PERFECT 79.7 63.8 45.4 32.6 23.8 16.6 7.4 2.7 1.6 0.4

SPEC95-int 64.3 50.3 39.2 27.1 17.8 10.9 6.4 3.5 1.6 0.6

SPEC95-fp 62.7 43.0 23.8 16.6 14.1 11.5 8.8 6.7 4.1 1.8



5. lista INDice: ai = 4 * di-1 + IV ; 4 = tamaño del entero índiceIV = dirección base del vector de índices

ai es la dirección lanzada por un ld/st en su ejecución i. di es el dato leido por un loaden su ejecución i, y Bsize es el tamaño de bloque. Las instrucciones store sólo puedenseguir los tres primero patrones.

Los grupos presentados en la Tabla 4.2 son disjuntos. Si una instrucción ld/st cumplevarios patrones en una misma instancia se clasifica según el patrón que viene cum-pliendo en las instancias precedentes. Si cumple constantemente varios patrones se leclasifica según una prioridad predefinida: escalar, lista (por dirección o índice) y stride(secuencial o no). Cuando una instrucción individual inicia una ráfaga de accesos qu si-guen un patrón cualquiera, las primeras referencias (en las cuales no puede determi-narse todavía patrón) se acumulan a posteriori en dicho patrón. Toda referencia quequeda fuera de los 5 patrones engrosa la columna "sin patrón".

Tabla 4.2 Clasificación de accesos segun su patrón, con Bsize = 32.

PERFECT ESC SEC STR DIR IND SIN-PATRON

QCD lg 51.67 20.33 1.8 0.05 0.14 26.01

MDG lw 46.18 27.25 3.65 0 0 22.92

BDNA na 69 23.07 5.12 0.02 0.03 2.76

ARC2D sr 20.33 46.62 28.11 0 0.04 4.9

FLO52 tf 14.33 71.38 5.01 0 0 9.28

TRFD ti 4.9 44.38 20.83 0 0 29.89

SPEC95-int

go 31.62 3.52 1.45 0.08 3.87 59.46

gcc 35.42 14.8 1.45 1.33 1.01 45.99

compress 63.98 11.54 5.24 0.17 0.01 19.06

ijpeg 19.61 49.01 4.02 2.42 0.55 24.39

xlisp 37.62 7.86 5.16 4.08 0.14 45.14

m88ksim 30.49 47.66 0.14 0.07 0.6 21.04

perl 40.8 2.42 1.43 2.04 0.04 53.27

vortex 67.87 4.31 0.33 0.08 0.91 26.5

SPEC95-fp

applu 30.86 13.83 34.35 0 0 20.96

apsi 39.87 45.71 9.6 0 0.02 4.8

fpppp 98.65 0.25 0.06 0 0 1.04

hydro2d 12.12 87.6 0.05 0 0 0.23

Caracterización


La mayoría de los accesos son escalares o secuenciales, muy pocos siguen patrones destride o listas encadenadas y estos aparecen muy concentrados en unos pocos bench-marks. El porcentaje de los no clasificados (SIN-PATRON) es muy variable y se concen-tra sobre todo en los programas de enteros. Estos usan algunas estructuras de datoscuyos patrones de acceso no detectamos, como arboles o tablas hash.

La mayoría de los estudios precedentes muestran un número muy alto de accesos detipo stride, pero es debido a que clasifican los accesos secuenciales como un caso parti-cular de stride (con s < Bsize). Una excepción es [DS95], donde se estudian por separa-do los accesos secuenciales y los de stride en programas pertenecientes a SPLASH-I yen un entorno multiprocesador. Las distribuciones observadas en ese trabajo son simi-lares a las encontradas por nosotros para SPEC95 y Perfect Club.

El frecuente patrón secuencial, al ser considerado caso particular de patrón stride, ase-gura la utilidad de una LSC preparada para detectar strides. Sin embargo, laprebúsqueda secuencial es mucho más simple y barata como ya hemos comentado.

Por otra parte, prebuscar escalares es inútil cuando las prebúsquedas se lanzan acce-diendo a LSC con el Contador de Programa real. No tiene sentido lanzar una peticiónpor demanda y otra por prebúsqueda sobre la misma dirección de bloque y en el mis-mo momento. Sí tendría sentido al lanzar las prebúsquedas con un PC adelantado(LA-PC en los trabajos de Chen y Baer[BC91]).

En resumen, el objetivo de la LSC debería ser únicamente descubrir los patrones strideno secuencial y lista. La suma de todos ellos (columnas STR, DIR e IND) es pequeñapero significativa: los valores medios para Perfect, SPEC95int y SPEC95fp son 10,8%,4,6% y 8,35 respectivamente. Sin embargo, en algunos programas es mucho más alta laproporción de los accesos que cumplen estos patrones (ARC2D, TRFD, applu,spice2g6), y en ellos se puede obtener un alto beneficio de este tipo de prebúsqueda.

4.2.4 Correlación entre frecuencias de ejecución y de fallo

Mediante un mecanismo basado en LSC un ld/st lanza prebúsquedas sobre datos parasu propio consumo, que él mismo necesitara en su próxima ejecución. Es inútil por tan-to guardar en LSC un ld/st que nunca falla, ya que intentará prebuscar datos que ya

mgrid 18.11 78.5 0.25 0 0 3.14

spice2g6 33.44 2.79 5.73 0.08 21.17 36.79

su2cor 19.73 74.14 0.15 0 2.34 3.64

swim 0.02 99.21 0.08 0.02 0.29 0.38

tomcatv 31.06 66.8 0.17 0.05 0.01 1.91

turb3d 29.67 56.63 6.23 0 0.24 7.23

wave5 21.96 63.03 9.32 0 1.15 4.54

Tabla 4.2 Clasificación de accesos segun su patrón, con Bsize = 32.



están en cache (y fallará la condición C3). La LSC será más efectiva cuanto más fallos

provoquen los ld/st que almacena, el ideal seria guardar en LSC los ld/st que más fa-

llos provocan en cada fase del programa.

En los mecanismos propuestos hasta el momento, la inserción de un ld/st en la tabla

se realiza cada vez que éste se ejecuta. Podemos llamar a este método de inserción in-

serción always. Con este método, y en ausencia de conflictos, la probabilidad de que un

ld/st se encuentre en LSC es proporcional a la frecuencia de ejecución de dicha ins-

trucción. Sin embargo, la frecuencia de ejecución puede no ser igual a la frecuencia de

fallo, es decir, puede ocurrir que el conjunto de ld/st que estamos guardando en cache,

el de mayor frecuencia de ejecución, no coincida con el conjunto de los más falladores,

del que sacaríamos el mayor beneficio.

Para analizar la correlación entre frecuencia de ejecución y frecuencia de fallo hemos

seleccionado en nuestros benchmarks los dos conjuntos, el de las instrucciones ld/st

que más se ejecuta y el de las que más falla. Para la selección del conjunto que más falla

hemos simulado una cache de 8KBytes, mapeo directo y bloques de 16 bytes, añadien-

do prebúsqueda secuencial para eliminar los ld/st que dejarian de fallar si ese meca-

nismo existiera. Hemos ordenado todos los ld/st de cada benchmark segun su numero

de ejecuciones por un lado y segun su numero de fallos por otro. En cada una de las lis-

tas ordenadas hemos cogido de la cabeza los ld/st necesarios para completar el 90% de

los accesos en la primera y el 90% de los fallos en la segunda.

Tras la creación de estos dos conjuntos podemos clasificar las instrucciones ld/st en

cuatro clases disjuntas:

• Clase A: Ld/st que no aparecen en ninguna de las dos listas. No son importantes ni

en cuanto a número de veces que se ejecutan ni en cuanto a fallos que provocan.

• Clase B: Ld/st que pertenecen a la lista de los más ejecutados pero no a la de los

que más fallos provocan.

• Clase C: Ld/st que pertenecen a la lista de los que más fallos provocan pero no a la

de los más ejecutados.

• Clase D: Ld/st que pertenecen a las dos listas. Son los más importantes tanto en

número de veces que se ejecutan como en número de fallos que provocan.

Las instrucciones que deseamos guardar en LSC pertenecen a las clases C y D. Sin em-

bargo, las instrucciones que realmente ocupan la LSC son las de las clases B y D. En la

Tabla 4.3 puede observarse como B∪D es mucho mayor que C∪D, en un factor 5, 2 y

5,4 para Perfect, SPEC95int y SPEC95fp respectivamente.

Prebúsqueda mediante análisis de código


Los ld/st de la clase C tienen una baja frecuencia de ejecución, y por tanto una bajaprobabilidad de estar en LSC. Sin embargo producen una gran cantidad de fallos y portanto seria bueno que estuviesen en LSC. Sobre el total de las instrucciones que provo-can muchos fallos (C∪D) suponen en media el 25%.

Por el contrario, los ld/st de la clase B tienen una alta frecuencia de ejecución, por loque es alta la probabilidad de que ocupen un lugar en LSC, sin embargo casi no provo-can fallos, es inutil guardarlos. En media, estas instrucciones suponen el 78,6% de lasmás ejecutadas (B∪D).

4.3 Prebúsqueda mediante análisis de código

En este apartado y el siguiente se presentan dos mecanismos que pretenden conseguirprestaciones similares a la prebúsqueda LSC, reduciendo en lo posible el área necesariapara implementarlos.

Los mecanismos basados en LSC detectan patrones regulares en el acceso a datos ob-servando la secuencia de direcciones que lanza el procesador. Este mecanismo los de-tecta observando el código que ejecuta el procesador. Empezaremos analizando quécódigo se ejecuta para generar un cierto patrón, luego veremos como detectarlo y porúltimo estudiaremos el coste y las prestaciones de una posible implementación.

4.3.1 Patrones en el código

Supongamos una arquitectura con un único modo de direccionamiento para datos queconsiste en calcular la dirección de memoria como la suma de un registro base y undesplazamiento codificado en la propia instrucción ld/st.

ld %Rd, [ %Rb + desp ]

donde %Rd es el número de registro destino del dato, %Rb es el número del registrobase usado para el cálculo de la dirección y desp es el desplazamiento.

Tabla 4.3 Clasificación de las instrucciones ld/st individuales según sus frecuencias de ejecución y de fallo en una cache de datos de 8KB, mapeo directo y tamaño de bloque 16.

A B C D

10% 90%ejec. 90%ejec90%fallos 90%fallos

Perfect Club 7271 1125 194 71

SPEC95int 5366 588 328 121

SPEC95fp 1407 635 118 21



El recorrido regular de cualquier estructura de datos siempre se basa en la ejecución re-petida de una o varias instrucciones de este tipo. Entre dos ejecuciones consecutivas deun mismo ld/st se ejecutan las instrucciones necesarias para modificar el registro usa-do en el cálculo de la dirección (Rb), de acuerdo con el patrón deseado. La actualiza-ción de Rb suele ser una tarea muy sencilla, a menudo se consigue con la ejecución deuna sola instrucción. Sin embargo, en otros casos se llega a la generación del mismo pa-trón tras un cálculo complejo, más dificil de identificar. A continuación se analiza el có-digo más sencillo necesario para generar cada uno de los patrones de accesopresentados en el capítulo anterior. En este análisis se basa el mecanismo deprebúsqueda que se presenta en este apartado.

– Escalares: El registro de dirección no se modifica entre dos ejecuciones consecu-tivas del ld/st.

– Secuenciales y stride constante: Se suma una constante al registro de direcciónentre dos ejecuciones consecutivas del ld/st. Aparecerá una estructura del ti-po:

bucle1: ––––––

load %Rd, [%Rb+desp]

––––––

add/sub %Rb, Const_stride, Rb

––––––

jump bucle1

donde Rb es un registro que interviene en el cálculo de la dirección de una in-strucción ld/st que aparece en el mismo bucle. Const_stride puede ser un val-or codificado en la propia instrucción add/sub o residir en un registro. El valorde Const_stride determina si el patrón es secuencial o de stride constante.

– Recorrido de listas encadenadas por dirección: El valor leido por una instruc-ción load en una iteración se usa en la siguiente en el cálculo de la dirección delmismo load. A este valor se le suma una constante. Hay muchas formas de im-plementar este recorrido, la más sencilla consiste en usar el mismo registrocomo destino del load y como base para el cálculo de su dirección:

bucle2: ––––––

ld %Rb, [%Rb+desp]

––––––

jump bucle2



– Recorrido de vectores de índices encadenados: El valor leido por una instruc-ción load en una iteración se usa en la siguiente en el cálculo de la dirección delmismo load. El valor se multiplica por una constante igual al tamaño de uníndice y se le suma otra constante que es la dirección inicial del vector. Hay mu-chas formas de implementar este recorrido, la más sencilla consiste en usar elmismo registro como destino del load y como base para el cálculo de su direc-ción. Además, en el mismo bucle aparecerá un instrucción para realizar la mul-tiplicación sobre el mismo registro:

bucle3: ––––––

ld %Rb, [%Rb+desp]

––––––

sll %Rb, 2, %Rb ; desplaza Rb dos posiciones a la izquierda

––––––

jump bucle3

desplazar Rb dos posiciones a la izquierda equivale a multiplicarlo por 4, quesuponemos es el tamaño del índice.

– Recorridos irregulares o con otros patrones: durante el resto del bucle, algunainstrucción modifica Rb de forma distinta a las expuestas anteriormente.

4.3.2 SPAR

SPAR (Stride Pattern in Address Register) es un mecanismo para la detección de patro-nes mediante análisis de código. Analiza las operaciones que se realizan sobre los regis-tros usados en instrucciones ld/st, y mantiene una tabla (Register Stride Table, RST)que asocia a cada registro dos estados, uno para detectar recorridos con stride constan-te y otro para detectar recorridos de listas. Los estados de un registro se actualizan se-gún las operaciones que se realizan sobre él.

En la Figura 4.1 se muestra el diagrama de estados usado para la detección de recorri-dos con stride constante. Cada registro se encuentra en uno de estos estados, y cambiacuando aparece en una instrucción como registro destino o cuando se produce un salto haciaatrás tomado. Este diagrama intenta detectar bucles similares a bucle1, caracterizadospor la presencia de una instrucción ld/st, una add y un salto hacia atrás tomado. Si unregistro Ri se está usando en un recorrido de este tipo su estado variará entre PREF1 yPREF2 tras un pequeño periodo transitorio. Cada vez que pase por la instrucción add seguardará en RST el valor sumado al registro (el stride). Al ejecutar una instrucción ld/st, si el registro usado para el cálculo de la dirección está en alguno de esos dos esta-dos, se lanzará una prebúsqueda sumando a la dirección actual el valor almacenado en RST.



Figura 4.1 SPAR: diagrama de estados para la detección de recorridos con stride constante.

En la Figura 4.2 se muestra el diagrama de estados usado para la detección de recorri-dos de listas. Este diagrama intenta detectar bucles similares a bucle2 y bucle3, caracte-rizados por la presencia de una instrucción load cuyo registro destino se usa comofuente para el cálculo de dirección. Si aparece una instrucción de este tipo, su registropasa a estado DIR y se almacena en RST el valor leido por la instrucción. El registropermanece en este estado mientras otra instrucción no lo use como registro destino.Cada vez que se ejecute la instrucción load se lanzará una prebúsqueda calculada co-mo:

âi+1 = di + Despi

donde Despi se calcula como:

Despi = ai - di-1

Si un registro clasificado como DIR se desplaza dos posiciones a la izquierda, el registropasa al estado IND. Cada vez que se ejecute la instrucción load se lanzará unaprebúsqueda calculada como:

âi+1 = IVi + di * Isize

donde IVi se calcula como:

IVi = ai - di-1 * Isize

tal como se describe en el capítulo anterior.

INI

TRAN1

TRAN2

PREF1PREF2

add

no salto

salto

no add

add

salto

add

no saltono add



Figura 4.2 SPAR: diagrama de estados para la detección de recorridos de listas.

4.3.3 Análisis de coste de SPAR

La Register Stride Table necesita tantas entradas como registros tiene el procesador. Ennuestro caso, SPARC posee un banco físico de registros de tamaño variable y organiza-do en ventanas, del que sólo son visibles 32 registros en cada momento. Para simplifi-car la implementación nuestra tabla sólo tiene 32 entradas, y no se actualiza con loscambios de ventana activa (instrucciones SAVE y RESTORE). Por tanto, ocasionalmentesus contenidos no son coherentes y dan lugar a prebúsquedas erróneas.

Su implementación requiere una tabla de 32 entradas, que almacena el valor de stride yel de desplazamiento asociados a cada registro y cinco bits de estado. Usa además unsumador para el cálculo de la dirección a prebuscar. Este sumador debe ser capaz desumar tres valores, por lo que usaremos un sumador CSA como etapa previa. No es ne-cesario hardware adicional para la decodificación de las instrucciones puesto que sepuede usar la información generada por el propio decodificador del procesador.

Si comparamos con el coste de un mecanismo LSC convencional con 512 entradas,SPAR emplea una tabla con 4 veces menos entradas y cada una de ellas requiere sólo8bytes y 5 bits en lugar de 24 bytes. Además LSC usa 4 sumadores mientras SPAR sólouno. Las dos tablas necesitan doble puerto.

4.3.4 Análisis de prestaciones de SPAR

Salvo que se diga lo contrario evaluamos prestaciones sobre el sistema de referenciapresentado en el capítulo anterior (cache de datos de 32 KB, mapeo directo y bloque de

INI

ld %Rb, [%Rb+desp]

sll %Rb, 4 %Rb

ld %Rb, [%Rb+desp]sll %Rb, 4 %Rb

ld %Rb, [%Rb+desp]

DIR

IND

otros

otros



32 bytes).Dado que la mayoría de los benchmarks que usamos no trabaja con strides nilistas vamos a estudiar por separado el comportamiento de los algoritmos deprebúsqueda ante los benchmarks que usan strides y listas y los que no lo hacen. El obje-tivo de nuestro mecanismo es, con muy bajo coste añadido al mecanismo secuencialclásico, mejorar las prestaciones en los benchmarks que siguen el patrón y no molestaren el resto.

De los datos del apartado 4.2 deducimos que sólo cuatro programas entre los 25 anali-zados trabajan con strides y listas de forma intensiva:

SPEC92: spice (21,2%: patrón INDice)

SPEC95: APP (33.5%: patrón STRide)

PERFECT: ARC2D (30.3%: patrón STRide) y TRFD (37.1%: patrón STRide)

En laFigura 4.3 se presentan los datos medios para los 4 programas citados, consegui-dos por varios mecanismos de prebúsqueda conectados a una cache de 32 KB. La pri-mera barra empezando por abajo representa los datos de un sistema sin prebúsqueda.La segunda los de un sistema con OBLst. La tercera SPAR + OBLst. La más alta corres-ponde a un sistema con LSC de 512 entradas.

Figura 4.3 Comparación para los cuatro benchmarks que exhiben comportamientos de stride y lista, de varios sistemas: sin prebúsqueda, con prebúsqueda secuencial (OBLst), con SPAR + OBLst, y con prebúsqueda LSC de 512 entradas.

Como vemos en la figura, el primer objetivo se puede considerar cumplido: para estegrupo de programas, al añadir SPAR a OBLst disminuye la tasa de fallos en un 27,2% y

0,190

0,160

0,189

0,294

52,0

15,8

8,0

0,0

810 44 0Prebúsquedasinútiles




δ / N D / N md mf

% P/N CPI de datos

LSC 512

OBLst

No prebúsqueda

SPAR + OBLst



el data CPI un 19,7%. Como efectos negativos, aumenta mucho la presión sobre lacache de primer nivel (P) y un poco sobre el siguiente nivel de la jerarquía (B).

Si comparamos los datos de SPAR+OBLst con los de una LSC de 512 entradas,SPAR+OBLst mejora tanto la tasa de fallos (6,5% menos) como el data CPI (20,4% me-nos). La presión sobre la cache de datos también es mucho menor. Sólo aumenta la pre-sión sobre el siguiente nivel de la jerarquía.

Los datos para el resto de programas se muestran en la Figura 4.4. Se presentan por se-parado las medias de todos los programas pertenecientes a SPEC-fp, SPEC-int y PerfectClub, sin considerar a los cuatro programas seleccionados anteriormente.



Figura 4.4 Comparación para el resto de los benchmarks que no tienen un comportamiento destacado de stride y lista, de varios sistemas: sin prebúsqueda, con prebúsqueda secuencial (OBLst), con SPAR + OBLst, y con prebúsqueda LSC de 512 entradas

% P/N CPI de datos

0,058

0,077

0,078

0,234

67,5

7,0

6,4

0,0

36,6

4,0

2,4

0,0

0,048

0,024

0,023

0,113

18,3

6,6

4,0

0,0

0,078

0,087

0,087

0,091

844 08

422 04

633 06





δ / N D / N md mf

LSC 512

OBLst

No prebúsqueda

SPAR + OBLst

LSC 512

OBLst

No prebúsqueda

SPAR + OBLst

LSC 512

OBLst

No prebúsqueda

SPAR + OBLst

SPEC95fp

Perfect

SPEC95int

Prebúsqueda LSC con inserción on-miss


Como se esperaba, en los programas sin patrones distintos al secuencial, las prestacio-nes de SPAR + OBLst son similares a las de OBLst. Sólo en SPEC95-int se consigue unamejora significativa (11,4% menos fallos y 10,2% menos dataCPI).

En cuanto a la comparación con LSC-512, SPAR+OBLst es muy parecida en SPEC95-int,peor en SPEC95fp y mejor en Perfect Club. Aunque las diferencias relativas en estasdos últimas cargas de trabajo son muy grandes, pierden importancia si miramos susvalores absolutos, ya que los dos mecanismos son muy eficientes eliminando fallos.

Experimentos adicionales no presentados en este trabajo muestran que con tamaños de8KB y 128KB se obtienen resultados parecidos, lo cual indica la insensibilidad de lacomparación frente al tamaño de cache.

4.4 Prebúsqueda LSC con inserción on-miss

La caracterización del apartado 2 parece indicar que el bajo rendimiento de los meca-nismos LSC se debe a un mal uso de la tabla. La LSC debe almacenar muchas instruc-ciones ld/st pero la mayoría de estas instrucciones nunca llegan a lanzarprebúsquedas útiles. Además, la mayoría de las que sí lanzan prebúsquedas útiles lohacen siguiendo un patrón secuencial.

El objetivo del mecanismo presentado en este apartado es aumentar el rendimiento deuna LSC filtrando las instrucciones ld/st que debe almacenar. Consiste en la combina-ción de dos mecanismos: a) prebúsqueda LSC con inserción on-miss, LSCmi [IVB+98],y b) prebúsqueda secuencial marcada (OBLst) [Smi82].

4.4.1 Inserción on-miss

La actualización de una LSC típica se realiza de la siguiente manera: cada vez que seejecuta un ld/st se lanza una búsqueda sobre LSC indexando con el contador de pro-grama. Si la instrucción es encontrada se actualizan los campos de su entrada en la ta-bla para reflejar el nuevo estado, tras la nueva ejecución. Si la instrucción no seencuentra en la tabla, se añade a ella, expulsando a otra instrucción para hacerle hueco.

Bajo inserción on-miss se realiza la búsqueda de la misma manera. Si la instrucción seencuentra en LSCmi se mantiene igualmente la información modificando los camposnecesarios. En caso de no encontrarse sólo se añadirá el ld/st a LSCmi (reemplazandoa otro ld/st) si el acceso a cache ha producido un fallo.

De esta manera la probabilidad de que una instrucción ld/st se encuentre en LSCmiserá proporcional al número de veces que dicha instrucción falle, y no al número de ve-ces que la instrucción se ejecute. Si dos o más ld/st compiten por un mismo conjuntoen LSCmi, las que aciertan en cache se eliminan de la competición, aumentando la esta-bilidad de las que fallan. Si una sola instrucción intenta ocupar un conjunto, lo conse-guirá la primera vez que falle y nunca lo abandonará.



Como vimos en el apartado 4.2.3 el patrón secuencial es con mucha diferencia el máscomún en el acceso a datos. Su prebúsqueda es muy sencilla y eficiente, no requiriendoel uso de una estructura tan cara como la LSCmi. Al añadir prebúsqueda secuencialbuscamos la eliminación de todos los ld/st que siguen este patrón de la competiciónpor la LSCmi. El uso de prebúsqueda secuencial unido a la inserción on-miss nos per-mitirá jugar con tamaños de LSCmi mucho menores que los usados hasta el momento,consiguiendo parecidos resultados. Por otra parte, si existen relaciones secuenciales en-tre direcciones lanzadas por distintos ld/st (debido a la localidad espacial es muy pro-bable), un mecanismo LSCmi no será capaz de descubrirlas, mientras OBLst generaráprebúsquedas para ellas.

Como ejemplo se puede pensar en una lista encadenada de structs de tamaño mayorque el bloque de cache. El load que realiza el recorrido siguiendo los punteros será cla-sificado por el detector correspondiente. Sin embargo, los loads que acceden a los res-tantes campos del struct no siguen un patrón regular. Sólo la prebúsqueda secuencial escapaz de prebuscar para ellos bajo ciertas condiciones.

En la Tabla 4.4 se presenta la probabilidad de que un ld/st provoque una expulsión alacceder a una LSCmi. Esta probabilidad es comparable con la mostrada en la tabla Ta-bla 4.1, en el sentido de que su inverso es el número medio de veces que una instruc-ción es ejecutada mientras permanece en LSCmi, sin ser expulsada. La diferencia entrelas dos tablas da idea de la estabilidad conseguida por el nuevo método; se pueden verdiferencias de entre uno y dos órdenes de magnitud.

4.4.2 Análisis de prestaciones de la inserción on-miss

Salvo que se diga lo contrario evaluamos prestaciones sobre el sistema de referenciapresentado en el capítulo anterior (cache de datos de 32 KB, mapeo directo y bloque de32 bytes).

En primer lugar comentamos las diferencias entre la prebúsqueda LSC convencional(Figura 4.5) y la prebúsqueda LSCmi (Figura 4.6). Los datos numéricos que citamoscomo ejemplo corresponden a SPEC95fp. Los programas de Perfect Club se comportande forma similar y los de SPEC95int siguen las mismas tendencias aunque cuantitativa-mente son menos sensibles a cualquier tipo de prebúsqueda.

Tabla 4.4 Probabilidad de expulsión de un ld/st en una LSCmi vs. número de entradas (expulsiones en una LSCmi dividido por el número de referencias a datos).

16 32 64 128 256 512 1024 2048 4096 8192

Perfect 1,64 1,09 0,61 0,30 0,19 0,09 0,06 0,03 0,01 0,00

specint 2,95 2,42 1,91 1,40 0,93 0,59 0,36 0,22 0,13 0,06

specfp 9,16 5,48 2,32 0,70 0,55 0,37 0,21 0,11 0,04 0,01



Figura 4.5 Prestaciones de una LSC convencional.

0,078

0,078

0,078

0,08

0,082

0,087

0,091

18,3

17,6

15,1

11,2

8,4

4

0

0,095

0,097

0,117

0,129

0,151

0,064

0,163

48,1

42,7

25,5

14,9

7

3,2

0

512

128

32

16

8

OBLst

No prebúsqueda

512

128

32

16

8

OBLst

No prebúsqueda

512

128

32

16

8

OBLst

No prebúsqueda

8 4 0 4 8

4 2 0 2 4

4 2 0 2 4

SPEC95fp

Perfect

SPEC95int

61,2

59,4

40,7

26,4

15

7,3

0

0,082

0,087

0,115

0,154

0,191

0,105

0,249





δ / N D / N md mf

% P/N CPI de datos



Figura 4.6 Prestaciones de una LSC con inserción on-miss.

En primer lugar podemos observar una gran disminución del número deprebúsquedas (P/N) para los tamaños grandes de LSCmi. Tomando como ejemploSPEC95-fp, con tamaños de 512 y 128 la inserción on-miss elimina en torno al 35% delas prebúsquedas, rebajando en la misma proporción la presión sobre el primer nivelde cache. Con LSC más pequeñas ocurre al contrario, el número de prebúsquedas au-

0,054

0,055

0,062

0,075

0,094

0,064

0,163

15,2

14,4

10,5

7,9

5,4

3,2

0

0,078

0,078

0,078

0,079

0,079

0,087

0,091

10,6

9,8

7,9

6,3

5,4

4

0

39,5

38,8

32,5

26,5

18,6

7,3

0

0,079

0,078

0,09

0,107

0,143

0,105

0,249

512

128

32

16

8

OBLst

No prebúsqueda

512

128

32

16

8

OBLst

No prebúsqueda

512

128

32

16

8

OBLst

No prebúsqueda

8 4 0 4 8

4 2 0 2 4

4 2 0 2 4

SPEC95fp

Perfect

SPEC95int





δ / N D / N md mf

% P/N CPI de datos



menta debido a que en el mecanismo convencional, la alta volatilidad de las entradasde LSCmi impide la generación de prebúsquedas.

Por otra parte, aumenta el número de fallos de prebúsqueda o peticiones de bloque alsiguiente nivel (B/N). Frente a LSCconv de los mismos tamaños el incremento es de0%, 4%, 20%, 52% y 82% para LSCmi de 512, 128, 32, 16 y 8 entradas respectivamente.Este aumento se debe a que la inserción on-miss favorece la permanencia en LSCmi delos ld/st que más fallos provocan.

En presencia de patrón regular los bloques prebuscados son útiles y por tanto disminu-ye la tasa de fallos. Sólo con una LSC de 512 entradas aumenta ligeramente la tasa defallos (el 0.8%), en los demás casos siempre disminuye, más cuanto menor es LSC:9,8%, 27,8%, 37,1% y 28,8% para LSC de 128, 32, 16 y 8 entradas.

En cuanto a las prestaciones globales, la prebúsqueda LSCmi siempre consigue mejorresultado que LSCconv, disminuyendo CPI de datos entre el 3,6% (LSCmi-512) y el30,5% (LSCmi-16). Como efecto lateral, disminuye la sensibilidad tanto de la tasa de fa-llos como del CPI de datos frente al tamaño de LSCmi.

4.4.3 Análisis de prestaciones: LSCmi + OBLst

Analizamos a continuación las prestaciones de un sistema con LSCmi y prebúsquedasecuencial marcada (OBLst) trabajando de forma concurrente. En la Figura 4.7 se pre-sentan los datos de este sistema, que serán comparados con los presentados en aparta-dos anteriores. Al eliminar los ld/st con patrón secuencial debería disminuirconsiderablemente la presión sobre LSC, aumentando su efectividad incluso con tama-ños pequeños. Empezaremos de nuevo analizando los datos de SPEC95fp.



Figura 4.7 Prestaciones de una LSC con inserción on-miss y prebúsqueda secuencial marcada.

En SPEC95fp, al añadir prebúsqueda secuencial aumenta ligeramente la presión sobrela cache de datos (P), pero sigue siendo mucho menor que con inserción always. ConLSCmi de 512-128 entradas se realizan en torno a un 25% menos de prebúsquedas quecon inserción always. En general aumenta mucho el número de prebúsquedas efectivas(B) respecto al sistema con inserción always, entre el 34% para LSCmi-512 y el 269%para LSCmi-8.

FP

INT

PC

512

128

32

16

8

OBLst

No prebúsqueda

512

128

32

16

8

OBLst

No prebúsqueda

512

128

32

16

8

OBLst

No prebúsqueda

0,08

0,079

0,08

0,082

0,083

0,105

0,249

45,1

44,4

39

33,3

26,7

7,3

0

0,081

0,081

0,081

0,081

0,081

0,087

0,091

13,1

12,4

10,7

9,2

7,9

4

0

0,055

0,055

0,056

0,058

0,059

0,064

0,163

15,4

14,7

11,8

9,9

8

3,2

0

8 4 0 4 8

4 2 0 2 4

4 2 0 2 4

SPEC95fp

Perfect

SPEC95int





δ / N D / N md mf

% P/N CPI de datos



La disminución de la tasa de fallos también es espectacular: entre el 21% para LSCmi-512 y el 70% para LSCmi-8. La reducción en data-CPI se encuentra entre el 2,4% paraLSCmi-512 y el 56% para LSCmi-8.

El resultado para Perfect Club es similar al de SPEC95fp. El de la carga entera es similarcualitativa pero no cuantitativamente, como muestra la Figura 4.7. El único hecho rese-ñable en esta última carga es el gran aumento de los bloques prebuscados y nunca usa-dos (δ), que se debe a la presencia de la prebúsqueda secuencial.

De nuevo, el hecho que mayor relevancia tiene para nosotros es que prácticamente des-aparece la sensibilidad de la tasa de fallos y el CPI de datos ante la reducción del tama-ño de LSC. Al pasar de 512 a 8 entradas la perdida de prestaciones es de sólo el 3.75%en CPI de datos para SPEC95fp.

Como muestra la Tabla 4.5 una LSC de 8 entradas con inserción on-miss y prebúsquedasecuencial consigue mejores valores en casi todas las métricas que una LSC convencio-nal de 512 entradas. Reduce la presión sobre la cache de datos (elimina el 56.5%), au-menta el número de prebúsquedas efectivas (28.7% más en B/N), y disminuye con ellola tasa de fallos (el 10.3%). Como único efecto negativo aparece una pérdida de preci-sión –D/(D+δ)– debido al uso de OBLst. Como resultado global, el data-CPI de los dossistemas es prácticamente el mismo, pero con un coste de la alternativa LSCmi 64 vecesmenor.

4.4.4 Resultado en programas con patrones regulares

Como vimos en el apartado de caracterización son pocos los programas que lanzan se-cuencias de direcciones con patrones distintos al secuencial. Los resultados de el apar-tado anterior pueden estar muy influenciados por este hecho. Por tanto, puede serinteresante estudiar las prestaciones del nuevo mecanismo en los pocos programas quesi siguen estos patrones.

En laFigura 4.8 se presentan los datos medios para el grupo de programas applu, apsi ywave5 de SPEC95-fp, spice de SPEC92 y arc2d y trfd de Perfect Club. En la gráfica dearriba aparecen los datos de LSCconv y en la de abajo los de LSCmi + OBLst. Todas lasobservaciones del apartado anterior siguen siendo ciertas. Las diferencias de prestacio-nes son aún mayores en favor de LSCmi + OBLst.

Tabla 4.5 Prestaciones de una LSC convencional de 512 entradas frente a las de una LSCmi de 8 entradas y prebúsqueda secuencial marcada

P/N B/N (A+a)/N data-CPI delta/N

LSCconv-512 61.2 5.86 1.72 0.082 0.978

LSCmi-8 + OBLst 26.7 7.54 1.54 0.083 0.785



Figura 4.8 Prestaciones de una LSC convencional (arriba), frente a una LSCmi y prebúsqueda secuencial marcada (abajo), sobre los programas: applu, apsi, wave5, spice, arc2d y trfd.

En laTabla 4.6 se muestran los datos medios, para el mismo grupo de programas, de unsistema con LSCconv de 512 entradas y los de uno con LSCmi de 8 entradas + OBLst.En data-CPI, el sistema con LSCmi-8 + OBLst consigue un tiempo un 14,5% menor queel convencional de 512 entradas.

FP

INT

512

128

32

16

8

OBLst

No prebúsqueda

512

128

32

16

8

OBLst

No prebúsqueda

0,165

0,169

0,192

0,207

0,232

0,172

0,289

56,7

50,4

31,5

20,4

13,6

7,7

0,0

0,078

0,078

0,078

0,08

0,082

0,087

0,091

33,4

32,2

27,6

24,2

21,1

7,7

0,0

8 4 0 4 8

4 2 0 2 4

LSCmi

LSCconv

+ OBLst





δ / N D / N md mf

% P/N CPI de datos

Ejecución superescalar y fuera de orden


Se han simulado otras configuracionescon caches de 8KB y 128KB cuyos resultados nose presentan. Las conclusiones son válidas para todos los tamaños, aunque la ventajade LSCmi + OBLst es mayor con caches más grandes. Por otra parte, también se han si-mulado mecanismos de lanzamiento de prebúsquedas mediante LA-PC, como en[BC91], con una distancia de prebúsqueda igual a 1,5 veces la latencia del siguiente ni-vel de la jerarquía. En este sistema aumenta la presión sobre cache debida aprebúsquedas (P/N), debido a que el mecanismo intenta prebuscar también los esca-lares. La ventaja de LSCmi + OBLst es aún mayor en estos sistemas, debido a que sonmuchas más las prebúsquedas que aciertan en cache y son eliminadas.

4.4.5 Análisis de coste de la inserción on-miss

La implementación de un mecanismo LSC con inserción on-miss es idéntica a la deLSC convencional. La única diferencia en coste viene dada por la diferencia de tamañosde la tabla.

Como hemos visto, una LSCmi de 8 entradas y OBLst consigue similares prestacionesa una de 512 entradas convencional. El coste de la tabla para LSCmi es por tanto 64 ve-ces menor que el de LSCconv. Los circuitos de control y aritmético son similares en losdos mecanismos. Por otra parte el de OBLst ya vimos que es despreciable.

4.5 Ejecución superescalar y fuera de orden

En este punto se hace necesaria de nuevo una reflexión sobre la validez de los nuevosmétodos de prebúsqueda al ser integrados en un procesador que lanza en desordenvarias instrucciones por ciclo.

Como comentamos en el capítulo 2, la ejecución fuera de orden es capaz de ocultar par-te de la latencia en el acceso a la jerarquía de memoria. Es por tanto una política quetrabaja en el mismo sentido que la prebúsqueda. Si fuese capaz de ocultar por completola latencia de fallo desaparecería la necesidad de prebuscar. Sin embargo, hay trabajosque demuestran que la ejecución fuera de orden por si sola no es capaz de hacerlo. En[FCJ+97] se analiza un procesador con ejecución fuera de orden variando algunos

Tabla 4.6 Prestaciones de una LSC convencional de 512 entradas frente a las de una LSCmi de 8 entradas y prebúsqueda secuencial marcada

P/N B/N (A+a)/N data-CPI delta/N

LSCconv-512 56,7 4,90 3,05 0.165 0.956

LSCmi-8 + OBLst 21,1 7,80 2,80 0.141 0.665



parámetros de la jerarquía de memoria. Entre ellos está el mecanismo de prebúsqueda,basado en stream buffers. Concluye que al añadir este mecanismo al sistema se consigueun significativo incremento de prestaciones.

La implementación de dos niveles de cache dentro del chip varía de forma notable larelación de tiempos en la jerarquía. La penalización de fallo en el primer nivel conacierto en el segundo disminuye considerablemente, y es posible que la ocultación par-cial de esta latencia por la ejecución en desorden permita desplazar la prebúsqueda delprimer nivel de cache al segundo.

Todos los mecanismos de prebúsqueda analizados en este capítulo son adaptables a unsegundo nivel dentro del chip. Algunos de ellos necesitan información proporcionadadirectamente por el procesador, que por tanto sigue siendo accesible. Queda por estu-diar la influencia que en estos mecanismos tiene el posible desorden en las referencias amemoria.

4.6 Conclusiones

En los últimos años se han propuesto varios mecanismos de prebúsqueda hardware dedatos. Muchos de ellos intentan superar la prebúsqueda secuencial analizando nuevospatrones de acceso. Sin embargo, la última generación de procesadores no incorporaninguno de estos mecanismos.

El análisis de coste y prestaciones realizado en el capítulo anterior indica que los nue-vos mecanismos de prebúsqueda son mucho más caros que el secuencial y ofrecen in-crementos de prestaciones modestos. En este capítulo se realiza una caracterización dela carga de trabajo buscando las causas del pobre resultado obtenido con los mecanis-mos basados en tablas de ld/st. Este estudio revela que: i) El tamaño de LSC debe sermuy grande para acoger a todas las instrucciones ld/st activas en cada momento deejecución de un programa. Los tamaños propuestos hasta el momento pueden ser insu-ficientes, sin embargo suponen un área similar a la de la cache de datos. ii) La mayoríade las secuencias lanzadas por la carga de trabajo siguen patrones escalares o secuen-ciales, muy pocas siguen patrones de stride o listas encadenadas y estas aparecen muyconcentradas en unos pocos benchmarks. Y iii) Una porción muy elevada de las instruc-ciones almacenadas en una LSC nunca provocan fallos, y por tanto es inútil que gene-ren prebúsquedas puesto que los bloques que intentan prebuscar ya están en cache. Elespacio que ocupan en LSC también es inútil.

En este capítulo se estudian dos mecanismos alternativos de bajo coste, capaces de con-seguir parecidas prestaciones en los pocos programas que lo permiten, pero con uncoste mucho más reducido. Ambos combinan un mecanismo nuevo con laprebúsqueda secuencial. El objetivo de ambos es mantener las prestaciones del meca-nismo secuencial en los programas que siguen este patrón (la mayoría), y conseguir

Referencias


mejoras significativas en los que siguen patrones de stride constante o recorrido de lis-tas.

El primero de ellos, SPAR (Stride Pattern in Address Register), es un mecanismo para ladetección de patrones mediante análisis de código. Analiza las operaciones que se rea-lizan sobre los registros usados en instrucciones ld/st, y mantiene una tabla (RegisterStride Table) que asocia a cada registro dos estados, uno para detectar recorridos constride constante y otro para detectar recorridos de listas. Los estados de un registro seactualizan según las operaciones que se realizan sobre él.

El segundo, la inserción on-miss, persigue aumentar el rendimiento de una LSC con-vencional filtrando las instrucciones ld/st que debe almacenar. La inserción de unainstrucción ld/st en una LSCmi se condiciona al acierto o fallo del acceso que se harealizado a cache. Sólo se añadirá el ld/st a LSC (reemplazando a otro ld/st) si el acce-so a cache ha producido un fallo. De esta manera la probabilidad de que una instruc-ción ld/st se encuentre en LSC será proporcional al número de veces que dichainstrucción falle, y no al número de veces que la instrucción se ejecute.

Los dos mecanismos tienen costes de implementación mucho menores que los basadosen tablas de ld/st y, al ser usados en combinación con OBLst, consiguen parecidasprestaciones incluso en los programas que usan patrones no secuenciales de forma in-tensiva. SPAR usa una tabla unas 12 veces menor que una LSCconv de 512 entradas.Con inserción on-miss el tamaño de LSC se puede dividir por 64 manteniendo presta-ciones. El único punto negro de ambos es que aumentan el tráfico con el siguiente nivelde la jerarquía debido a la baja precisión de la prebúsqueda secuencial.

4.7 Referencias

[BC91] J.L. Baer and T.F. Chen. “An Effective On-chip Preloading Scheme to Reduce Data Access Penal-ty”. In Supercomputing 91, pp.176-186, 1991.

[DS95] F. Dahlgren and P. Stenström, “Effectiveness of Hardware-Based Stride and Sequential Prefetch-ing in Shared Memory Multiprocessors”, Proc. first IEEE Symp. High-Performance ComputerArchitecture, IEEE CS Press, Los Alamitos, Calif., 1995, pp. 68-77.

[FCJ+97] K.I. Farkas, P. Chow, N.P. Jouppi and Z. Vranesic. "Memory-System Design Considerations forDynamically-Scheduled Processors". In Proc. of 24th Int. Symp. on Computer Architecture, pp.133-143, 1997.

[FPJ92] J.W.C. Fu, J.H. Patel and B. L. Janssens. “Stride Directed Prefetching in Scalar Processors”. InProc. of 25th Int. Symp. on Microarchitecture (MICRO-25), ACM, pp.102-110, December 1992.

[IVB+98] P. Ibáñez, V. Viñals, J.L. Briz and M.J. Garzarán. "Characterization and Improvement of Load/Store Cache-base Prefetching". Admitido en el ICS98.

[JT93] Y. Jegou and O. Temam. “Speculative Prefetching”. Proc. of ICS-93, pp.1-11, December 1992.

[MH96] S. Mehrotra and L. Harrison. “Examination of a Memory Access Classification Scheme for Point-er-Intensive and Numeric Programs”. Proc. of ICS-96, pp.133-140, 1996.

[Smi82] A.J. Smith. “Cache Memories”. Computing Surveys, 14(3):473-530, September 1982.


C A P Í T U L O 5

Conclusiones y líneas abiertas

En esta tesis hemos estudiado dos soluciones para minimizar el impacto de la latenciaen las prestaciones de un procesador con caches integradas. Las dos soluciones actúansobre el sistema de memoria para reducir bien el número de fallos, bien su latencia.

En primer lugar se estudia la incorporación de varios niveles de cache dentro del chipdel procesador. El objetivo de esta solución es disminuir la penalización media sufridapor un fallo en el primer nivel de la jerarquía. El hecho de implementar dos niveles decache muy acoplados crea nuevas condiciones de contorno, aparecen nuevas posibili-dades y también nuevos compromisos. Se estudia la relación de contenidos entre losdos niveles integrados. Se compara la gestión convencional en inclusión con nuevosmétodos de gestión en exclusión y demanda.

En segundo lugar se estudia la incorporación de mecanismos de prebúsqueda hard-ware de datos. El objetivo de esta solución es disminuir el número de fallos en las ca-ches más cercanas al procesador. Entre los métodos existentes se seleccionan los másapropiados para caches integradas y se analiza su coste y rendimiento. Tras este análisisse proponen dos nuevos mecanismos de bajo coste que consiguen prestaciones simila-res a las de los mecanismos convencionales.

Durante todo el desarrollo de la tesis, y en paralelo con el trabajo central, se ha prestadoespecial atención al desarrollo de técnicas para la disminución del coste temporal de si-mulación. Se han depurado para ello nuevas técnicas de muestreo aplicables a simu-ladores ciclo a ciclo en un contexto general de procesadores y jerarquías de memoriacon elevada actividad paralela.



5.1 Memorias cache multinivel integradas

La creciente discrepancia en las velocidades del procesador y la RAM dinámica pro-mueve un diseño jerárquico del sistema de memoria. Creemos que la aparición de nue-vas formas de ocultación parcial de latencia, como la ejecución en desorden, sólo hafrenado temporalmente la incorporación de varios niveles dentro del procesador.

Bajo este supuesto de diseño multinivel hemos comparado varias alternativas de ges-tión de los contenidos de dos niveles de cache integrados en el chip procesador, conrespaldo en un tercer nivel exterior. Proponemos dos alternativas de gestión de conte-nidos: Exclusión y Demanda, desarrollando para las mismas nuevos protocolos cohe-rentes y sus necesidades hardware. El algoritmo para Exclusión y sus necesidadeshardware han resultado ser incluso más sencillos que en Inclusión.

En el trabajo presentado en esta tesis se comparan varios diseños para una jerarquía decache on chip analizando su coste en área y sus prestaciones en tiempo de ejecución. Eldiseño base consiste en implementar un solo nivel de cache que ocupa toda el área dis-ponible. Los diseños alternativos dividen este espacio en dos niveles de cache, de dife-rentes tamaños y con distintas gestiones de contenidos: inclusión y exclusión. Lasconclusiones se resumen en:

• Incluyendo un solo nivel de cache, las mejores prestaciones se consiguen con untamaño de 64KB. Tamaños mayores implican pérdida de prestaciones debido al au-mento de tiempo de ciclo.

• Al incluir dos niveles, las mejores prestaciones se consiguen con caches en L2 de256KB y en L1 de entre 16 y 32 KB. Es decir, si se dispone de espacio dentro del chipse puede duplicar el dedicado a memoria cache mejorando prestaciones ( 16.8%,18,8% y 22,8% para SPEC92, SPEC95int y SPEC95fp respectivamente).

• La gestión de contenidos en exclusión consigue mejor TPI que la gestión en In-clusión prácticamente en todos los tamaños de cache analizados, y para todos losgrupos de programas de prueba. Las ganancias medias para los programas deSPEC92, SPEC95int y SPEC95fp son de 6%, 6,3% y 5,7% respectivamente.

5.2 Prebúsqueda

En cuanto a prebúsqueda, nuestro objetivo es mejorar los mecanismos propuestos paracaches on-chip en entornos monoprocesador. Nuestro trabajo se centra en los métodosde prebúsqueda para recorridos secuenciales, con stride constante y de listas.

Se propone un nuevo modelo de prestaciones basado en tasa de fallos y CPI que inte-gra las mas importantes métricas que influirán en las prestaciones finales de un meca-nismo de prebúsqueda.

Con la ayuda de este modelo se analizan en detalle los mecanismos existentes para elentorno en que se mueve la tesis y se detectan posibles puntos de mejora. El estudio se

Aportaciones metodológicas


centra en la prebúsqueda secuencial y en los mecanismos basados en tabla de ld/st(LSC). Se concluye que para conseguir tasas de fallos y CPI de datos menores que losde secuencial, un mecanismo LSC requiere una tabla de al menos 128 entradas. El au-mento medio en prestaciones es modesto y no parece justificar el alto coste de este me-canismo.

Tras este análisis se proponen dos mecanismos alternativos de bajo coste, capaces deconseguir parecidas prestaciones en los pocos programas que lo permiten, pero con uncoste mucho mas reducido. Ambos combinan un mecanismo nuevo con laprebúsqueda secuencial. El objetivo de ambos es mantener las prestaciones del meca-nismo secuencial en los programas que siguen este patrón (la mayoría), y conseguirmejoras significativas en los que siguen patrones de stride constante o recorrido de lis-tas.

El primero de ellos, SPAR (Stride Pattern in Address Register), es un mecanismo para ladetección de patrones mediante análisis de código. Analiza las operaciones que se rea-lizan sobre los registros usados en instrucciones ld/st. El segundo, la inserción on-miss, persigue aumentar el rendimiento de una LSC convencional filtrando las instruc-ciones ld/st que debe almacenar.

Los dos mecanismos tienen costes de implementación mucho menores que los basadosen tablas de ld/st y, al ser usados en combinación con OBLst, consiguen parecidasprestaciones. SPAR usa una tabla unas 12 veces menor que una LSCconv de 512 entra-das. Con inserción on-miss el tamaño de LSC se puede dividir por 64 manteniendoprestaciones. El único punto negro de ambos es que aumentan el tráfico con el siguien-te nivel de la jerarquía debido a la baja precisión de la prebúsqueda secuencial.

5.3 Aportaciones metodológicas

Partiendo de las propuestas existentes sobre muestreo temporal aplicado a simulaciónde fallos, presentamos dos aportaciones dirigidas a extender su uso a simulaciones deciclo y mejorar el proceso de selección de la muestra. El objetivo final es conseguir unmétodo que permita obtener resultados fiables, simulando detalladamente una peque-ña porción representativa de cada programa de prueba.

La primera aportación es aplicable a simulaciones ciclo a ciclo de sistemas monoproce-so. En estos sistemas, al implementar muestreo surge el problema del arranque en fríoen el inicio de cada observación. Para eliminarlo se propone mantener actualizado elestado de las caches entre dos observaciones consecutivas mediante una simulación defallos. El resultado es un método que permite obtener los resultados de una simulaciónciclo a ciclo en un tiempo similar al de una simulación de fallos. El error cometido almuestrear se limita al propio error estadístico, ya que el error por arranque en frío seelimina.



La segunda aportación es aplicable a cualquier tipo de simulación en la que se genera

la traza en el mismo momento que se consume. Es un nuevo método de selección de la

muestra, basado en las carácterísticas propias de la ejecución de un programa: presen-

cia de transitorio y comportamiento periódico. Requiere un análisis previo de la evolu-

ción temporal del programa de prueba para detectar esas características. Tras este

análisis se propone distribuir las observaciones que componen la muestra a lo largo de

un periodo, por supuesto una vez eliminado el transitorio. Se consiguen muestras tan

precisas como las conseguidas con los métodos convencionales de muestreo, pero con

coste temporal mucho menor, similar al de los métodos de reducción de traza sin

muestreo.

5.4 Lineas abiertas

A continuación vamos a citar las principales líneas abiertas derivadas del trabajo pre-

sentado en esta tesis.

En primer lugar consideramos muy interesante la formalización de las técnicas de

muestreo y selección de carga. En este sentido parece interesante aplicar técnicas de

análisis espectral para la caracterización del régimen permanente y desarrollar algorit-

mos específicos para capturar la parte transitoria.

En segundo lugar pensamos extender la evaluación experimental de nuestras técnicas

originales de gestión de contenidos y prebúsqueda en un contexto de lanzamiento su-

perescalar y fuera de orden. La consideración simultánea de ambos tipos de técnicas

introducirá sin duda nuevos compromisos y variantes de diseño.

Finalmente, y entrando en un terreno mucho más amplio, planeamos extender los con-

ceptos desarrollados en esta tesis en el ámbito de los múltiprocesadores de memoria

compartida, empezando por las organizaciones sencillas basadas en bus, y migrando

hacia organizaciones más avanzadas de memoria compartida distribuida.


Apéndice A

Figura A.1 APPLU. 63.221 Minst; Periódico, periodo = 18 Minst, transitorio = 3.935 Minst.

Figura A.2 APSI. 45.555 Minst; 3 etapas.

0 1000 2000 3000 4000 5000 6000 70000

0,1

0 10000 20000 30000 400000

0,1

0,2

0,3

0,4

Apéndice A


Figura A.3 HYDRO. 58.599 Minst; Periódico, periodo = 141 Minst, transitorio = 420 Minst.

Figura A.4 MGRID. 91.586 Minst; Periódico, periodo = 91 Minst, transitorio = 0.

Figura A.5 SU2COR. 50.458 Minst; Periódico, periodo = 5.280 Minst, transitorio = 6.280 Minst.

0 1000 2000 3000 4000 5000 6000 70000

0,1

0,2

0,3

0,4

0,5

0,6

0 1000 2000 3000 4000 5000 6000 70000

0,1

0,2

0,3

0 10000 20000 30000 40000 500000

0,1

0,2

0,3

0,4

0,5


Figura A.6 SWIM. 40.569 Minst; Periódico, periodo = 44 Minst, transitorio = 138 Minst.

Figura A.7 TOMCATV. 50.730 Minst; Periódico, periodo = 61 Minst, transitorio = 4.420 Minst.

Figura A.8 TURB3D. 259.940 Minst. Periódico, periodo = 2.126 Minst, transitorio = 0.

0 1000 2000 3000 4000 5000 6000 70000

0,10,20,3

0,40,5

0,60,7

0,8

0 1000 2000 3000 4000 5000 6000 70000

0,10,20,3

0,40,5

0,60,7

0,8

0 1000 2000 3000 4000 5000 6000 70000

0,10,20,30,40,50,60,70,80,9

1

Apéndice A


Figura A.9 IJPEG. 40.597 Minst; Periódico, periodo = 650, transitorio = 0.

Figura A.10 M88KSIM. 75.884 Minst; 2 etapas.

Figura A.11 PERL. 17.518 Minst; Regular, transitorio = 300 Minst.

0 1000 2000 3000 4000 5000 6000 70000

0,1

0 10000 20000 30000 40000 50000 60000 700000

0,02

0,04

0,06

0 1000 2000 3000 4000 5000 6000 70000

0,1

0,2

0,3

0,4


Figura A.12 VORTEX. 72.661 Minst; Periódico, periodo = 4.820 Minst, transitorio = 2.700 Minst.

0 10000 20000 30000 40000 50000 60000 700000

0,1

0,2

0,3

Apéndice A



Apéndice B

Apéndice B


Figura B.1 Espacio práctico de diseño en Inclusión y Exclusión para SPEC92. Selección de puntos posibles de diseño que ofrecen un mínimo de prestaciones o bien cubren un área determinada con unas prestaciones adecuadas.

8

9

10

11

12

13

14

15

16

17

18

0 500000 1000000 1500000

No L2

8 KB

16 KB

32 KB

64 KB

128 KB

Inclusión

Exclusión

TPI

L1size (rbe)

64 + 64 KB

L2size


Figura B.2 Espacio práctico de diseño en Inclusión y Exclusión para SPEC95int. Selección de puntos posibles de diseño que ofrecen un mínimo de prestaciones o bien cubren un área determinada con unas prestaciones adecuadas

7

9

11

13

15

17

19

0 500000 1000000 1500000 2000000 2500000

No L2

8 KB

16 KB

32 KB

64 KB

128 KB

256 KB

Inclusión

Exclusión

TPI

L1size (rbe)

64 + 64 KB

L2size

Apéndice B


Figura B.3 Espacio práctico de diseño en Inclusión y Exclusión para SPEC95fp. Selección de puntos posibles de diseño que ofrecen un mínimo de prestaciones o bien cubren un área determinada con unas prestaciones adecuadas.

12

14

16

18

20

22

24

26

28

0 500000 1000000 1500000 2000000 2500000

No L2

8 KB

16 KB

32 KB

64 KB

128 KB

256 KB

Inclusión

Exclusión

TPI

L1size (rbe)

64 + 64 KB

L2size

INDICE - unizar.eswebdiis.unizar.es/gaz/biblio/pdfs/1998_tesis_Pablo.pdf · 2.3.4 Coherencia basada...

Documents

Transcript of INDICE - unizar.eswebdiis.unizar.es/gaz/biblio/pdfs/1998_tesis_Pablo.pdf · 2.3.4 Coherencia basada...