Tema 4.

Procesadores Multihilo y Multicore

Indice

•  1. Introducción
•  2. Procesadores multihilo
–  2.1 Procesadores FGMT
–  2.2 Procesadores CGMT
–  2.3 Procesadores SMT
•  3. Procesadores multinúcleo

©Julio Sahuquillo -2-

 1. Introducción
•  Los arquitectos de computadores siempre han perseguido incrementar el
procesamiento en paralelo para mejorar las prestaciones.
•  Se puede implementar de distintas formas según la unidad de paralelismo y el
número de unidades de proceso del sistema.

•  Unidades de paralelismo. Casos extremos:

–  Paralelismo a nivel de programa o proceso
•  Al principio la multiprogramación permitía que varios programas
compartiesen la memoria
•  Cuando un programa en ejecución realiza E/S cede la CPU via cambio
de contexto ! solapamiento CPU-E/S
–  Paralelismo a nivel de instrucción
•  Varias instrucciones del mismo programa se ejecutan en paralelo
•  Segmentación: forma más simple
•  Superescalares: extensión de la segmentación con más unidades
funcionales

©Julio Sahuquillo -3-

1. Introducción

•  Paralelismo en sistemas multiprocesador/multinúcleo. Conceptos:

–  Multiprocesador:
•  Incluye soporte hardware/software para la creación de procesos
concurrentes y su sincronización, así como protocolos para
asegurar la consistencia de datos a través de la jerarquía de
memoria
•  Cargas que pueden ejecutan:
–  Paralelas (Multithreaded): varios procesadores cooperan ejecutando
distintas porciones de un mismo programa
–  Multiprogrammed. También pueden ejecutar distintos programas en
distintos procesadores
•  Explotan paralelismo:
–  A nivel de ILP dentro de un procesador
–  A nivel de tarea en distintos procesadores

©Julio Sahuquillo -4-

 1.  Introducción
Paralelismo a nivel de tarea (thread-level)
•  Paralelismo a nivel de tarea. Terminología SO:
–  Proceso: programa en ejecución junto con su estado formado por
valores del PC, registros y tabla de procesos del SO
•  Contenido tabla procesos:
–  PID: previene el “flashing” de la TLB durante el cambio de
contexto
–  Puntero a la tabla de páginas, que mantiene la correspondencia
de dirección virtual a física del proceso
–  …
•  Un cambio de proceso debe guardar el estado
–  Hilo (thread):
•  Un proceso puede tener un único hilo de control o varios
•  Los hilos de un proceso comparten el espacio de direcciones
–  El cambio de contexto entre hilos de un proceso es menos costoso
que entre procesos

©Julio Sahuquillo -5-

1.  Introducción
Paralelismo a nivel de tarea (thread-level)

•  Multithilo (multithreading)
–  Definición inicial (SO): ejecución entrelazada de hilos del mismo proceso
–  Definición actual (arquitectura):
•  son tareas independientes (igual que en multiprogramación)
pero se replica parte del estado del proceso para cada hilo
por lo que el cambio de contexto es menos costoso
–  Se puede implementar en un mismo procesador
–  Granuralidad: se define por los eventos que mandan el cambio en el thread
de ejecución
•  Grano fino
•  Grano grueso
•  Simultáneo

©Julio Sahuquillo -6-

 1. Introducción
•  Procesadores superescalares (repaso):
–  Las instrucciones que se buscan, lanzan, hacen WB y commit viene limitado por
•  Fetch width, issue width, WB width, commit width
•  Eejmplo para ancho igual 2 en todas ellas:

ADD.F F3,F2,F1 IF ID Rn I A1 A2 WB C !
ADD.F F4,F5,F2 IF ID Rn I A1 A2 WB C!
ADD.F F3,F3,F1 IF ID Rn i i I A1 A2 WB C!
ADD.F F7,F8,F8 IF ID Rn I A1 A2 WB C!
ADD.F F9,F8,F1 IF ID Rn I A1 A2 WB C!
ADD.F F4,F9,F2 IF ID Rn i i i I A1 A2 WB C!
•  Ventajas:
–  Mejor aprovechamiento de los operadores
–  Mayores prestaciones:
la mejora es directamente proporcional a la efectividad del ancho de issue
•  En el ejemplo se lanzan 4 en los 3 primeros ciclos hábiles
•  Inconveniente
–  Lógica compleja: principalmente decodificación y lanzamiento

©Julio Sahuquillo -7-

1. Introducción
•  Limitación de los procesadores superscalares
–  En la práctica se lanzan menos instrucciones a
ejecución por ciclo que el ancho de issue.
–  Además se pueden producir largas latencias para
resolver las dependencias debido a:
•  Fallos de cache, de TLB, fallos de predicción, …
–  2 tipos de desperdicio de slots de issue
•  Desperdicio Horizontal:
–  Se lanzan menos instrucciones que el ancho de
issue
•  Desperdicio Vertical: Procesador superscalar
–  En algunos ciclos no se lanza ninguna debido a un con ancho de issue 4
evento de larga duración
•  ¿Cómo reducir los desperdicios?
–  Posible solución: ofrecer soporte para la ejecución de
varios threads

©Julio Sahuquillo -8-

 1. Introducción
Thread A Thread B Thread C

Issue slots Issue slots Issue slots

tiempo

–  Procesadores multithread
•  Rediseñar el procesador, para que parte de los recursos del core (por
ejemplo, la lógica de decodificación) puedan compartirse entre los threads

©Julio Sahuquillo -9-

2. Procesadores multithread

•  Permiten que distintos threads ejecuten instrucciones compartiendo recursos del

procesador de manera temporal
–  mayor utilización de los operadores y ocultan las altas latencias de memoria:
Permiten reducir ambos desperdicios
•  Thread y contexto
–  Thread (sofware): es la tarea que se ejecuta
–  Contexto (hardware): soporte para la ejecución de un thread software
•  Ej. El Montecito es un microprocesador dual-core dual-thread itanium
–  Contexto mínimo por thread: el PC y registros asignados

Icache Fetch B. Registros

I. queue Dcache
PC queue Decode Rename

•  Clasificación según granuralidad

•  Multithread de grano fino o FGMT: cambian de thread cada ciclo
•  Multithread de grano grueso o CGMT: cambian de thread ante eventos de larga latencia
•  Simultáneo o SMT: no se produce el cambio de thread

©Julio Sahuquillo -10-

 2.1 Multithread de grano fino (FGMT)
Concepto
•  Cambia de contexto tan pronto como la ejecución de un thread va a
retrasarse (por ej. 1 ciclo debido a una dependencia RAW)
•  El cambio de contexto debe requerir un “tiempo 0”
•  ¿Qué tipo de desperdicio se reduce?

Thread A Thread B Thread C

Issue slots
Issue slots Issue slots Issue slots
tiempo

tiempo
©Julio Sahuquillo -11-

2.1 Procesadores FGMT

CDC600
•  CDC 6600: primera implementación. Componentes:
•  10 unidades de procesadores de periférico (PPUs) para E/S
•  Cada PPU tiene su PC y su BR
•  ALU compartida (round-robin) y Memoria compartida
–  Operación con ALU: un “ciclo menor” para ejecutar una operación
–  Acceso a memoria (dato/instr.): se requiere un “ciclo mayor” (10 menores)
•  Cambio de contexto cada ciclo ! debe haber bastantes threads listos para su
ejecución para ocultar la latencia del elemento más lento que debe estar
segmentado
•  No se vacía el pipeline cuando se cambia de thread, pero cada instrucción lleva
una etiqueta con el thread asociado
•  Ejemplo escalando el procesador a una latencia de memoria 4 ciclos
Acceso E/S de T0

PPU0 M1 M2 M3 M4 A M1 M2 M3 M4 A . . .

PPU1 M1 M2 M3 M4 A M1 M2 M3 M4 A . . .

PPU2 M1 M2 M3 M4 A M1 M2 M3 M4 A . . .

PPU3 M1 M2 M3 M4 A M1 M2 M3 M4 A . . .

©Julio Sahuquillo -12-

 2.1 Procesadores FGMT
Tera MTA
•  Supercomputador Tera MTA (Multithreaded Architecture), 1998
–  Multiprocesador diseñado para aplicaciones científicas
–  Memoria: recurso más caro del sistema, además de alta latencia
–  Cada procesador ofrece soporte para la ejecución de 128 threads
simultáneamente
•  128 contadores de programa
•  Cada thread tiene su banco de 32 registros de 64 bits más 8 registros
destino para saltos y prefetch de instrucciones
•  No hay caches pero hay buffers para instrucciones
–  Para ocultar la latencia de búsqueda en memoria en teoría (modelo
PPU) se requieren al menos 70 threads listos para ejecutarse
•  Para atacar el inconveniente, se incluye un campo de 3 bits que indica
cuántas instrucciones de un mismo thread se pueden ejecutar antes de que
aparezca un riesgo (de control o datos)
•  Se pueden ejecutar conjuntos de 8 instrucciones organizados por el
compilador --> se requieren solo 9 threads (9x8=72)
•  También se pueden explotar características multithreading en procesadores
VLIW

©Julio Sahuquillo -13-

2.1 Procesadores FGMT

Resumen
•  Implementación tipo Tera
–  No es viable si hay pocos threads
–  No se pueden beneficiar las prestaciones individuales de determinados
threads
–  Falta de caches
•  Malas prestaciones con 1 solo thread ! su tiempo de ejecución puede ser
veces 70 mayor que un diseño basado en cache
•  Excelente para aplicaciones con muchos fallos de cache sin la sobrecarga
de comprobar si son fallos o aciertos
•  Resumen
–  Persiguen maximizar las prestaciones globales y considera que siempre
hay suficientes threads disponibles
–  FGMT es un buen modelo de arquitectura para
•  Aplicaciones donde se puede extraer muchos threads como
aplicaciones científicas representativas de los supercomputadores e.g. Tera
•  Cargas multiprogramadas donde cada proceso requiere un gran ancho de
banda memoria y poca potencia computacional, Ej. Niagara destinado a
servidores web
•  Es el modelo que impera en las GPUs

©Julio Sahuquillo -14-

 2.2 Multithread de grano grueso: CGMT
•  Modelo intermedio: se beneficia de algunas de las ventajas de grano fino sin
imponer restricciones a las prestaciones de un thread ya que utiliza políticas
de cambio de thread
•  Cambio de contexto
–  Se realiza cuando el thread activo “se para” por un evento de alta
latencia, por ejemplo, un fallo de cache
–  Interesante para procesadores con lanzamiento en orden
•  Implementaciones
–  Primera implementación: máquina Alewife en el MIT, 1990
•  Implementado en máquinas de investigación:1990 y 1995
–  Procesadores comerciales:
•  Northstar y Pulsar PowerPC de IBM: 1996 y 1998
•  Montecito: dual-core dual-thread Itanium processor

©Julio Sahuquillo -15-

2.2 Procesadores CGMT

Máquina típica
•  Sistema con jerarquía de cache y SO con MV paginada y TLBs
•  Caches libres de bloqueo
•  TLBs utilizan PIDs para considerar tanto threads pertenecientes al mismo
programa como a programas distintos
•  Procesador con ejecución en orden
–  Las instrucciones de un thread pueden ocupar distintas etapas del
pipeline
–  Las instrucciones llevan etiquetas para identificar el conjunto de
registros asociado al thread
•  Soporte hardware para varios contextos, cada contexto :
–  Banco de registros: evita salvar y restaurar registros para cada thread
–  Conjunto de registros de control y registros especiales que apuntan a la
tabla de páginas, topes de la pila, acciones a realizar con las
excepciones, etc
•  Se pueden generar más threads que contextos
–  Políticas de cambio de thread
•  En teoría, un procesador de grano grueso no utilizaría tiempo para realizar
el cambio de thread, al igual que en grano fino

©Julio Sahuquillo -16-

 2.2 Procesadores CGMT
Cambio de thread
•  Cambio de thread: acciones a realizar y consecuencias
–  Las instrucciones en el pipeline que siguen a la que ha causado el cambio
de contexto, en principio, deben drenarse
–  Las instrucciones del thread entrante tardarán unos ciclos en llegar a la
etapa de ejecución ! penalización que depende de la longitud del pipeline
–  Inconveniente: los eventos que causan el cambio de contexto se detectan en
etapas avanzadas del pipeline
•  Se necesita un tiempo para rellenar el pipeline ! varias burbujas según la
longitud del pipeline
•  Solución 1
–  Replicar todos los registros del pipeline para cada thread y salvar el estado del
pipeline en cada cambio de contexto (Motorola 88000)
•  El cambio de contexto puede activarse el siguiente ciclo sin que aparezcan
burbujas
–  Complejidad considerable para replicar todo el estado
•  Solución 2
–  Implementar pipelines cortos y dejar que aparezcan burbujas
–  Ejemplo: el IBM Northstar/pulsar con 3 ciclos de penalización no replica registros

©Julio Sahuquillo -17-

2.2 Procesadores CGMT

Número de contextos
•  ¿Cuántos contextos deben soportarse? Limitado por
–  El coste hardware requerido
–  Uso y eficiencia de recursos compartidos como caches, TLBs y predictores
de salto
–  Sobrecarga para elegir entre los threads libres, que debe ser pequeña
•  Regla simplista: “si la latencia más larga a ocultar es de n ciclos y las
operaciones con dicha latencia ocurren cada m ciclos, el número de
threads soportados debe ser n/m”. Ejemplo:
–  Si latencia de M=200 ciclos y los fallos de L2 ocurren cada 50 ciclos, debería
haber 4 contextos hardware
(asumiendo quelos cambios de thread se disparan por fallos de L2)
–  Análisis:
•  Supongamos que para cuantificar los 50 ciclos, se han lanzado las tareas de
manera individual.
•  En principio, si hay más tareas en ejecución (4 contextos), el valor sería
menor ! necesidad de más contextos
•  Pero, al haber más, aumenta la competencia por los recursos compartidos, y
y los fallos en L1,TLB, y predictor de saltos ocurrirán con mayor frecuencia
(menos eficiencia) ! necesidad de menos contextos
•  ¿Solución?

©Julio Sahuquillo -18-

 2.2 Procesadores CGMT
Máquinas comerciales
•  Primera implementación: máquina Alewife en el MIT, 1990
–  Procesador SPARC en orden modificado para soportar 4 contextos
hardware, pero se podían generar un nº ilimitado de threads
–  Cambio de contexto:
•  Por fallos de cache (1 sola cache off-chip) o fallos de intentos de
sincronización
•  Se implementó via traps y requería 10 ciclos
•  Se vaciaba el pipeline ! implementación simple
•  Variación del IBM Power PC
–  Pipeline de 5 etapas con soporte para 2 threads cada uno con su buffer
de instrucciones (cola de fetch)
–  Destinado a cargas comerciales con grandes working sets ! muchos
fallos de cache
–  Ejecución con sofware de multiprocesador existente
–  Cambios de contexto: fallos de L1 cache y L1 I-TLB
•  Fallo de L1 implica acceso a L2 (>= 8 ciclos) se detecta en la última etapa
del pipeline ! la penalización de rellenar el pipeline son 3 ciclos desde el
buffer
–  Mejora de prestaciones del 30%

©Julio Sahuquillo -19-

2.2 Procesadores CGMT

Políticas de cambio de thread: conceptos
•  Políticas de cambio de thread: deben garantizar equidad
–  No puede estar guiada solo por fallos de cache ya que varía para las
distintas aplicaciones y fases de ejecución para una misma aplicación.
–  Para proporcionar equidad se suele aplicar “cuando se produce un
evento de alta latencia (por ej. fallo de cache) o expira un quantum”
•  Prioridades de los threads se pueden cambiar por software (instrucciones)
–  Ejemplo: IBM NorthStar/Pulsar
–  El programador puede dar prioridades a los threads para mejorar sus
prestaciones o las prestaciones globales
–  A un mismo thread se le pueden asignar distintas prioridades (de
manera dinámica) durante su ejecución
•  Ej.: cuando un programa entra en su sección crítica después de
adquirir un cerrojo puede subir su prioridad y luego bajarla al salir
•  Las prioridades también se pueden modificar por hardware mediante
mecanismos que identifican secuencias de ejecución

©Julio Sahuquillo -20-

 2.2 Procesadores CGMT
Máquina de estados para cambio de thread
•  Ejemplo de máquina de estados
–  Para que se produzca el cambio debe haber algún otro thread en estado
ready

RELACIÓN COSTE PRESTACIONES

–  IBM mostró que su máquina IBM Northstar alcanzaba una
mejora de prestaciones del 30% con un incremento de área de un 10%
sin repercutir en el tiempo de ciclo
–  El único coste añadido fue la lógica de cambio de threads y prioridades
y duplicar el banco de registros para ofrecer soporte para 2 threads

©Julio Sahuquillo -21-

2.3 Procesadores Simultaneous Multithread: SMT

•  Único modelo que permite lanzar instrucciones de distintos threads en el

mismo ciclo
–  Reducción de desperdicio horizontal!
•  Propuesto en 1996 por Tullsen, Universidad de Washington
•  Ejemplo procesadores comerciales
–  Pentium4, IBM Power 5--IBM Power8,
Thread A Thread B Thread C

Issue slots Issue slots Issue slots Issue slots

tiempo
tiempo

©Julio Sahuquillo -22-

 2.3 Procesadores SMT
•  Entrelaza instrucciones de distintos threads en las distintas etapas del
pipeline para maximizar la utilización de los recursos
•  Los procesadores superescalares con ejecución o-o-o son ideales para dar
soporte a esta idea
–  Se pueden mezclar instrucciones de distintos threads en una misma IQ
–  Los registros lógicos se renombran utilizando físicos
•  Se puede compartir los registros del banco
•  Aspectos de diseño
–  Decidir qué recursos del core serán privados (se replican por thread)
y cuáles compartidos
–  ¿se comparte el ROB? ¿Y la cache? ¿Y la lógica de decodificación? …
•  El diseño varía mucho según:
–  Qué recursos se comparten
–  ¿Cómo se comparten? Necesidad de políticas de compartición

©Julio Sahuquillo -23-

2.3 Procesadores SMT

Compartición de recursos
•  Ejemplos de compartición de recursos en procesadores multithread
–  En todos ellos, la etapa de fetch y commit se ha puesto privada

©Julio Sahuquillo -24-

 2.3 Procesadores SMT
Aspectos de implementación
•  Los procesadores superescalares tienen múltiples colas en el pipeline, como:
–  Cola de fetch: desde donde el decode va cogiendo instrucciones
–  Cola decode-rename: desde donde se van renombrando
–  Iqueue desde donde se lanzan
–  ….
•  Cuando se llega a una etapa compartida
–  Las instrucciones los threads se mezclan en la misma cola
–  La cola debe ofrecer varios puertos de escritura, lo que complica el diseño
–  Las instrucciones deben separarse antes de commit para mantener
excepciones precisas por thread
•  La cola de load/store y el ROB deben rediseñarse o particionarse para
mantener instrucciones de múltiples threads
–  Si se particionan por thread
•  Diseño sencillo
•  Mal aprovechamiento cuando hay menos threads que particiones, ya
que algunas particiones no se utilizarán
–  Consecuencias particionado del ROB
•  No puede gestionarse como una cola circular
•  Debe poder vaciarse efectivamente (saltos y excepciones)
©Julio Sahuquillo -25-

2.3 Procesadores SMT

Políticas de fetch
•  Políticas de compartición de recursos deben garantizar equidad a fin de que
ningún thread se vea perjudicado pero deben alcanzar buenas prestaciones
globales
Ejemplos políticas de fetch
•  Round-robin: busca instrucciones de los threads de manera alternativa
–  Inconveniente: si un thread tiene un evento de alta latencia se siguen
buscando instrucciones de dicho thread
•  ICOUNT: prioriza a los threads con menos instrucciones en la IQ
–  Si hay muchas instrucciones significa que el thread no avanza
–  Inconveniente: si hay un fallo de L2, las instrucciones de un thread
(dependientes) no avanzarán y se llenará la IQ
•  STALL: mejora de ICount
–  Cuando hay un fallo de L2, ya no se buscan más instrucciones de dicho
thread
–  Inconveniente: puede detectarse demasiado tarde y haber entrado
muchas instrucciones de dicho thread

©Julio Sahuquillo -26-

 2.3 Procesadores SMT
Políticas de fetch (cont)
–  FLUSH: mejora de Stall
•  Si se detecta un fallo de L2 tarde ! libera recursos asociados a dicho thread
•  Problema: consumo para re-hacer el trabajo realizado por dicho thread
•  STALL funciona mejor que FLUSH si hay pocos fallos de L2
–  Otras políticas: FLUSH++ , Data Gating , DCRA , …

©Julio Sahuquillo -27-

3. Procesadores multicore

•  También llamados CMPs: chip multiprocessors

•  Replican todo el core = pipeline del procesador + L1.
•  La idea inicial era distribuir la complejidad de los superescalares
en más cores y más simples
Thread A Thread B

Issue slots
Issue slots Issue slots

Partición Espacial
tiempo
tiempo

©Julio Sahuquillo -28-

 3. Procesadores multicore

•  ¿De donde viene el beneficio?

–  Cores más simples (idea inicial)
–  Menor consumo ! menor temperatura ! menor coste de
empaquetamiento
–  Dedican parte del área del chip a recursos compartidos entre los
cores
•  Los primeros compartían partes de las caches de último nivel
•  Cache de L2 (etiquetas y datos), etiquetas de L3, …
•  Facilita la tarea de interconexion del sistema
•  Controlador de memoria, controlador de coherencia, controladores
gráficos, interfaces de bus, etc

©Julio Sahuquillo -29-

3. Procesadores multicore
Caracterización de los CMPs
–  Nº de cores
•  Los primeros tenían 2, en 2006 llegaron a 4 y a 8.
•  Hoy se habla de many-core, algunos, por ej. El SCC de Intel
tienen 48.
–  Multithreading
•  Puede no haber
•  SMT: Power 5, Power 6, Intel Xeon, Power 8, dual Pentium 4, etc.
•  Grano grueso: Montecito.
•  Grano fino: Sun Niagara, cada procesador soporta 16 threads
–  Tipo de ejecución
•  En orden: Sun Niagara, ATOM
•  Fuera de orden: Power 5, dual Pentium 4
–  Homogenedidad de los cores
•  La mayoría suelen ser homógeneos a nivel de “tile”.
Se diseña uno y se replica, aunque pueden funcionar a distinta
frecuencia, regulador DVFS local
•  Existen propuestas que combinan procesadores simples con
complejos, ejemplo: ARM big.LITTLE
•  La tendencia reciente 2013-14 es combinar la CPU+GPU en el
mismo chip

©Julio Sahuquillo -30-

 3. Procesadores multicore
Caracterización de los CMPs (cont.)
–  Jerarquía de cache
•  Todos tienen caches de L1 privadas (tanto de instrucciones como
datos)
•  L2 puede ser privada (dual core) o compartida (dual processor)
•  Suelen incluir una L3 compartida
–  Red de interconexión entre procesadores y caches de L2
•  Las caches de L2 se dividen en bancos.
•  La conexión entre las caches de L1 de los n procesadores y los m
bancos de L2 es via buses o crossbar,
esto es el tiempo de acceso es uniforme

©Julio Sahuquillo -31-

Ejemplo de CMP: IBM Power 4

•  174M de transistores
•  CMP con 2 cores
•  Características del core:
–  Ejecución fuera de orden
–  Cache de datos de L1
•  Privada, 32KB, write through
–  Cache de instrucciones de L1
•  Privada, 64KB
•  Cache de L2 (compartida entre los cores)
–  Organizada en 3 bancos de 512B. Cada banco contiene:
•  Una cola de stores
•  Múltiples MSHR, buffers de writeback, colas de snoop para gestionar
acciones de coherencia
•  Las etiquetas de L2 contienen el vector de compartidores
que indica qué cores tiene una copia compartida del bloque para acciones de
coherencia
•  Ancho de banda de L2 a los cores es superior 100GB/s y superior a 10GB/s
el ancho de banda de L2 a L3 y chips exteriores,
©Julio Sahuquillo -28-
 Diagrama de bloques del IBM Power 4
CIU: core interface unit (crossbar)
NC: non-cacheable unit
Fabric controler: responsable de la comunicación entre L2 y L3 (en chip aparte), y entre Power 4
GX controler: responsable de controlar el flujo de información entrada/salida del sistema
En azul: pervasive functions – para depuración

©Julio Sahuquillo -29-

Layout del IBM Power 4

•  Los 3 bancos de L2 más las etiquetas de L3 ocupan casi la mitad del chip.
•  La Load/sotre unit ocupa una parte significativa

©Julio Sahuquillo -29-

Ejemplo IBM Power 8

©Julio Sahuquillo -35-

FIN

36