Pipeline

PipelinePipeline

Até agora, nos prendemos muito em economizar espaço na memória e baratear o custo de uma máquina

Mas, e quando quisermos uma máquina mais veloz, isto é, com melhor desempenho?

1

Até aqui, sempre assumimos que o tempo de um ciclo era fixo e pré-definido. E por causa disso, o número de microinstruções a serem executadas definia o tempo gasto na execução do programa

Esquecendo um pouco a memória,vamos focar agora em comoreduzir o tempo gasto na execu-ção das microinstruções

A seguir, veremos o uso dopipeline

2

Até aqui, seguindo o modelo de Von Neumann, vimos que as etapas de execução de uma instrução seguem uma ordem: busca da instrução, identificação, busca dos operandos, execução da operação e armazenamento do resultado

Podemos representar desta forma, onde cada quadrado representa um subciclo:

3

BI

BOE AR

Vimos também que, por este modelo, uma nova microinstrução só pode ser executada após o término da anterior, mesmo que não haja interdependência entre elas

Esquematizando, teríamos:

Como otimizar este processo? 4

BI

BOE AR1

2

tempo

3

BI

BOE AR

B ...

CuriosidadesCuriosidades

Henry Ford (1863 – 1947) nasceu nos EUA, fundou a Ford – fábrica de auto- móveis – e defendia for- temente o consumismo Mas nada disso nos interessa

5

CuriosidadesCuriosidades

Ford utilizava a chamada “linha de montagem”, que consistia emespecializar seus empregados emfunções definidas O mesmo empregado passava todo o tempo realizando uma única tarefa, mais específica possível e repetidas vezes, de forma que a prática o levasse a diminuir a chance de erros e o fizesse gastar menos tempo para concluir a tarefa 6

Aplicaremos o “fordismo” aos nossos estudos: as componentes deverão estar exercendo suas funções sempre que possível, em vez de ter que esperar o que chamávamos de um ciclo para voltar a trabalhar

O ganho no desempenho é bastante significativo

7

BI

BOE AR1

2

tempo

3

BI

BOE AR

B ...BI

Aplicaremos o “fordismo” aos nossos estudos: as componentes deverão estar exercendo suas funções sempre que possível, em vez de ter que esperar o que chamávamos de um ciclo para voltar a trabalhar

O ganho no desempenho é bastante significativo

8

BI

BOE AR1

2

tempo

3

BI

BOE AR

BI

BOE AR

Dessa forma, assim que a busca de uma instrução for concluída, pode ser iniciada a busca da próxima, já que as componentes especializadas nesta tarefa (no caso, PC, IR e MAR) já estarão livres. E o mesmo serve para identificação, busca de operandos etc

Podemos chamar cada um dos quadrados de um estágio do pipeline

Antes, o tempo total era dado pelo tempo de uma instrução multiplicado pelo total de instruções:

t = n.tinst 9

No pipeline, o tempo de uma instrução é dado pelo número de estágios multiplicado pelo tempo de um estágio:

tinst = ne.te

E, se analisarmos o esquema de execução das instruções no pipeline feito há pouco, teremos o tempo total de execução no pipeline:

tpipe = tinst + (n – 1).te

= (ne + n – 1).te

Com isso, podemos conhecer o speedup, ou seja, o quanto mais rápido é a execução por pipeline em relação à arquitetura anterior

10

O cálculo se dá dividindo o tempo total t do modelo de Von Neumann pelo tempo gasto no pipeline, o que nos dá:

O número de estágios vai ser sempre muito inferior ao número de instruções, portanto podemos ignorar os valores ne e -1 no denominador. No numerador, isso não é possível por ser uma multiplicação, e não uma soma

Passamos a ter então:

11

Com o resultado, inferimos que a execução de um programa é, idealmente, ne vezes mais rápida no pipeline

É fácil visualizar isso:

12

Note que na área entre os pontilhados, 4 tarefas estão sendo executadas ao mesmo tempo, enquanto apenas uma estaria sendo no modelo antigo. Isto porque são 4 estágios

Lembre-se de que, em uma aplicação real, o esquema anterior teria centenas de microinstruções. Isto é, a área entre as linhas pontilhadas sempre vai ser a imensa maioria

Mas, como sempre, existem problemas

E é deles que vamos falar a partir de agora13

Dependência de dados Quando há dependência de dados entre instruções,

algumas componentes precisam se manter ociosas durante alguns ciclos

Isto caracteriza desperdício de tempo

14

a = b + cd = a + h

B E GRIBO

B E GRIBO

Vamos acompanhar a sucessão dos ciclos para entender o que acontece

IBO




15

a = b + cd = a + h

B E GRIBO

B E GRIBO

B

No primeiro ciclo, a instrução é buscada. Ou seja, ao seu final, a máquina apenas tem a instrução sem nem sequer saber o que significa, pois ainda não foi identificada

IBO




16

a = b + cd = a + h

B E GRIBO

B E GRIBO

IBO

B

Aqui, a máquina identifica a instrução “a = b + c” e já busca o valor dos operandos b e c. Neste mesmo ciclo, já é buscada a instrução “d = a + h”

IBO




17

a = b + cd = a + h

B E GRIBO

B E GRIBO

IBO E

IBO

Agora, aparece o problema. Neste ciclo, buscamos os operandos a e h da instrução 2, sendo que a é o resultado da instrução 1. E este resultado ainda não foi gravado, já que isto só terá sido feito ao final do ciclo seguinte

- -




18

a = b + cd = a + h

B E GRIBO

E GRIBO

Portanto, faz-se necessário esperar até que o valor de a esteja corretamente gravado em algum registrador

B

Note que, sem esse problema, levaríamos 5 ciclos para executar as 2 instruções. Com o impasse, levamos 2 ciclos a mais

Se a dependência de dados ocorresse seguidamente em 500 instruções, levaríamos 2 ciclos a mais para cada dependência

De pouco mais de 500 ciclos, a sequência passaria a levar cerca de 1500 ciclos para ser executada

Há ainda outro problema, muito mais comum do que a dependência de dados

19

Dependência de controle Sabemos que o endereço da instrução a ser buscada

na memória se encontra no registrador PC Sabemos também que, se não há desvios, a próxima

instrução a ser buscada está no endereço dado por pc (conteúdo de PC) + 1

No pipeline, busca-se uma instrução em um estágio, e já no próximo busca-se a instrução seguinte, no endereço pc + 1

20

21

Memória de Controle

MPCINC

MUX

AMUX

COND

N1

N0

LMS

ULANZ

Controle

Controle

Convém uma pequena revisão. Lembra-se deste esquema? É sobre como são feitos os desvios de instruções

ULA . . . . .

ADDR

Na verdade, não é necessário relembrar o que acontece em cada parte no desenho

Tudo o que precisamos ter em mente é que os desvios condicionais são realizados após alguma operação na ULA, a qual libera os sinais N e Z que contêm informações sobre a saída da ULA. Esta saída é, então, avaliada de acordo com a condição do desvio

Dito isso, conclui-se então que só no terceiro estágio saberemos se ocorrerá desvio

22B E GRI

BO

Isso significa que teremos problemas no pipeline se tivermos uma instrução parecida com:

Suponha que a instrução acima esteja no endereço 1 da memória principal

23

se a = 0 então goto 8

B E GRIBO

B E GRIBO

IBO



24


B E GRIBO

B E GRIBO

B

IBO

Neste ciclo, estaremos buscando a nossa instrução. PC contém seu endereço, então o conteúdo de PC é 1



25


B E GRIBO

B E GRIBO

IBO

B IBO

Agora, identificamos nossa instrução e buscamos o operando a. Vamos supor que este seja igual a 0. Neste mesmo ciclo, buscamos a próxima instrução, por default, no endereço pc + 1. Está sendo buscada, então, a instrução no endereço 2



26


B E GRIBO

B E GRIBO

I E

IBO

Porém, chegamos agora ao ciclo onde a primeira instrução é executada. A ULA dará como saída o próprio operando a, que será avaliado na lógica de microssequenciamento e, como é igual a 0, a execução do programa teria de ser desviada para a instrução no endereço 8 (goto 8)

- -



27


B E GRIBO

B E GRIBO

E agora? Constatamos anteriormente que a instrução no endereço 2 já foi buscada, e a máquina a essa altura já identificou e buscou os operandos dessa instrução que não nos interessa

- -



28


B E GRIBO

B E GRIBO

Mais uma vez, é necessário esperar alguns ciclos até que tenhamos a confirmação de que haverá desvio, para só depois buscar a próxima instrução

Nós, como projetistas da máquina, precisamos sempre buscar formas de passar por todos os obstáculos existentes em uma implementação

A saída geralmente é pensar em otimizações que diminuam o prejuízo causado por possíveis problemas de uma implementação

29

A primeira otimização, que qualquer bom compilador deve ser capaz de fazer, é uma arrumação na sequência de instruções a fim de diminuir ao máximo o número de ocorrências de dependência de dados em um programa

Vimos que a sequênciaa = b + c

d = a + h

causaria um desperdício de 2 ciclos na máquina Entretanto, o compilador pode “procurar” outras

instruções que nada tenham a ver com estas e executá-las neste espaço 30

Por exemplo, se houver no programa outras duas instruções de soma, a ordem de execução pode ser:

a = b + c

x = y + z

m = n + p

d = a + h

Desta forma, não haverá perda de tempo

31

B E GRIBO

B E GRIBO

B E GRIBO

B E GRIBO

a = b + c

x = y + z

m = n + p

d = a + h

O processador acaba de gravar o resultado em algum registrador

Inicia-se a busca dos operandos. Quando o registrador onde está a for consultado, lá já estará o valor correto de a

Outra otimização possível é conhecida como Data Forwarding

Consiste em buscar os operandos sem esperar que o resultado da instrução anterior seja gravado em um registrador, mesmo que um desses operandos seja esse resultado

32

ULA

Registradores

Na sequência:a = b + c

d = a + h

sabemos que a segunda instrução também pode ser escrita como “d = b + c + h”

Desta forma, não precisamos esperar até que o registrador da variável a seja atualizado para buscar os operandos da segunda instrução

Em outras palavras, não é necessário esperar chegarmos ao final do estágio onde o resultado é gravado (GR) para conhecermos um dos operandos da segunda instrução

33

34

- -

B E GRIBO

E GRIBOB

Antes, precisávamos do valor gravado em um registrador

35

- -

B E GRIBO

E GRIBOB

Agora, podemos reaproveitar este valor logo após o término da execução da operação na ULA

Esta seria uma opção bastante útil para um caso do tipo:

a = b + cd = a + ef = d + gh = f + ij = h + kx = j + h

Processadores como o da Intel possuem uma série de outras otimizações na implementação do pipeline

Prejuízos causados por dependência de controle são diminuídos com maneiras de “prever” se a instrução atual causará desvio na execução da sequência de instruções, com probabilidades altas de acerto

Outra otimização possível é armazenar certas informações quando houver desvios na instrução, para serem usadas quando esta instrução aparecer novamente. Por exemplo, em um loop onde são feitas 10 iterações, ocorrem 9 desvios para a mesma instrução (a primeira)

36

Acompanhe:

i <- 1;

para i = 1 até 10 faça

instrução 1;

instrução 2;

instrução 3;

i <- i + 1;

fim do loop

37

i = 1

Acompanhe:

i <- 1;


instrução 1;

instrução 2;

instrução 3;

i <- i + 1;

fim do loop

38

A condição é analisada e não ocorre desvio: entramos no loop

Acompanhe:

i <- 1;


instrução 1;

instrução 2;

instrução 3;

i <- i + 1;

fim do loop

39

Hora de analisar novamente se i é menor ou igual a 10

Acompanhe:

i <- 1;


instrução 1;

instrução 2;

instrução 3;

i <- i + 1;

fim do loop

40

Neste momento, i = 2, então para iniciar a segunda iteração...

Acompanhe:

i <- 1;


instrução 1;

instrução 2;

instrução 3;

i <- i + 1;

fim do loop

41

...desviamos de volta para a primeira instrução no loop

Há ainda uma última forma de otimização que melhora o desempenho da nossa máquina, conhecida como superpipelining

Vimos que a implementação do pipeline agiliza, idealmente, ne vezes a execução das instruções em relação à nossa máquina antiga

Ora, por que então usar apenas 4 estágios? Um dos processadores da Intel possui pipeline

de 20 estágios. Apenas para dar uma ideia, os primeiros 4 estágios são usados para operações de busca de instruções

42

. . .

. . .

B1 B2 B3 B4

Esta configuração caracteriza exatamente um superpipeline

Ok, 20 estágios já está melhor que 4. Mas por que não usar, talvez, 1000 estágios?

Para executar várias operações do mesmo tipo ao mesmo tempo, precisaríamos aumentar o número de componentes. No caso de 4 operações de busca, por exemplo, o processador precisa ter 4 PCs para armazenar o endereço dessas instruções, 4 IRs para armazenar as instruções propriamente ditas, etc

Aumentar o número de componentes encarece a máquina, o que tornaria um desastre elevar demais o número de estágios do pipeline 43

Muito bem, falamos bastante sobre como amenizar os revés do pipeline, mas não podemos esquecer que estes não são os únicos que afetam o desempenho da máquina

Até agora, economizamos alguns ciclos aqui, outros lá, já executamos várias instruções ao mesmo tempo e por aí vai

Mas não nos aprofundamos ainda em um outro problema que aumenta consideravelmente o tempo gasto pela máquina na execução de problemas: leitura e escrita na memória principal

Estas operações levam aproximadamente 100 ciclos para serem realizadas! 44

Pipeline

Documents

Transcript of Pipeline