Arquitectura de Computadores II Clase #11 Facultad de Ingeniería Universidad de la República

Instituto de Computación Curso 2009

Veremos… 

Rendimiento

1

Performance Medir, Reportar, y Sumarizar Tomar opciones inteligentes Ver a través de la “niebla” del marketing Entender el problema/motivación

   

Por qué algunos programas se comportan mejor en determinado hardware y no en otro? Qué factores de la performance del sistema dependen del hardware?

 

• (ejemplo: se necesita una nueva máquina, o un nuevo sistema operativo?)

Como afecta la performance el set de instrucciones? Y la organización?



Cuál tiene mejor performance? Plane

DC to Paris

Speed

Passengers

Throughput (pmph)

Boeing 747

6.5 hours

610 mph

470

286,700

Concorde

3 hours

1350 mph

132

178,200



Tiempo de ejecución de una tarea (ExTime) 



Tiempo de Ejecución, tiempo de respuesta, latencia

Tareas por día, hora, semana, seg, ns … (Performance) 

Throughput, ancho de banda

2

Performance del Computador: TIEMPO 

Tiempo de respuesta (latencia)  



Cuanto lleva ejecutar un trabajo? Cuanto hay que esperar por el resultado de una consulta a la base de datos?

Throughput 

Cuantos trabajos pueden ejecutarse a la vez?



Cual es el tiempo de ejecución promedio?



Cuantos trabajos terminan por unidad de tiempo? • O cuanto trabajo se está llevando a cabo?



Preguntas típicas 

Cuanto se mejora si le agregamos un procesador al servidor?



Qué mejora se obtiene agregando una nueva máquina?

Tiempo de Ejecución 

Tiempo transcurrido 

Mide “todo”



Una medida útil, pero difícil de usar para comparar sistemas

• Accesos a memoria y disco, E/S, etc



Tiempo de CPU  



No cuenta E/S, o el tiempo que se emplea en ejecutar otros programas (en sistemas multitarea) Se puede dividir en tiempo del sistema y tiempo de usuario

Nos interesa: tiempo de usuario de la CPU 

Tiempo empleado en la ejecución de las líneas de código de “nuestro” programa

3

Definición de Performance 

Performance: unidades de ejecución por unidad de tiempo 

 

Más grande es mejor

Performance(x) = 1/ Execution_time(x) "X es n veces más rápido que Y" significa n =



ExTime(Y) --------ExTime(X)

=

Performance(X) -------------Performance(Y)

Recordar  

Velocidad del Concorde vs. Boeing 747 Throughput del Boeing 747 vs. Concorde

Ciclos de Reloj 

Una medida alternativa a los segundos para el tiempo de ejecución son los ciclos de reloj segundos ciclos segundos = ! programa programa ciclo



Representamos el tiempo en forma discreta mediante “ticks” :



Tiempo del ciclo = tiempo entre ticks = segundos por ciclo=período Frecuencia del reloj = ciclos por segundo

time



 

(1 Hz = 1 ciclo/seg = 1/seg) 1 Un reloj de 200 Mhz tiene un ciclo de: 200 !106 1

seg

1 = !10 "8 seg 2

-8

= 0,5 !10 seg = 5 !10-9 seg = 5 nanosegs

4

Tiempo de CPU Tiempo CPU = Segundos Programa  

Ciclos

Programa

x Segundos

Instrucciones

Ciclo

La performance es determinada por el tiempo de ejecución Variables que afectan la performance   



= Instrucciones x

# de ciclos por instrucción # de instrucciones del programa # de ciclos por segundo

Un error habitual es considerar que una sola de estas variables es indicativa de la performance 

Caso típico: frecuencia de reloj (# de ciclos por segundo)

Ciclos por Instrucción (Throughput) “Ciclos por Instrucción”

! # Segs Inst Ciclo Tiempo CPU = Recuento Inst ! CPI ! 1 Frecuencia

Tiempo CPU = # Inst

Prog

CPI = (Tiempo CPU ! Frecuencia)

! # Ciclos

Recuento Inst

= Ciclos

Recuento Inst

n

Tiempo CPU = Ciclo de Reloj ! " CPI j ! I j j =1

“Frecuencia de Instrucciones” n

CPI = " CPI j ! Fj j =1

siendo Fj =

Ij Recuento de Instrucciones

CPI debe medirse, ya que la referencia técnica no tiene en cuenta ineficiencias del cache, por ejemplo

5

Una Alternativa: MIPS   

MIPS (millones de instrucciones por segundo) MIPS=Recuento de Instrucciones/(Tiempo_Ejec x 10^6) MIPS=Frecuencia del Reloj/(CPI x 10^6) 



Obs: este número crece en programas con instrucciones sencillas

Ejemplo 

Dos diferentes compiladores se prueban en una máquina de 100 MHz con tres clases de instrucciones A, B, y C, que requieren uno, dos y tres ciclos (respectivamente). Ambos compiladores producen código para un programa muy grande • El primer compilador usa 5 millones de insts. A, 1 millón de B y 1 millón de C • El segundo compilador usa 10 millones de insts. A instructions, 1 millón de B y 1 millón de C

 

Cual es “mejor” de acuerdo a los MIPS? Cual ejecuta más rápido?

Aspectos de la Performance de la CPU Recuento Inst

CPI

Programa Compilador

X X

(X)

Set de Inst.

X

X

Organización Tecnología  

X

Ciclo de Reloj

X X

Tener en cuenta esta matriz para mejorar la performance Invertir recursos donde se gasta el tiempo! (Ley de Amdahl)

6

Ejemplo: Cálculo de CPI

(1/2)

Máquina Base (Reg / Reg) Op ALU Load Store Branch

Freq 50% 20% 10% 20%

CPI 1 2 2 2

Freq*CPI(i) .5 .4 .2 .4 1.5

(% Time) (33%) (27%) (13%) (27%)

Mezcla Típica

Ejemplo: Cálculo de CPI CPI de la máquina

(2/2)

Mezcla de Instrucciones

5 x 30 + 1 x 20 + 2 x 20 + 2 x 10 + 2 x 20

100

= 2.7 c ic lo s /ins tru c c ió n

D o nd e s e g as ta e l tie m p o ?

7

Ejemplo: Impacto del Branch Stall  

Se asume CPI = 1.0 ignorando bifurcaciones (ideal) En realidad se produce un “stall” de 3 ciclos por bifurcación 



Op Otras Bifurc.



=> CPI real= 1.9

 



Si 30% bifurcaciones, “stall” 3 ciclos en 30% Freq 70% 30%

Cycles CPI(i) 1 .7 4 1.2

(% Tiempo) (37%) (63%)

O sea que la máquina real es 1/1.9 = 0.52 veces “más rápida” (o sea el doble de lenta!)

Ley de Amdahl

(1/2)

Aceleración (Speedup) debida a mejora E: ExTime sin E Performance con E Speedup(E) = ------------= ------------------ExTime con E Performance sin E 

Tiempo Ejec con mejora = Tiempo de Ejec. NO afectado + (Tiempo de Ejec. afectado / Fracción mejorada) 

Ejemplo: 



Consideramos un programa que se ejecuta en 100 segs; la multiplicación es responsable de 80 segs. del total. Cuanto debemos mejorar la multiplicación para que el programa se ejecute 4 veces más rápido?

Principio: mejorar el caso más común (regla 20/80)

8

Ley de Amdahl

(2/2)

ExTimenew = ExTimeold x (1 - Fractionenhanced) + Fractionenhanced Speedupenhanced

Speedupoverall =



ExTimeold ExTimenew

1 =

(1 - Fractionenhanced) + Fractionenhanced Speedupenhanced

Ejemplo: 

Instrucciones de Punto Flotante mejorada para correr a 2X; pero únicamente 10% de las instrucciones son PF

ExTimenew = ExTimeold x (0.9 + .1/2) = 0.95 x ExTimeold 1 Speedupoverall = = 1.053 0.95

Ley de Amdahl: ejemplo

Se emplea el 30% del tiempo ejecutando código que no se puede paralelizar

Queremos ejecutar un programa en N CPUs

CPUs

(1/2)

Calcularemos aceleración para N = 2, 3, 4, 5, ∞ 2

3

4

5

∞

Aceleración

9

Ley de Amdahl: ejemplo

(2/2)

S(∞)

2

S=

3

# CPUs

1 (30 % + (70% / N) ) / 100 % 2

3

4

5

∞

1.54

1.85

2.1

2.3

3.3

CPUs Aceleración

Métricas de Performance Applicación Lenguaje de Programación

(1/2)

Respuestas por mes Operaciones por segundo

Compilador ISA

(millones) de Instrucciones por segundo: MIPS (millones) de operaciones (PF) por segundo: MFLOP/s

Datapath Control Function Units Transistores Pistas Pins

Megabytes por segundo Ciclos por segundo (clock rate)

10

Métricas de Performance 

(2/2)

Programas reales 

Se usan programas que representan una carga de trabajo típica, clases de aplicaciones típicas • Compiladores de C, procesadores de texto, herramientas CAD



Kernels 

Extractos “clave” de programas reales



Permiten estudiar aspectos aislados de la arquitectura

• Livermore Loops, Linpack 

Synthetic benchmarks 

Filosofía similar a kernels, intentan promediar frecuencia de operaciones de un gran conjunto de programas típicos • Whetstone (numérico), Dhrystone (E/S datos )

  

Interesantes para arquitectos y diseñadores Fácil de estandarizar Pero… • Pueden ser “violados”

Benchmarks 

Benchmark Suites 



 

Las compañías se ponen de acuerdo en un conjunto de programas y entradas reales Aún pueden ser “violados”… Buen indicador de performance (y tecnología de compiladores)

SPEC89 



Combinaciones de benchmarks sintéticos, focalizados en algún aspecto relevante: SPECCPU2000, SPECint1997, SPECfp1992, SPECWeb, SPECSFS, TPC-C, etc

SPEC (System Performance Evaluation Cooperative) 



(1/2)

10 programas resultan en un número único (“SPECmarks”)

SPEC92 

SPECInt92 (6 programas enteros) y SPECfp92 (14 programas de punto flotante), Flags del Compilador ilimitadas

11

Benchmarks 

SPEC95   









12 Integer 14 Floating Point

SPEC2006 



nuevo set de programas: SPECint95 (8 programas enteros) y SPECfp95 (10 programas de punto flotante) “benchmarks útiles por 3 años” Flags uniformes para todos los programas: SPECint_base95, SPECfp_base95

SPEC2000 



(2/2)

12 Integer 17 Floating Point

Los programas varían entre generaciones de SPEC Más información en http://www.spec.org/ 

Leer http://www.spec.org/cpu2006/Docs/readme1st.html

SPEC CPU2000: benchmarks de enteros

12

SPEC CPU2000: benchmarks de punto flotante

Resultados: SPECint 2000

13

Resultados: SPECfp 2000

Un ejemplo de optimización para que los números “den bien”: SPEC89 800





Un programa: 99% del tiempo en una única línea de código Ajustes (“mejoras”) al compilador en benchmarks “clave” introduce mejoras enormes (nasa7, matrix300)

700

600 tio ra 500 e c n a m r 400 fo r e p C E P 300 S 200

100

0

gcc

espresso

spice

doduc

nasa7

li

eqntott

matrix300

fpppp

tomcatv

Benchmark Compiler Enhanced compiler

14

La CPU no es todo… …otros benchmarks SPEC 

SPECint y SPECfp miden tareas de computación intensiva, enfatizando los siguientes elementos de la arquitectura:   



CPU Arquitectura de memoria Compiladores

NO atacan otros elementos tales como el sistema operativo, la red, los gráficos o el subsistema de E/S. Existen otros benchmarks que tienen en cuenta:        

Graphics and Workstation Performance High Performance Computing, OpenMP, MPI Java Client/Server Mail Servers Network File System Power and Performance Web Servers Virtualization (planificado)

Reportes de performance 





Los reportes deben permitir reproducir las mediciones de performance a otros investigadores Se deben publicar banderas del compilador para las métricas de base y optimizada (peak) Obs: ninguno de los benchmarks del SPEC CPU2006 tienen múltiples threads

15

Resumen de performance

(1/3)



Interesa tener UN número que resuma la performance de un sistema



Media Aritmética basada en el tiempo de ejecución:  



Media Armónica de “velocidades” (rates) basada en el tiempo de ejecución:  

 

Σ(Ti)/n Ti es el tiempo de ejecución del i-simo los n programas que componen la carga de trabajo

n/Σ(1/Ri) Ri es una función de 1/Ti (por ejemplo MIPS)

Pregunta: cual es la mezcla de programas mas adecuada para medir la performance? “Pesan” todos lo mismo? Como respuesta surgen las medias ponderadas…

Resumen de performance

(2/3)



Media Aritmética ponderada basada en el tiempo de ejecución:



Media Armónica ponderada de “velocidades” (rates) basada en el tiempo de ejecución:



Cómo se eligen los pesos?



SPEC benchmarks: Tiempo de Ejecución Normalizado con respecto a una “máquina canónica”, útil para representar escalas de performance (ej., X veces más rápido que VAX)



Media Geométrica del tiempo de ejecución normalizado:







 



Σ(W i*Ti)

n/Σ(Wi/Ri)

En la comparación de dos sistemas NO influye la referencia! ( Π Tj / Nj ) 1/n = Π ( Tj / Nj )1/n Tiempos de ejecución normalizados consistentes, independientes de la referencia (no se cumple si usamos la media aritmética para el tiempos de ejecución normalizado) Se cumple: la razón de las medias geométricas es igual a la media geométrica de la razón de performance

16

Resumen de performance Sistema A Programa P1 (segs) Programa P2 (segs) Tiempo total (segs) Media aritmética: W(1) Media aritmética: W(2) Media aritmética: W(3)

1 1000 1001 500,5 91,909 1,999

Sistema B Sistema C W(1) W(2) W(3) 10 20 0,5 0,909 0,999 100 20 0,5 0,091 0,001 110 40 55 20 18,19 20 10,09 20



W(1) pesa igual P1 y P2 W(2) peso inversamente proporcional a Tiempo de Ejecución en B W(3) peso inversamente proporcional a Tiempo de Ejecución en A



Comparar resultados de diferentes medias:

 

Programa P1 Programa P2 Media aritmética Media geométrica Tiempo total

(3/3)

Normalizado a A Normalizado a B Normalizado a C A B C A B C A B C 1 10 20 0,1 1 2 0,05 0,5 1 0,1 0,02 10 1 0,2 50 5 1 5,05 10 5,05 1 1,1 25,025 2,75 1 1 0,63 1 1 0,63 1,5811 1,58 1 0,11 0,04 9,1 1 0,36 25,025 2,75

1 1 1 1 1

Evaluación de Performance  

Para bien o para mal, los benchmarks son tomados en cuenta..... Los buenos productos tienen:  







El diseño se debe orientar a mejorar la performance de las cargas de trabajo (programas) reales, y no solamente los programas que ayudan a vender! Tiempo total de ejecución es un resumen consistente de la performance Para una arquitectura dada la mejora de la performance viene de:   



Buenos resultados en los benchmarks Buena forma de sumarizar la performance

Incremento de la frecuencia de reloj (sin afectar los CPI!) Mejora en la organización del procesador para baja los CPI Mejora en los compiladores para bajar CPI y/o recuento deinstrucciones

Cuidado con mejorar un solo aspecto!

17