O documento discute conceitos fundamentais de programação paralela, incluindo: (1) algoritmos paralelos exploram recursos de máquinas paralelas; (2) decomposição de problemas em tarefas paralelas; (3) mapeamento de tarefas a processadores.

1. Programação Paralela Lu iz Art h u r
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 e tais processos podem se comunicar uns com os
outros, a fim de resolver um determinado problema.
Já um algoritmo seqüencial que é executado passo a passo de forma
serial ou seqüencial como foi definido durante a sua programação
1

2. Programação Paralela Lu iz Art h u r
Um fato de extrema importância na maioria dos sistemas paralelos,
principalmente os que exploram o paralelismo explicito (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.
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 de um algoritmo que explore todo este potencial
da arquitetura.
Pois nada 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 seja talvez uma das
tarefas mais difíceis na construção de um sistema paralelo.
2

3. Programação Paralela Lu iz Art h u r
Uma prática constantemente utilizada por programadores é a
reutilização de algoritmos, pois se um algoritmo realiza uma função
de forma eficiente, porque não utilizá-lo em outro programa que irá
necessitar das funcionalidades deste algoritmo.
Esta técnica de 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 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).
3

4. Programação Paralela Lu iz Art h u r
Assim, a 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 rápido
em um sistema semelhante com 64 processadores, a menos que o
programa seja remodelado para esta arquitetura.
Isso ocorre (dentre outros fatores) 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.
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.
4

5. Programação Paralela Lu iz Art h u r
Aplicações Paralelas
Os sistemas computacionais, em geral, são projetados com o propósito
de agilizar a execução de uma determinada tarefa. Entretanto
algumas aplicações, principalmente científicas, requerem grande
poder computacional. 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.
Uma técnica que vem tendo muito destaque para melhorar o
desempenho de tais aplicações é a exploração do paralelismo
apresentado por essas aplicações. Pois, a maioria das aplicações
possuem algum nível de paralelismo, que pode ser explorado de
maneira que o programa possa ter seu tempo de execução reduzido.
5

6. Programação Paralela Lu iz Art h u r
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 o problema
e podem ser executados de forma simultânea.
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 a serem
executados de forma seqüencial, sem nenhum nível de paralelismo.
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üências.
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.
6

7. Programação Paralela Lu iz Art h u r
A construção de um algoritmo paralelo segue basicamente os
seguintes passos:
Identificar pontos do programa que podem ser executadas de forma

paralela;
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. Diminuindo a comunicação entre processos;
Sincronizar eficientemente os processadores nos mais diversos

estágios de execução que um programa paralelo possa vir a possuir,
de forma que os processadores não fiquem com uma carga de trabalho
muito elevada ou muito baixa.
7

8. Programação Paralela Lu iz Art h u r
Para a construção de aplicações paralelas podem ser utilizados
basicamente três tipos de ferramentas de programação:
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 tipo de ferramenta normalmente consegue-se um ganho de
desempenho pequeno se comparado à exploração explicita do
paralelismo, mas a construção do aplicativo 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.
8

9. Programação Paralela Lu iz Art h u r
➢Extensões de paralelização: São normalmente bibliotecas que
possuem primitivas de comunicações, que facilitam o gerenciamento
dos processos existentes em aplicações paralelas. Essas bibliotecas
podem ser utilizadas a 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.
9

10. Programação Paralela Lu iz Art h u r
É obvio que todas as ferramentas apresentadas possuem algumas
vantagens e desvantagens.
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
ótimo desempenho em arquiteturas paralelas, entretanto esse tipo de
prática exige que o programador aprenda uma nova linguagem de
programação, o que pode levar um tempo considerável e consumir um
tempo precioso na construção da aplicação paralela.
Desta forma a ferramenta que atualmente merece maior atenção
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 dele apenas aprender como usar de forma eficiente as rotinas
que possibilitam a programação paralela. Além de que esse tipo de
ferramenta permite uma melhor adaptação de códigos seqüenciais
para códigos paralelos, e finalmente consegue explorar de forma
eficiente todos os recursos de uma arquitetura paralela.
10

11. Programação Paralela Lu iz Art h u r
No que se refere a programação paralela alguns aspectos devem ser
tratados:
Tarefas
Para que um programa obtenha um bom desempenho em uma
arquitetura paralela, ou melhor, em várias arquiteturas é necessário
decompô-lo em um conjunto de tarefas (também conhecido
como 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.
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 tarefa.
11

12. Programação Paralela Lu iz Art h u r
Decomposição/Particionamento
A decomposição de problemas em tarefas envolve o particionamento
da aplicação. O Particionamento é definido como um conjunto
especifico 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:
• 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.
• Particionamento Dinâmico: Neste método o particionamento
é feito durante a execução do programa.
12

13. Programação Paralela Lu iz Art h u r
Escalonamento
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 o aumento da
utilização de recursos computacionais fornecidos pela arquitetura
paralela.
O escalonamento é comumente observado em Sistemas
Operacionais, porém este é conhecido como escalonamento local, e
refere-se ao problema de atribuição das fatias de tempo (time-slices)
de um processador aos processos.
O escalonamento citado aqui faz referência a um escalonamento
global aplicável geralmente em Sistemas Distribuídos ou Paralelos.
O escalonamento da mesma forma que o particionamento, também
pode ser estático ou dinâmico
13

14. Programação Paralela Lu iz Art h u r
Escalonamento
Sendo que 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 bem como o tempo que cada
unidade de processamento e seus recursos levaram para executar
tal tarefa o que não é nada fácil, outra dificuldade neste modelo, é
que se uma unidade de processamento parar de funcionar, o
programa irá ser abortado, já que não há como fazer o re-
escalonamento das tarefas, pois esse é estático.
No dinâmico os 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 irá ser
executado, já que normalmente o programa vai se adaptar e moldar
a 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.
Se o problema se adapta a qualquer número de processadores (1-n)
então o algoritmo é chamado de escalável. 14

15. Programação Paralela Lu iz Art h u r
Granularidade
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 a performance de um algoritmo paralelo depende da
granularidade do programa.
Se um programa for dividido em um pequeno número de grandes
tarefas (chamada de 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. 15

16. Programação Paralela Lu iz Art h u r
Tamanho do Problema
Outro aspecto que deve ser observado é a relação entre o número de
processadores e o tamanho do problema. O programador deve estar
atento a esse fator.
Na verdade o tamanho do problema já foi um dos maiores
empecilhos enfrentados por sistemas computacionais, já que em
1967 Amdahl’s definiu que em um dado problema de tamanho fixo, o
paralelismo não teria grandes ganhos de desempenho, pois logo
atingiria o pico de ganho de desempenho e não continuaria a
aumentar o desempenho conforme fosse crescendo o número de
processadores.
A esta afirmação se deu o nome de lei de Amdahl’s, tal lei causou
certo marasmo dentre as pesquisas de sistemas paralelos, até que
em 1988 Gustafson, observou que Amdahl’s assume que o número
de processador é independente do tamanho do problema, o que
normalmente nunca é o caso. Na prática o tamanho do problema e
escalar ao número de processadores. Quando é dado mais poder
computacional, o problema geralmente se expande para fazer uso
das facilidades da arquitetura tal descoberta permitiu que os
estudos sobre sistemas paralelos tomassem novos rumos. 16

17. Programação Paralela Lu iz Art h u r
Modelos de algoritmos paralelos
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 através de técnicas de decomposição,
mapeamento e estratégias de minimização das interações entre as
tarefas.
17

18. Programação Paralela Lu iz Art h u r
Data Parallelism
Explora os dados a serem processados pelo programa paralelo.
Cada tarefa executa operações semelhantes sobre dados
diferentes. Este modelo emprega balanceamento de carga de
trabalho estático o que normalmente garante um bom
balanceamento de carga.
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, portanto este modelo
apresenta ganhos de desempenho exponenciais (quanto mais
processadores melhor), e quanto maior a entrada de dados melhor é
seu desempenho.
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.
18

19. Programação Paralela Lu iz Art h u r
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.
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.
Este tipo de modelo é mais facilmente implementado em
arquiteturas de memória compartilhada, mas pode ser
implementado em arquiteturas de memória distribuída também.
Desta forma um programa paralelo pode ser representado por um
grafo de tarefas (task graph) nos quais os nós representam módulos
e arestas indicam a necessidade de comunicação entre esses nós.
Um exemplo de aplicação que utiliza este modelo é o método de
ordenação quicksort.
19

20. Programação Paralela Lu iz Art h u r
20

21. Programação Paralela Lu iz Art h u r
Work Pool
Também conhecido como Task Pool, é caracterizado por um
mapeamento dinâmico entre tarefas e processadores visando desta
forma um alto grau de 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. As tarefas podem ser estáticas ou dinâmicas,
desta forma um processo pode gerar uma tarefa e colocá-la numa
lista global (work pool) para ser executada.
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.
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.
21

22. Programação Paralela Lu iz Art h u r
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.
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.
22

23. Programação Paralela Lu iz Art h u r
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.
Cada estágio executa uma tarefa diferente sobre este fluxo de
dados. 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.
Utilizando mais uma vez o exemplo da multiplicação de matriz, 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 soma e o último pela saída,
terminando desta forma todos os estágios do pipeline necessários
por essa aplicação.
23

24. Programação Paralela Lu iz Art h u r
Em alguns 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 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 existem mais dois
modelos que podem ser considerados como modelos básicos para os
discutidos anteriormente: Síncrona e Asincrona.
- Na estrutura síncrona (Partitioning Algorithms) dois ou mais
processos estão ligados por um ponto comum de execução usado
com propósitos de sincronização. Um processo irá atingir um ponto
no qual terá de esperar por outros (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.
- A estrutura assíncrona permite que os processos pertencentes ao
algoritmo trabalhem com o dado mais recente fornecido pela
execução de outros processos (um ou mais). Quando um processo
termina um estágio este atualiza as informações necessárias e inicia
o próximo estágio.
24

25. Programação Paralela Lu iz Art h u r
Em comparação com algoritmos síncronos, os assíncronos requerem
menos acesso à memória compartilhada, o que reduz a disputa por
memória.
Em geral, algoritmos assíncronos são mais eficientes devido aos
processos nunca esperam outro processo.
Isso normalmente diminui o tempo de execução o resultado dos
processos que são executados mais rapidamente pode ser usado
para eliminar processos mais lentos; menos competição por
memória.
Entretanto algoritmos assíncronos são difíceis de programar. Sua
análise é mais complexa que a de um algoritmo síncrono.
Sendo ainda às vezes até mesmo impossível de resolver um dado
problema de maneira assíncrona.
25

26. Programação Paralela Lu iz Art h u r
AVALIAÇÃO DE DESEMPENHO
Quando um sistema paralelo utiliza dois processadores, logo se cria
a expectativa de que qualquer programa executado nesta máquina
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 de desempenho, o código do programa originalmente
desenvolvido de forma seqüencial deve, de alguma maneira, ser
100% paralelizado.
A lei de Amdahl sugere que é muito difícil alcançar uma
performance de pico esperada para as arquiteturas paralelas mas,
ainda que não se consiga paralelizar totalmente um algoritmo e
alcançar sempre a performance ideal em sistemas paralelos, é
possível atingir ganhos de desempenhos consideráveis paralelizando
os núcleos de programas (parte principal do programa na qual se
concentra a maior parte do esforço computacional) de forma que o
programa paralelo obtenha ganhos de desempenho consideráveis.
26

27. Programação Paralela Lu iz Art h u r
AVALIAÇÃO DE DESEMPENHO
Uma questão muito importante a ser abordada por qualquer
pesquisador de sistemas paralelos, é o de como verificar e explorar
o ganho de performance em um sistema paralelo, já que a
performance em sistemas paralelos é o resultado de interações
complexas entre recursos de hardware e software.
Envolvendo características de aplicações, tal como, estrutura do
algoritmo, parâmetros de entrada, tamanho do problema e físicas,
como, número de processador, taxas de transferência da rede de
interconexão, etc.
Todos esses aspectos determinam como a aplicação explora os
recursos disponíveis em arquiteturas paralelas e consequentemente
como influenciam na performance.
27

28. Programação Paralela Lu iz Art h u r
AVALIAÇÃO DE DESEMPENHO
Uma boa maneira de se conseguir uma ótima interação entre
hardware e software e atingir um bom desempenho usando sistemas
paralelos é analisando o comportamento de cada atributo da
arquitetura frente a um conjunto de algoritmos (tais algoritmos são
denominados Benchmarks) que teste tal arquitetura da maneira
mais completa possível.
Desta forma faz-se necessárias ferramentas para analisar de forma
concisa como um algoritmo faz uso da arquitetura paralela.
Softwares de analise e métricas de performance são divididos em
estáticos e dinâmicos.
Medidas estáticas incluem: número de nós, grau de sincronização,
tamanho do caminho a ser percorrido, caminho máximo que um nó
de entrada tem de fazer a um nó de saída, tamanho do problema,
etc.
Métricas dinâmicas são: tempo de computação total entre os
processadores, tempo de comunicação, tempo de execução, volume
de comunicação, volume de entrada/saída, entre outros.
28

29. Programação Paralela Lu iz Art h u r
Medidas em computação paralela faz referência à execução de uma
aplicação paralela com P processadores, onde K diferentes
atividades e N regiões de códigos podem estar sendo monitoradas.
Esses parâmetros podem ser medidos analisando diferentes
parâmetros, por exemplo, medir atividades de computação,
comunicação, aceso a memória, I/O (Input/Output – entrada/saída)
ou regiões do código como loops, rotinas, etc.
Vários parâmetros podem ser medidos em arquiteturas paralelas:
➔Parâmetros de tempo;
➔Parâmetros quantitativos como:
• Número de operações de entrada e saída (I/O);
• Número de bytes lidos e escritos (read/written);
• Número de acessos à memória;
• Número de perdas de cache (cache misses);
• Número de bytes enviados e recebidos (sent/received);
Então as propriedades de métricas de sistemas paralelos devem ser
extensamente estudadas, pois elas influenciam diretamente no
desempenho de uma aplicação
29

30. Programação Paralela Lu iz Art h u r
O tamanho do problema já foi um dos maiores empecilhos
enfrentados por sistemas computacionais, já que em 1967 Amdahl’s
definiu que em um dado problema de tamanho fixo, o paralelismo
não teria grandes ganhos de desempenho, pois logo atingiria o pico
de ganho de desempenho e não continuaria a aumentar o
desempenho conforme fosse crescendo o número de processadores.
A esta afirmação se deu o nome de lei de Amdahl’s, tal lei causou
certo marasmo dentre as pesquisas de sistemas paralelos, até que
em 1988 Gustafson, observou que Amdahl’s assume que o número
de processador é independente do tamanho do problema, o que
normalmente nunca é o caso.
Na prática o tamanho do problema e escalar ao número de
processadores. Quando é dado mais poder computacional, o
problema geralmente se expande para fazer uso das facilidades da
arquitetura, tal descoberta permitiu que os estudos sobre sistemas
paralelos tomassem novos rumos.
30

31. Programação Paralela Lu iz Art h u r
Elapsed Time
Existem diversas medidas para a caracterização de performance de
um sistema paralelo, mas as que mais se destacam são: tempo de
execução, speedup e eficiência.
Historicamente o tempo de execução ou o tempo decorrido (elapsed
time) é uma das métricas mais populares para verificar a
performance em um dado sistema.
O tempo de execução serial é o tempo decorrido do inicio da
execução do programa até o seu termino em um computador
seqüencial.
Já o tempo de execução paralelo é o tempo decorrente do momento
em que o programa inicialmente é executado na arquitetura paralela
até o momento que o ultimo processador empregado para a
resolução do problema termina a execução.
31

32. Programação Paralela Lu iz Art h u r
Speedup
Em conjunto com o tempo decorrido existe uma métrica denominada
speedup (aceleração ou ganho de desempenho) que é extremamente
utilizada em bibliografias sobre arquitetura paralela.
O speedup é o produto do tempo decorrido de uma arquitetura pela
outra, um bom motivo para se utilizar o speedup é que ele combina
todos os efeitos típicos da computação paralela e apresenta
resultados gráficos
Existem duas modalidades bem definidas para se medir o speedup,
que são:
• Speedup absoluto;
• Speedup Relativo.
32

33. Programação Paralela Lu iz Art h u r
Speedup
O speedup absoluto é definido como o tempo decorrido na
execução seqüencial do melhor algoritmo dividido pelo tempo de
execução decorrente no algoritmo paralelo.
Já speedup relativo é definido como o tempo decorrente de um
algoritmo paralelo em um processador e o tempo decorrente do
mesmo algoritmo paralelo em N processadores.
A razão para se usar speedup relativo é que a performance de
algoritmos paralelos varia de acordo com o número de
processadores disponíveis em uma arquitetura e comparando o
mesmo algoritmo com vários números de processadores é possível
verificar de forma mais sincera a degradação do uso do paralelismo,
do que se usando o speedup absoluto que faz a comparação com um
algoritmo serial, o que pode não ser tão imparcial.
33

34. Speedup Programação Paralela Lu iz Art h u r
Existem vários parâmetros que podem ser expressos através do
speedup, os mais significantes são o speedup de tamanho de
problema fixo (fixed-size speedup) que foi descrito por Amdahl’s, e o
speedup de tempo fixo (fixed-time speedup), descrito por
Gustafson’s que é o mais usado atualmente.
W1 W1 W1 W1 TW1
Tam an h o d o Tem p o d e
Pr ob lem a Execu ção
TW1
TW1
TW1
WN WN WN WN
TWN WTN WTN WTN
1 2 3 4 1 2 3 4
Nú m er o p r oces s ad or es Nú m ero p r oces s ad or es
Am d ah l’s - fixed - siz e speed u p
W1
W1
Tam an h o d o Tem p o d e
Pr ob lem a Execu ção
W1
W1 TW1 TW1 WT1 WT1
WN WN WN WN
WTN TWN WTN WTN
1 2 3 4 1 2 3 4
34
Nú m er o p r oces s ad or es Nú m ero p r oces s ad or es
Gu s tafs on - fixed - tim e speed u p

35. Programação Paralela Lu iz Art h u r
Speedup
Na pratica pode-se definir a aceleração (speedup) ou ganho que
sofre cada arquitetura, medindo-se o tempo de execução na
arquitetura seqüencial dividido pelo tempo consumido pela execução
na arquitetura paralela, para executar o mesmo problema, isso para
o speedup absoluto. No caso do speedup relativo é só colocar no
lugar do tempo de execução do programa seqüencial o tempo do
algoritmo paralelo executado com apenas um processador.
Tem poExecu Seqü en cial
ção
=
A celeração
Tem poExecu Paralelo
ção
SPEEDUP Absoluto
Tem poExecu
çãoParalel1
o
=
A celeração
Tem poExecu
çãoParalel N
o
SPEEDUP Relativo
35

36. Eficiência Programação Paralela Lu iz Art h u r
Outra medida que pode ser empregada no estudo de arquiteturas
paralelas e é derivada do speedup é a eficiência. Eficiência é uma
medida da fração de tempo para o qual um processador é realmente
usado. Em sistemas paralelos ideais o speedup é igual ao número de
processadores e a eficiência é igual a um. Na pratica o speedup é
menor que o número de processadores e a eficiência fica entre zero
e um.
A analise de eficiência permite determinar a melhor combinação de
algoritmo e arquitetura para um problema.
A eficiência relata o tamanho do problema e o número de
processadores requeridos para manter o sistema eficiente, e isso ira
ajudar a determinar a escalabilidade do sistema, sua velocidade e
largura de banda da rede de comunicação.
Existe um referencia direta entre o número de processadores,
tamanho do problema e a eficiência, de forma que se for aumentado
o número de processadores a eficiência será reduzida, e
aumentando o tamanho do problema é aumentada à eficiência, desta
forma se for aumentado ambos a eficiência será constante.
36

37. Programação Paralela Lu iz Art h u r
Eficiência
Uma pergunta natural então é: qual é o limite para se aumentar o
número de processadores proporcionalmente ao tamanho do
problema?
Isso depende da arquitetura, mas se o tamanho do problema é
constante enquanto o número de processadores aumenta a
eficiência apresenta quedas, por causa do acréscimo de overhead
(controle de comunicação entre os processadores) causado pelo
número de processadores.
Já se o tamanho do problema aumenta enquanto o número de
processadores é constante então a eficiência aumenta (no caso
sistemas paralelos escalares) devido ao baixo overhead que torna-se
insignificante perto da computação do problema.
Desta forma pode-se manter a eficiência desde que se aumente de
forma proporcional o tamanho do problema. É claro que é muito
difícil encontrar a relação exata entre o tamanho do problema ideal
para cada arquitetura, já que o problema pode estar associado a
inúmeros aspectos de hardware e software.
37

38. Programação Paralela Lu iz Art h u r
Eficiência
A eficiência é considerada um método analítico que investiga a
escalabilidade dos algoritmos.
Tal métrica é obtida pela formula E = S/p, sendo S o speedup e p o
número de processadores.
Portanto o número processadores deve se escolhido de forma a
maximizar a eficiência e o speedup da arquitetura.
Cada algoritmo paralelo tem um inerente aumento de concorrência
entre os processadores que determina o número máximo de
processadores que podem ser simultaneamente usado durante a
resolução de um dado tamanho do problema.
38