Dissertacao - Algoritmos para simulador de arquiteturas paralelas

6.346 visualizações

Publicada em

Publicada em: Tecnologia
0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
6.346
No SlideShare
0
A partir de incorporações
0
Número de incorporações
154
Ações
Compartilhamentos
0
Downloads
273
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Dissertacao - Algoritmos para simulador de arquiteturas paralelas

  1. 1. LUIZ ARTHUR FEITOSA DOS SANTOS Desenvolvimento de Algoritmos Paralelos para Simulador de Multiprocessadores Superescalares MARINGÁ 2005
  2. 2. LUIZ ARTHUR FEITOSA DOS SANTOS Desenvolvimento de Algoritmos Paralelos para Simulador de Multiprocessadores Superescalares Dissertação apresentada ao Programa de Pós-Graduação em Ciência da Computação da Universidade Estadual de Maringá, como requisito parcial para obtenção do grau de Mestre em Ciência da Computação. Orientador: Prof. Dr. João Angelo Martini MARINGÁ 2005
  3. 3. LUIZ ARTHUR FEITOSA DOS SANTOS Desenvolvimento de Algoritmos Paralelos para Simulador de Multiprocessadores Superescalares Dissertação apresentada ao Programa de Pós-Graduação em Ciência da Computação da Universidade Estadual de Maringá, como requisito parcial para obtenção do grau de Mestre em Ciência da Computação. Aprovado em BANCA EXAMINADORA Prof. Dr. João Angelo Martini Universidade Estadual de Maringá – UEM Prof. Dr. Ronaldo A. L. Gonçalves Universidade Estadual de Maringá – UEM Profa. Drª. Roberta Spolon Ulson Departamento de Computação – UNESP
  4. 4. DEDICATÓRIA Dedico este trabalho Aos meus pais, a minha namorada, aos meus amigos e principalmente a Deus.
  5. 5. AGRADECIMENTOS Agradeço inicialmente aos meus pais Wanderley Feitosa dos Santos e Enezita M. Verderio dos Santos, que me deram todo o apoio necessário para conclusão de mais esta etapa da minha vida, e principalmente porque são fontes inesgotáveis de inspiração para mim. Agradeço ao meu orientador João Angelo Martini, pelos conselhos profissionais, amizade e pelo conhecimento compartilhado. Agradeço à minha amada namorada Keula Massuda, por todo apoio que está me deu nos momentos fácies e principalmente nos difíceis, demonstrando todo seu carinho e consideração. Agradeço aos meus amigos Ricardo Alexandre Lavarias, Edson Jose Tomiazzi “Kitio”, Igor Wiese, Rogério Pozza, André Pozza, Edson Alves de Oliveira Junior, Aysllan Possebom, Jeber Gonzaga e Leila Massuda, pela amizade e contribuições. Agradeço a todos os professores que compartilharam conhecimento e me ajudaram a concluir este trabalho, dentre eles: Ronaldo A. L. Gonçalves, Elisa Hatsue M. Huzita, Itana M. S. Gimenes, Ademir Aparecido Constantino, Munif Gebara Junior, Claudete Werner, Daniela Flor, Yandre Maldonato e Roni Fancis Shigueta. Agradeço ao Departamento de Informática, principalmente à Maria Inês Davanço, por toda atenção, respeito, paciência e amizade.
  6. 6. “Penso noventa e nove vezes e nada descubro deixo de pensar, mergulho em profundo silêncio e eis que a verdade se revela.” Albert Einstein
  7. 7. RESUMO A necessidade de resolver problemas intensivamente computacionais vem exigindo arquiteturas computacionais com desempenhos cada vez mais elevados. Para atender essa demanda, esforços de pesquisa têm sido desenvolvidos na área de arquiteturas paralelas. Para se obter resultados satisfatórios com arquiteturas paralelas são necessários estudos meticulosos de hardware e software. Uma alternativa de apoio a pesquisas em arquiteturas paralelas é o uso de simuladores. Neste contexto, diversos grupos de pesquisa têm desenvolvido simuladores de arquiteturas paralelas. O grupo de pesquisa em Arquiteturas de Alto Desempenho da Universidade Estadual de Maringá desenvolveu uma ferramenta de simulação denominada Simulador de Multiprocessadores Superescalares. Entretanto somente essa ferramenta de simulação não permite investigar arquiteturas, é necessário também o uso de algoritmos desenvolvidos especificamente para este simulador. Assim, este trabalho tem por objetivo o desenvolvimento de algoritmos paralelos a serem utilizados em conjunto com o Simulador de Multiprocessadores Superescalares, fornecendo assim meios de simular e avaliar uma arquitetura paralela. Tais algoritmos visam testar e explorar os diversos aspectos de uma arquitetura paralela. Viabilizando o estudo de arquiteturas paralelas em uma variedade de configurações de arquiteturas fornecidas pelo simulador, possibilitando também que a ferramenta seja usada como apoio ao ensino de arquiteturas paralelas. Após o desenvolvimento dos algoritmos para simulação no SMS, ficou constatado que os algoritmos em conjunto com a ferramenta de simulação proporcionam um ambiente ideal para o estudo e experimentação de arquiteturas paralelas. Palavras-chave:Arquitetura de Computadores. Computação Paralela. Simulação. Algoritmos.
  8. 8. ABSTRACT The need for solving problems intensively related to computers has been demanding computer architectures more and more developed. To attend this demand research efforts have been developing the parallel architecture area. To obtain better results with them, it’s necessary some, searches on meticulous. hardware and software An alternative to support those search on parallel architectures is the use of simulators. On this context, some research groups have been developing parallel architectures simulators. The high development architectures from Universidade Estadual de Maringá developed a simulator tool called Superscalar Multiprocessors Simulator. However only this simulator tool isn’t able to investigate architectures, it’s also necessary the use of algorithms specifically develop for that simulator. This way, this paper has main goal the development of parallel algorithms to be used along with the Superscalar Multiprocessor Simulator offering conditions to simulate and evaluate a parallel architecture. Those algorithms aim to test and explore the diverse aspects of a parallel architecture. Making the study of parallel architectures possible in a variety of architecture configuration given by the simulator, also making possible that the tool be used as a support to the parallel architecture teaching. After the development of those algorithms for simulation on the SMS, it was proved that the algorithms along with the simulation tool permit an ideal environment for the parallel architectures study and experiment. Keywords: Computer Architectures. Parallel Computation. Simulation. Algorithms.
  9. 9. LISTA DE ILUSTRAÇÕES Figura 1 - Máquina de von Neumann...........................................................................................18 Figura 2 - (a) Memória compartilhada (b) Memória distribuída..................................................23 Figura 3 - Arquitetura do simulador SMS....................................................................................33 Figura 4 - Inicializando a biblioteca de comunicação do SMS ....................................................36 Figura 5 - Usando funções da biblioteca SMS .............................................................................38 Figura 6 - Características dos Speedups de tamanho fixo e tempo fixo.......................................59 Figura 7 - Speedup Absoluto ........................................................................................................60 Figura 8 - Speedup Relativo .........................................................................................................60 Figura 9 - Eficiência .....................................................................................................................62 Figura 10 - Matriz.........................................................................................................................64 Figura 11 - Algoritmo seqüencial para multiplicação de matrizes...............................................65 Figura 12 - Divisão da Matriz em Vetores no Programa Mestre .................................................65 Figura 13 - Multiplicação dos Vetores pelas Colunas da Matriz B nos Processadores Escravos.............................................................................................................................66 Figura 14 - O programa mestre reagrupa os vetores resultantes dos processos escravos ............66 Figura 15 - Algoritmo paralelo de multiplicação de matrizes......................................................68 Figura 16 - Saída reduzida de uma simulação no SMS................................................................69 Figura 17 - Tempo de execução do algoritmo de multiplicação de matrizes...............................70 Figura 18 - Speedup apresentado pelo algoritmo paralelo de multiplicação de matrizes ............70 Figura 19 - Eficiência apresentada pelo algoritmo paralelo de multiplicação de matrizes ..........71 Figura 20 - Fórmula para calcular o valor de π ...........................................................................73 Figura 21 - Programa escravo do cálculo do π ...........................................................................74
  10. 10. Figura 22 - Speedup do algoritmo paralelo do cálculo do π .......................................................75 Figura 23 - Tempo de execução do algoritmo do cálculo do π ...................................................76 Figura 24 - Eficiência apresentada pelo algoritmo do cálculo do π ............................................76 Figura 25 - Definição de integral de uma função não negativa....................................................77 Figura 26 - Usando integral para definir trapézio ........................................................................78 Figura 27 - Trapézio .....................................................................................................................78 Figura 28 - Código do algoritmo Trapezoidal rule com MPI.......................................................79 Figura 29 - Código do algoritmo Trapezoidal rule com SMS......................................................81 Figura 30 - Tempo total de execução do Trapezoidal rule ..........................................................83 Figura 31 - Speedup Trapezoidal rule..........................................................................................84 Figura 32 - Eficiência do algoritmo Trapezoidal rule frente a arquitetura ..................................84 Figura 33 - Algoritmo de Round-Trip ..........................................................................................86 Figura 34 - Algoritmo Bubble Sort ..............................................................................................88 Figura 35 - Algoritmo de ordenação Odd-Even ...........................................................................89 Figura 36 - Processo de ordenação utilizando algoritmo Odd-even.............................................90 Figura 37 - Ordenação por Odd-Even utilizada no SMS .............................................................91 Figura 38 - Tempo total de execução do Odd-Even sort..............................................................92 Figura 39 - Speedup do Odd-Even sort ........................................................................................93 Figura 40 - Eficiência do Odd-even sort ......................................................................................93 Figura 41 - Uso da rede de interconexão do algoritmo Odd-Even sort........................................94 Figura 42 - Uso da rede de interconexão do algoritmo de cálculo do π.......................................94 Figura 43 - Linha de comando para executar o programa de cálculo do π com cache de dados de tamanho de 4096...........................................................................................................96 Figura 44 - Speedup do π com alteração de cache de dados ........................................................97 Figura 45 - Eficiência do π com alteração de cache de dados......................................................98
  11. 11. Figura 46 - Linha de comando que dispara o simulador SMS com alterações no previsor de desvio.................................................................................................................................98 Figura 47 - Speedup e eficiência do algoritmo Trapezoidal rule com previsor de desvio alterado ..............................................................................................................................99 Figura 48 - Elapsed Time do algoritmo Odd-Even com duas redes de interconexão.................100
  12. 12. LISTA DE TABELAS Tabela 1 - Simuladores do SimpleScalar......................................................................................27 Tabela 2 - Primitivas SMS para passagem de mensagem ............................................................32 Tabela 3 - Taxa de transferência da rede de interconexão em bytes por segundo........................87
  13. 13. SUMÁRIO 1 INTRODUÇÃO .......................................................................................................... ....15 2 COMPUTAÇÃO PARALELA.......................................................................................17 2.1 Processamento Seqüencial ..............................................................................................17 2.2 Classificação de Flynn .....................................................................................................19 2.3 Processamento Paralelo ..................................................................................................21 2.4 Arquiteturas Paralelas com Memória Compartilhada e Distribuída.........................22 2.4.1 Multiprocessadores com Memória Compartilhada............................................................22 2.4.2 Multiprocessadores com Memória Distribuída .................................................................23 3 SIMULADOR DE ARQUITETURAS ..........................................................................25 3.1 SimpleScalar ....................................................................................................................25 3.2 Simulador de Ambientes Paralelos ................................................................................27 3.3 Algoritmos para testes e avaliação de desempenho......................................................29 3.4 Simulador de Multiprocessadores Superescalares - SMS ...........................................31 3.5 Biblioteca de Passagem de Mensagem do SMS ............................................................35 4 PROGRAMAÇÃO PARALELA E ALGORITMOS PARALELOS .........................39 4.1 Aplicações Paralelas ........................................................................................................41 4.2 Passagem de Mensagens..................................................................................................52 5 AVALIAÇÃO DE DESEMPENHO ..............................................................................54 5.1 Alguns aspectos quanto a medidas de desempenho......................................................55 5.2 Tempo de execução..........................................................................................................57 5.3 Speedup. ...........................................................................................................................57 5.4 Eficiência. .........................................................................................................................61
  14. 14. 6 ALGORITMOS PARALELOS PARA O SMS ............................................................63 6.1 Algoritmo Paralelo de Multiplicação de Matrizes........................................................63 6.2 Algoritmo Paralelo para Cálculo do π ..........................................................................72 6.3 Algoritmo Trapezoidal Rule ...........................................................................................76 6.4 Algoritmo para testes da Rede de Interconexão do Simulador SMS..........................84 6.5 Algoritmo de ordenação Odd-Even ...............................................................................87 6.6 Simulação de Outras Arquiteturas com o SMS e os Algoritmos ................................94 7 CONCLUSÃO................................................................................................................101 8 TRABALHOS FUTUROS ............................................................................................103 REFERÊNCIAS ............................................................................................................104 ANEXO A.......................................................................................................................108
  15. 15. 15 1 INTRODUÇÃO A motivação principal para investigação, desenvolvimento e utilização de arquiteturas paralelas fundamenta-se na necessidade de se resolver problemas intensivamente computacionais. São os chamados “Grand Challenges” (WOODWARD, 1996; CHANG; EWING, 1999), problemas como previsão de tempo e simulação de dinâmica molecular, que exigem máquinas com grande capacidade de processamento. Tal poder de processamento pode ser viabilizado por meio de arquiteturas paralelas. Inicialmente a exploração de paralelismo se deu em um nível mais baixo, como por exemplo, processadores superescalares (SMITH, 1995). Arquiteturas paralelas exploram o paralelismo em um nível mais alto. Neste modelo o problema a ser resolvido é dividido entre os processadores que compõem a arquitetura. Idealmente, se um trabalho foi subdivido e está sendo executado por p processadores, espera-se que ele seja concluído p vezes mais rápido do que seria quando executado por um único processador. Obviamente, esse caso ideal, na prática não é alcançado devido a problemas como tempo de comunicação entre os processadores e trechos de código do programa essencialmente seqüenciais. Arquiteturas paralelas são normalmente complexas e apresentam um custo de desenvolvimento elevado. Por isso, a simulação através de software se mostra como a melhor técnica para avaliação dessas arquiteturas quando comparada à modelagem analítica e à construção de máquinas reais. Em um software simulador, pode-se: modelar toda a complexidade de uma arquitetura; efetuar alterações e correções durante o processo de desenvolvimento; usar tantas máquinas quanto estiverem disponíveis e até simular recursos que ainda não estão disponíveis fisicamente. Além do que em arquiteturas reais, há outros
  16. 16. 16 custos relacionados aos problemas de instalação, gerenciamento e manutenção que também encarecem as experiências pretendidas. O uso de simuladores também reduz esses fatores e facilita o estudo de arquiteturas paralelas. Dada a importância dos simuladores na pesquisa de computadores, o foco deste trabalho consiste no desenvolvimento um conjunto de algoritmos para testes com o Simulador de Multiprocessadores Superescalares. O SMS permite o desenvolvimento de aplicações e a análise de desempenho de arquiteturas paralelas e possibilita a configuração de diferentes modelos arquiteturais. O usuário do SMS pode simular ambientes paralelos de memória distribuída, bem como definir a topologia e o protocolo de rede de interconexão utilizada para comunicação entre os processadores. Em conjunto com os algoritmos a ferramenta pode ser vista como uma alternativa de baixo custo para pesquisa e ensino na área de Arquitetura de Computadores de Alto Desempenho, pois, viabiliza o desenvolvimento de aplicações paralelas e análise de desempenho de diversos modelos de arquiteturas. Este trabalho está organizado conforme segue: o capítulo 2 faz uma breve descrição sobre Computação Paralela. O capítulo 3 descreve alguns simuladores e trata da ferramenta de simulação SMS. No capítulo 4 são tratados os diversos aspectos de programação em ambientes paralelos. Já o capítulo 5 apresenta medidas de desempenho para auxiliar na análise das saídas do simulador. Por fim, no capítulo 6 são apresentados os algoritmos propostos para o simulador SMS, e nos capítulos seguintes são apresentados as conclusões finais e os trabalhos futuros.
  17. 17. 17 2 COMPUTAÇÃO PARALELA Este capítulo discute os fundamentos de computação paralela. Introduz as bases do modelo seqüencial que servirá de modelo de comparação com o modelo de computação paralela. Apresenta a taxonomia de Flynn, que é a mais utilizada nas classificações de arquiteturas de computadores. 2.1 Processamento Seqüencial O modelo de processamento seqüencial, teve dentre seus criadores Blaise Pascal, Charles Babbage e John von Neumann. John von Neumann apresentou um modelo elementar de execução seqüencial, composto basicamente por memória, unidade lógica e aritmética, unidade de controle e os dispositivos de entrada/saída (Figura 1) (TANENBAUM, 2001). Em computadores estritamente seqüenciais, as instruções que compõem um programa são executadas de forma seqüencial (conforme foram definidas pelo programador) pelo processador. Este modelo proposto serve até hoje como base para a resolução de problemas através de algoritmos seqüenciais. Entretanto, atualmente mesmo as arquiteturas seqüenciais utilizam algum tipo de paralelismo interno ao processador ou aos dispositivos que compõem a arquitetura de forma a conseguirem melhores desempenhos. Grande parte dos processadores modernos explora o paralelismo em nível de instrução (ILP – Instruction-Level Parallelism) para melhora de desempenho. Outra técnica, denominada pipeline, permite a execução sobreposta de várias instruções. Antes do uso do pipeline uma instrução tinha que esperar a instrução anterior completar a execução para poder ser executada. Por exemplo, para que uma instrução seja
  18. 18. 18 completada ela necessita passar por estágios, tal como: busca de instrução, decodificação, leitura de registradores, execução e escrita de resultado em registrador. Sem o uso do pipeline as instruções têm que passar uma por vez, através de todos os estágios. Já com o advento do pipeline, enquanto uma instrução está na unidade de decodificação, já existe outra instrução sendo buscada, outra sendo executada e assim por diante. Dessa forma, o pipeline permite que os estágios necessários para o processamento de instruções fiquem ocupados, de modo que o processador não fique ocioso (HENNESSY, 2003). Figura 1 - Máquina de von Neumann Outra melhoria de desempenho foi obtida com o modelo superescalar. Processadores superescalares basicamente buscam e decodificam diversos fluxos de instruções ao mesmo tempo, permitindo que várias instruções sejam executadas em um único ciclo de clock (SMITH, 1995). Processadores superescalares possibilitam a execução de instruções em paralelo, utilizando o paralelismo em nível de instrução. O funcionamento de um processador superescalar consiste basicamente nos seguintes passos: i. Os fluxos de dados são analisados quanto a dependências de dados, já que alguns dados
  19. 19. 19 podem ter dependências em relação a outras instruções, necessitando aguardar a execução dessas, para somente então poderem ser processadas. ii. Depois deste passo é que as instruções são distribuídas para as unidades funcionais de acordo com o tipo de instrução. iii. As próximas instruções a serem iniciadas para a execução em paralelo, são baseadas primeiramente na disponibilidade do operador de dados, que preferencialmente respeita a ordem do programa seqüencial, porém o processador superescalar pode permitir a execução de uma instrução fora de ordem (HENNESSY, 2003), o que é uma característica marcante neste tipo de processador. iv. Após os passos anteriores é necessário que essas instruções sejam reordenadas, tal tarefa permite que as instruções apesar de serem executadas em ordem diferente do programa original voltem à ordem original que foi estabelecida no programa seqüencial. E desta forma termina-se a execução de uma instrução no processador superescalar. Assim, processadores superescalares possibilitam que instruções sejam executadas em uma ordem diferente daquela do programa original e de forma paralela, fazendo melhor uso de unidades funcionais através do pipeline. Todos esses aspectos de paralelismo em arquiteturas seqüenciais já trouxeram inúmeros benefícios à computação, e uniram de certa forma modelos paralelos e seqüenciais, necessitando assim de uma classificação para essas arquiteturas. A seção 2.2 discute a Classificação de Flynn. 2.2 Classificação de Flynn Michael Flynn, em 1966, classificou os inúmeros modelos de arquitetura computacional de acordo com o número de instruções executadas e o número de conjuntos de
  20. 20. 20 dados tratados (FLYNN, 1966), essa caracterização produziu quatro classes de computadores, que são: - Arquitetura SISD - Single Instruction, Single Data: Conjunto único de instruções, conjunto único de dados. É a identificação mais simples de um computador, cujas instruções são executadas de forma seqüencial, ou seja, tal máquina só processa uma única instrução sobre um único dado por vez. É o modelo de von Neumann. - Arquitetura MISD - Multiple Instruction, Single Data: Múltiplas instruções, conjunto único de dados. São computadores que executam várias instruções ao mesmo tempo sobre um único dado. Não existe nenhuma máquina implementada neste modelo, e até mesmo Flynn duvidou que algum dia isso pudesse existir. - Arquitetura SIMD – Single Instruction, Multiple Data: Conjunto único de instruções, múltiplos conjuntos de dados. É o equivalente ao paralelismo de dados, no qual uma instrução é executada paralelamente utilizando vários dados (processadores vetoriais, matriciais se enquadram nesta categoria). - Arquitetura MIMD – Multiple Instruction, Multiple Data: Múltiplos conjuntos de instruções, múltiplos conjuntos de dados. Este modelo é o que faz a melhor referência à computação paralela propriamente dita, pois se refere ao modelo de execução paralela, no qual cada processador está essencialmente agindo independentemente, havendo, portanto realmente múltiplos fluxos de instruções e múltiplos dados (ZARGHAN, 1995). A taxonomia de Flynn, apesar de elementar está em uso até hoje em função de sua classificação simples, fácil de entender e por ser muito semelhante aos modelos reais de arquiteturas de computadores. Atualmente existem modelos híbridos que se enquadram em mais de uma categoria, o que levou a outras propostas de taxonomias (GUTZMANN, 1996).
  21. 21. 21 2.3 Processamento Paralelo Existem problemas que requerem um grande poder de processamento, por exemplo, simulações numéricas em sistemas complexos como previsão de clima, aplicações aerodinâmicas, programas de exploração sísmica, engenharia genética, entre inúmeras outras aplicações (WOODWARD, 1996; CHANG; EWING, 1999). Em sistemas com apenas um processador o desempenho do modelo dito seqüencial, está intrinsecamente relacionado às restrições tecnológicas de cada época, sendo que uma aplicação só terá melhoras de desempenho se tal processador tiver uma melhora de hardware. Em geral, os processadores têm melhorado seu desempenho em mais de 50% ao ano, mas um dia essa evolução pode encontrar algum limite físico, o que se tornará um empecilho para cientistas que desenvolvem cada vez mais programas que utilizam conjuntos de dados gigantescos e necessitam de computadores que possam processar esta massa de dados a uma velocidade cada vez mais rápida e não podem ficar limitados a esse obstáculo. Neste contexto, a computação paralela é uma alternativa viável com potencial para superar esse obstáculo. Mas o que é computação paralela? A definição clássica dada por (ALMASI, 1989) é : “Um computador paralelo é um conjunto de elementos de processamento que se comunicam e cooperam para resolver rapidamente grandes problemas”. Outras definições podem ser obtidas, mas basicamente todas trazem a idéia de que é possível empregar vários processadores para resolver um dado problema de forma paralela e obter-se um menor tempo de processamento (WAHEED, 1993).
  22. 22. 22 2.4 Arquiteturas Paralelas com Memória Compartilhada e Distribuída Dentro da categoria MIMD é possível obter uma subclassificação das arquiteturas em função do modelo de acesso à memória. Neste contexto existem dois modelos bem definidos, que são: computadores com memória compartilhada e computadores com memória distribuída, que são abordados nas subseções subseqüentes. 2.4.1 Multiprocessadores com Memória Compartilhada Neste esquema os processadores acessam uma memória única, que é compartilhada entre todos os processadores, ou mesmo que exista uma memória para cada processador o endereçamento é global e compartilhado por todos (Figura 2a). A comunicação entre a memória global e processadores é feita através de instruções load e store que dão acesso aos endereços da memória. Neste modelo surge a necessidade de se coordenar os acessos ao meio comum, gerenciando quem pode ler e escrever em um determinado endereço comum da memória, a esta coordenação de acessos se dá o nome de sincronização. Este modelo também é denominado de “fortemente acoplado”, e ainda pode ser dividido em dois esquemas distintos que são: Multiprocessadores UMA (Uniform Memory Access) e NUMA (NonUniform Memory Access). No modelo UMA ou SMP (Symmetric MultiProcessor) todos os processadores consomem o mesmo tempo para acessar a memória compartilhada; enquanto que no modelo NUMA alguns acessos à memória são mais rápidos que outros. (BADER, 1997; PATTERSON, 2000).
  23. 23. 23 Processador 1 Processador 1 Memória Cache Cache Memória Barramento Barramento Processador 2 Processador 2 Disp. Cache Entrada/ Cache Saída Memória Disp Processador 3 Entrada/ Processador N Cache Saída Cache Memória (a) (b) Figura 2 - (a) Memória compartilhada (b) Memória distribuída 2.4.2 Multiprocessadores com memória distribuída Nesta arquitetura cada processador possui memória própria que não é compartilhada com outro processador, ou seja, o endereçamento de memória não é compartilhado pelos processadores (figura 2b). Existem funções send e receive, para efetuar trocas de mensagens e assim realizar a comunicação e sincronização dos processadores que constituem a arquitetura, já que isso não ocorre diretamente via memória compartilhada. A esta classificação pode-se também dar o nome de “fracamente acoplada” ou multicomputadores, já que cada nó (unidade constituída por um processador, memória local e dispositivos de entrada e saída) é composto por todos os dispositivos que compõem um computador completo. Nesta categoria de arquitetura pode-se enquadrar os clusters. Existem inúmeras características a serem observadas no modelo de memória distribuída, sendo uma das principais para este trabalho o fato de que em sistemas multicomputadores ao contrário do que ocorre na computação seqüencial, a programação torna-se mais complexa, pois requer que o programador explore o paralelismo explícito durante a programação. Assim, o programador tem que conhecer bem a arquitetura em que o
  24. 24. 24 programa paralelo será executado, para poder explorar o paralelismo na arquitetura. Outra desvantagem deste modelo é a necessidade constante de trocas de mensagens necessárias para sincronização do programa pela rede. Isso pode levar à sobrecarga do subsistema de comunicação, tornando a rede de interconexão um gargalo do sistema. Porém, este tipo de arquitetura está sendo a melhor alternativa para realização de pesquisas em universidades em função do custo e pode apresentar melhoras de desempenho comparáveis aos supercomputadores.
  25. 25. 25 3 SIMULADOR DE ARQUITETURAS Simuladores possibilitam que novas arquiteturas sejam projetadas e analisadas em ambientes de software antes de passarem para a linha de produção, reduzindo de certa forma o custo e o tempo de conclusão envolvidos na construção das arquiteturas. Tal prática permite até avaliar projetos arquiteturais de computadores que nem mesmo podem ser construídos, devido às restrições tecnológicas da época. O uso de simuladores está tão consolidado que mesmo empresas de renome, como Intel, utilizam simuladores para analisar seus processadores, como é o caso do Pentium 4 (AUSTIN, 2002), proporcionando ao mercado um processador que já passou por uma bateria de testes mesmo antes de ser concebido. Desde o advento do computador é uma prática comum para engenheiros utilizar modelos de simulação para estudar sistemas físicos de computadores. Entretanto, para obter simulações realistas principalmente em ambientes paralelos é necessário utilizar cargas de trabalhos muito grandes de forma que os programas a serem simulados trabalhem com bilhões de instruções (EECKHOUT, 2004). O nível de complexidade de simulação de arquiteturas paralelas bem como a carga de trabalho dos algoritmos a serem testados cresce tão rapidamente que já existem trabalhos que utilizam computadores paralelos para realizar simulações dos próprios ambientes paralelos e desta forma diminuir o tempo consumido com simulações de tais ambientes (TROPPER, 2002). 3.1 SimpleScalar Existe um leque muito grande de simuladores (BAGRODIA, 2000) que são
  26. 26. 26 utilizados para os mais diversos propósitos, alguns exemplos de simuladores de arquiteturas computacionais são: Neander e Ramsés da Universidade Federal do Rio Grande do Sul, baseados no modelo seqüencial proposto por John von Neumann; RSIM (Rice Simulation) (PAI, 1997), que faz simulação de arquiteturas superescalares; ABSS (Augmentation-Based SPARC Simulation) (SUNADA, 1998), empregado principalmente em simulações de memórias e Proteus (BREWER, 1991), que fornece suporte a sistemas multiprocessadores. Um outro simulador que tem sido extensivamente utilizado no meio acadêmico e também por empresas é o simulador SimpleScalar (BURGER, 1997; AUSTIN, 2002). O SimpleScalar foi desenvolvido em 1992 na Universidade de Wisconsin sob a coordenação de Gurindar S. Sohi. E posteriormente Doug Burger disponibilizou uma versão gratuita do simulador para uso não comercial, a qual está disponível na Internet no endereço eletrônico www.simplescalar.com. O SimpleScalar pode emular diversos conjuntos de instruções, como por exemplo: ARM, MIPS, Alpha, PowerPC e x86, e devido à sua arquitetura aberta ele pode ser estendido a outros conjuntos de instruções. Outro fator que influencia a utilização deste simulador em larga escala é o fato dele ser executado em sistemas operacionais gratuitos como o Linux. Os pesquisadores de novas arquiteturas podem utilizar benchmarks pré-compilados ou criar novas aplicações para serem testadas e analisadas neste simulador, a construção desses programas é realizada utilizando-se uma linguagem de programação de alto nível, que pode ser C ou Fortran. O código fonte depois de pronto é compilado especialmente para ser executado no SimpleScalar, possibilitando assim a execução de programas reais em protótipos virtuais de arquiteturas. A ferramenta de simulação SimpleScalar é constituída por um conjunto de vários simuladores, conforme pode-se observar na tabela 1. Desta forma, o SimpleScalar pode viabilizar simulações de arquiteturas de forma rápida e concisa através do sim-fast ou simulações mais detalhadas e dinâmicas através do sim-outorder, possibilitando a simulação
  27. 27. 27 de processadores que dão suporte a caches non-bloking, execução especulativa, renomeação de registradores e diversos modos de previsão de desvio. Linhas de Velocidade de Simulador Descrição código Simulação sim-safe Simulador simples 320 6 MIPS sim-fast Simulador otimizado 780 7 MIPS sim-profile Programa dinâmico para análise 1300 4 MIPS sim-bpred Simulador de previsão de desvios 1200 5 MIPS sim-cache Simulador de caches multinível 1400 4 MIPS sim-fuzz Testador e analisador de instruções aleatórias 2300 2 MIPS sim-outorder Simulador de microarquiteturas detalhado 3900 0.3 MIPS Tabela 1 - Simuladores do SimpleScalar 3.2 Simuladores de Ambientes Paralelos Muitos centros de pesquisas em computação de alto desempenho têm desenvolvido pesquisas no sentido de “construir” simuladores para arquiteturas paralelas servindo como ferramenta para pesquisa e ensino de arquiteturas paralelas. Alguns desses são: • MINT (MIPS Interpreter) (VEENSTRA, 1993) que utiliza threads para simular um ambiente multiprocessador, conta com sistema de interconexão e hierarquia de memória. O MINT roda executáveis compilados para plataformas MIPS (R3000). • RSIM (Rice Simulator) (PAI, 1997) que implementa um modelo de processador detalhado para arquitetura superescalar. Simula um sistema multiprocessador de memória compartilhada. O RSIM roda nas plataformas SPARC e Solaris. • ABSS (SPARC Simulator) (SUNADA, 1998) empregado principalmente nas simulações de memória. O ABSS usa threads para simular multiprocessadores. Ele roda apenas nas plataformas SPARC e possui interface gráfica derivada do MINT. • Limes (Multiprocessor Simulator for PC Platforms) (MAGDIC, 1999) instrumenta o
  28. 28. 28 código em assembler com chamadas “kernel call-outs” em tempo de compilação. Para isso é preciso que as aplicações utilizem macros do tipo ANL (Argonne National Lab) para expressar o paralelismo. O Limes também usa threads para simular um ambiente multiprocessador e roda em plataformas PC. • Proteus (BREWER, 1991) permite a simulação de multiprocessadores com interconexões do tipo: bus, k-ary, n-cube e butterfly. Possui biblioteca para passagem de mensagens, gerenciamento de memória e threads, além de coleta de dados e interface gráfica sofisticada para representar as saídas da simulação. • Augmint (NGUYEN, 1996) usa threads para simular um sistema multiprocessador com espaço de memória compartilhada e privada (para determinadas variáveis). Ele roda aplicações escritas em C e C++ com macros-m4. Ele roda em arquiteturas Intel x86. • Tango Lite (HERROD, 1993) simula um ambiente multiprocessador com memória compartilhada. Ao contrário do seu predecessor o Tango, o Tango Lite usa threads ao invés de Unix Process. As aplicações podem ser escritas em C ou Fortran e devem fazer uso de macros-m4 para criação e controle de processos, bem como para a comunicação e sincronização dos processos. O Tango Lite roda em plataforma MIPS (R3000). • MulSim (MATLOFF, 2005) é um simulador para ambiente multiprocessador com memória compartilhada, dispondo de vários tipos de interconexão entre memória e processador. • Multiprocessor Enhancements of the SimpleScalar Tool Set (MANJIKIAN, 2001). Simulador funcional (não detalhado) e simulador de cache baseados na ferramenta SimpleScalar, usam threads para simular um ambiente multiprocessador. Conta com suporte à visualização gráfica do conteúdo da cache.
  29. 29. 29 • SMINT ou Superescalar MINT (LU, 1998) é um simulador de multiprocessadores superescalares baseado no simulador MINT. A ferramenta de simulação apresentada neste trabalho (nas seções subseqüentes) difere-se dos demais simuladores apresentados por permitir simulações detalhadas de arquiteturas paralelas de memória distribuída, com processadores superescalares que fazem uso de passagem de mensagem para comunicação entre os processadores. Sendo que a grande maioria dos simuladores existentes permite apenas a simulação de ambientes de memória compartilhada usando threads para a programação. Atualmente é muito interessante a simulação de ambientes com memória distribuída que utilizam técnicas de passagem de mensagem, pois o uso desta tecnologia está bastante difundido no mercado e em universidades. O que torna o simulador SMS muito útil, já que tal simulador possibilita o estudo detalhado de tais ambientes de computação. 3.3 Algoritmos para testes e avaliação de desempenho Os simuladores citados na seção 3.2 são utilizados para reproduzirem ambientes computacionais reais e para isso precisam de algoritmos que possam ser executados nas simulações. Mesmo abordando melhor o assunto sobre algoritmos e programação paralela no capítulo 4, esta seção apresenta uma breve discussão dos programas utilizados com os simuladores de arquiteturas ou mesmo algoritmos utilizados em testes de sistemas computacionais reais. Os algoritmos utilizados para testes de desempenho no meio computacional são normalmente denominados benchmarks, que são programas reais ou apenas partes de programas chamadas de kernels. Estes kernels são as partes mais críticas ou significativas de um programa real utilizado para testar uma arquitetura ou apenas uma parte da arquitetura.
  30. 30. 30 Então, um benchmark é um programa que tem por objetivo proporcionar uma carga de trabalho a uma arquitetura computacional, de forma que se possa avaliar o desempenho da arquitetura segundo as características do benchmark. Existem vários benchmarks e um dos mais conceituados é o System Performance Evaluation Cooperative (SPEC) (DUJMOVIC, 1998), que tem por objetivo melhorar os resultados de testes sobre desempenho em sistemas computacionais. Fundado em 1988 o SPEC iniciou com apenas alguns programas de testes simples que visavam apenas comparar computadores da época. Porém, atualmente o SPEC está disponível para vários tipos de testes com arquiteturas, abrangendo desde testes com computadores pessoais através do grupo OSG (Open System Group), passando por testes de desempenhos de dispositivos com funcionalidades gráficas com o grupo CPC (Graphics Performance Characterization) e chegando por fim a grupos que criam benchmarks para computação de alto desempenho como o grupo HPG (High-Performance Group). Seguindo a linha de programas para testes de arquiteturas para computação paralela ou de alto desempenho existem dois benchmarks que merecem destaques: NAS Parallel Benchmarks (NPB) (BAILEY, 1993) e SPLASH (Standford Parallel Application for Shared Memory) (WOO, 1995). O NAS é um conjunto de programas desenvolvidos pela agência aeroespacial dos Estados Unidos da América (NASA). Os benchmaks do NAS são derivados de aplicações envolvendo dinâmicas de fluídos, consistindo de cinco kernels e três pseudo-aplicações. O SPLASH, desenvolvido pela Universidade de Stanford está na versão 2, e é constituído por kernels envolvendo matrizes e vetores tal como (Complex 1D FFT e Integer Radix Sort) e aplicações completas como o Ocean Simulation e Water Simulation with Spatial Data Structure. Todos esses benchmarks auxiliam a comunidade científica a realizar testes com
  31. 31. 31 sistemas computacionais. Entretanto, se utilizados para uso acadêmico, principalmente com intuído de auxiliar no ensino de arquiteturas paralelas, tais benchmarks deixam a desejar, já que quase todos são muito complexos dificultando a sua compreensão de imediato. Assim esses benchmarks são bons para testes de arquiteturas, mas não para o ensino de aplicações paralelas (BAGRODIA, 1999). Como o objetivo deste trabalho é desenvolver os aplicativos para um simulador de arquiteturas paralelas com fins educacionais, os algoritmos propostos aqui têm de ser o mais simples possível para que um estudante possa entender o algoritmo e da mesma forma possa utilizá-lo para testar a arquitetura. 3.4 Simulador de Multiprocessadores Superescalares - SMS Neste contexto, o grupo de pesquisas de arquiteturas de alto desempenho do Departamento de Informática da Universidade Estadual de Maringá também tem desenvolvido pesquisas em simulação de arquiteturas paralelas e desenvolveu a ferramenta de simulação SMS. A ferramenta SMS viabiliza o desenvolvimento de aplicações e análise de desempenho de computadores paralelos. O SMS tem como base o núcleo do simulador SimpleScalar. Atualmente a ferramenta dispõe de memória distribuída, primitivas de comunicação (Send e Receive) para troca de mensagens e uma rede de interconexão com topologia de barramento compartilhado (SANDRI, 2004). Dentre as alterações realizadas no SimpleScalar para o desenvolvimento do SMS, uma das principais características implementadas é a biblioteca que realiza a comunicação entre os vários processadores que constituem a arquitetura simulada. As bibliotecas fornecem primitivas (ver tabela 2) de comunicação semelhantes às do MPI
  32. 32. 32 (Message-Passing Interface) (PACHECO, 1997). Através desta biblioteca pode-se desenvolver aplicativos paralelos e testá-los nas mais diversas arquiteturas. Primitivas Descrição Não bloqueantes Send Envia Sendbc Envia para todos os processadores em paralelo (Broadcast) Recv Recebe Bloqueantes por espera ocupada Send_be Envia Sendbc_be Envia para todos os processadores em paralelo (Broadcast) Recv_be Recebe Recvo_be Recebe recuperando a origem Recvseto_be Recebe passando a origem Bloqueantes por Interrupção Send_bi Envia Sendbc_bi Envia para todos os processadores em paralelo (Broadcast) Recv_bi Recebe Recvo_bi Recebe recuperando a origem Recvseto_bi Recebe passando a origem Tabela 2 - Primitivas SMS para passagem de mensagem A figura 3 mostra o modelo funcional da ferramenta. Existem 3 módulos principais: Interface Gráfica, Interface do Simulador e Simulador. O módulo de Interface Gráfica é usado pelo usuário para definir previamente os parâmetros que caracterizam a arquitetura simulada, tais como: o número de conjuntos e de associatividade da cache, o modo de previsão de desvios, o número de unidades funcionais, memória compartilhada ou distribuída, a topologia e o protocolo de comunicação, e os programas que serão simulados. O módulo de Interface do Simulador é responsável por iniciar o módulo Simulador, repassando a ele as configurações realizadas no módulo de Interface Gráfica. Esse módulo realiza a distribuição dos processos entre os processadores, e faz a coleta de dados disponibilizados pelo módulo Simulador, repassando-os para o módulo de Interface Gráfica. O módulo Simulador é composto de 4 submódulos principais. Esses submódulos interagem entre si, a fim de promover a execução de aplicações paralelas. São eles: Primitivas
  33. 33. 33 de Comunicação, Gerenciador de Memória, Protocolo e Topologia. Interface Gráfica Interface para passagem de parâmetros da simulação Interface Simulador Disparador e Coletor Programas do Usuário Programa 1 Programa 2 Programa 3 ... Programa N Simulador Bibliotecas – Send e Receive Gerenciador de Memória Paralelo Protocolo Topologia Processador Processador 2 Processador ... Processador Figura 3 - Arquitetura do simulador SMS O submódulo Primitivas de Comunicação dispõe de primitivas Send e Receive que operam de três maneiras distintas: não bloqueantes, bloqueantes por espera e bloqueantes por interrupção. As primitivas não bloqueantes enviam e recebem mensagens sem realizar nenhum tipo de espera ou bloqueio. As primitivas bloqueantes por espera enviam e recebem mensagens, porém permanecem em espera ocupada aguardando até que uma outra mensagem de confirmação de envio ou recebimento seja transmitida. As primitivas bloqueantes por interrupção são semelhantes às bloqueantes por espera, entretanto, ao invés da espera ocupada, o programa é interrompido pelo simulador fazendo com que os ciclos de execução não sejam computados para esse programa. O submódulo Gerenciador de Memória simula o uso de memória compartilhada e distribuída. Quanto à hierarquia de memória, o simulador conta com cache de instruções, cache de dados e opção para cache unificada. O gerenciador de memória conta também com protocolo para coerência de cache e política de escrita na cache. A memória distribuída está implementada, e a memória compartilhada está sendo implementada. O simulador
  34. 34. 34 possibilitará testar os mesmos algoritmos com arquiteturas paralelas de memória compartilhada e distribuída, melhorando ainda mais o nível de simulação. O submódulo Protocolo é encarregado do gerenciamento da comunicação da rede de interconexão entre os processadores. O protocolo de comunicação é dependente da topologia da rede de interconexão escolhida. Esse submódulo emprega desde políticas simples de arbitragem de barramento até protocolos mais complexos de roteamento para redes de interconexão. O submódulo Topologia é responsável pela simulação da topologia da rede de interconexão. Esse submódulo permite a simulação de diversas configurações de redes de interconexão, como: barramento, redes multiestágio, crossbar, entre outras. A topologia tipo barramento comum já está implementada neste submódulo. Para a implementação da ferramenta foram replicadas as estruturas do simulador sim-outorder do SimpleScalar de maneira que a ferramenta comporta-se como um conjunto de vários simuladores sim-outorder sendo executados em paralelo. Para permitir a troca de mensagens entre os processadores simulados, desenvolveu-se a biblioteca de primitivas de comunicação que permite troca de mensagens entre os processadores. Essa biblioteca conta com primitivas não bloqueantes, bloqueantes por espera e bloqueantes por interrupção. Desta forma, a ferramenta atualmente permite a execução de qualquer algoritmo desenvolvido em C, tanto de forma seqüencial, quanto paralela. Para a simulação de programas paralelos é necessário o uso das primitivas de comunicação da própria ferramenta. As simulações atualmente permitem comparação, estudo e análise de sistemas reais baseados em arquitetura de memória distribuída que utilizam bibliotecas de passagem de mensagem. A ferramenta é uma ótima alternativa para testes de Arquiteturas de Alto Desempenho.
  35. 35. 35 3.5 Biblioteca de Passagem de Mensagem do SMS O simulador SMS tem uma biblioteca de passagem de mensagem baseada na biblioteca MPI, o que facilita o desenvolvimento de programas paralelos a serem executados no simulador, pois essa metodologia é semelhante à utilizada em arquiteturas reais de computação paralela (SANDRI, 2004). Durante a programação de um algoritmo a ser simulado no SMS, o programador irá desenvolver dois arquivos fontes, um arquivo fonte principal ou mestre, que irá fornecer atributos e funcionalidades básicas para o programa e iniciará e terminará todo o processo executado pela arquitetura paralela simulada. Esse programa é executado por um processador também denominado de mestre. O outro é um arquivo fonte secundário ou escravo que será executado pelos demais processadores (processadores escravos) que compõem a arquitetura paralela. O arquivo escravo faz normalmente o serviço bruto de processamento e computação de dados e é controlado pelo programa mestre. Para se utilizar a biblioteca do SMS faz-se necessário incluir no corpo do programa a chamada à biblioteca com.h., tanto no código fonte do arquivo mestre quanto do escravo (figura 4). Depois de declaradas todas as estruturas, variáveis, funções e todos os atributos que podem compor um código em C, faz-se necessário na função principal (do programa mestre e do escravo) incluir a função de sincronização (openchanel). Sem o uso de tal função os programas não se comportam adequadamente (não ficam sincronizados), assim o uso da função openchanel é obrigatório. De forma geral, essas são as únicas exigências para se desenvolver um programa paralelo a ser simulado pelo SMS. Entretanto, se um programa não usa passagem de mensagem não é necessário utilizar a biblioteca com.h nem a função openchanel para a simulação no SMS.
  36. 36. 36 # arquivo mestre.c # arquivo escravo.c #include <stdlib.h> #include <stdlib.h> #include <stdio.h> #include <stdio.h> #include </usr/sms/com.h> #include </usr/sms/com.h> ... ... void main (void) void main (void) { { int a, b, c; int a, b, c; double soma; double soma; openchanel(); openchanel(); puts("Mestre: inician"); puts("Mestre: inician"); ... ... } } Código fonte do programa mestre Código fonte do programa escravo Figura 4 - Inicializando a biblioteca de comunicação do SMS Após fazer a devida chamada à biblioteca de passagem de mensagem do SMS, e sincronizar os programas, é possível utilizar as funções de passagem e recebimento de mensagem dentro do simulador SMS. As principais funções da biblioteca SMS (todas as funções da biblioteca SMS podem ser vistas na tabela 2) são: send, sendbc, recv e recv_be. A função send, é responsável por enviar dados de um único computador de origem para um único computador de destino. Tomando como exemplo a linha: send(((char *)&texto), sizeof(texto),1). Tal linha envia o conteúdo da estrutura de dados texto ((char *) &texto), e especifica o tamanho da mesma estrutura ( sizeof (texto)). O tamanho da estrutura serve para alocar memória no processador que receber a estrutura. Por fim, envia a estrutura ao processador 1. A utilização de estruturas de dados para a passagem de valores no SMS facilita a compreensão da programação paralela. Dentro da estrutura é possível passar qualquer variável até mesmo um conjunto delas. A figura 5 mostra um exemplo de como poderia ser enviada a
  37. 37. 37 estrutura texto. A estrutura deve estar presente tanto no arquivo mestre como no arquivo escravo. Após enviar os dados usando a função send será necessário recebê-los no processador de destino. Isso é possível através da função recv, desta forma a sintaxe usada na função para receber a estrutura texto é recv(((char *)&texto), sizeof(texto)). Porém, com a função recv não haverá como sincronizar o algoritmo, de forma que, pode ser mais conveniente o uso da função recv_be, que também irá receber o dado, porém o programa que usa esta função ficará esperando (ocioso) até receber tal estrutura. Por fim, alguns dados podem ter de ser enviados para todos os processadores de forma que a função de envio broadcast (sendbc – envia para todos os processadores da arquitetura) é mais recomendada. Tal função envia com apenas uma mensagem e de uma única vez toda a estrutura de dados para todos os processadores, o que é bem mais eficaz do que enviar uma mensagem de cada vez para todos os processadores. A sintaxe para sendbc é muito parecida com a do send, omitindo-se apenas o processador de destino. Uma observação pertinente é que a mensagem em broadcast é enviada para todos os processadores inclusive para o processador que faz o uso da função, desta forma é necessário um recv_be neste processador também. Existem mais funções (tabela 2), porém apenas com as funções send, sendbc e recv_be é possível desenvolver a maioria dos algoritmos paralelos. Desta forma, através do uso das bibliotecas de comunicação apresentadas pelo simulador SMS, o usuário poderá de forma fácil e prática (já que não é necessário possuir um computador com várias unidades de processamento) entender como funciona um programa paralelo, e tão logo se acostume com os aspectos da programação paralela poderá facilmente passar do simulador SMS para um ambiente real.
  38. 38. 38 # arquivo mestre.c # arquivo escravo.c #include <stdlib.h> #include <stdlib.h> #include <stdio.h> #include <stdio.h> #include </usr/sms/com.h> #include </usr/sms/com.h> //declaração da estrutura texto //declaração da estrutura texto struct __texto struct __texto { { char mensagem; char mensagem; int processador_número; int processador_número; } __texto; } __texto; Struct _texto texto; Struct _texto texto; void main (void) void main (void) { { int i; int i; //abre canal //abre canal openchanel(); openchanel(); // atribui texto a estrutura //processador 1 recebe texto.mensagem=”ola mundo”; recv_be((char *)&texto) texto.processador_número=0; sizeof(texto)); //envia ao processador 1 //mostra o que foi recebido send((char *)&texto) printf(“o processador: %d sizeof(texto), 1); envia um %s”texto.processador_número, //atribui novo texto texto.mensagem); texto.mensagem=”ola Todos”; texto.processador_número=0; //recebe novo texto recv_be((char *)&texto) //envia para todos sizeof(texto)); sendbc((char *)&texto) sizeof(texto)); //mostra o que foi recebido printf(“o processador: %d //também recebe novo texto envia um recv_be((char *)&texto) %s”texto.processador_número, sizeof(texto)); texto.mensagem); } //mostra o que foi recebido printf(“o processador: %d envia um %s”texto.processador_número, texto.mensagem); } Fluxo das mensagens Código fonte do programa mestre Código fonte do programa escravo Figura 5 - Usando funções da biblioteca SMS
  39. 39. 39 4 PROGRAMAÇÃO PARALELA E ALGORITMOS PARALELOS Normalmente arquiteturas MIMD com memória compartilhada ou distribuída são criadas para computar programas das mais diversas áreas da ciência. Tais programas necessitam ser muito bem elaborados para explorar ao máximo os recursos de uma máquina paralela. Um algoritmo paralelo pode ser definido como um conjunto de processos (partes de um programa) que podem ser executados simultaneamente, tais processos podem se comunicar uns com os outros a fim de resolver um determinado problema. Já um algoritmo seqüencial é executado passo a passo de forma seqüencial como foi definido durante a sua programação (ZARGHAN, 1995). Um fato de extrema importância na maioria dos sistemas paralelos, principalmente os que exploram o paralelismo explícito (não em nível de instrução), é que o sistema paralelo em si é a combinação de um algoritmo paralelo e uma arquitetura paralela na qual o algoritmo é implementado (GUPTA, 1993), ou seja, para que um sistema paralelo atinja o seu objetivo principal, que é a melhora de desempenho na resolução de determinados problemas, é necessário, além de uma arquitetura física composta por vários processadores um algoritmo que explore todo este potencial da arquitetura. Pois não adianta ter os recursos necessários para melhorar o desempenho se estes não forem devidamente utilizados. Entretanto, a tarefa de construir algoritmos paralelos ótimos, que empreguem da melhor maneira possível todos os subsídios oferecidos pela arquitetura paralela, não é nada fácil, e talvez seja uma das tarefas mais difíceis no desenvolvimento de um sistema paralelo. Uma prática constantemente utilizada por programadores é a reutilização de algoritmos, pois se um algoritmo realiza uma função de forma eficiente, ele pode ser utilizado em outro programa que irá necessitar das funcionalidades desta função. Esta técnica de
  40. 40. 40 reutilização também é normalmente empregada na computação paralela, entretanto, muitos pesquisadores consideram que a melhor forma de se obter o paralelismo ideal é reconstruindo o algoritmo inteiro, modelando-o para a arquitetura na qual ele será executado. Sobre este problema Patterson (PATTERSON, 2000) comentou: “O maior obstáculo ao sucesso dos sistemas multiprocessadores não é o custo dos processadores usados em sua arquitetura, nem os problemas na topologia para conexão de redes, muito menos a indisponibilidade de linguagens de programação adequadas a tais sistemas; mas a grande dificuldade é o fato de que poucos programas de aplicação importantes têm sido reescritos para executar suas tarefas em sistemas multiprocessadores”. (PATTERSON, 2000, p. 416). Assim reutilização de algoritmos não é recomendável nem para arquiteturas paralelas semelhantes. Por exemplo, não se pode afirmar que um algoritmo projetado para ser executado em um computador contendo 8 processadores vai ser executado mais rapidamente em um sistema semelhante com 64 processadores, a menos que esse programa seja remodelado para esta arquitetura. Isso ocorre porque quanto maior a quantidade de processadores, maior será o esforço computacional para sincronizar os processos, e maior ainda será a utilização da rede de interconexão que interliga os processadores (CHOI, 1993; MATHESON, 1996). Por mais absurdo que possa parecer é bem provável que um programa especificamente projetado para ser executado em um computador com 8 processadores faça melhor uso desta arquitetura, do que de uma arquitetura com 64 processadores. Portanto, é fácil concluir que o programador, neste caso, tem que ser um especialista em hardware e software para tentar fazer um bom uso dos recursos de cada máquina paralela (KUMAR, 1991). Dessa discussão, conclui-se que diferentes tipos de aplicações são mais adequadas para uma determinada configuração ou outra dependendo de como foi paralelizado o código do programa.
  41. 41. 41 No que se refere à programação para computação paralela é possível encontrar modelos computacionais em que o programador não precisa se preocupar em como o sistema fará uso do paralelismo, ficando isso a cargo do compilador da arquitetura. Porém, é muito difícil obter-se o uso ideal dos recursos de um computador paralelo de forma automática, já que há diversas máquinas com as mais variadas configurações de hardware, o que dificulta o processo do compilador em explorar as características de cada arquitetura paralela, sendo então necessário um compilador para cada computador paralelo, o que é inviável. Por isso, os métodos mais utilizados na programação paralela são aqueles nos quais o programador deve instruir o programa em como explorar a arquitetura (os vários processadores, a memória e a rede de interconexão), ou seja, o programador precisa conhecer a arquitetura e não apenas programar e deixar que o compilador utilize os recursos disponíveis. Neste cenário destacam-se os métodos de variáveis compartilhadas e de passagem explícita de mensagem. Na técnica de variáveis compartilhadas todos os processos têm acesso a uma memória comum (endereçamento global), podendo se comunicar lendo e escrevendo (load e store) nesta memória. Esta técnica é comumente utilizada em sistemas multiprocessadores de memória compartilhada, e apesar de um pouco mais complexa pode ser empregada também em sistemas multicomputadores com memória distribuída. O outro método é o de trocas de mensagens, que tem se popularizado devido ao seu grande uso em Clusters. Neste esquema são empregadas primitivas de envio e recebimento (send e receiver), que são usadas para trocas de mensagens entre processos (TANENBAUM, 2001). 4.1. Aplicações Paralelas Os sistemas computacionais, em geral, são projetados com o propósito de
  42. 42. 42 agilizar a execução de uma determinada tarefa. Entretanto, algumas aplicações, principalmente científicas, requerem grande poder computacional (WOODWARD, 1996; CHANG, 1999; EWING, 1999). Algumas dessas aplicações podem consumir muito tempo de processamento, e em casos extremos podem se tornar impraticáveis devido ao longo tempo de computação. A fim de atender essa demanda foram desenvolvidas técnicas para reduzir o tempo de execução de tais aplicações. Uma técnica que vem tendo muito destaque é a exploração do paralelismo apresentado por essas aplicações. Pois a maioria das aplicações possui algum nível de paralelismo, que pode ser explorado de maneira que o programa possa ter seu tempo de execução reduzido. Então, aplicações paralelas fazem uso de múltiplos processadores para resolver um determinado problema, e isso é possível através da execução simultânea de diversos passos que compõem a solução do problema. Isso permite que uma aplicação paralela faça uso de vários processadores, o que não ocorre em programas seqüenciais, que essencialmente executam conjuntos básicos de passos de forma seqüencial, sem nenhum nível de paralelismo (GRAMA, 2003). Mesmo com o possível benefício de redução do tempo de execução da aplicação, o uso do paralelismo requer alguns cuidados que não são necessários em aplicações seqüenciais. Por exemplo, a aplicação paralela, apesar de possuir uma semântica parecida com a aplicação seqüencial, deve tratar de aspectos inerentes às suas características paralelas tais como: definir quais processos podem ser executados de forma paralela e gerenciar de forma eficiente a sincronização e comunicação entre tais processos. Segundo Grama a construção de um algoritmo paralelo segue basicamente os seguintes passos (GRAMA, 2003): • Identificar pontos do programa que podem ser executadas de forma paralela;
  43. 43. 43 • Distribuir as entradas e saídas de dados pertinentes à aplicação, bem como os dados intermediários gerados durante a execução das tarefas e que estão associados ao programa; • Gerenciar da melhor forma possível o acesso aos dados compartilhados pelos processadores, para execução de um dado problema, reduzindo a comunicação entre processos; • Sincronizar eficientemente os processadores nos mais diversos estágios de execução de um programa paralelo, de forma que os processadores não fiquem com uma carga de trabalho muito elevada ou muito baixa. Para que um programa obtenha um bom desempenho em uma arquitetura paralela é necessário decompô-lo em um conjunto de tarefas (processos), que são unidades de programas bem definidas que fazem parte da aplicação principal. A execução simultânea de múltiplas tarefas para resolver um dado problema pode reduzir o tempo de execução da aplicação. As tarefas podem ser executadas todas juntas ou em qualquer seqüência. Tarefas também podem apresentar dependência, e desta forma necessitam esperar que outras tarefas sejam executadas para terminar sua própria execução. A decomposição de problemas em tarefas envolve o particionamento da aplicação. O particionamento é definido como um conjunto específico de tarefas que irá resolver um dado problema em um computador paralelo da maneira mais eficiente possível. Existem dois métodos para se particionar tarefas (CHOI, 1993; ZARGHAN, 1995): • Particionamento Estático: Neste método as tarefas são particionadas durante a programação e não em tempo de execução, desta forma cada processador recebe sua carga de trabalho antes de iniciar a computação. A vantagem é que normalmente neste método existe pouca comunicação e disputa entre os processos, pois estes já foram previamente particionados. Então, no particionamento estático existe uma
  44. 44. 44 “simplicidade” relativa no gerenciamento das tarefas. Entretanto, é uma tarefa extremamente complexa para o programador dividir as tarefas entre os processadores de forma eficiente (principalmente em ambientes paralelos heterogêneos), e se a divisão de tarefas não for feita de forma correta alguns processadores podem ficar ociosos enquanto outros ficam sobrecarregados durante a execução. • Particionamento Dinâmico: Neste método o particionamento é realizado durante a execução do programa. A vantagem é que ele supervisiona os processadores de forma que todos fiquem ocupados. A desvantagem é que esse método normalmente tem grande demanda de comunicação. Uma vez que o programa foi dividido em processos, cada processo pode ser executado em um processador diferente. A esse mapeamento entre processos e processadores dá se o nome de escalonamento, o qual tem por objetivo a melhor utilização dos recursos computacionais fornecidos pela arquitetura paralela (GRAMA, 2003). O escalonamento é comumente observado em Sistemas Operacionais, porém neste caso é conhecido como escalonamento local, e refere-se ao problema de atribuição de time-slices de um processador aos processos (TANENBAUM, 2001). O escalonamento em computação paralela faz referência a um escalonamento aplicável a Sistemas Distribuídos ou Paralelos. O escalonamento (KUMAR, 1991) da mesma forma que o particionamento, também pode ser estático ou dinâmico. No estático, os processos e a ordem em que eles serão executados são conhecidos antes da execução do programa. Para se realizar um bom escalonamento estático é necessário conhecer o tempo de execução de cada tarefa e o tempo que cada unidade de processamento e seus recursos consomem para executar tal tarefa. É obvio que isso não é nada fácil. Outra dificuldade no escalonamento estático, é que se uma unidade de processamento parar de funcionar, o programa será abortado, já que não há como fazer o re-escalonamento das tarefas, pois este é estático. No escalonamento dinâmico os
  45. 45. 45 processos são atribuídos aos seus processadores durante a execução. Neste ambiente não se faz necessário conhecer totalmente o ambiente no qual o programa paralelo será executado, já que normalmente o programa irá se adaptar e se moldar à arquitetura paralela, o que oferece uma melhor utilização dos processadores disponíveis, incrementando desta forma a flexibilidade quanto ao aproveitamento do número de processadores que compõem a arquitetura. Para se realizar um bom escalonamento dinâmico é preciso analisar os pontos críticos da arquitetura (por exemplo, gargalos como a rede de interconexão) e buscar a melhor maneira para dividir as tarefas entre os processadores, isso possibilitará a distribuição das tarefas de forma eficiente e melhorará o desempenho do algoritmo. A esse processo se dá o nome de balanceamento de carga (CALZAROSSA, 2003). O número e o tamanho das tarefas decompostas em uma dada aplicação determinam a granularidade do problema. Desta forma, granularidade refere-se ao tamanho de uma tarefa em um processador e o desempenho de um algoritmo paralelo depende diretamente da granularidade do programa (LU, 1998). Se um programa for dividido em um pequeno número de grandes tarefas (granularidade grossa) a tendência é que esse algoritmo seja mais adequado para arquiteturas com um número pequeno de processadores e desta forma se torne uma aplicação com um nível de paralelização muito baixo. Já se um programa for dividido em um grande número de pequenas tarefas (granularidade fina), o programa terá um nível de paralelização maior, entretanto, é bem provável que neste caso o programa faça maior uso da rede interconexão, podendo desta forma perder desempenho devido ao alto grau de comunicação requerido entre as tarefas. O programador de aplicações paralelas deve balancear a granularidade da aplicação tentando manter um alto coeficiente de paralelização e da mesma forma tentando reduzir a necessidade de comunicação entre as tarefas, procurando assim obter uma granularidade média.
  46. 46. 46 Uma alternativa para reduzir a demanda de comunicação entre as tarefas é definir grupos de tarefas, relacionando as tarefas que mais se comunicam e deixando-as juntas onde a comunicação tenha um custo menor (CHOI, 1993; MATHESON, 1996; CREMONESI, 1999). Outro aspecto que deve ser observado é a relação entre o número de processadores e o tamanho do problema, essa relação influencia na redução da comunicação entre as tarefas (GUSTAFSON, 1988; GUPTA, 1993; GRAMA, 1993; HOGANSON, 1999;). Esta relação será discutida mais detalhadamente no tópico sobre avaliação de desempenho, no capítulo 5. Portanto, ajustar o número de processadores ao tamanho do programa ou vice- versa leva a um tempo de execução melhor, e o programador deve estar atento a esse fator e aos outros discutidos anteriormente (GRAMA, 2003; ZARGHAN 1995). Quanto ao ambiente de programação e desenvolvimento de aplicações paralelas é possível encontrar basicamente três tipos de ferramentas de programação (GRAMA, 2003): • Compiladores: Fazem a paralelização de forma automática. Neste tipo de ferramenta o programa normalmente é construído de forma seqüencial, ficando a cargo do próprio compilador explorar o paralelismo da aplicação. Neste modelo, normalmente consegue-se um ganho de desempenho menor se comparado à exploração explícita do paralelismo, mas a construção do aplicativo através de compiladores exige o mínimo esforço do programador, já que este irá programar normalmente (de forma seqüencial), sem se preocupar em descobrir qual trecho de código deve ser paralelizado e como isso será realizado. • Extensões de Paralelização: São normalmente bibliotecas que possuem primitivas de comunicações (como por exemplo: MPI e PVM), que facilitam o gerenciamento dos processos existentes em aplicações paralelas. Essas bibliotecas podem ser utilizadas a
  47. 47. 47 partir de linguagens de programação normalmente seqüenciais (C++, Fortran, Pascal, etc). • Linguagens de Programação Paralelas: Especialmente projetadas para serem usadas em ambientes paralelos, tais linguagens possibilitam a construção de aplicações bem estruturadas e possuem rotinas de gerenciamento de processos paralelos muito eficientes, dinamizando desta forma a comunicação, sincronização e gerenciamento da aplicação paralela. Todas as ferramentas apresentadas possuem seus prós e contras. O compilador paralelo facilita a programação e agiliza o desenvolvimento da aplicação, mas normalmente não consegue fazer o uso ideal dos recursos fornecidos por cada arquitetura paralela. Por sua vez, as linguagens de programação paralelas conseguem um bom desempenho em arquiteturas paralelas (GRAMA, 2003), entretanto, exigem que o programador aprenda uma nova linguagem de programação, o que pode levar um tempo considerável e consumir também um tempo precioso no desenvolvimento da aplicação paralela. Desta forma, as ferramentas que atualmente merecem maior destaque são as extensões paralelas, que podem ser usadas pelo programador em uma linguagem de programação já conhecida por ele, ficando a cargo do programador apenas aprender como usar de forma eficiente as rotinas que possibilitam a programação paralela. Além disso, as extensões permitem uma melhor adaptação de códigos seqüenciais para códigos paralelos, e conseguem explorar de forma eficiente grande parte dos recursos de uma arquitetura paralela. Além de escolher alguma ferramenta de programação, é necessário ter-se em mente como o algoritmo será paralelizado, principalmente se o desenvolvedor do aplicativo escolher uma ferramenta na qual necessite paralelizar a aplicação de forma direta como ferramentas de extensão e linguagens paralelas. Modelos de algoritmos paralelos são formas de estruturar algoritmos paralelos
  48. 48. 48 através de técnicas de decomposição, mapeamento e estratégias de minimização das interações entre as tarefas. O enfoque principal deste trabalho aborda paralelismo no contexto de memória distribuída. Neste tipo de arquitetura pode-se aplicar as seguintes abordagens para se extrair o paralelismo: • Data Parallelism - Explora os dados a serem processados pelo programa paralelo. Cada tarefa executa operações semelhantes sobre dados diferentes (GRAMA, 2003). Este modelo emprega balanceamento de carga de trabalho estático, o que normalmente garante um bom balanceamento de carga (GRAMA, 2003; ZHANG, 1994). O paralelismo de dados apresenta ótimos resultados, pois geralmente não requer muita comunicação o que diminui o overhead e o tempo gasto com a comunicação (ZHANG, 1994), e quanto maior a entrada de dados melhor é seu desempenho (GUSTAFSON, 1988; ZARGHAN, 1995). Um exemplo desta prática é um algoritmo de multiplicação de matrizes no qual as colunas e as linhas das matrizes a serem multiplicadas são distribuídas entre os diversos processadores que compõem a arquitetura paralela, e cada processador executa o mesmo código para multiplicar essas linhas e colunas, completando desta forma a aplicação. • Task Graph - Neste modelo o inter-relacionamento entre as tarefas do problema é utilizado para agrupar os dados relacionados. Procurando-se deixar os dados que se inter-relacionam sempre onde possam ser acessados de forma mais rápida (por exemplo, na memória local), facilitando a comunicação ou pelo menos reduzindo o custo da comunicação entre os processos (CREMONESI, 1999). O modelo Task Graph é utilizado para resolver problemas nos quais vários dados estão associados e as tarefas necessitam interagir entre elas, fazendo uso desses dados (GRAMA, 2003). Este tipo de modelo é mais facilmente implementado em arquiteturas de memória
  49. 49. 49 compartilhada, mas pode ser implementado em arquiteturas de memória distribuída. Desta forma, um programa paralelo pode ser representado por um grafo de tarefas (task graph), no qual os nós representam módulos e as arestas indicam a necessidade de comunicação entre esses nós (CHOI, 1993). Um exemplo de aplicação que utiliza este modelo é o método de ordenação quicksort. • Work Pool - Também conhecido como Task Pool, é caracterizado por um mapeamento dinâmico entre tarefas e processadores visando desta forma um bom balanceamento de carga entre os processadores. Tal mapeamento pode ser centralizado ou descentralizado. As tarefas podem ser armazenadas em listas de prioridade, tabelas hash, ou em árvores. Em arquiteturas de passagem de mensagem esse modelo é normalmente usado quando a quantia de dados associados à tarefa é relativamente pequena se comparada com a computação associada com as tarefas (GRAMA, 2003). O mesmo exemplo da multiplicação de matriz pode ser utilizado aqui, mas neste caso os processadores irão buscar as tarefas a serem executadas (as linhas e colunas) em uma lista. • Processor Farm – Neste modelo existe um processador principal (também chamado de “mestre”) que é responsável por gerenciar um grupo de processadores (chamados de “escravos”), no qual cada escravo processa assincronamente tarefas submetidas pelo mestre. O mestre gerencia o trabalho dos escravos e faz o balanceamento de carga. Este modelo é muito utilizado tanto por arquiteturas de memória compartilhada quanto por memória distribuída, entretanto é necessário ter-se cuidado para que o processador mestre não se torne um gargalo neste modelo (GRAMA, 2003). Utilizando a mesma aplicação de multiplicação de matrizes, neste método um processador ficará responsável por distribuir as colunas e linhas a serem multiplicadas.
  50. 50. 50 • Pipeline ou Produtor-Consumidor – Este modelo segue o modelo de pipeline empregado pelos processadores, ou seja, um fluxo de dados é passado através de uma sucessão estágios (HENNESSY, 2003). Cada estágio executa uma tarefa diferente sobre este fluxo de dados (ZARGHAN, 1995). Essa execução simultânea de diferentes tarefas sobre um fluxo de dados também é chamado de stream parallelism. Cada processo no pipeline pode ser visto como o consumidor de uma seqüência de dados do processo que o precede e um produtor de dados para o processo seguinte do pipeline, daí o nome Produtor-Consumidor (GRAMA, 2003). Utilizando mais uma vez o exemplo da multiplicação de matrizes, neste método cada estágio seria responsável por uma operação, sendo, o primeiro estágio responsável pela entrada de dados, o segundo pela multiplicação, o seguinte pela adição e o último pela saída, terminando desta forma todos os estágios do pipeline necessários para essa aplicação. Em muitos casos mais de um modelo de programação paralela pode ser aplicado para a resolução de um problema. Um modelo híbrido pode ser construído aplicando-se vários modelos de forma hierárquica ou aplicando-se múltiplos modelos de forma seqüencial para diferentes fases do algoritmo. Ainda no que se refere a modelos de programação é possível encontrar mais dois modelos (ZARGHAN, 1995): estruturas síncronas e assíncronas. Tais modelos podem ser considerados como modelos base para os modelos discutidos anteriormente. Na estrutura síncrona dois ou mais processos estão ligados por um ponto comum de execução usado com propósitos de sincronização entre processos. Um processo irá atingir um ponto no qual terá de esperar por um ou mais processos. Após os processos terem alcançado o ponto de sincronização, eles podem continuar a execução do programa até o próximo ponto de sincronização. Nesta estrutura, os demais processos sempre esperaram pelo processo mais lento e esta é a principal desvantagem deste método. Esta estrutura de
  51. 51. 51 algoritmo paralelo também é conhecida como Partitioning Algorithms. É possível aplicar estruturas de sincronização em diversos problemas. Este método envolve, por exemplo, uma série de iterações em grandes estruturas de matrizes. Cada iteração usa o resultado parcial produzido pela iteração precedente e o transforma em busca de uma solução final. A computação em cada iteração pode ser paralelizada de forma que cada processo trabalhe em diferentes partes dos dados da matriz. De qualquer forma, depois de cada iteração os processos devem ser sincronizados devido ao resultado parcial produzido, que será usado pelo processo seguinte em outra iteração. Esse ciclo continuará até serem cumpridos todos os passos e assim atingir uma solução final. A estrutura assíncrona permite que os processos pertencentes ao algoritmo trabalhem com o dado mais recente fornecido pela execução de outros processos. Quando um processo termina um estágio, ele atualiza as informações necessárias e inicia o próximo estágio. Quando este modelo é utilizado em um ambiente de passagem de mensagem, um processo lê algumas mensagens de entrada de dados e depois completa um estágio. Baseado nas mensagens e nos resultados obtidos pelo estagio anterior, o processo ativa seu próximo estágio e envia mensagens para outros estágios. Desta forma, algoritmos assíncronos continuam ou terminam seus processos conforme os valores de passagem de mensagem e não esperam por um conjunto de entrada de dados como no caso do modelo síncrono. Em comparação com algoritmos síncronos, os assíncronos requerem menos acessos à memória compartilhada, o que reduz a disputa por memória. Em geral, algoritmos assíncronos são mais eficientes devido à seguinte característica: os processos não esperam pela execução de outros processos. Isso normalmente diminui o tempo de execução; os resultados dos processos que são executados mais rapidamente podem ser usados para eliminar processos mais lentos; proporcionando menos competição por memória. Entretanto,
  52. 52. 52 algoritmos assíncronos são difíceis de programar. Sua análise é mais complexa que a de um algoritmo síncrono. Todas as técnicas de programação para ambientes paralelos não são exclusivas e podem ser combinadas para produzirem resultados melhores em uma aplicação paralela. Além disso, freqüentemente aplicações paralelas possuem várias etapas de computação, em que pode ser necessário aplicar diferentes tipos de decomposição. 4.2 Passagem de Mensagens Não basta dispor de diversos processadores para se obter computadores mais rápidos. É necessário que haja um gerenciamento correto desses processadores para que o programa obtenha um desempenho ideal e é justamente com o propósito de fornecer um gerenciamento dos multiprocessadores ou multicomputadores que surge a técnica de passagem de mensagem. Conforme discutido na seção 4.1, não existe um modelo padrão de programação paralela, porém existe uma prática chamada de extensão de paralelização que tem sido muito utilizada. Neste contexto existem duas bibliotecas de passagem de mensagem, que têm sido amplamente utilizadas e que efetuam a intercomunicação entre os processadores, podendo ser tomadas como referência em programação paralela. As bibliotecas PVM (Parallel Virtual Machine) e MPI (Message Passing Interface), são utilizadas a partir de linguagens de programação como C ou FORTRAN e, possibilitam o compartilhamento de informações entre os processadores que compõem a máquina paralela (PACHECO, 1997). Antes dessas bibliotecas cada fabricante tinha que desenvolver sua própria forma de trocar informações entre máquinas MIMD, o que dificultava ainda mais o cenário da programação em computação paralela. Portanto, essas bibliotecas vieram para auxiliar o programador.
  53. 53. 53 A passagem de mensagem é o método de comunicação baseado no envio e recebimento de mensagens, cuja funcionalidade é a gerência dos processos, entretanto quem determina como isso será feito é o programador, as bibliotecas fornecem apenas o meio de gerenciar tais tarefas não fazendo isso automaticamente, como faz um compilador (ZARGHAN, 1995).
  54. 54. 54 5 AVALIAÇÃO DE DESEMPENHO Quando um sistema paralelo utiliza dois processadores, logo se cria a expectativa de que qualquer programa executado neste sistema será processado duas vezes mais rápido do que numa máquina monoprocessada. Porém, isso não é verdade. Para que a execução paralela atinja o máximo possível de desempenho, o código do programa originalmente desenvolvido de forma seqüencial deve, de alguma maneira, ser 100% paralelizado. Supondo que seja possível obter esse patamar de programação, bem como possuir um sistema perfeito de sincronização entre os processadores, no qual a comunicação também seja efetuada em um tempo desprezível, então seria possível obter um sistema totalmente paralelo que certamente alcançaria um ganho de desempenho equivalente ao número de processadores que compõem a arquitetura. Entretanto é extremamente raro encontrar problemas a serem computados que não empreguem trechos estritamente seqüenciais. Amdahl, em 1967, questionou a eficiência de sistemas paralelos, afirmando que mesmo pequenas partes de um programa precisam ser paralelizadas para que todo o potencial da arquitetura possa ser explorado (SUN, 1990). Então, pode-se deduzir por essa afirmação, que o objetivo do ganho linear de desempenho envolve a descoberta de novos algoritmos que sejam inerentemente paralelos. A lei de Amdahl sugere que é muito difícil alcançar o desempenho de pico esperada para uma arquitetura paralela (PATTERSON, 2000). Mas, ainda que não se consiga paralelizar totalmente um algoritmo e alcançar sempre o desempenho ideal em sistemas paralelos, é possível obter ganhos significativos de desempenho paralelizando os núcleos de programas (partes em que se concentram os maiores esforços computacionais). Neste contexto, este capítulo discute alguns aspectos relacionados à avaliação de desempenho.

×