Este documento apresenta três algoritmos paralelos desenvolvidos para serem executados no Simulador de Multiprocessadores Superescalares (SMS). O objetivo é fornecer meios para simular e avaliar arquiteturas paralelas utilizando esta ferramenta de simulação. Os algoritmos desenvolvidos incluem a multiplicação de matrizes, cálculo do valor de π e a regra do trapézio, os quais exploram diferentes aspectos de uma arquitetura paralela e possibilitam a avaliação de desempenho

1. LUIZ ARTHUR FEITOSA DOS SANTOS
Desenvolvimento de Algoritmos Paralelos para Simulador de
Multiprocessadores Superescalares
MARINGÁ
2005

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. 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. DEDICATÓRIA
Dedico este trabalho
Aos meus pais, a minha namorada, aos meus amigos e principalmente a Deus.

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. “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. 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. 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. 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. 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. 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. 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. 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. 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
• 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
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
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
(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
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
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
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
# 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
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
# 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
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
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
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
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
• 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
“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
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
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
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
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
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
• 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
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
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
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
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.