Your SlideShare is downloading. ×
0
Tópicos - Computacao Paralela Programação 3 (Visão geral)
Tópicos - Computacao Paralela Programação 3 (Visão geral)
Tópicos - Computacao Paralela Programação 3 (Visão geral)
Tópicos - Computacao Paralela Programação 3 (Visão geral)
Tópicos - Computacao Paralela Programação 3 (Visão geral)
Tópicos - Computacao Paralela Programação 3 (Visão geral)
Tópicos - Computacao Paralela Programação 3 (Visão geral)
Tópicos - Computacao Paralela Programação 3 (Visão geral)
Tópicos - Computacao Paralela Programação 3 (Visão geral)
Tópicos - Computacao Paralela Programação 3 (Visão geral)
Tópicos - Computacao Paralela Programação 3 (Visão geral)
Tópicos - Computacao Paralela Programação 3 (Visão geral)
Tópicos - Computacao Paralela Programação 3 (Visão geral)
Tópicos - Computacao Paralela Programação 3 (Visão geral)
Tópicos - Computacao Paralela Programação 3 (Visão geral)
Tópicos - Computacao Paralela Programação 3 (Visão geral)
Tópicos - Computacao Paralela Programação 3 (Visão geral)
Tópicos - Computacao Paralela Programação 3 (Visão geral)
Tópicos - Computacao Paralela Programação 3 (Visão geral)
Tópicos - Computacao Paralela Programação 3 (Visão geral)
Tópicos - Computacao Paralela Programação 3 (Visão geral)
Tópicos - Computacao Paralela Programação 3 (Visão geral)
Tópicos - Computacao Paralela Programação 3 (Visão geral)
Tópicos - Computacao Paralela Programação 3 (Visão geral)
Tópicos - Computacao Paralela Programação 3 (Visão geral)
Tópicos - Computacao Paralela Programação 3 (Visão geral)
Tópicos - Computacao Paralela Programação 3 (Visão geral)
Tópicos - Computacao Paralela Programação 3 (Visão geral)
Tópicos - Computacao Paralela Programação 3 (Visão geral)
Tópicos - Computacao Paralela Programação 3 (Visão geral)
Tópicos - Computacao Paralela Programação 3 (Visão geral)
Tópicos - Computacao Paralela Programação 3 (Visão geral)
Tópicos - Computacao Paralela Programação 3 (Visão geral)
Tópicos - Computacao Paralela Programação 3 (Visão geral)
Tópicos - Computacao Paralela Programação 3 (Visão geral)
Tópicos - Computacao Paralela Programação 3 (Visão geral)
Tópicos - Computacao Paralela Programação 3 (Visão geral)
Tópicos - Computacao Paralela Programação 3 (Visão geral)
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Tópicos - Computacao Paralela Programação 3 (Visão geral)

1,985

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,985
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
51
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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

×