Execução concorrente de instruções

Execução concorrente de instruções Aspectos avançados João Canas Ferreira Outubro de 2010 João Canas Ferreira (FEUP) ILP Outubro de 2010 1 / 58 Assuntos 1 Previsão dinâmica de saltos 2 Sequenciamento dinâmico Algoritmo de Tomasulo 3 Distribuição de instruções 4 Emissão múltipla de instruções 5 Especulação por hardware 6 Limitações de concorrência a nível de instruções João Canas Ferreira (FEUP) ILP Outubro de 2010 2 / 58

Previsão dinâmica de saltos 1 Previsão dinâmica de saltos 2 Sequenciamento dinâmico Algoritmo de Tomasulo 3 Distribuição de instruções 4 Emissão múltipla de instruções 5 Especulação por hardware 6 Limitações de concorrência a nível de instruções João Canas Ferreira (FEUP) ILP Outubro de 2010 3 / 58 3

Previsão dinâmica de saltos Previsão dinâmica de saltos: o conceito A previsão (ou predição) de saltos condicionais é vital para processadores de elevado desempenho, porque evita que as dependências de controlo se tornem num factor limitativo. Esquema mais simples: tabela de previsão do resultado do teste branch-prediction buffer / branch history table. A tabela é uma memória indexada pelo bits menos significativos do endereço da instrução condicional. Cada posição tem 1 bit que indica se o salto foi recentemente tomado ou não. Problema de desempenho: um ciclo efectuado 10 vezes tem uma taxa de acerto de 80% (duas previsões erradas), embora fosse de esperar pelo menos 90%. (Porquê?) Solução: usar mais bits (2!) um contador com saturação. João Canas Ferreira (FEUP) ILP Outubro de 2010 4 / 58 4.1. Este esquema não tem etiquetas (como o esquema do acetato 10), e apenas reduz o tempo de salto, se o tempo necessário para calcular a condição for maior que o tempo de cálculo do endereço de destino. 4.2. Notar que a previsão pode ser efectuada com base na informação associada a um salto diferente daquele cujo desfecho se pretende calcular (mas que está colocado num endereço de memória que tem os os mesmos bits menos significativos). Tal pode reduzir a efectividade do mecanismo de previsão, mas não afecta a correcção do sistema (já que a predição deve ser sempre confirmada posteriormente). 4

Previsão dinâmica de saltos Esquema local de previsão de 2 bits Fonte: [CAQA3] João Canas Ferreira (FEUP) ILP Outubro de 2010 5 / 58 5.1. Os dois bits associados a cada posição servem para codificar quatro estados possíveis. O esquema pode ser generalizado para n bits, mas estudos empíricos indicam que a diminuta melhoria obtida não justifica a sua utilização. Por isso, a grande maioria dos sistemas usa tabelas de 2 bits por posição. 5.2. A utilização de 2 bits tem uma complicação: a tabela é actualizada mais frequentemente que no caso de uma tabela de 1 bit. Para tabelas de 1 bit por posição, a tabela é actualizada apenas quando ocorre uma falha de previsão. No caso das tabelas de 2 bits, a tabela deve ser actualizada a todos os acessos, i.e., a tabela é lida e escrita em todos os ciclos. 5

Previsão dinâmica de saltos Qualidade de previsão: medidas empíricas Fonte: [CAQA3] Benchmark SPEC89, IBM Power, 2 bits por posição, tabela de 4096 posições. João Canas Ferreira (FEUP) ILP Outubro de 2010 6 / 58 6.1. A taxa de falhas dos programas de vírgula flutuante é significativamente inferior à dos restantes programas. 6.2. Uma tabela de 4096 posições é considerada pequena. 6.3. Para determinar o efeito do tratamento de saltos para o desempenho global não basta conhecer o desempenho do previsor; também é necessário saber a taxa de ocorrência das instruções de salto. No caso dos resultados apresentados na tabela, são precisamente os programas em que a previsão mais falha aqueles que têm um maior número de saltos. 6

Previsão dinâmica de saltos Qualidade de previsão: tabela infinita Fonte: [CAQA3] Benchmark SPEC89, 2 bits por posição, tabela de 4096 posições vs. tabela infinita. João Canas Ferreira (FEUP) ILP Outubro de 2010 7 / 58 7.1. Os dados da tabela suportam a conclusão de que uma tabela com 4K posições tem um desempenho muito próximo daquele que seria obtido por uma tabela com um número infinito de posições. Logo, não é interessante aumentar o número de posições. 7.2. Como aumentar o número de bits por posição também não traz benefícios significativos, é necessário recorrer a previsores com uma estrutura mais sofisticada. 7

Previsão dinâmica de saltos Previsão com correlação Para melhorar a qualidade de previsão é necessário considerar o comportamento recente de outros saltos condicionais (previsão com correlação ou de dois níveis). if (aa==2) aa=0; if (bb==2) bb=0; if (aa!=bb) { DSUBUI R3,R1,#2 BNEZ R3,L1 ;salto b1 (aa!=2) DADD R1,R0,R0 ;aa=0 L1: DSUBUI R3,R2,#2 BNEZ R3,L2 ;salto b2 (bb!=2) DADD R2,R0,R0 ;bb=0 L2: DSUBU R3,R1,R2 ;R3=aa-bb BEQZ R3,L3 ;salto b3 (aa==bb) Se os saltos b1 e b2 não forem tomados, então b3 é certamente tomado, o que não pode ser previsto considerando apenas um único salto. João Canas Ferreira (FEUP) ILP Outubro de 2010 8 / 58 8.1. O exemplo mostra que, em geral, o desfecho de um salto condicional pode ser previsto melhor, se o desfecho dos saltos imediatamente precedentes for tido em conta. 8.2. Saltos precedentes são os executados imediatamente antes do salto que se pretende escrever, não aqueles ques estão colocados imediatamente antes no texto do programa. 8.3. O código do exemplo é retirado do program eqntott, um dos componentes do benchmark SPEC89. 8

Previsão dinâmica de saltos Previsão com correlação: um exemplo BNEZ R1,L1 ;salto b1 (d!=0) DADDIU R1,R0,#1 ; d==0, d=1 L1: DADDIU R3,R1,#-1 BNEZ R3,L2 ;salto b2 (D!=1)... L2: if (d==0) d=1; if (d==1) d=? prev. b1 acção b1 nova prev. b1 prev. b2 acção b2 nova prev. b2 2 NT T T NT T T 0 T NT NT T NT NT 2 NT T T NT T T 0 T NT NT T NT NT d=? prev. b1 acção b1 nova prev. b1 pred. b2 acção b2 nova prev. b2 2 NT/NT T T/NT NT/NT T NT/T 0 T/NT NT T/NT NT/T NT NT/T 2 T/NT T T/NT NT/T T NT/T 0 T/NT NT T/NT NT/T NT NT/T Previsor (0,1) X/Y X: previsão se último salto NT; Y: previsão se último salto T. Previsor (1,1) João Canas Ferreira (FEUP) ILP Outubro de 2010 9 / 58 9.1. Nestes exemplos, assume-se que todos os bits de previsto estão inicializados a NT (not taken). 9.2. Na tabela inferior, a notação P1/P2 indica que P1 é a previsão feita se o salto precedente não foi tomado, enquanto P2 é previsão feita se o salto precedente foi tomado. 9.3. Em geral, um previsor (m, n) usa o comportamente dos m saltos precedentes para escolher um de 2 m previsores, cada um dos quais é um previsor de n bits. 9.4. Neste contexto, diz-se que os m saltos precedentes constituem a história global, enquanto cada um dos previsores individuais regista a história local, i.e., o comportamento anterior do salto a previsão. 9

Previsão dinâmica de saltos Tabela com informação global e local Implementação de um buffer de previsão (2,2). Fonte: [CAQA3] João Canas Ferreira (FEUP) ILP Outubro de 2010 10 / 58 10.1. No caso do previsor (2,2) ilustrado na figura, história global é guardada num registo de deslocamento de 2 bits, que permite seleccionar uma de quatro tabelas. O endereço da instrução de salto é usado para escolher a posição da tabela. 10.2. O número de bits de um previsor (m, n) é dado por 2 m n nº de posições da tabela Como a utilização de k bits do endereço permite seleccionar uma de 2 k posições, o número de bits também é dado por 2 m n 2 k. 10

Previsão dinâmica de saltos Previsão com correlação: comparação empírica Fonte: [CAQA3] João Canas Ferreira (FEUP) ILP Outubro de 2010 11 / 58 11.1. Para comparar a efectividade de dois previsores diferentes, devem usar-se previsores com igual número de bits. Neste caso, o previsor (0,2) de 4096 posições é comparado com um previsor (2,2) de 1024 posições por tabela local. 11.2. A tabela mostra que um previsor com informação global permite reduzir significativamente a taxa de falhas, por comparação com um previsor local com o mesmo número de bits. 11

Previsão de torneio Previsão dinâmica de saltos Os previsores de torneio: constituem um exemplo de previsão multi-nível de saltos; usam múltiplas tabelas de previsão e um seleccionador para escolher qual usar; geralmente um nível baseia-se em informação global e outro em informação local; implementações actuais: contador saturado de 2 bits para escolher entre dois níveis; obtêm melhores resultados para tamanhos médios (8 Kb 32 Kb); cada tabela de previsão pode ter mais que um nível (p.ex. Alpha 21264). João Canas Ferreira (FEUP) ILP Outubro de 2010 12 / 58 12.1. Um previsor de torneio faz uma competição entre previsores, escolhendo em cada situação qual dos resultados deve usar (dos previsores em competição). Tipicamente, dois previsores estão em competição, sendo um deles global (p. ex., do tipo previsor por correlação) e o outro local (p. ex., previsor local do tipo (0,2)). 12.2. Previsores de torneio são o tipo mais frequente de previsores multi-nível. Um previsor multi-nível usa vários níveis de tabelas, em conjunto com um algoritmo para escolher entre os múltiplos previsores. 12

Previsão dinâmica de saltos Previsão de torneio: exemplo com 2 bits Fonte: [CAQA3] João Canas Ferreira (FEUP) ILP Outubro de 2010 13 / 58 13.1. Na prática, um previsor de torneio usa um contador com saturação para escolher entre dois previsores. Com base no endereço da intrução a prever, o previsor consulta uma tabela com 2 bits, que indicam o previsor a usar. Dependendo do resultado da previsão dos dois subprevisores, o contador é actualizado, conforme ilustrado na figura. 13.2. Para cada jogada do torneio existem 4 possibilidades: ambos os previsores acertam, ambos falham, previsor 1 acerta e o 2 falha, ou vice-versa. Quando ambos acertam ou falham simultaneamente, o previsor de torneio não muda de estado. 13.3. Na figura do acetato, a notação X/Y, em que X e Y podem ser 0 (falha) ou 1 (acerto), indica o desfecho de cada subprevisor. 13

Previsão dinâmica de saltos Previsão de torneio: selecção da tabela local Fonte: [CAQA3] Cada tabela tem 1024 posições, 2 bits cada; global: 2 bits João Canas Ferreira (FEUP) ILP Outubro de 2010 14 / 58 14.1. A figura mostra que a capacidade para trocar entre dois previsores é particularmente atraente no caso dos programas que não usam vírgula flutuante, já que neste caso, o recurso ao previsor global é bastante frequente (superior a 50% no caso de eqntott). 14

Previsão dinâmica de saltos Taxa de falhas para diferentes estratégias de previsão Fonte: [CAQA3] João Canas Ferreira (FEUP) ILP Outubro de 2010 15 / 58 15.1. A figura mostra o resultado de uma avaliação empírica de previsores com o mesmo número de bits, mas diferentes estruturas. Como seria de esperar, os previsores de torneio são os que apresentam melhor desempenho. 15.2. Como já se tinha observado em caso anteriores, a capacidade de previsão não melhora a partir de um certo tamanho. 15.3. Os dados foram obtidos para programas SPEC89. 15

Sequenciamento dinâmico 1 Previsão dinâmica de saltos 2 Sequenciamento dinâmico Algoritmo de Tomasulo 3 Distribuição de instruções 4 Emissão múltipla de instruções 5 Especulação por hardware 6 Limitações de concorrência a nível de instruções João Canas Ferreira (FEUP) ILP Outubro de 2010 16 / 58 16

Sequenciamento dinâmico O conceito de sequenciamento dinâmico Sequenciamento dinâmico: rearranjo da execução de operações efectuado pelo processador com o objectivo de reduzir os protelamentos, preservando o fluxo de dados. Vantagens: 1 Possibilita o tratamento de casos em que as dependências não são conhecidas em tempo de compilação; Importante para obter bons desempenhos sem comprometer a compatibilidade binária. 2 Simplifica o compilador; 3 Permite que código compilado para uma arquitectura de pipeline execute bem noutra; 4 Serve de base a especulação de hardware, uma técnica com vantagens apreciáveis para o desempenho. João Canas Ferreira (FEUP) ILP Outubro de 2010 17 / 58 17.1. O sequenciamento estático é aquele que é efectuado pelo compilador. 17.2. O sequenciamento estático é muito importante para processadores que não emitem instruções fora de ordem (emissão estática): a ordem óptima das instruções deve ser determinada pelo compilador, tendo em conta a organização do encadeamento de instruções. 17.3. Exemplo de utilidade de sequenciamento dinâmico: DIV.D ADD.D SUB.D F0, F2, F4 F10, F0, F8 F12, F8, F14 A dependência da instrução ADD.D em relação a DIV.D leva o CPU a protelar. Contudo, SUB.D não depende de nenhuma instrução anterior (em execução) e poderia executar imediatamente (sem esperar que as duas instruções precedentes sejam completamente ou parcialmente executadas.) 17

Sequenciamento dinâmico Redução do impacto de conflitos Situação: É detectado um conflito entre a instrução descodificada (andar ID) e uma instrução em execução. Solução 1: Esperar que a instrução em execução ultrapasse a fase que está na origem do conflito (protelar). Entretanto, todas as instruções posteriores à instrução em conflito são suspensas e nenhuma instrução adicional é processada. Solução 2: A instrução em conflito é suspensa (até que o conflito desapareça porque a instrução anterior passou um certo estágio) mas instruções posteriores continuam a respectiva execução (caso elas próprias não tenham conflitos) e novas instruções podem ser processadas. A solução 2 (sequenciamento dinâmico) é potencialmente mais vantajosa, mas implica a execução de instruções fora de ordem bem como a terminação fora de ordem. conflitos WAR e WAW; dificuldade na coordenação com excepções (imprecisão). João Canas Ferreira (FEUP) ILP Outubro de 2010 18 / 58 18.1. Neste contexto, execução refere-se ao processamento geralmente efectuado no(s) andar(es) EX. 18.2. O objectivo principal do sequenciamento dinâmico é evitar os conflitos causados por dependências (estruturais, de dados ou de controlo). 18.3. O sequenciamento dinâmico vem facilitado quando as instruções são simples, i.e. para conjuntos de instruções RISC. 18.4. Implementações da arquitectura IA-32, uma arquitectura CISC, convertem internamente as instruções em conjuntos de micro-operações. Estas últimas são sequenciadas dinamicamente e executadas. 18

Sequenciamento dinâmico Extensão de pipeline para sequenciamento dinâmico Dividir o andar ID em dois: 1 Emissão Descodificação da instrução e verificação de conflitos estruturais. 2 Leitura de operandos (RO) Esperar até que não haja conflitos de dados e, então, ler os operandos. IF coloca a instrução num registo ou numa fila de instruções pendentes; as instruções são emitidas a partir daí. Quando uma instrução passa de RO para EX começa a execução propriamente dita. Sequenciamento dinâmico permite ter múltiplas instruções em execução e requer unidades pipelined, múltiplas unidades funcionais, ou ambas. Assumir que as instruções são emitidas em ordem, mas podem entrar em execução fora de ordem. Abordagens: painel de resultados (scoreboard); algoritmo de Tomasulo. João Canas Ferreira (FEUP) ILP Outubro de 2010 19 / 58 19.1. Scoreboard foi usado pela primeira vez no CDC 6600. 19.2. As instruções passam do estado de emissão para o de RO em ordem. A passagem do estado RO para EX é que pode ser feita fora de ordem (de acordo com a disponibilidade dos operandos). 19.3. O tratamento de unidades pipelined é essencialmente idêntico ao de múltiplas unidades funcionais. Nos exemplos usados a seguir assumiremos que o processador tem múltiplas unidades funcionais. 19.4. A abordgem analisada caracteriza-se por ter emissão de instruções por ordem, mas execução fora de ordem : instruções posteriores podem ultrapassar outras instruções na fase RO. 19

Sequenciamento dinâmico Algoritmo de Tomasulo 1 Previsão dinâmica de saltos 2 Sequenciamento dinâmico Algoritmo de Tomasulo 3 Distribuição de instruções 4 Emissão múltipla de instruções 5 Especulação por hardware 6 Limitações de concorrência a nível de instruções João Canas Ferreira (FEUP) ILP Outubro de 2010 20 / 58 20

Sequenciamento dinâmico Algoritmo de Tomasulo Aspectos básicos do algoritmo de Tomasulo 1 Primeira utilização: unidade VF do IBM 360/91. 2 Existem muitas variações em uso actualmente. 3 Combina a monitorização da disponibilidade de operandos (evitar conflitos RAW) com register renaming (minimizar conflitos WAW e WAR). 4 Register renaming (RR) modifica o nome dos registos-destino de forma a que as escritas fora de ordem não afectem instruções que dependem de um valor anterior do operando. 5 Esta abordagem usa estações de reserva (ER) para implementar register renaming. Uma estação de reserva obtém e guarda um operando mal este esteja disponível; referências a registos são substituídas por referências a estações (instruções pendentes designam qual a estação que fornece os dados de entrada); quando ocorrem escritas sobrepostas, apenas a última é efectuada. 6 Se existirem mais estações que registos é possível eliminar conflitos que não podem ser eliminados pelo compilador. João Canas Ferreira (FEUP) ILP Outubro de 2010 21 / 58 21.1. O IBM 360/91 tinha apenas 4 registos de vírgula flutuante e não tinha memórias cache. As operações de VF eram longas e os acessos a memória também. 21.2. Ao contrário do MIPS, o IBM 360/91 permite acessos a memória nas instruções de vírgula flutuante. 21.3. O acesso a memória é mediado por uma unidade especializada (e não integrado directamente na pipeline de processamento). 21

Sequenciamento dinâmico Algoritmo de Tomasulo Eliminação de dependências por registos adicionais DIV.D F0,F2,F4 DIV.D F0,F2,F4 ADD.D F6, F0,F8 ADD.D S,F0,F8 S.D F6,0(R1) S.D S,0(R1) SUB.D F8,F10,F14 SUB.D T,F10,F14 MUL.D F6,F10, F8 MUL.D F6,F10,T (Supondo a existência de dois registos auxiliares S e T.) No código original existem 3 dependências verdadeiras e 2 dependências de nome: Antidependência entre ADD.D e SUB.D via F8 conflito WAR. Dependência de saída entre ADD.D e MUL.D via F6 conflito WAW. A utilização de registos auxiliares elimina as dependências de nomes. No caso actual, os registos são os buffers das estações de reserva. João Canas Ferreira (FEUP) ILP Outubro de 2010 22 / 58 22.1. Um CPU que implemente RR consegue fazer as alterações equivalentes à do exemplo durante o processamento do fluxo de instruções. 22.2. Este caso particular também pode ser resolvido por sequenciamento estático (feito por compilador), se existirem registos livres. 22.3. O uso de estações de reserva tem dois outros aspectos importantes: 1. O controlo da execução e a detecção de conflitos são distribuídos. 2. Resultados de uma unidade funcional são passados directamente para buffers de ER que deles necessitem (sem passar pelo banco de registos). 22

Sequenciamento dinâmico Algoritmo de Tomasulo MIPS adaptado para o algoritmo de Tomasulo Fonte: [CAQA3] João Canas Ferreira (FEUP) ILP Outubro de 2010 23 / 58 23.1. A figura mostra a estrutura da unidade de VF do MIPS adaptada para utilização do algoritmo de Tomasulo. (O tratamento de dados inteiros não está ilustrado.) 23.2. O sistema inclui uma unidade load/store para tratamento dos acessos a memória (para valores VF). 23.3. Cada estação de reserva inclui os operandos, a indicação da operação e alguns bits de controlo. 23.4. Funções do load buffer: 1. Armazenar componentes necessários ao cálculo do endereço efectivo até este ser realizado (guardar offset até valor do registo ser conhecido). 2. Registar as operações de load à espera de valores da memória. 3. Guardar valores lidos até puderem ser passados ao CDB. 23.5. Funções do store buffer: 1. Como para load buffer. 2. Armazenar endereço efectivo enquanto espera pelo valor a guardar em memória. 3. Armazenar endereço efectivo e dados enquanto a unidade de memória não estiver livre. 23

Sequenciamento dinâmico Etapas do algoritmo de Tomasulo Algoritmo de Tomasulo 1 Emissão Obter a próxima instrução de fila de instruções. Se existir uma ER apropriada vazia, emitir instrução para a ER com os operandos (se existirem). Se não existirem ER vazias, a instrução é suspensa. Se os operandos não estão nos registos, referenciar as unidades que os produzem (register renaming). 2 Execução Se algum dos operandos ainda não está disponível, monitorar o barramento comum até que apareça. Quando todos os operandos estão disponíveis, a operação pode ser efectuada. (Assim evitam-se os conflitos RAW). Múltiplas instruções podem ter a possibilidade de entrar em execução simultaneamente. 3 Escrita Quando o resultado está disponível, é enviado via CDB para o registo e para todas as ER (incluindo o store buffer). João Canas Ferreira (FEUP) ILP Outubro de 2010 24 / 58 24.1. Um acesso a memória é feito em dois tempos: 1. Cálculo do endereço efectivo quando o valor do registo base estiver disponível. O resultado é guardado no buffer. 2. O segundo tempo depende do tipo de acesso: a) Loads executam mal a unidade de memória esteja livre. b) Stores podem ter de esperar pelo valor a guardar. Quando este estiver disponível, é armazenado no store buffer e a instrução fica à espera de utilizar a unidade de memória. 24.2. Para evitar conflitos nos acessos a memória, o cálculo do endereço efectivo é sempre feito por ordem e é seguido de uma verificação de conflitos. Caso seja detectado um conflito, a colocação de novos acesso na unidade load/store é suspensa até que o conflito desapareça. 24

Sequenciamento dinâmico Tratamento de acessos a memória Algoritmo de Tomasulo Os acessos a memória processam-se em dois passos: 1 Calcular o endereço efectivo quando o registo de base está disponível e colocá-lo no buffer correspondente (load/store). 2 Executar load quando a unidade de memória estiver disponível; Store espera pelo valor a guardar (já no store buffer) antes de aceder a memória. Quando load e store acedem à mesma posição, então se 1 load precede store: trocá-los provoca WAR; 2 store precede load: trocá-los provoca RAW; 3 store precede store: trocá-los provoca WAW. Para detectar estas situações, é necessário conhecer os endereços de qualquer acesso a memória precedente. Condição suficiente: calcular os endereços efectivos por ordem e comparar (em paralelo) com os endereços nos buffers. João Canas Ferreira (FEUP) ILP Outubro de 2010 25 / 58 25.1. Acessos a memória podem ser feitos por uma ordem diferente da especificada no programa desde que acedam a posições diferentes de memória. 25.2. Consequências: Para determinar se uma operação de load pode ser executada, o processador deve determinar se existe alguma instrução de store ainda pendente para o mesmo endereço. Para uma operação de store é necessário verificar se não existe nenhum acesso anterior pendente para o mesmo endereço. Este processo é designado por desambiguação dinâmica de memória (dynamic memory disambiguation). 25.3. Para garantir estas condições, basta calcular o endereço efectivo pela ordem especificada no programa e fazer a respectiva verificação. Caso esta indique um conflito, o tratamento de instruçõe load/store protela. 25

Sequenciamento dinâmico Algoritmo de Tomasulo Algoritmo de Tomasulo: Sumário Sequenciamento dinâmico permite obter muito bons desempenhos (desde que os saltos sejam bem previstos). Algoritmo de Tomasulo é particularmente favorável para arquitecturas: para as quais é difícil sequenciar instruções estaticamente; têm poucos registos; em que se pretende obter elevado desempenho sem compilação específica. Desvantagens do algoritmo de Tomasulo: complexidade: cada ER tem uma memória associativa e controlo sofisticado ; CDB limita o desempenho: múltiplos CDBs podem ser usados, mas complicam ainda mais a implementação. João Canas Ferreira (FEUP) ILP Outubro de 2010 26 / 58 26.1. Referência original: R. M. Tomasulo, An Efficient Algorithm for Exploiting Multiple Arithmetic Units, IBM Journal of Research and Development, Volume 11, Number 1, pp. 25 33 (1967), http://www.research.ibm.com/journal/rd/111/tomasulo.pdf 26

Distribuição de instruções 1 Previsão dinâmica de saltos 2 Sequenciamento dinâmico Algoritmo de Tomasulo 3 Distribuição de instruções 4 Emissão múltipla de instruções 5 Especulação por hardware 6 Limitações de concorrência a nível de instruções João Canas Ferreira (FEUP) ILP Outubro de 2010 27 / 58 27

Distribuição de instruções Aumentar o desempenho da distribuição de instruções Para desempenho de pipelines é vital ter a capacidade de distribuir as instruções pelas unidades funcionais em tempo útil. tabelas de destinos de saltos (branch-target buffer); associar instruções a destinos de saltos de maneira a obter o destino do salto ainda em IF; unidades integradas de obtenção de instruções (integrated instruction fetch unit); unidades de previsão de endereços de retorno tratamento de saltos indirectos (85% dos saltos indirectos de SPEC86). Máximo actual: emissão de 4 8 instruções por ciclo. João Canas Ferreira (FEUP) ILP Outubro de 2010 28 / 58 28.1. Prever os saltos não é suficiente para garantir elevado desempenho. O que é preciso é assegurar a capacidade de fornecer as instruções atempadamente ao núcleo de processamento. A previsão de saltos é o primeiro e imprescindível passo, mas outras medidas são necessárias. As mais elementares são as indicadas no acetato. 28

Distribuição de instruções Tabela de destinos de saltos Fonte: [CAQA3] Apenas regista informação sobre ciclos tomados. João Canas Ferreira (FEUP) ILP Outubro de 2010 29 / 58 29.1. Os mecanismos de previsão de salto analisados até aqui não trazem benefício algum para a pipeline MIPS, já que o desfecho do salto é determinado em simultâneo com o endereço de destino: ambos estão disponíveis no ciclo ID. 29.2. Para obter melhor desempenho, usa-se uma tabela, que, para cada salto (previsto como tomado), regista o endereço de destino. 29.3. Notar que a existência de uma etiqueta é mesmo necessária. A ambiguidade existente nas tabelas de saltos não pode existir aqui. Isso implicaria que, em caso de acerto (sem confirmação de etiqueta), poderia ser escolhido um endereço de destino referente a outro salto. 29.4. A tabela de destino de saltos é acedida no ciclo IF. Caso haja um acerto, o endereço da próxima instrução fica imediatamente disponível, e pode ser usado no ciclo de relógio seguinte. (Pipeline MIPS deixa de protelar.) 29.5. O texto da terceira coluna do figura é enganador: a tabela guarda informação sobre saltos tomados. Por isso, a terceira coluna é optativa. 29.6. A utilização de previsores de 2 bits implica guardar informação sobre saltos não tomados. Muitos sistemas utilizam simultaneamente uma tabela de previsão de saltos e uma tabela de destino de saltos. A alternativa é incluir na tabela de destino de saltos informação para os saltos não tomados (a existência de uma 3ª coluna seria obrigatória). 29

Distribuição de instruções Tratamento de saltos com previsão de destino Fonte: [CAQA3] João Canas Ferreira (FEUP) ILP Outubro de 2010 30 / 58 30.1. A figura mostra em que ciclos é que as diferentes tarefas associadas à utilização de uma tabela de destino de saltos são efectuadas. 30.2. A penalidade por uma previsão mal feita é de 2 ciclos, o que é maior que o protelamento associado a um salto na ausência de tabela de destino de saltos (TDS). Por outras palavras, a utilização de uma TDS diminui o número de vezes que é necessário protelar, mas aumenta a penalidade naquelas situações em que não se consegue evitar o protelamento. 30

Distribuição de instruções Unidade integrada de obtenção de instruções Unidade autónoma que alimenta o resto da pipeline. As suas funções são: previsão de saltos integrada A previsão de saltos é integrada na unidade de obtenção de instruções para alimentar a pipeline de obtenção de instruções com os valores previstos; pre-obtenção de instruções A unidade obtém instruções antes de estas serem referenciadas; acesso a memória de instruções A obtenção de múltiplas instruções por ciclo coloca vários problemas (p.ex. múltiplas leituras de cache), cujo tratamento é encapsulado por esta unidade; também proporciona armazenamento temporário (buffering). João Canas Ferreira (FEUP) ILP Outubro de 2010 31 / 58 31.1. Para atingir os níveis de desempenho desejado, a maior parte dos processadores recentes opta por usar uma unidade integrada de obtenção de instruções (integrated instruction fetch unit). Esta unidade é autónoma e a sua tarefa é alimentar a pipeline de execução. 31.2. À medida que aumenta o número de instruções que podem ser emitidas por ciclo (ver acetato 16), esta unidade pode transformar-se num gargalo de desempenho. 31.3. Esta unidade é a que faz a interface com a memória. 31

Distribuição de instruções Previsão de endereços de retorno A previsão de saltos indirectos (i.e., via registos) não é feita eficientemente pelas estratégias já referidas. Branch-target prediction funciona, mas não é eficaz. (Porquê?) O retorno de subrotinas constitui cerca de 85% dos saltos indirectos. O processador mantém uma pilha de endereços de retorno: coloca aí um endereço quando executa uma chamada e retira um quando faz um retorno. Pilhas suficientemente grandes permitem prever perfeitamente os endereços de retorno. João Canas Ferreira (FEUP) ILP Outubro de 2010 32 / 58 32.1. A previsão de destino de saltos não é eficaz, porque o destino do salto (associado ao retorno de uma função) não é sempre o mesmo. 32

Distribuição de instruções Previsão de endereços de retorno: profundidade da pilha Fonte: [CAQA3] João Canas Ferreira (FEUP) ILP Outubro de 2010 33 / 58 33.1. Como o número de invocações pendentes de subrotinas é geralmente reduzido (com algumas excepções), pequenas pilhas de endereços de retorno funcionam bastante bem. Nos resultados apresentados no gráfico, uma pilha de 8 posições é suficiente para prever correctamente os retornos de função de todos os programas, excepto um. O benchmark li é um interpretador de LISP a executar um programa recursivo. 33.2. Para estes seis programas, o retorno de subrotinas representa 81% de todos os saltos indirectos. 33

Emissão múltipla de instruções 1 Previsão dinâmica de saltos 2 Sequenciamento dinâmico Algoritmo de Tomasulo 3 Distribuição de instruções 4 Emissão múltipla de instruções 5 Especulação por hardware 6 Limitações de concorrência a nível de instruções João Canas Ferreira (FEUP) ILP Outubro de 2010 34 / 58 34

Emissão múltipla de instruções Emissão de mais que uma instrução por ciclo Para obter CPI<1 é necessário emitir mais que uma instrução por ciclo. Processadores com emissão múltipla dividem-se em: 1 Processador super-escalar: número variável de instruções por ciclo, sequenciamento dinâmico (ou estático), execução fora de ordem. 2 Processador VLIW (very long instruction word): número fixo de instruções por ciclo ou pacote de instruções com concorrência explicitamente indicada (EPIC explicit parallel instruction computer); sequenciamento estático. Para cada instrução de um pacote de instruções: examinar as instruções por ordem; instruções em conflito com instruções em execução ou com instruções anteriores do pacote não são emitidas. Na prática, as instruções de um pacote são todas examinadas concorrentemente; a complexidade da tarefa obriga a usar uma pipeline no andar de emissão (aumenta a importância da previsão). João Canas Ferreira (FEUP) ILP Outubro de 2010 35 / 58 35.1. Processadores VLIW estão muito dependentes da qualidade do compilador, que, por sua vez, deve ter um conhecimento detalhado da microarquitectura do processador. 35.2. Processadores superescalares mais antigos e processadores para sistemas embutidos usam sequenciamento estático. Por exemplo, o processador Blackfin (Analog Devices) permite executar 2 instruções de 16 bits em paralelo com uma instrução de 32 bits. 35

Emissão múltipla de instruções Caracterização de processadores com multi-emissão Nome comum Super-escalar (estático) Super-escalar (dinâmico) Super-escalar (especulação) Emissão Detecção de conflitos Sequenciamento Característica marcante dinâmica hardware estático execução em ordem dinâmica hardware dinâmico execução fora de ordem dinâmica hardware dinâmico com especulação execução fora de ordem com especulação VLIW/LIW estática software estático sem conflitos entre pacotes de instruções EPIC Fonte: [CAQA3] sobretudo estática sobretudo software geralmente estático dependências explícitas Exemplo Sun Ultra SPARC II/III IBM Power2 Pentium 4, MIPS R10K, IBM RS64III Trimedia, i860 Itanium João Canas Ferreira (FEUP) ILP Outubro de 2010 36 / 58 36.1. O tratamento que se segue está focado nos três primeiros tipos de multi-emissão indicados na tabela. 36

Emissão múltipla de instruções Emissão estática para processadores superscalares Emissão de um número variável de instruções (típico 0 8). Instruções são emitidas por ordem e todos os conflitos são detectados durante o processo de emissão. Detecção de conflitos envolve as outras instruções em emissão, bem como as já emitidas. Emissão estática: o processador não toma decisões sobre a emissão simultânea de instruções; isso é tarefa do compilador. Pacote de emissão: grupo de instruções produzido pela unidade de obtenção de instruções (fetch unit) que potencialmente podem ser emitidas num ciclo. Emissão de instruções é uma tarefa complexa: é frequentemente dividida em 2 (às vezes mais) etapas em pipeline. João Canas Ferreira (FEUP) ILP Outubro de 2010 37 / 58 37.1. São emitidas 0 instruções quando o processador está em protelamento. 37.2. Quando uma instrução exibe uma dependência de dados ou não verifica os outros critérios de emissão (conflito estrutural), apenas as instruções que a precedem serão emitidas. 37.3. A verificação dos requisitos para emissão das instruções é feito no primeiro andar da pipeline de emissão e inclui a detecção de conflitos com instruções ainda na pipeline de emissão (e não apenas com as instruções já emitidas). 37.4. Uma estratégia comum é a seguinte: 1. O primeiro andar determina quantas instruções podem ser emitidas, ignorando dependências de instruções já emitidas. 2. o segundo andar examina as dependências entre as instruções seleccionadas e as instruções em execução. 37.5. Pipelines de emissão de instruções aumentam ainda mais a penalidade por erros de previsão de saltos, implicando assim um aumento da importância da qualidade da previsão. 37.6. A emissão de instruções pode limitar o período de relógio, constituindo assim um obstáculo ao aumento do desempenho por via do aumento da frequência. 37

Emissão múltipla de instruções Exemplo: 2-issue MIPS com emissão estática 1 instrução VF + 1 instrução inteira (ALU, load/store); esta organização minimiza os conflitos adicionais em relação à emissão simples; pacote de emissão: possível conflito RAW entre instrução load/store de VF e operação VF. soma VF: 3 ciclos. Fonte: [CAQA3] João Canas Ferreira (FEUP) ILP Outubro de 2010 38 / 58 38.1. As duas pipelines são quase independentes. Não esquecer que existem dois bancos de registos diferentes (um para valores inteiros e outro para valores de vírgula flutuante). 38.2. Neste cenário, acessos a memória são consideradas instruções inteiras. 38.3. As maiores dificuldades na detecção de conflitos envolvem a leitura e a escrita em memória de valores de vírgula flutuante. Também podem surgir problemas com instruções de movimento de dados entre os dois bancos de registos. 38.4. Restrições ao tipo de instruções que podem ser emitidas em simultâneo são comuns em prcessadores multi-emissão. 38

Emissão múltipla de instruções Emissão dinâmica: exemplo 1 Características: MIPS, dual-issue, extensão do algoritmo de Tomasulo à unidade inteira, 2 CDBs; Emissão de duas instruções por ciclo (para unidades diferentes); Instruções só executam após o tratamento do salto condicional de que dependem; Andares de escrita dos resultados (1 ciclo); Latências: inteiros, 1 ciclo; loads, 2 ciclos; soma VF: 3 ciclos; Unidade de tratamento de saltos. LOOP: L.D F0, 0(R1) ADD.D F4, F0, F2 S.D F4, 0(R1) DADDIU R1, R1, #-8 BNE R1, R2, LOOP João Canas Ferreira (FEUP) ILP Outubro de 2010 39 / 58 39.1. As duas principais estratégias para emitir duas instruções por ciclo são: 1. executar a emissão de cada instrução em meio-ciclo (ncluido a verificação de dependências); 2. emitir mesmo as duas instruções em paralelo (incluido o tratamento de todas as dependências entre instruções em emissão). Muitos processadores modernos usam as duas abordagens simultaneamente para emitir 4 ou mais instruções por ciclo. 39

Emissão múltipla de instruções Exemplo 1: Sequência de execução Fonte: [CAQA3] João Canas Ferreira (FEUP) ILP Outubro de 2010 40 / 58 40.1. Neste exemplo assume-se que instruções podem ser emitidas, mesmo quando existem dependências entre elas, ficando nesse caso a aguardar a resolução do conflito nas respectivas estações de reserva. 40.2. A unidade de vírgula flutuante é pipelined. 40.3. Assumir a existência de dois CDBs e previsão de saltos perfeita. 40.4. A condição de salto é avaliada na etapa de execução. 40.5. Taxa de emissão (no exemplo): 5/3 = 1.67. 40.6. Taxa de execução (IPC) : 15/16 = 0.94. 40.7. Se não existirem protelamentos por falha da previsão de saltos, as estações de reserva ficarão todas preenchidas e torna-se necessário protelar. 40.8. A vantagem sobre emissão simples é pequena, porque este ciclo apenas tem uma instrução de vírgula flutuante. Neste caso, é a unidade inteira limita o desempenho. 40

Emissão múltipla de instruções Exemplo 1: Utilização de recursos Fonte: [CAQA3] João Canas Ferreira (FEUP) ILP Outubro de 2010 41 / 58 41.1. Cada entrada da tabela indica quando é que a correspondente unidade está a ser usada: iteração/instrução. 41.2. Para este exemplo, apenas um CDB é necessário. Por isso, o segundo CDB não está representado. 41.3. Notar que a unidade inteira é bastante usada. 41

Emissão múltipla de instruções Emissão dinâmica: exemplo 2 Duas unidades inteiras distintas: uma para operações (ALU) e outra para cálculo do endereço efectivo. Fonte: [CAQA3] João Canas Ferreira (FEUP) ILP Outubro de 2010 42 / 58 42.1. Neste exemplo existe uma unidade adicional para realizar o cálculo dos endereços de memória. 42.2. As três iterações executam agora em 11 ciclos (entrada em execução da última instrução), 5 ciclos menos que no exemplo anterior: IPC = 15/11 = 1.36; CPI = 0.73. 42

Emissão múltipla de instruções Exemplo 2: utilização de recursos Fonte: [CAQA3] João Canas Ferreira (FEUP) ILP Outubro de 2010 43 / 58 43.1. Neste caso, já são necessários dois CDBs. 43.2. A taxa de utilização das unidades funcionais é, globalmente, baixa. 43.3. Observação geral sobre os dois exemplos: é a dependência de controlo que impede de obter maior eficiência. 43

Especulação por hardware 1 Previsão dinâmica de saltos 2 Sequenciamento dinâmico Algoritmo de Tomasulo 3 Distribuição de instruções 4 Emissão múltipla de instruções 5 Especulação por hardware 6 Limitações de concorrência a nível de instruções João Canas Ferreira (FEUP) ILP Outubro de 2010 44 / 58 44

Execução especulativa Especulação por hardware Processadores de elevado desempenho precisam de executar mais que uma instrução de salto por ciclo. Especular: Prever os saltos e executá-los (não apenas emiti-los)! Especulação combina três conceitos: 1 previsão dinâmica de saltos; 2 execução especulativa de instruções antes de resolver conflitos de controlo (com capacidade de anulação); 3 sequenciamento dinâmico. Separação entre encaminhamento dos resultados para as operações e terminação da instrução: a instrução só armazena resultados quando for confirmado que os resultados são válidos. Guardar os resultados num reorder buffer (ROB) até ao estágio de instruction commit ( compromisso ). Especulação permite aplicar o sequenciamento dinâmico simultaneamente a mais que um bloco básico. João Canas Ferreira (FEUP) ILP Outubro de 2010 45 / 58 45.1. A execução especulativa pressupõe a capacidade de anular os efeitos de instruções executadas especulativamente. 45.2. Execução especulativa é usado em PowerPC 603/604/G3/G4, MIPS R10000/R12000, Pentium II/III/4, Alpha 21264, AMD K5/K6/Athlon. 45.3. É necessário separar a realização dos cálculos da finalização da instrução: introduzir uma nova fase de finalização (designada por commit or retirement). 45.4. A finalização é feita pela ordem das instruções no fio de execução: é essa a função do reorder buffer. (Existem ainda outras alternativas para obter o mesmo efeito.) 45

Especulação por hardware Hardware para especulação Fonte: [CAQA3] João Canas Ferreira (FEUP) ILP Outubro de 2010 46 / 58 46.1. Exemplo aplicado à unidade de vírgula flutuante usada para ilustrar o sequenciamento dinâmico. A extensão para o CPU completo é conceptualmente simples. 46.2. Por comparação com a versão anterior, acrescentou-se o ROB e removeu-se o store buffer, cujo papel passa a ser desempenhado pela ROB. 46.3. Neste esquema, apenas um instrução pode ser finalizada em cada ciclo de relógio. O mecanismo pode ser aumentado usando mais que um CDB. 46

Especulação por hardware Reorder buffer O reorder buffer (ROB) fornece registos temporários adicionais para guardar resultados entre o instante em que a instrução termina a execução e faz commit. ROB também é fonte de operandos. ROB é similar ao store buffer; na prática, o ROB combina a funcionalidade de ambos. O ROB tem a seguinte informação para cada instrução emitida: 1 tipo de instrução (salto sem resultado; store resultado em memória;alu/load resultado em registo). 2 destino (onde guardar o resultado); 3 valor; 4 ready indica se o valor é válido. Cada instrução é referenciada pela sua posição no ROB. João Canas Ferreira (FEUP) ILP Outubro de 2010 47 / 58 47.1. O reorder buffer fornece registos extra, de forma similar aos que são fornecidos pelas estações de reserva. 47.2. Os operandos são etiquetados pela sua posição no ROB (e não nas estações de reserva). 47

Especulação por hardware Etapas do processamento de instruções Emissão Obter instrução da fila de instruções. Emitir a instrução se existirem uma ER e uma posição no ROB livres. Enviar operandos para ER se estiverem disponíveis nos registos ou no ROB. [dispatch] Execução Se algum dos operandos não estiver disponível, monitorar o CDB. Store só necessita do cálculo do endereço efectivo. Quando os operandos estão disponíveis, executar a instrução, possivelmente em múltiplos ciclos. [issue] Escrita Enviar resultado via CDB para ROB e ER. Para stores o valor (o endereço) é guardado no ROB. Commit A acção depende do tipo de instrução: Salto mal previsto: limpar ROB e recomeçar processamento com instrução a seguir ao salto. Operação normal: a instrução chega ao topo do ROB com o resultado presente; este é enviado para o registo. [completion] No fim, a posição do ROB é libertada. Quando o ROB fica cheio, a emissão de instruções é suspensa. João Canas Ferreira (FEUP) ILP Outubro de 2010 48 / 58 48.1. A fase de emissão também é designada por despacho (dispatch). 48.2. A detecção de conflitos RAW é feita na fase de execução. 48.3. Instruções de escrita em memória (load) ficam neste estado até o valor a escrever estar disponível. 48.4. As instruções do ROB entram em commit por ordem. Deste ponto de vista, o ROB porta-se como uma fila. 48

Especulação por hardware Exemplo: Emissão dupla sem especulação Fonte: [CAQA3] João Canas Ferreira (FEUP) ILP Outubro de 2010 49 / 58 49.1. O fragmento de código incrementa os elementos de um vector. 49.2. A instrução L.D a seguir ao salto condicional BNE necessita de esperar pelo resulado do salto. 49.3. O exemplo assume a existência de uma unidade de cálculo de endereços e emissão dupla (conforme o exemplo do acetato 23. 49

Especulação por hardware Exemplo: Emissão dupla com especulação Fonte: [CAQA3] João Canas Ferreira (FEUP) ILP Outubro de 2010 50 / 58 50.1. Esta versão executa mais depressa (a última instrução do exemplo tem início no ciclo 13) devido à execução especulativa da instrução L.D. 50.2. O aumento do desempenho é extremamente dependente da previsão correcta dos saltos. 50

Limitações de concorrência a nível de instruções 1 Previsão dinâmica de saltos 2 Sequenciamento dinâmico Algoritmo de Tomasulo 3 Distribuição de instruções 4 Emissão múltipla de instruções 5 Especulação por hardware 6 Limitações de concorrência a nível de instruções João Canas Ferreira (FEUP) ILP Outubro de 2010 51 / 58 51

Limitações de concorrência a nível de instruções Limitações de ILP Os estudos estabelecem um modelo (conjunto de suposições) e determinam a quantidade de paralelismo existente em instruções emitidas por ciclo. Modelo de processador ideal: 1 Register renaming Número infinito de registos. 2 Previsão de saltos A previsão é perfeita. 3 Previsão de saltos incondicionais Todos os saltos incondicionais (incluindo retornos de subrotinas) são previsto perfeitamente. 4 Acesso a memória Todos os endereços são conhecidos em qualquer altura; load pode ser adiantado em relação a store (desde que não acedam à mesma posição de memória). Os pontos 2 e 3 eliminam as dependências de controlo. Os pontos 1 e 4 eliminam todas as dependências excepto as verdadeiras. O processador pode emitir um número infinito de instruções por ciclo; todas as unidades funcionais têm 1 ciclo de latência; caches perfeitas: 1 ciclo de acesso. João Canas Ferreira (FEUP) ILP Outubro de 2010 52 / 58 52.1. A principal linha de orientação para o aumento do desempenho de processadores foi, nos anos 80 e 90, o aproveitamento da concorrência a nível de instruções (instruction-level parallelism ILP). Portanto, é importante ter uma noção de quanta concorrência existe realmente nos programas escritos de maneira convencional (i.e., para uma arquitectura puramente sequencial). 52.2. Estudos empíricos deste tipo só podem ser feitos por simulação. Geralmente, começa-se por examinar os resultados obtidos por um processador ideal, para depois analisar a influência de cada uma das limitações realistas. 52.3. Os resultdos apresentados a seguir provêm do seguinte trabalho: Wall, D. W., Limits of Instruction-Level Parallelism, Research Report Rep. WRL-93-6, Western Research Laboratory, Digital Equipment Corp. (http://www.hpl.hp.com/techreports/compaq-dec/wrl-93-6.html). 52.4. Em todos os caso analisados, não existem restrições aos tipos de instruções que podem ser emitidas simultaneamente. 52

Limitações de concorrência a nível de instruções ILP para um processador perfeito Fonte: [CAQA3] A concorrência de operações é medida pelo número médio de instruções emitidas por ciclo (1/CPI). Todas as instruções têm latência de 1 ciclo. João Canas Ferreira (FEUP) ILP Outubro de 2010 53 / 58 53.1. Os programas fpppp, doduc e tomcatv são programas científicos, que fazem uso significativo de dados em vírgula flutuante. Os restantes utilizam apenas aritmética inteira. 53.2. Os programas científicos apresentam maior quantidade de paralelismo, como seria de esperar. 53.3. Nestas simulações, cada instrução é emitida o mais cedo que as dependências de dados permitam. Como todos os saltos são previstos sem erros, tal pode implicar grande movimentação das instruções. 53

Limitações de concorrência a nível de instruções Efeito da dimensão da janela Fonte: [CAQA3] Janela: n.º de instruções examinadas simultaneamente. Nos estudos subsequentes assume-se: janela de 2K / 64-issue. João Canas Ferreira (FEUP) ILP Outubro de 2010 54 / 58 54.1. Em cada ciclo, um processador perfeito deve: 1. Procurar arbitrariamente longe no futuro todas as instruções que possam ser emitidas neste ciclo (prevendo correctamente todos os saltos); 2. Renomear registos para evitar conflitos WAR e WAW; 3. Determinar se existem dependências de dados (verdadeiras) entre as instruções a emitir neste ciclo e renomear os respectivos operandos; 4. Determinar se existem dependência de dados (verdadeiras) via memória e tratá-las apropriadamente. Para além disso, deve ter suficientes unidades funcionais para permitir a emissão de todas as instruções prontas. 54.2. A tarefa de verificar se existem dependências de dados entre n instruções, cada uma com dois operandos, requer (n 2 n) comparações. Por exemplo, detectar as dependências entre 2000 instruções requer pouco menos de 4 milhões de comparações. Por outras palavras, uma janela de instruções de 2000 requereria um processador capaz de fazer 4 milhões de comparações por ciclo. Processadores do início do século XXI têm janelas cujo tamanho varia entre 64 e 128 instruções. 54.3. O efeito de considerar uma janela de instruções finita é claramente mostrado na figura: o paralelismo disponível desce significativamente. 54

Limitações de concorrência a nível de instruções Efeito da previsão realista Fonte: [CAQA3] João Canas Ferreira (FEUP) ILP Outubro de 2010 55 / 58 55.1. O efeito de usar mecanismos realistas de previsão de saltos também é claro: descida significativa do paralelismo (menos de 20 instruções emitidas por ciclo, em média). 55.2. Previsão estática: A previsão é baseada no perfil de execução do programa. Depois de analisado um perfil da execução do programa, o previsor (um programa) decide, para cada instrução de salto, se esta deve ser prevista como tomada ou não-tomada, e altera o binário por forma a indicar isso ao processador. (Alguns processadores permitem anotar cada instrução de salto com um bit a indicar qual o sentido da prevista.) Trata-se de uma prevista estática, no sentido em que é feita off-line. 55

Limitações de concorrência a nível de instruções Efeito de um número finito de registos em RR Fonte: [CAQA3] A figura mostra o efeito de se dispor de um número finito de registos adicionais, para além dos especificados pela arquitectura do conjunto de instruções. João Canas Ferreira (FEUP) ILP Outubro de 2010 56 / 58 56.1. Registos de VF e para dados inteiros são aumentados do mesmo número. Por exemplo, os valores para a abcissa 32 correspondem a utilização adicional de 32 registo de VF e de 32 registos para dados inteiros. 56.2. Em 2001, o processador Alpha 21264 era aquele que mais registos adicionais tinha: 41. 56.3. Os resultados mostram que as dependências de nome (que resultam em conflitos WAR e WAW) podem limitar significativamente o paralelismo disponível. De facto,observa-se empiricamente que o impacto relativo destas dependências aumenta com o paralelismo disponível. 56

Limitações de concorrência a nível de instruções Características de alguns processadores comerciais Fonte: [CAQA3] João Canas Ferreira (FEUP) ILP Outubro de 2010 57 / 58 57.1. Dados representativos de processadores comerciais em 2002. 57.2. Notar os diferentes tipos de restrições à emissão conjunta de instruções (terceira coluna a contar da direita). 57

Referências Referências CAQA4 J. L. Hennessey & D. A. Patterson, Computer Arquitecture: A Quantitative Approach, 4ª ed. CAQA3 J. L. Hennessey & D. A. Patterson, Computer Arquitecture: A Quantitative Approach, 3ª ed. COD4 D. A. Patterson & J. L. Hennessey, Computer Organization and Design, 4a ed. Os tópicos tratados nesta apresentação são abordados nas seguintes secções de [CAQA4]: 2.1, 2.3 2.9 3.1 3.3 João Canas Ferreira (FEUP) ILP Outubro de 2010 58 / 58