UNIVERSIDADE TÉCNICA DE LISBOA

Transcrição

1 UNIVERSIDADE TÉCNICA DE LISBOA INSTITUTO SUPERIOR TÉCNICO Optimização e Avaliação de Aplicações de Simulação Numérica João Nuno de Oliveira e Silva (Licenciado) Dissertação para obtenção do grau de Mestre em Engenharia Informática e de Computadores Orientador: Doutor Paulo Jorge Pires Ferreira Presidente: Doutor Paulo Jorge Tavares Guedes Vogais: Doutor João Luís Ferreira Sobral Doutor Paulo Jorge Pires Ferreira Setembro 2002

2

3 Dissertação realizada sob a orientação do Prof. Doutor Paulo Jorge Pires Ferreira Professor Auxiliar do Departamento de Engenharia Informática do Instituto Superior Técnico da Universidade Técnica de Lisboa

4

5 Nome: João Nuno de Oliveira e Silva Título: Optimização e Avaliação de Aplicações de Simulação Numérica Palavras-chave: Simulação Numérica, optimização, paralelização, Memória Paralela e Distribuída Keywords: Numerical Simulation, Code Optimization, Paralelization, Distributed Shared Memory

6

7 Resumo A simulação numérica é, cada vez mais, usada na substituição de experiências físicas. Na indústria naval, as simulações de modelos de embarcações em tanques de ensaio é passível de ser substituída por simulações numéricas. Com um esforço, adicional ao desenvolvimento desses programas, consegue-se obter uma redução dos tempos de simulação, tornando-os aplicáveis em todo o processo de desenho de embarcações. A aplicação analisada é um simulador do comportamento hidrodinâmico de carenas de embarcações. A necessidade de optimizar esta aplicação advêm de uma das características desejadas ser a avaliação rápida dos cascos, cujos resultados influenciam alterações futuras no seu desenho. Para optimizar esta aplicação utilizaram-se diversas técnicas. Ao código que resolvia os vários sistemas de equações, e que não manipulava estruturas dinâmicas, aplicaram-se optimizações dependentes da arquitectura dos computadores. O código que manipulava estruturas dinâmicas apenas foi optimizado aplicando técnicas dependentes do processador (alteração do algoritmo). Para além das optimizações, também se realizou a sua paralelização de algum código, usando-se threads e Memória Partilhada e Distribuída. Com estas optimizações também se conseguiu comparar a eficiência de diversas tecnologias de suporte à execução paralela de aplicações: threads, PVM e Memória Partilhada e Distribuída. Ao longo deste trabalho usaram-se diversas técnicas de avaliação de desempenho. Em resumo, para além de termos conseguido tornar a aplicação de simulação mais usável, reduzindo-lhe o tempo de execução, também se consegui experimentar e avaliar os ganhos obtidos com a aplicação de várias técnicas sobre código com características distintas. i

8

9 Abstract Numerical simulation became a good substitution of physical experiences. In Naval industry, ship hull numerical simulation may be used instead of ship hull towing tank experiment. With an additional effort, by reducing simulation time, we can apply these numerical simulations to all the ship design and analysis process. The analyzed application simulates the ship behavior in a towing tank experience. This application must be optimized due to the fact that the results produced should be used in subsequent phases of the ship design process. In order to optimize this application we used several optimization techniques. In the equation systems solver witch didn t handle any dynamic structure we used machinelevel optimization. On the other hand, the code that handled dynamic structures was optimized using application-level optimizations (algorithm changes). Besides the optimizations, we also parallelized some of its code using threads and Distributed Shared Memory. With these optimizations we also managed to compare the efficiency of some parallel execution support platforms: threads. PVM and Distributed Shared Memory. During this work we also used some performance evaluation techniques. With this work we not only managed to make the simulation application more usable, by reducing the execution time, but also experienced and evaluate several optimization techniques applied to distinct codes. iii

10

11 Agradecimentos Ao Professor Dr. Paulo Guedes pela orientação inicial na execução do trabalho aqui descrito e ao Professor Dr. Paulo Ferreira pela orientação final e acompanhamento na escrita deste documento. A todos os elementos do Grupo de Sistemas Distribuídos que ao longo destes anos se interessaram pelo trabalho por mim realizado e pelas ideias com eles discutidas. Ao Professor Dr. Paulo Ferreira, Engº João Garcia e Engº Alfonso Sandoval pela leitura atenta que fizeram a este documento. Ao Eng. David Matos e Drª Luísa Coheur pelas consultas de orientação profissional gratuitas dadas ao longo destes últimos anos. À malta do Aikido (Engº Artur Caetano, João Almeida e Isabel Bentes) pelas horas de descontracção partilhadas e pela descoberta de algo novo. Finalmente, mas não menos sentido, aos meus Pais e Irmãos, pelo longo acompanhamento e imprescindível apoio dado durante toda a minha educação e formação. João Nuno Silva Lisboa, 1 de Setembro de 2002 v

12

13 Para quem ler vii

14

15 Índice Resumo... i Abstract... iii Agradecimentos... v Índice... ix Índice de Figuras... xiii Índice de Tabelas... xv 1 Introdução Motivação Enquadramento Contribuições Estrutura do Documento Trabalho Relacionado Introdução Técnicas de Optimização de Código Sequencial Optimizações não dependentes da plataforma Optimizações dependentes da plataforma Arquitectura do Pentium II Optimizações aplicáveis a Pentium II Paralelização Arquitectura de Sistemas Paralelos Comunicação entre tarefas em multiprocessadores Memória Partilhada Infra-estrutura de passagem de mensagens Distributed Shared Memory...32 ix

16 Optimização e Avaliação de Aplicações de Simulação Numérica High Performance Fortran (HPF) Optimizações aplicáveis a código paralelo Lei de Amdahl Técnicas de avaliação de desempenho Timers Relógio do sistema Contadores de alta precisão Contadores dos processadores Contadores do S.O Polling vs. Instrumentação Software de profiling Gprof Etch Vtune Resumo e enquadramento Enquadramento Descrição do Projecto Flash Arquitectura do sistema Aplicação de simulação Ambiente de execução Participação do INESC Realização Optimização do Solver (Conjugate gradient) Função Solve Função Atimes Função Asolve Paralelização do Solver (Conjugate gradient) Paralelização usando threads Paralelização usando DSM Optimização do simulador (aplicação FLASH) Paralelização do simulador (aplicação FLASH) Servidor para execução de tarefas remotas (TreadMark) Avaliação de desempenho das versões série...74 x

17 Índice Driver para leitura de contadores Avaliação de desempenho das versões paralelas Resumo Avaliação Ambiente de teste Optimização do Solver (Conjugate gradient) Paralelização do Solver (conjugate gradient) Optimização do simulador (aplicação FLASH) Paralelização do simulador (aplicação FLASH) Conclusões...93 Apêndice A Matrizes esparsas Apêndice B Conjugate Gradient Bibliografia Glossário xi

18

19 Índice de Figuras Fig. 2.1 Micro-arquitectura dos processadores da família P6 com Advance Transfer Cache (cache de nível 2)...12 Fig. 2.2 Unidade de Execução...15 Fig. 2.3 Exemplo de uso não optimizado da cache...19 Fig. 2.4 Exemplo de uso optimizado da cache...20 Fig. 2.5 Alteração do acesso a vectores de modo a permitir a utilização de registos...21 Fig. 2.6 Arquitectura de multiprocessadores de memória partilhada com ligações...23 Fig. 2.7 Exemplo da arquitectura de um computador multiprocessador vectorial...24 Fig. 2.8 Exemplo da arquitectura de um computador massivamente paralelo...25 Fig. 2.9 Configuração de um cluster formando dois sistemas paralelos independentes.27 Fig Desempenho máximo de uma aplicação paralela segundo lei de Amdahl...36 Fig. 3.1 Arquitectura geral da plataforma de desenvolvimento e simulação das embarcações...49 Fig. 3.2 Vista conceptual do simulador (versão série)...50 Fig. 3.3 Diagrama de classes simplificado do simulador...51 Fig. 3.4 Exemplo de uma iteração da simulação...52 Fig. 4.1 Optimização da função solve...56 Fig. 4.2 Implementação original da função atimes...58 Fig. 4.3 Versão optimizada da função atimes...60 Fig. 4.4 Implementação original da função asolve...61 Fig. 4.5 Versão paralela dum produto interno...64 Fig. 4.6 Multiplicação de uma matriz por um vector (versão série)...64 Fig. 4.7 Multiplicação de uma matriz por um vector (versão paralela)...65 xiii

20 Optimização e Avaliação de Aplicações de Simulação Numérica Fig. 4.8 Criação de um vector em memória partilhada e distribuída Fig. 4.9 Conversão para matriz esparsa (versão não optimizada) Fig Conversão para matriz esparsa (versão optimizada) Fig Envio dos dados necessário à criação do sistema de equações (comunicação entre processos usando PVM) Fig Envio dos dados necessário à criação do sistema de equações (comunicação entre processos usando DSM) Fig Envio da solução do sistema de equações (comunicação entre processos usando DSM) Fig Inicialização de um contador do processador Pentium Fig Leitura de um contador do processador Pentium Fig Programação necessária à leitura dos contadores do Windows Fig Leitura de um valor contabilizado num contador do Windows Fig. 5.1 Tempos de execução da versão paralela usando TreadMarks Fig. 5.2 Dados transmitidos e enviados pelo nó mestre nas versões paralelas usando PVM e TreadMarks Fig. A.1 Representação esparsa de uma matriz xiv

21 Índice de Tabelas Tab. 2.1 Eventos contabilizáveis com Performance-Monitoring counters...40 Tab. 2.2 Contadores contabilizáveis com Performance counters do Windows...41 Tab. 3.1 Sistemas usados pelo parceiros para execução do código de simulação...53 Tab. 4.1 Dados manipulados na função solve e suas dependências...63 Tab. 5.1 Características dos computadores usados nos testes de desempenho...82 Tab. 5.2 Análise estática do solver...83 Tab. 5.3 Número total de acessos à memória numa execução típica do solver...85 Tab. 5.4 Número total de cache misses no acesso à memória numa execução típica do solver...86 Tab. 5.5 Tempos de execução da versões serial do solver numa execução típica do solver...86 Tab. 5.6 Resultados da paralelização do solver usando threads e TreadMarks...87 Tab. 5.7 Tempos de execução da aplicação de simulação...89 Tab. 5.8 Speedups expectáveis e obtidos com a versão paralela usando TreadMarks...91 Tab. 5.9 Comparação dos tempos de execução das versões paralelas usando PVM e TreadMarks (DSM)...91 xv

22

23 1 Introdução 1.1 Motivação Desde há várias décadas que têm vindo a ser realizadas simulações de fenómenos físicos usando computadores. Nos primeiros tempos, as simulações eram realizadas em computadores especialmente construídos para o efeito. Com o desenvolvimento da electrónica e das arquitecturas de processadores, nasceu um mercado para supercomputadores unicamente dedicados ao cálculo numérico. O preços dos supercomputadores sempre limitou o seu uso às grande empresas e grandes centros de investigação. As pequenas e médias empresas nunca tiveram possibilidade de efectuar simulações dos seus produtos devido ao custo proibitivo dos supercomputadores e do seu tempo de processamento. Nos últimos anos, verificou-se um aumento de desempenho considerável nos computadores pessoais, já suplantando o desempenho dos supercomputadores de alguns anos atrás. Aliado a este aumento de desempenho, a possibilidade de usar vários computadores ligados numa rede para a realização de cálculos em paralelo, tornou o cálculo numérico intensivo mais acessível. Para as pequenas e médias empresas, o uso de computadores pessoais tornou-se uma alternativa viável à aquisição de supercomputadores. O desempenho dos computadores pessoais está ao nível do das estações de trabalho. Também é possível, com custo mínimo, usar vários computadores em paralelo formando um cluster. As empresas já usam abun- 1

24 Optimização e Avaliação de Aplicações de Simulação Numérica dantemente os computadores pessoais na sua operação normal, podendo estes computadores ser usados em conjunto na simulação de produtos. Para além da fácil criação de um cluster, também a sua escalabilidade os torna atraentes: o aumento do desempenho é conseguido substituindo os computadores existentes por outros mais rápidos ou, mais simplesmente, adicionando novos computadores ao conjunto já existente. Para tirar partido da existência de vários computadores, é necessário alterar o código sequencial, paralelizando-o. Um programa, depois de paralelizado, pode ser executado em simultâneo em vários processadores ou computadores. O tempo de execução dos programas consegue ser reduzido aumentando o número de computadores participantes no cálculo. O desenvolvimento destes programas de simulação é útil mas, com algum esforço adicional, é possível aumentar o desempenho destas aplicações. Este aumento do desempenho permite que o tempo despendido na simulação dos produtos se reduza, permitindo a avaliação de soluções distintas para o mesmo produto ou uma afinação iterativa dos mesmos. A solução mais óbvia para a aceleração das aplicações é a aquisição de computadores mais rápidos. Os ganhos podem ser substanciais, mas os custos podem tornar esta solução inviável para muitas empresas. A optimização do código é a solução com custos mais reduzidos, se executada durante a produção do software de simulação, visto não obrigar à aquisição de computadores mais rápidos. A optimização consiste na alteração do código do programa de modo a que este se execute mais rapidamente no tipo de computadores a usar na simulação. Este passo nem sempre é realizado, visto as aplicações serem desenvolvidas por especialistas no domínio da simulação, mas sem conhecimentos de arquitectura de computadores. 1.2 Enquadramento O trabalho apresentado nesta tese desenvolveu-se no âmbito dum projecto europeu. Este projecto, FLASH HPCN Tools for Enhanced Hydrodynamic Design of Fast Ships on Parallel Computing Platforms, tinha como objectivo o desenvolvimento de um pacote de software para desenho de embarcações, que integrasse ferramentas de CAD, com software de simulação do comportamento dos cascos das embarcações. Após a avaliação dos meios computacionais existentes nas instalações dos participantes, foi decidido que a plataforma de execução dos programas desenvolvidos consistiria em 2

25 Introdução computadores pessoais. Também se constatou que havia a possibilidade de executar código paralelo, quer em várias máquinas quer em multiprocessadores de memória partilhada. O trabalho por nós desenvolvido neste projecto, centrou-se na melhoria do desempenho do código de simulação produzido por um dos parceiros, recorrendo-se à optimização do código sequencial e do código paralelizado. Numa primeira fase, tendo apenas acesso a uma versão preliminar do simulador, optou- -se por efectuar primeiramente a sua optimização sem preocupações de execução num ambiente paralelo: Observou-se inicialmente onde era despendido mais tempo durante a execução; Realizaram-se optimizações, primeiro da ordenação das instruções de modo a reduzir os tempos perdidos pelo processador e, depois, dos algoritmos usados, para reduzir as instruções executadas. Durante esta primeira fase também se observaram as possibilidades de paralelização de partes deste código. Após a optimização do código sequencial, decidiu-se efectuar alterações à versão paralela desenvolvida por um dos parceiros. Esta primeira versão paralela usava passagem de mensagens (PVM[Gei94]) para efectuar a comunicação entre os computadores. Constatou- -se o fraco desempenho desta versão paralela. O trabalho por nós realizado prendeu-se com a tentativa de, usando outra tecnologia de comunicação (memória partilhada e distribuída), optimizar a versão paralela e permitir uma fácil instalação clusters de computadores pessoais. Alterou-se a implementação paralela para passar a usar memória partilhada e distribuída, usando-se o sistema TreadMarks[Kel94], tentando-se com esta opção reduzir a comunicação entre os vários computadores. Um outro factor que se teve em conta no desenvolvimento desta última tarefa, foi o público alvo da aplicação. Uma preocupação constante foi a facilidade de uso das aplicações paralelas. Para tal alterámos o sistema de lançamento remoto das tarefas do TreadMarks. 1.3 Contribuições A primeira e mais evidente contribuição é a optimização das várias versões do simulador. Foram por nós desenvolvidas duas versões optimizadas do simulador: 3

26 Optimização e Avaliação de Aplicações de Simulação Numérica Protótipo para execução em monoprocessador, optimizado e com desempenho superior à versão original; Protótipo paralelo para execução em rede de computadores pessoais, com desempenho superior às versões originais (série e paralela) ; Também ao nível de software de suporte, foram realizadas implementações que deverão ser referidas: Software para medição da ocorrência de eventos de processador associados ao desempenho de aplicações Alteração do modo de iniciação de tarefas no sistema TreadMarks; Paralelamente, pode-se considerar este documento como referência interessante a futuras optimizações. São aqui descritas as várias técnicas de optimização por nós aplicadas a software de simulação, com a apresentação dos ganhos reais obtidos. 1.4 Estrutura do Documento Este documento está dividido em 6 capítulos. Neste primeiro capítulo apresenta-se uma introdução ao trabalho realizado e descrito nesta dissertação. No segundo capítulo apresentam-se as várias técnicas de avaliação e optimização de código existente. Descrevem-se, não só, as técnicas de optimização aplicáveis a código executado em um só processador, mas também se apresentam várias tecnologias de suporte à execução de código em vários processadores. Nos dois capítulos seguintes apresenta-se uma descrição do projecto onde este trabalho se inseriu (capítulo Enquadramento ) e o trabalho por nós aí realizado (capítulo Realização ). Os resultados de desempenho são apresentadas no capítulo Avaliação ; as conclusões do nosso trabalho são descritas no último capítulo. 4

27 2 Trabalho Relacionado São apresentadas neste capítulo, técnicas que permitem o aumento de desempenho de aplicações de simulação numérica. São apresentadas optimizações que dependem da arquitectura de execução e outras das quais se obtêm resultados independentemente da arquitectura. São descritas algumas técnicas de optimização de código e tecnologias que permitem a execução paralela de código em vários processadores ou computadores. A escolhas das técnicas de optimização aqui apresentadas foi realizada ao longo do desenvolvimento do projecto, sendo representativas das várias técnicas existentes e possíveis de aplicar em aplicações de simulação numérica. Em relação aos sistemas computacionais paralelos, apresentamos uma resenha histórica, com indicação dos sistemas actualmente em uso. Também descrevemos as várias possibilidades existentes no campo de sistemas de suporte à programação paralela. No fim deste capítulo, apresentamos várias ferramentas de análise do desempenho existentes e investigadas antes do início do projecto, assim como algumas características dos computadores e sistemas operativos actuais usadas na avaliação concreta da nossa aplicação de simulação. 2.1 Introdução Existem duas características que se desejam do software de simulação: exactidão e rapidez. Como os resultados a obter devem ser o mais próximos possíveis da realidade, a exactidão é característica importante. A outra característica, a rapidez, também é importante, 5

28 Optimização e Avaliação de Aplicações de Simulação Numérica visto os resultados das simulações serem dados importantes para decisões futuras e necessários em tempo útil. Neste capítulo, serão apresentadas técnicas cuja aplicação permitem a melhoria do desempenho de aplicações de simulação numérica. Também são apresentadas metodologias de avaliação de programas, a fim de identificar o código cuja alteração introduz maiores ganhos de desempenho. Existem duas tarefas que se podem realizar e que permitem o aumento do desempenho dos programas: optimização do código que se executa de forma sequencial num único processador; paralelização do código para ser executado em vários processadores (multiprocessadores ou rede de PC's). Enquanto que, com a optimização do código, se altera o programa para que execute o mínimo de instruções e o mais rapidamente possível, com a paralelização, divide-se o trabalho a realizar por vários processadores ou computadores, reduzindo-se o tempo total de execução à medida que se aumenta o número de processadores envolvidos nos cálculos. A optimização do código sequencial necessita de acesso ao código dos programas de simulação, e com um custo muito inferior ao da aquisição de novo hardware conseguem-se obter ganhos significativos nos tempos de execução. A optimização de código sequencial segue duas fases: Avaliação do programa Aplicação de técnicas de optimização Para se concluir quais as instruções duma aplicação que demoram mais tempo, é necessário medir com exactidão o tempo de execução de cada função. Um modo de conseguir isso, consiste em alterar o código do programa a observar, introduzindo as chamadas às funções de temporização no início e fim de cada função, ou em blocos pais pequenos. Em seguida é apenas necessário avaliar os tempos medidos. As modificações podem ser realizadas automaticamente por um programa externo ou manualmente pelo programador. A inclusão das funções explicitamente por um programador permite a medição do tempo de execução do código com maior precisão. Outro modo consiste em usar técnicas de amostragem. Com uma determinada frequência avalia-se qual o código que se executa, traçando um gráfico aproximado do tempo 6

29 Trabalho Relacionado despendido na execução de cada módulo e função. As técnicas básicas de optimização sequencial consistem em alterar porções de código de modo a reduzir o número de instruções executadas. Este tipo de optimização não necessita de conhecimento da arquitectura computacional usada. Basta apenas observar o código que permite melhores ganhos e alterar o algoritmo aí usado de modo a reduzir o número de instruções executadas. Existem também outras técnicas de optimização em que o conhecimento da arquitectura é necessário. Quando se pretende, por exemplo, reduzir o tempo de espera do processador devido a determinados encadeamentos de instruções, é necessário conhecer a arquitectura interna do processador. Neste caso, não é suficiente saber onde se despende mais tempo, mas também é necessário saber com exactidão porque ocorrem estas perdas de desempenho dependentes do processador utilizado. Para efectuar a paralelização de código, também é necessário avaliar quais as partes do programa que permitem maiores ganhos. É necessário, depois, decidir qual o tipo de distribuição dos dados entre os vários nós de processamento e que tecnologia usar para efectuar a comunicação entre os vários nós. Dependendo do tipo de computadores existentes, assim diferentes tecnologias de comunicação devem ser utilizadas. Se o código paralelizado vai ser executado em multiprocessadores de memória partilhada, é mais atractivo utilizar o paradigma de memória partilhada[bro97]. Nos computadores multiprocessadores de memória distribuída, já é mais natural usar uma infra-estrutura de passagem de mensagens[sun90], [Sni96]. Caso se deseje utilizar vários computadores ligados por uma rede para executarem código paralelo, pode-se usar passagem de mensagens ou memória partilhada e distribuída, como se apresentará mais adiante. 2.2 Técnicas de Optimização de Código Sequencial Os compiladores actuais efectuam optimizações ao código dependentes do processador de destino. Embora tais optimizações sejam válidas e eficientes, existem alguns casos onde a observação do código e sua alteração pelo programador pode trazer ganhos adicionais; em particular, quando: o número de instruções é elevado, havendo um modo mais eficiente de codificar o problema; a sequência dos acessos aos dados provoca atrasos nos acessos; 7

30 Optimização e Avaliação de Aplicações de Simulação Numérica o encadeamento das instruções provoca atrasos na sua execução. O primeiro problema apontado advém do uso de algoritmos não optimizados. Muitas vezes, a descrição dos algoritmos, devido a requisitos de legibilidade e compreensão, não é a óptima. Os dois problemas seguintes são causados pelo facto dos processadores não executarem de modo óptimo algumas sequências de instruções. Devido ao uso de caches, também a ordem pela qual os dados são acedidos, pode provocar atrasos, como se verá na secção Estes problemas podem ser resolvidos por duas acções distintas mas complementares. Primeiro, é necessário alterar a implementação dos algoritmos de modo a reduzir o número de instruções realizadas, verificando depois se essas instruções executam do modo mais eficiente, em termos de acesso aos dados e encadeamento de instruções, na arquitectura escolhida para a execução do programa Optimizações não dependentes da plataforma O primeiro tipo de optimização que se deve tentar realizar é a que for independente da arquitectura. Este tipo de optimizações pode-se realizar logo após a identificação das rotinas que demoram mais tempo a executar. Normalmente estas optimizações limitam-se a alterar as instruções usadas de modo a reduzir o seu número; por exemplo, reduzir o número de iterações de um ciclo, reduzir o número de operações aritméticas e reduzir o número de comparações. Em casos extremos, este tipo de optimizações pode-se traduzir na alteração de todo o algoritmo por um outro mais eficiente. As optimizações apresentadas podem ser realizadas sem preocupações relacionadas com a arquitectura de execução se o código for executado em computadores do tipo monoprocessador não vectorial. No caso de computadores vectoriais ou multiprocessadores (secção 2.3.1), algumas alterações poderão reduzir o desempenho, visto não possibilitarem a utilização das capacidades dos processadores[dow98]. Com efeito, os computadores vectoriais e os multiprocessadores aproveitam a estrutura dos dados e o modo como o código lhes acede para executar em paralelo várias instruções. Apresentamos de seguida algumas optimizações não dependentes da arquitectura de execução aplicáveis a código de cálculo numérico. Estas optimizações prendem-se com a eliminação de instruções repetidas, expressões complexas ou condições. Também se apresenta o loop unrolling que tenta reduzir os custos de avaliação da condição de terminação dos ciclos. 8

31 Trabalho Relacionado Eliminação de sub-expressões Uma das situações onde se pode obter algum ganho de desempenho é na redução de cálculos duplicados. 1 c = a + b + d 2 e = q + a + b Observa-se no exemplo anterior que se duplica o cálculo da expressão a + b. Consegue-se optimizar este código usando uma variável auxiliar onde ficará guardado o resultado da expressão em causa. 3 temp = a + b 4 c = temp + d 5 e = q + temp Os ganhos desta optimização aumentam com a complexidade da expressão desnecessariamente calculada. Uma optimização semelhante é a eliminação de cálculos invariantes dentro de um ciclo. 1 for (i = 0 ; i < N ; i++){ 2 a[i] = a[i] / sqrt(x*x + y*x); 3 } Ao exemplo anterior retirar-se-á a expressão sqrt(x*x + y*x) de dentro do ciclo, reduzindo os cálculos efectuados. 1 temp = sqrt( x*x +y*x); 2 for (i = 0 ; i < N ; i++){ 3 a[i] = a[i] / temp; 4 } Alguns compiladores efectuam a eliminação de sub-expressões simples. No entanto, quando as sub-expressões contêm chamadas a funções, os compiladores não efectuam esta optimização. Como as funções invocadas podem ter efeitos paralelos no estado do programa, só o programador sabe se pode substituir as várias chamadas às funções por uma única. Eliminação de condições dentro de ciclos A existência de condições dentro de um ciclo aumenta os atrasos causados por este tipo de instrução. Quando se verifica que estas condições são a causa de grandes tempos de execução, é necessário eliminá-las. Quando, dentro de um ciclo, o teste depende do seu índice, é possível com o conhecimento prévio que se tem dos dados, eliminar essas condições. No exemplo seguinte, em cada iteração do ciclo interior, comparam-se os índices i e j. 9

32 Optimização e Avaliação de Aplicações de Simulação Numérica 1 for (i = 0; i < N; i++){ 2 for (j = 0; j < N; i++){ 3 if (j <= i) 4 a[i][j] = a[i][j] + b[i][j] * c; 5 else 6 a[i][j] = 0; 7 } 8 } A condição testada N*N vezes durante a execução do código apresentado pode ser eliminada: 1 for (i = 0; i < N; i++){ 2 for (j = 0; j <= i; i++){ 3 a[i][j] = a[i][j] + b[i][j] * c; 4 } 5 for ( ; j < N; i++){ 6 a[i][j] = 0; 7 } 8 } Loop unrolling Existem situações em que o peso da avaliação da guarda de um ciclo é superior ao das operações executadas em cada iteração. Nestes casos, o loop unrolling permite obter ganhos significativos. Com efeito, com o loop unrolling tenta-se reduzir o número de testes executados, aumentando o número de instruções a executar em cada iteração. 1 for (i = 0 ; i < N; i++){ 2 a[i] = A[i] +b[i] * c; 3 } Se no exemplo anterior N for múltiplo de 4, pode-se aplicar loop unrolling, passando-se, em cada iteração, a executar 4 atribuições. Considere-se o exemplo seguinte: 1 for (i = 0 ; i < N; i += 4){ 2 a[i] = A[i] +b[i] * c; i++; 3 a[i] = A[i] +b[i] * c; i++; 4 a[i] = A[i] +b[i] * c; i++; 5 a[i] = A[i] +b[i] * c; i++; 6 } Com a aplicação desta técnica, reduz-se o tempo despendido na execução das instruções de controle do ciclo. Caso o número de iterações seja constante e predefinido, aquando da compilação, é possível eliminar completamente o ciclo, substituindo-o por uma simples sequência de operações. 10

33 Trabalho Relacionado Optimizações dependentes da plataforma A arquitectura dos processadores e computadores usados no cálculo no tempo de execução do código. Estas arquitecturas são desenvolvidas de modo a reduzir o tempo de execução das instruções mas, devido à arquitectura interna dos processadores e aos tipos de cache usados, existem determinadas combinações de operações e acessos aos dados que não são executadas tão eficientemente quanto possível. Descrevem-se de seguida as características arquitecturais do processador Pentium II relevantes para as possíveis optimizações a realizar. Apresentam-se depois as optimizações possíveis. A escolha deste processador (Pentium II) prendeu-se com sua grande implantação e ser este o processador usado nos computadores que executam o simulador optimizado. O facto da sua arquitectura ser semelhante à de outros processadores disponíveis também teve influência na sua escolha, tornando-o um bom exemplo. Este processador apresenta toda as técnicas de aumento de desempenho presentes em todos os outros processadores de alto desempenho: arquitectura super-escalar; execução de instruções for a de ordem; existência de pipeline de execução predição da execução dos saltos Arquitectura do Pentium II Os processadores Pentium II e Pentium III[Int01a] são implementações da arquitectura de 32 bits da Intel (IA-32). Estes processadores têm uma arquitectura de execução dinâmica que fornece as seguintes características que influenciam o desempenho das execuções de aplicações: Execução de instruções fora de ordem para aproveitar paralelismo Arquitectura super-escalar para aproveitar paralelismo Pipeline de execução para aproveitar paralelismo Predição de saltos para reduzir atrasos de execução Caches nível 1 de dados e instruções internas ao processador Embora estes processadores tenham algumas inovações em relação ao processador 11

34 Optimização e Avaliação de Aplicações de Simulação Numérica Pentium Pro, a arquitectura básica é a mesma, pertencendo todos à mesma família, que se referencia a partir daqui como P6[Int98]. O pipeline desta família de processadores é formado por 3 partes: Fetch & Decode Unit Dispatch / Execute Unit Retirement Unit Na Fig. 2.1 mostra-se o esquema geral desta arquitectura e os fluxos de dados entre os vários componentes. System Bus Bus Unit 2 nd Level Cache 1 st Level Data Cache 1 st Level Instruction Cache Fetch/Decode Execution Retirement Instruction Pool/reorder buffer BTBs/Branch Prediction Fig. 2.1 Micro-arquitectura dos processadores da família P6 com Advance Transfer Cache (cache de nível 2) A unidade de fetch/decode é responsável por traduzir as instruções assembly em µoperações que serão executadas na unidade de execução. Para garantir que a unidade de execução não espera pela descodificação de instruções, a unidade de descodificação deve garantir um fluxo constante de µoperações. Isto é conseguido aproveitando-se a rapidez da cache de instruções e efectuando a descodificação de várias instruções em paralelo. Também é nesta unidade que se prevêem quais as instruções a descodificar quando se atinge um salto (JMP, JE, ). Com a informação armazenada nos BTBs (Branch Target Buffer) prevê-se se um salto vai ser executado ou não e quais as instruções a descodificar de seguida. A unidade de execução é responsável por executar as instruções existentes na Instruction 12

35 Trabalho Relacionado Pool de modo mais eficiente. Se uma micro-instrução não pode ser executada, porque os seus operandos ainda não foram calculados, esta unidade pode executar outra micro- -instrução; deste modo os atrasos causados por dependência de µoperações são minorados executando instruções que não dependem de operações ainda não terminadas. Devido ao desenho desta unidade, é possível executar várias instruções independentes em paralelo. A unidade de retirement é responsável por, após a conclusão das instruções, actualizar os dados em memória pela ordem correcta. Como as instruções podem ser executadas por uma ordem diferente daquela com que aparecem no código, não é possível actualizar a memória logo que uma instrução se complete. A retirement unit observa a ordem correcta pela qual as instruções deveriam ter sido executadas e vai actualizando a memória segundo essa ordem. Descrevem-se de seguida as várias características destes processadores, indicando qual a funcionalidade de cada um dos componentes atrás apresentados. Consegue-se assim perceber de que modo os encadeamentos de instruções tiram ou não proveito da arquitectura e como essas instruções se podem optimizar. Execução de instruções fora de ordem O núcleo dos processadores P6 permite avaliar a interdependência entre as várias instruções assembly e µoperações (resultados e operandos) e realizar a sua execução por ordem diferente daquela pela qual aparecem no código. Conseguem-se assim esconder os atrasos na execução das instruções, intercalando outras independentes. A descodificação das instruções assembly é realizada na unidade de fetch/decode e são armazenadas, com informação da localização dos operandos e resultados, na Instruction Pool. Aquando do fim de uma instrução, esta é retirada da Instruction Pool, e são verificadas quais as instruções aí existentes que dependiam deste resultado. Todas aquelas que não dependam de nenhum outro resultado podem ser imediatamente executadas pela unidade de execução. Consegue-se assim que a unidade de execução tenha sempre instruções para executar, mesmo que não sejam executadas pela ordem pela qual aparecem no código. A forte interdependência entre operandos das várias instruções obriga a que estas sejam executadas pela ordem do programa, o que pode levar ao não aproveitamento do paralelismo associado às várias unidades do processador. 13

36 Optimização e Avaliação de Aplicações de Simulação Numérica Pipeline de execução O uso de um pipeline permite a realização de várias actividades sucessivas em paralelo. Esta característica é conseguida utilizando as três unidades atrás descritas: unidade de fetch/decode, unidade de execução e retirement unit. O aumento de desempenho obtém-se pelo facto de todos os três componentes atrás descritos funcionarem em paralelo, processando dados que, num determinado instante, são independentes. Enquanto a unidade de execução executa uma determinada instrução, a unidade de fetch/decode lê da memória instruções que serão mais tarde executadas. Quando a unidade de execução terminar uma instrução, não necessita de esperar que novas instruções sejam lidas e descodificadas. Estas operações foram realizadas em paralelo com a execução de instruções anteriores. Após a conclusão da execução de uma instrução, a retirement unit é responsável pela actualização da memória com os resultados da execução. Esta operação é realizada em paralelo com a leitura, descodificação e execução de outras instruções. Arquitectura Super-escalar A unidade de execução permite a execução de várias instruções independentes em paralelo. A unidade de execução é responsável por distribuir as várias µoperações existentes na Instruction Pool pelos 5 portos existentes nesta unidade (ver Fig. 2.2). Esta distribuição é realizada à medida que as várias sub-unidades de execução vão ficando livres. Estas unidades podem executar em paralelo e permitem a finalização de várias instruções num mesmo ciclo de relógio. Como cada unidade tem um tipo específico de instruções que pode executar, é necessário garantir que existem na Instruction Poll instruções dos vários tipos possíveis, porque só assim é possível garantir que existe paralelismo na execução das instruções. A existência de uma única unidade de execução de operações de vírgula flutuante, evita que duas instruções de vírgula flutuante sejam iniciadas simultaneamente. Neste caso, não se aproveita tão eficientemente o paralelismo da unidade de execução. Um caso semelhante pode ocorrer com instruções inteiras, quando duas instruções só podem ser executadas pela mesma sub-unidade de execução. 14

37 Trabalho Relacionado MMX Execution Unit Floating Point Execution Unit Port 0 Integer Execution Unit Instruction Poll (ReOrder Buffer) Reservation Station Port 1 MMX Execution Unit Jump Execution Unit Integer Execution Unit Port 2 Store Execution Unit Port 3, 4 Load Execution Unit Fig. 2.2 Unidade de Execução Cada uma destas sub-unidades de execução tem no seu interior um pipeline para garantir a frequência máxima de execução de instruções (até 1 micro-instrução/ciclo). Com a combinação correcta de instruções é possível garantir uma frequência de terminação de instruções superior a 1 instrução por ciclo de relógio. Predição de saltos Normalmente, a leitura e descodificação de instruções realiza-se sequencialmente, tal qual aparecem no código, e não como são executados. Este facto é problemático no caso dos saltos que se realizam e alteram o fluxo de execução do código. Quando um salto ocorre, a próxima instrução a executar não é aquela que se encontra a seguir no código. Se a leitura e descodificação for cega, as instruções anteriormente descodificadas (devido à existência de pipeline) devem ser ignoradas e será necessário recomeçar a leitura e descodificação de instruções a partir da nova posição de execução. No caso de um if,que apenas é executado uma vez, estas perdas podem não ser muito significativas mas nos ciclos com guarda no fim de cada iteração, o tempo perdido pode ser significativo. Em cada iteração, sempre que o salto se executa, há necessidade de esvaziar o pipeline. Os processadores com arquitectura IA-32 conseguem, usando o historial de execução dos ciclos, prever qual a instrução que se vai executar de seguida. Num ciclo, por exemplo, a previsão só falha aquando da última iteração. No caso dos processadores de família P6 é a BTBs/Brach Prediction que armazena a direcção do salto (para a frente ou para trás), 15

38 Optimização e Avaliação de Aplicações de Simulação Numérica assim como o seu destino, e indica à unidade de fetch/decode qual a instrução que, a seguir ao salto, deve ser lida e descodificada. Para além desta predição (dita dinâmica), quando não existe informação nos Branch Target Buffers acerca do salto a executar, é executada predição estática; esta baseia-se em algumas heurísticas: todos os saltos não condicionais serão executados; saltos condicionais para trás serão executados; saltos condicionais para a frente não serão executados. Resumindo, com estas técnicas consegue-se reduzir drasticamente o tempo perdido nos saltos, devido à eliminação da necessidade de esvaziar completamente o pipeline na maioria das situações: Salto erradamente predito penalidade de 10 a 15 ciclos Predição dinâmica o salto executado e correctamente previsto penalidade de 1 ciclo o salto não executado e correctamente previsto sem penalidade Predição estática correcta penalidade de aproximadamente 6 ciclos O número de ciclos correspondentes a um salto erradamente predito é devido ao esvaziamento de todo o pipeline até ao início da nova instrução. Nas outras situações as penalidades, caso haja, são devidas à necessidade de carregar e descodificar um novo conjunto de instruções. No caso de um ciclo, a última iteração será erradamente prevista, perdendo-se cerca de 15 ciclos de processador. No entanto, nas várias iterações intermédias, quando as previsões acertam, as penalidades, caso existam, são substancialmente menores. Cache de dados e instruções Devido à sua rapidez, os acessos aos dados em memória atrasam significativamente a execução das instruções no processador. O tempo de acesso à memória é cerca de 10 vezes superior ao tempo de acesso aos registos internos do processador. Para melhorar o tempo de leitura e escrita na memória existem algumas alterações arquitecturais que se podem aplicar ao computador: Usar memória mais rápida 16

39 Trabalho Relacionado Usar bancos de memória para serem acedidos intercaladamente (escondendo os atrasos de funcionamento da memória) Usar buses de memória mais largos Usar caches rápidas entre a memória e o processador. Ao desenhar um computador é necessário balancear os custos envolvidos com a aplicação das tecnologias acima descritas e os ganhos obtidos. Uma das soluções adoptadas e que permitem bons ganhos é o uso de caches de vários níveis e com tamanhos variados. A cache é formada por memória rápida que, em cada instante, aloja um determinado conjunto de dados. Esta memória está organizada por linhas onde são armazenados valores contíguos existentes na memória. Estas linhas de memória são carregadas quando o processador acede a uma posição de memória que não se encontra na cache. Na leitura do primeiro valor o tempo perdido é elevado: o valor tem de ser lido do nível de memória seguinte mas as seguintes leituras contíguas já se efectuam sem atrasos. Com a organização da memória em várias hierarquias, cada vez mais rápidas e caras mas mais pequenas, consegue-se reduzir o tempo de leitura da memória com uma boa relação custo/desempenho. Enquanto que as três primeiras alterações ao sistema de memória não obrigam ao redesenho das aplicações, o uso de caches obriga à avaliação e redesenho dos padrões de acesso à memória para obter os ganhos máximos. Há sequências de acessos à memória que não aproveitam os dados armazenados nas várias caches. Os processadores com arquitectura P6 contêm, no seu núcleo, duas caches de nível 1, uma de dados e outra de código. Estas duas caches são associativas de quatro vias, têm uma capacidade de 16 Kbytes (8 Kbytes no caso do Pentium Pro) e o comprimento de cada linha é de 32 bytes. Usam um mecanismo de write-back e um algoritmo pseudo-lru (least recently used) para a substituição dos valores armazenados. A cache de nível 2, que armazena dados e código, está ligada ao processador por um bus dedicado de 64 bits com relógio igual ao do processador. Esta cache tem um tamanho variável, mas superior a 256 Kbytes. Assim, dependendo do mercado de destino do processador, alterando o tamanho da cache, consegue-se balancear o desempenho com o custo. O uso de dois níveis de cache consegue esconder o tamanho reduzido da cache de nível 1. Nem todos os misses à cache de nível 1 resultam num acesso à memória. Só quando os dados não se encontram em nenhuma das caches tal acontece. Neste caso perdem-se cerca de 17

40 Optimização e Avaliação de Aplicações de Simulação Numérica 10 ciclos de relógio. Para o preenchimento de uma linha de cache são lidos 4 blocos de 8 bytes da memória. Os dados lidos ficam acessíveis ao processador à medida que vão sendo transferidos para a cache. Também com a finalidade de optimizar as escritas em memória, os processadores Pentium usam 12 store buffers. Aquando da execução de uma instrução de escrita, os dados não são transferidos imediatamente para a cache ou memória, mas sim para um destes buffers. Mais tarde, os dados serão realmente transferidos para a memória. Deste modo, logo que os dados são transferido para os buffers, o processador e buses ficam livres para a realização de outras instruções. Estes buffers também são necessários para garantir que os dados são escritos na memória pela mesma ordem pelas quais as operações aparecem no código. Como as instruções são ordenadas por questões de optimização, é necessário garantir que a ordem das escritas seja a correcta Optimizações aplicáveis a Pentium II Descrevem-se nesta secção algumas optimizações realizáveis em programas e que dependem das arquitecturas do processador e computador: Optimização do acesso aos dados de modo a aproveitar os ganhos introduzidos pelas caches Optimizar a execução das instruções usando instruções mais rápidas e permitindo a sua execução em paralelo. Existem outra optimizações[int97], [Int99] que podem ser realizadas mas estão mais orientadas para o desenho de compiladores. A optimização do uso dos registos, por exemplo, é um tipo de optimização que é difícil realizar tendo apenas acesso ao código de alto nível, mas que é imprescindível que seja realizada por um compilador. Optimização do uso da cache O uso de caches nos computadores modernos faz com que os acessos à memória não tenham todos o mesmo custo. Ao aceder-se a uma posição de memória, se esta não estiver já na cache, são também transferidos os valores adjacentes. As próximas leituras a algum desses valores realizar-se-ão muito mais rapidamente. Assim, para obter os ganhos do uso de caches, é necessário que haja localidade espacial nos acessos consecutivos à memória. No exemplo apresentado na Fig. 2.3, devido à ordem dos ciclos e de actualização dos 18

41 Trabalho Relacionado índices, a contabilização de elementos nulos de uma matriz não tira partido da existência de caches. 1 for (j =0; j<= N; j++){ 2 /* percorrer colunas */ 3 for (i =0; I <=N; i++){ 4 /* percorrer linhas */ 5 if (m[i][j] == 0) 6 count ++; 7 } 8 } i x x x x x x j Fig. 2.3 Exemplo de uso não optimizado da cache (acesso com cache misses - x, dados carregados para cache ) Na primeira iteração do ciclo exterior são visitadas todas as linhas da matriz, verificando se a primeira posição é nula. Em cada acesso é lida uma linha de dados para a cache. A partir do momento em que a cache já está cheia, é necessário substituir as linhas mais antigas. Para matrizes grandes, quando se termina a primeira iteração, as primeiras linhas já não se encontram na cache. Se o tamanho da matriz for superior ao da cache, é provável que a partir de determinada linha, os cache misses obriguem à substituição dos dados armazenados na cache. Assim, na segunda iteração externa são percorridas outra vez todas as linhas da matriz, obrigando à leitura de todos os dados a partir da memória. Neste caso, a existência da cache não se reflecte me ganhos observáveis, Com efeito, os acessos aos dados demorariam o mesmo tempo se as caches não existissem. Com esta aproximação não se obtém ganho nenhum do uso da cache. Em todas as leituras é necessário efectuar a transferência de dados a partir da memória principal. Trocando a ordem dos ciclos já se obtêm ganhos do uso da cache, tal como se observe na Fig No primeiro acesso à matriz, é necessário efectuar a leitura de uma linha da cache. Os próximos acessos (nos endereços seguintes) já aproveitam os dados armazenados em cache, não obrigando à transferência de dados a partir da memória principal. A partir deste momento, como os acessos à memória são todos sequenciais, após uma leitura da memória principal, ocorrem diversos acessos cujos dados já se encontram em cache, reduzindo o tempo total de leitura. Para tipo de dados dinâmicos a optimização dos acessos à memória já é mais difícil. Como a localização lógica das estruturas não influencia a sua localização física, não se consegue garantir uma localidade espacial de referência aquando do acessos aos dados. Assim, não 19

42 Optimização e Avaliação de Aplicações de Simulação Numérica se consegue tirar partido da cache. 1 for (i =0; i<= N; j++){ 2 /* percorrer linhas */ 3 for (j =0; j <=N; i++){ 4 /* percorrer colunas*/ 5 if (m[i][j] == 0) 6 count ++; 7 } 8 } i j x x Fig. 2.4 Exemplo de uso optimizado da cache (acesso com cache misses - x, acesso com cache hit, dados carregados para cache ) Optimização da execução das instruções As optimizações relacionadas com o encadeamento das instruções, geralmente, podem ser resolvidas pelo compilador e pela possibilidade do processador executar instruções fora de ordem. Há, no entanto, casos em que a organização do código impossibilita a execução óptima das instruções. A arquitectura da unidade de execução dos processadores Pentium II permite a execução simultânea de várias instruções em portos diferentes. Como cada porto executa determinado tipo de instruções é necessário garantir que existem instruções de tipos distintos para manter o funcionamento dos vários portos em paralelo. Uma outra origem de atrasos é a dependência entre operandos e resultados de várias instruções. Uma instrução só pode ser executada caso todos os seus operandos já tenham sido calculados pelas instruções anteriores. Quando se têm uma grande dependência entre resultados e operações posteriores é possível que ocorram stalls no processador. Em código de processamento numérico, a alta densidade de instruções de vírgula flutuante, os dois problemas anteriores são muito frequentes. O elevado tempo de execução das instruções de vírgula flutuante (entre 5 e 17 ciclos de relógio) e o facto dos processadores Pentium II só terem uma unidade de execução de vírgula flutuante agravam os problemas atrás descritos. É então necessário escrever o código de modo a que seja possível intercalar operações de vírgula flutuante e outras de manipulação de inteiros ou leituras/escritas. Se houver a intercalação de instruções não dependentes entre si, consegue-se aproveitar o pipeline de execução de instruções de vírgula flutuante. É possível iniciar a execução de 20