UNIDADE IV�Avaliação de Desempenho

Prof. Júlio César Mesquita Ruzicki

ARQUITETURA DE COMPUTADORES

Avaliação de desempenho

2

• Algo difícil de fazer mesmo entre processadores da mesma família�
• a velocidade bruta não nos diz se um processador é melhor do que outro�
• informações como modo de endereçamento, largura de barramento, forma de execução das instruções dizem mais

Visão geral de medidas

3

• Sabe-se que o ciclo de clock é o tempo gasto para executar uma instrução sequencial (normalmente).�
• O ciclo de clock é finito e varia de acordo com o projeto do processador (tecnologia, custo, nicho alvo)�
• Ele não diz que é mais efetivo (não rápido)
• BlackFin( 400 MHz) e SHARC (200 MHz)

Visão geral de medidas

4

• No projeto físico do processador várias questões devem ser pensadas para se definir o clock
• grau de paralelismo na execução das instruções
• pipeline, execução fora de ordem?
• memória cache?
• tempo de acesso da RAM, banco de registradores
• A busca de instruções já é pesada!

Visão geral de medidas

5

• Diferentes instruções do mesmo processador podem exigir tempos diferentes para a execução
• No PIC (RISC) um salto usa 2 ciclos, sequenciais 1 ciclo.
• No 8051 (CISC), as instruções tomam vários ciclos�
• Portanto, frequência de clock não diz nada!

Taxa de execução de instruções

6

• Um programa executa um certa quantidade de instruções�
• I_c = contagem de instruções executadas (emitidas)
• traço dinâmico
• não confundir com código estático�
• Toda instrução gasta um nº de ciclos de clock, definimos como CPI (ciclos por instrução)

Taxa de execução de instruções

7

• O CPI varia de acordo com as instruções executadas�
• um programa apresenta um CPI médio�
• instruções como LOAD e STORE apresentam maior CPI do que INC e ADD.

​

• instruções de salto e controle também

Taxa de execução de instruções

8

• Podemos definir o CPI médio de um programa�

• T= Ic x CPI x Tc�Tc=1/fc

Taxa de execução de instruções

9

• Sabendo que a memória está incluída no processo de execução podemos escrever também:

T= Ic x [p + (m x k)] x Tc

​

Onde:�p= nº de ciclos para decodificar e executar uma instrução

m= nº de referências de memória necessária

k= razão entre o tempo de ciclo de memória e tempo de ciclo do processador

​

​

​

Fatores de desempenho

10

( Ic, p, m, k, Tc)

• Estes parâmetros são influenciados por 4 atributos do sistema:

1. O projeto do ISA.

2. Tecnologia do compilador (eficiência)

3. tecnologia de fabricação do processador

4. Hierarquia de memória

​

​

​

​

Taxa MIPS

11

• Uma medida usada mas não confiável

​

​

​

• Inadequada pois o MIPS varia de acordo com a natureza da aplicação
• fabricantes publicam como constante

​

​

Taxa MIPS

12

Taxa MIPS

13

• Uma medida usada mas não confiável
• Exemplo para processador de 400 MHz

​

​

​

​

​

• CPI= 0,6 x 1 + (2 x 0,18) + (4 x 0,12) + (8 x 0,1)= 2,24
• MIPS= (400 x 10⁶) /(2,24 x 10⁶)= 178

​

​

Taxa MFLOPS

14

• Muito usado em jogos
• Expressa a quantidade de operações em ponto flutuante

​

​

​

​

​

​

Benchmark

15

• Considere o código em C:
• A= B + C�
• Convertido para assembly CISC:
• add mem(A), mem(B), mem(C)�
• Convertido para assembly RISC:
• load reg1, mem(B)
• load reg2, mem(C)
• add reg3, reg2, reg1
• Store mem(A), reg3

​

​

​

​

​

​

​

Benchmark

16

• Weicker (1990) lista as características desejadas:
• escrito em alto nível para facilitar o transporte
• representar um nicho de mercado (redes, video, audio etc)
• ser medido com facilidade
• ter uma ampla distribuição (acessibilidade)

​

​

​

​

​

​

​

​

​

Avaliando Resultados

17

• É desejável a execução de vários programas do benchmarks nos processadores alvo�
• Podemos usar uma média harmônica ou aritmética�
• podemos ter interesse particular em alguma categoria mas ter conhecimento do comportamento nas demais.�
• No final devemos nos preocupar com o tempo de execução e não com a taxa de execução.

​

​

​

​

​

​

​

​

​

Avaliando Resultados

18

Avaliando Resultados

19

• A performance de um computador ou processador pode ser medido usando a expressão:
• Performance_X=1/tempo de execução_X�
• Podemos comparar dois computadores fazendo: (sendo X mais rápido que Y)
• n=Performance_X/Performance_Y=tempo de execução_Y/tempo de execução_X

​

Exemplo: um computador A executou um programa em 20 ms e o computador B executou o mesmo programa em 40 ms

• Performance_A=1/0,02= 50
• Performance_B=1/0,04= 25
• n=Performance_A/Performance_B= 2

​

​

​

​

Avaliando Resultados

20

• Tempo de CPU (tc)-> tempo gasto pela CPU para as computações do programas, excetuando acesso E/S.
• Tempo de CPU de usuário (tcu)-> tempo de cpu gasto na execução do programa.
• Tempo de CPU do sistema (tcs)-> tempo de cpu gasto pelo SO para executar o programa (ex.: serviços)

​

Exemplo: time sudo moserial

real 0m4.317s

user 0m0.226s

sys 0m0.047s

​

Te(real)=4,317s; tcu=0,226s; tcs=0,047s; tc=(tcu+tcs)/Te=0,063

​

​

​

​

​

Lei de Amdahl

21

• Quando projetamos um sistema a preocupação está no desempenho para executar o caso mais comum.
• Por isso os fabricantes têm famílias de processadores para cada nicho de mercado.
• Eles exploram a Lei de Amdahl:
• Uma aceleração é função do tempo que certa melhoria implementada é usada durante a execução de um programa

​

S(speedup)=tempo de execução sem a melhoria� tempo de execução com a melhoria

​

Lei de Amdahl

22

• Podemos calcular a aceleração S esperada para uma certa melhoria no processamento:

​

• Suponha uma melhoria que acelera parte da execução 10 vezes mas é executada apenas 40% do tempo.

​

te_novo=1*((1-0,4)+0,4/10)=0,64 s

S=1/0,64=1,5625

Lei de Amdahl

23

• Podemos reescrever a equação anterior da seguinte forma:

​

• Suponha que a operação de raiz quadrada em ponto-flutuante (sqrt) é responsável por 20% do tempo de execução. Uma implementação em hardware dessa operação irá torná-la 10 vezes mais rápida. Por outro lado, as instruções de ponto-flutuante (fp) são responsáveis por 50% do tempo de execução e podem ser melhoradas, a fim de serem executadas 2 vezes mais rápido.

​

​

Ssqrt

Sfp

O processador MIPS monociclo

24

O processador MIPS monociclo

25

• O tempo de ciclo é determinado pelo caminho crítico:
• Instrução lw (load word)
• lê instrução;
• leitura do registrador base, extensão do sinal;
• cálculo do endereço;
• leitura do dado na memória
• escrita no registrador.�
• Todas as instruções levam o mesmo tempo!

​

​

O processador MIPS monociclo

26

• Supondo os tempos abaixo:
• Acesso à memória: 10 ns;
• ULA e somadores: 10 ns;
• acesso ao banco: 5 ns;
• outros(mux, etc…): 0 ns;
• Considerando o exemplo: GCC: 22% lw, 11% sw, 49% tipo-R, 16% beq, 2% jump
• O tempo de uma instrução 40 ns;
• Se ao invés do tempo fixo usarmos um ciclo variável e suficiente para cada instrução:
• tempo de ciclo=40*0.22 + 35*0.11 + 30*0.49 + 25*0.16 + 10*0.02 = 31.6 ns
• Ganho= 40/31,6=1,27

​

​

O processador MIPS Multiciclo

27

• Apenas uma memória, com instruções e dados
• Incremento do PC, cálculo do endereço de desvio, operações lógico-aritméticas realizadas todas pela mesma unidade funcional
• Introdução e ampliação dos multiplexadores nas entradas da ULA
• Introdução do registrador de Instruções (RI), para armazenar a instrução lida

​

​

O processador MIPS Multiciclo

28

• Considerando o exemplo: GCC: 22% lw, 11% sw, 49% tipo-R, 16% beq, 2% jump
• � lw: 22% (5 ciclos)
• � sw: 11% (4 ciclos)
• � tipo-R: 49% (4 ciclos)
• � beq: 16% (3 ciclos)
• � jump: 2% (3 ciclos)
• CPI = 0.22 * 5 + 0.11 * 4 + 0.49 * 4 + 0.16 *3+ 0.02*3 =4,04

​

​

​

Técnicas de aceleração

29

• Pipeline não diminui o tempo de execução das instruções�
• É uma técnica que aumenta a taxa de execução de instruções�
• Faz melhor uso das unidades presentes na arquitetura

​

• Explora o paralelismo entre as instruções
• Um conjunto reduzido de instruções facilita
• poucas instruções que acessam a memória

Técnicas de aceleração

30

• Algumas características da arquitetura complicam:
• Desvios (esvaziar o pipeline)
• dependência de dados (quando a instrução depende do resultado da anterior)
• Propriedades estruturais, como memória única

Técnicas de aceleração

31

Uma pessoa leva 5 UT para montar um bicicleta

Técnicas de aceleração

32

Técnicas de aceleração

33

Técnicas de aceleração

34

• O pipeline apresenta uma latência de 5UT, neste exemplo
• Após isso temos uma bicicleta por ciclo UT.
• cada etapa precisa usar no máximo 1 UT.
• não pode haver uma tarefa com 2 UT.

Técnicas de aceleração

35

• Exemplo de tempo de execução das instruções

​

Técnicas de aceleração

36

• Usando pipeline

​

Técnicas de aceleração

37

• Caso do MIPS com 5 estágios

​

Técnicas de aceleração

38

• Caso do MIPS com 5 estágios

​

Técnicas de aceleração

39

• Caso do MIPS com 5 estágios

​

Técnicas de aceleração

40

• Caso do MIPS com 5 estágios

​

Técnicas de aceleração

41

• Caso do MIPS com 5 estágios

​

Técnicas de aceleração

42

Técnicas de aceleração

43

• Quando ocorre um conflito de dados o pipeline deve ser congelado
• Como?

​

Técnicas de aceleração

44

​

​

ld r2, I

ld r3, J

add r2, r2, #123

sub r3, r3, #567

st r2, I

st r3, J

​

​

​

• Outra possibilidade é rearranjar o código, executando fora de ordem

​

ld r2, I

add r2, r2, #123

st r2, I

ld r3, J

sub r3, r3, #567

st r3, J

​

​

Técnicas de aceleração

45

• Podemos adiantar os dados

​

​

Técnicas de aceleração

46

• Quando temos instruções de desvio o que fazer?

​

​

• O pipeline pode ser congelado, mas haverá perda

​

​

Técnicas de aceleração

47

• Prever o que fazer é melhor:
• podemos assumir que o salto sempre ocorrerá
• podemos assumir que o salto nunca ocorrerá
• podemos verificar um histórico (uso de memória)
• podemos executar algumas instruções antes do salto (compilador re-ordenando o código)

​

​

​

Bibliografia

ARQUITETURA E ORGANIZAÇÃO DE COMPUTADORES, William Stallings, Makron Books, 5^a edição, 2002.

Organização e Projeto de Computadores: a interface hardware/software, David A. Patterson, John L. Hennessy, Ed. Campus, 3a edição, 2005.

ORGANIZAÇÃO ESTRUTURADA DE COMPUTADORES, Andrew S. Tanenbaum, Ed. Prentice Hall (Pearson), 5^a edição, 2007.

ARQUITETURA DE COMPUTADORES PESSOAIS, Raul Fernando Weber, Série Livros Didáticos do Instituto de Informática da UFRGS, Editora Sagra Luzzatto, 7^a edição, 2000.

​

contato: julioruzicki@ifsul.edu.br

​

48