Balanceamento de carga de processos em Ambientes Multicore

(1)

UNIJUÍ - Universidade Regional do Noroeste do Estado do Rio Grande do Sul

Micael Thales Hentges

Balanceamento de Carga de Processos em Ambientes Multicore

Ijuí, 2015 Micael Thales Hentges

(2)

2

Trabalho de conclusão de curso apresentado à banca avaliadora do curso de Ciência da Computação da Universidade Regional do Noroeste do Estado do Rio Grande do Sul - UNIJUI, como requisito parcial para a obtenção do título de Bacharel em Ciência da Computação.

Orientador: Edson Luiz Padoin

Ijuí, 2015

(3)

3

Trabalho de conclusão de curso apresentado à banca avaliadora do curso de Ciência da Computação da Universidade Regional do Noroeste do Estado do Rio Grande do Sul - UNIJUI, como requisito parcial para a obtenção do título de Bacharel em Ciência da Computação.

_________________________________ Orientador: Edson Luiz Padoin

BANCA EXAMINADORA

_________________________________ Prof. Marcos Ronaldo Melo Cavalheiro

Ijuí, 2015

(4)

4

“Que os vossos esforços desafiem as impossibilidades, lembrai-vos de que as grandes coisas do homem foram conquistadas do que parecia impossível”. Charles Chaplin.

(5)

5

Dedicatória Dedico este trabalho aos meus pais, irmão, amigos e parentes que tem me apoiado durante todo o tempo.

(6)

6

AGRADECIMENTOS

Primeiramente gostaria de agradecer ao professor Edson Luiz Padoin por ter me auxiliado e orientado nesta pesquisa. Agradeço também a todos os outros professores de que fui aluno nestes anos de curso. A todos os meus colegas.

(7)

7

RESUMO

Este trabalho analisa o ganho de desempenho com a utilização de Balanceadores de Carga em ambientes multicore. Com a finalidade de verificar o ganho computacional na sua utilização Para isso é necessário o estudo dos princípios de processamento paralelo, o que é um processo, thread e seus funcionamentos, como é feito o mapeamento, balanceamento de carga, migração dos processos e os ambientes de programação. Esta pesquisa busca resultados que demonstrem a eficiência dos balanceadores de carga em processos desbalanceados em ambiente multicore.

(8)

8

ABSTRACT

This paper analyzes the performance gain with the use of load balancers in multicore environments. In order to verify the computational gain in using This requires the study of the principles of parallel processing, which is a process, thread and its workings, as is done mapping, load balancing, migration processes and environments programming. This research seeks results that demonstrate the effectiveness of load balancers in unbalanced processes in multicore environment.

(9)

9

LISTA DE SIGLAS

API – Application Programming Interface BC – Balanceador de Carga

CPU – Central Processing Unit

CUDA – Compute Unified Device Architecture GPU – Graphics Processing Unit

MPI – Message Passing Interface

PAD – Processamento de Alto Desempenho SMPs - Symmetric Multiprocessors

SO – Sistema Operacional

(10)

10

LISTA DE FIGURAS

Figura 1 – (a) Três processos, cada um com uma thread. (b) Um processo com

três threads. ... 18

Figura 2 – Exemplos de distribuição de tarefas entre as quatro threads... 21

Figura 3 - Representação gráfica de um ambiente Charm++ ... 24

Figura 4 – Demonstração Funcionamento Stencil3d ... 32

Figura 5 – Execução Benchmark Stencil3d utilizando duas threads com carga 1. 34 Figura 6 – Execução Benchmark Stencil3d utilizando quatro threads. ... 35

Figura 7 – Comparação de tempos Benchmark Stencil3d carga 1. ... 36

Figura 8 – Execução Benchmark Stencil3d utilizando duas threads Carga 2. ... 37

Figura 9 – Execução Benchmark Stencil3d utilizando quatro threads Carga 2. ... 37

Figura 10 – Comparação de tempos Benchmark Stencil3d carga 2. ... 38

Figura 11 – Execução Benchmark Stencil3d utilizando duas threads Carga 3... 39

Figura 12 – Execução Benchmark Stencil3d utilizando quatro threads Carga 3... 39

Figura 13 – Comparação de tempos Benchmark Stencil3d Carga 3. ... 40

Figura 14 – Execução benchmark lb_test utilizando duas threads ... 41

Figura 15 – Execução benchmark lb_test utilizando quatro threads ... 41

(11)

11

LISTA DE TABELAS

Tabela 1 - Carga Benchmark Stencil3d ... 32 Tabela 2 - Carga Benchmark lb_test ... 33

(12)

12

SUMÁRIO

INTRODUÇÃO ... 14 2. ESTADO DA ARTE ... 17 2.1 Processos ... 17 2.1.1 Threads ... 18 2.2 Mapeamentos de Processos ... 18 2.2.1 Mapeamento Multicore ... 19 2.2.2 Mapeamento Cluster ... 20 2.3 Balanceamentos de Carga ... 20 2.4 Migração de Processos ... 21 2.5 Ambientes de Programação ... 23 2.5.1 Charm++ ... 23

2.5.1.1 Mapeamento de Processos em Charm++ ... 24

2.5.1.2 Migração de Processos em Charm++ ... 24

2.5.1.3 Balanceamento de Carga em Charm++ ... 25

2.5.2 Anahy ... 28 2.5.3 Cuda ... 28 2.5.4 Opencl ... 29 2.5.5 Sofa ... 29 2.5.6 XKAAPI ... 30 3 PROPOSTA E METODOLOGIA ... 31 3.1 Proposta ... 31 3.2 Ambiente de Teste ... 31 3.3 Benchmarks ... 31 3.3.1 Stencil3d ... 32 3.3.2 Benchmark lb_test ... 33

3.4 Balanceadores de Carga Utilizados ... 33

4 RESULTADOS ... 34

4.1 Testes Benchmark Stencil3d ... 34

4.1.1 Testes Carga 1... 34

4.1.2 Testes Carga 2 ... 36

(13)

13

4.2 Teste Benchmark lb_test ... 40

CONCLUSÃO ... 43

REFERÊNCIAS ... 45

(14)

14

INTRODUÇÃO

No início da computação o processador operava com apenas um núcleo programável, contendo códigos sequenciais onde o programa era executado da primeira à última linha de código, seguindo rigorosamente a ordem em que foi escrito. Mas com a evolução dos processadores, onde os atuais possuem mais de um núcleo programável, podendo executar vários processos ou programas paralelamente. Isso acabou gerando o problema de que um ou mais núcleos do processador acabassem ficando ociosos, por causa dos programas terem sidos criados à ser executados de forma sequencial. Para resolver isso foram desenvolvidos ambientes de programação como MPI, OpenMp, Charm++ entre outros. Uma das formas mais conhecidas de paralelização é o uso de Threads, e utilizadas pela maioria das linguagens, mas uma thread não é um processo e segundo (TANENBAUM e WOODHULL, 2008). Embora uma thread deva ser

executada em algum processo, a thread e seu processo são conceitos diferentes e podem ser tratadas separadamente. Os processos são usados para agrupar recursos já as threads são entidades programadas para execução na CPU. A vantagem de se usar threads é que no modelo de processo permite que várias execuções ocorram no mesmo ambiente de processos de forma bastante independente umas das outras.

Com isso a utilização de linguagens de paralelização, tornou-se possível fazer os processos trabalharem competindo pelos recursos computacionais evitando a ociosidade de núcleos do processador. Onde o sistema operacional gerencia os processos, de forma que cada um receba os recursos (dispositivos periféricos, espaços na memória principal, acesso a arquivos e acesso a CPU) de que precisa, que processos independentes não interfiram uns nos outros e caso precisam trocar informações sejam capazes de fazê-los. Como a multiprogramação visa ter vários processos executando o tempo todo, evitando que núcleos do processador fiquem ociosos e para melhor utilização da CPU, o SO trata de alternar os processos com tanta frequência que os usuários possam interagir com cada programa enquanto ele está sendo executado.

Para isso o sistema operacional necessita do mapeamento de processos que é o ato de decidir em qual unidade de processamento um determinado processo irá

(15)

15

executar, enquanto o escalonamento de processos irá determina a sequência de execução das tarefas. Ocorre que algumas vezes um core do processador possa ficar sobrecarregado na execução de um processo, tornando necessário o seu balanceamento de carga que faz a distribuição de processamento e comunicação em um sistema paralelo de modo que nenhum processador fique mais carregado do que outros. Pode ser tratado como um subconjunto de escalonamento. O balanceamento de carga e o escalonamento fazem com que seja maximizado o desempenho das aplicações mantendo o tempo de ociosidade e a comunicação entre processos tão baixos quanto possível. Para a realização do balanceamento de carga muitas vezes é necessário à migração de processos que é a ação de transferir um processo que está em execução em um processador para outro. Essa migração consiste em extrair o estado do processo no nó origem, transferi-lo ao nó destino e atualizar as conexões com os nós comunicantes.

Atualmente há vários ambientes de programação que permitem a realização do balanceamento de carga como o Charm++, Cuda, XKAAPI entre outros. O Charm++ é uma plataforma e modelo de programação paralela baseado em C++ desenvolvido com o objetivo de melhorar a produtividade da programação através de uma abstração de alto nível da computação paralela enquanto provendo bom desempenho. CHARM++ inclui diferentes implementações de checkpoint (PILLA e MENESES, 2015). Gerando dados considerados seguros e os checkpoints podem ter tamanhos arbitrários. A migrabilidade em Charm++ envolve a habilidade de mover chares entre unidades de processamento da plataforma paralela. Essa migrabilidade possibilita tolerância a falhas em aplicações em Charm++. Uma aplicação que realiza checkpointing de seus chares pode se prevenir ou se recuperar de uma falha através da migração ou reinicialização dos chares afetados. O balanceamento de carga em Charm++ é baseado na medição do tempo de atividade dos chares e das unidades de processamento. O arcabouço de balanceamento de carga de CHARM++ (SINHA, 1993) é uma das partes mais importantes de seu sistema.

Assim neste trabalho propõe-se a utilizar o ambiente de programação Charm++ e seus balanceadores de carga para medir o desempenho na execução de benchmarks com diferentes estruturas de paralelismo. O objetivo de verificar se há ou não ganho computacional com sua utilização.

(16)

16

O restante do trabalho está organizado como segue. No Capítulo 2 são discorridos a programação paralela, o estado da arte o que são processos e threads demonstrando suas diferenças, Mapeamento, Balanceamento de Carga e Migração de Processos e destacar os Ambientes de Programação paralelos estudados, como o Charm++, XKAAPI, CUDA e entre outros, e exploraremos como a paralelização é utilizada nos processos e formas de como se obter um melhor desempenho utilizando-se do Charm++ para auxílio do Sistema Operacional. O Capitulo 3 consta a proposta para a realização deste trabalho e a metodologia dos testes realizados como o processador, os benchmarks e balanceadores de carga utilizados. No Capítulo 4 apresenta uma comparação do desempenho dos balancedores, por meio da execução de benchmarks paralelos desbalanceados. No Capítulo 5 são tecidas considerações sobre os resultados atingidos até o presente momento e o que será realizado como trabalhos futuros.

A metodologia utilizada foi à pesquisa bibliográfica, para se obter conhecimento para sua realização e para os testes executados.

(17)

17

2 ESTADO DA ARTE

A abordagem multicore segue o modelo de multiprocessadores, em que diversos processadores independentes acessam um espaço comum de endereçamento de memória. Um sistema multicore consiste na aglomeração de múltiplas unidades funcionais, os cores, em uma única pastilha de processamento. Cada core é uma unidade de processamento completa, com seu próprio contador de programa, registradores e lógica de controle. Nos sistemas que possuem somente um núcleo, as funções de multitarefa podem ultrapassar a capacidade da CPU, o que implica em queda no desempenho enquanto as operações aguardam para serem processadas. Já os processadores de múltiplos núcleos podem trabalhar em um ambiente multitarefa. Onde os sistemas de múltiplos núcleos, como cada núcleo tem seu próprio cache, o sistema operacional dispõe de recursos para lidar com o processamento intensivo de tarefas executadas em paralelo. Mas algumas vezes precisa de ajudas externas como balanceadores de carga, mapeamento de processos e migração de processos para assim, poder melhora a eficiência do sistema e o desempenho dos aplicativos em computadores que executam vários aplicativos em simultâneo.

2.1 Processos

Um processo é a atividade de executar um programa sob o controle do sistema operacional, pode se dizer que e um programa em execução, mas é muito mais que do que um código de um programa. Associado a um processo está o estado atual da atividade, chamado de estado do processo. Esse estado inclui a posição atual no programa sendo executado, assim como os valores nos outros registradores da CPU e das células de memória associadas.

Os computadores atuais com CPU’s multicores executam muitos processos, todos eles competindo pelos recursos computacionais. E é tarefa do sistema operacional gerenciar estes processos, de forma que cada um receba os recursos (dispositivos periféricos, espaços na memória principal, acesso a arquivos e acesso a CPU) de que precisa, que processos independentes não interfiram uns nos outros e que processos que precisam trocar informações sejam capazes de fazê-los.

Segundo (SILBERSCHATZ, GALVIN e GAGNE, 2008) “um Programa se torna um processo quando um arquivo executável é carregado na memória”.

(18)

18

2.1.1 Threads

Uma thread é uma unidade básica de utilização de CPU, ela compreende um ID de thread, um contador de programa, um conjunto de registradores e uma pilha.

Outro conceito que um processo tem é o de fluxo de execução, normalmente denominado apenas por thread. Uma thread tem um contador de programa que controla qual instrução vai ser executada. Ela possui registradores, os quais contêm suas variáveis de trabalho correntes. Possui uma pilha, que contém o histórico de execução, com o bloco para cada função chamada, mas das quais ainda não houve retorno. (TANENBAUM e WOODHULL , 2008)

Também conforme (TANENBAUM e WOODHULL, 2008) Embora uma thread deva ser executada em algum processo, a thread e seu processo são conceitos diferentes e podem ser tratadas separadamente. Os processos são usados para agrupar recursos já as threads são entidades programadas para execução na CPU.

A vantagem de se usar threads é que no modelo de processo permite que várias execuções ocorram no mesmo ambiente de processos de forma bastante independente uma das outras.

Figura 1 – (a) Três processos, cada um com uma thread. (b) Um processo com três threads.

Fonte: TANENBAUM e WOODHULL 2008.

2.2 Mapeamentos de Processos

O mapeamento de processos é o ato de decidir em qual unidade de processamento um determinado processo irá executar, enquanto o escalonamento de processos determina a sequência de execução das tarefas. O mapeamento de processos de aplicações paralelas é um problema NP-difícil, assim calcula-lo em tempo hábil, são utilizados algoritmos heurísticos que levam em consideração as características da

(19)

19

aplicação paralela e da organização do sistema para se aproximar do mapeamento mais adequado.

 Mapeamentos de Processos Estáticos é quando o mapeamento é feito somente uma vez no início da execução da aplicação e se mantém o mesmo até o final desta execução.

 Mapeamento de Processos Dinâmico quando o mapeamento dos processos pode variar ao longo da execução da aplicação paralela, conforme os padrões de comunicação entre os processos ou a disponibilidade de recursos se modifiquem. Neste caso surge a migração de processos em execução. A execução de uma aplicação paralela pode ser entendida como um histórico distribuído, onde o estado da aplicação a qualquer momento no tempo é uma fotografia composta pelo estado de nós individuais e pelas mensagens em trânsito. Tal fotografia do sistema é também chamada de checkpoint. Funções de checkpointing são usualmente acionadas em momentos de sincronização global. Desse modo, o checkpoint não precisa incluir o estado dos canais de comunicação, pois não há mensagens em trânsito, e a interferência na execução da aplicação é mantida pequena.

2.2.1 Mapeamento Multicore

Segundo (CRUZ et al, 2011) O mapeamento de processos e uma técnica que possibilita o aumento de desempenho em aplicações paralelas através de uma alocação mais eficiente dos recursos. Escalonando as threads que compartilham o mesmo espaço de memória em núcleos que compartilham uma mesma memória cache propicia um melhor desempenho de que quando nenhuma memória cache e compartilhada.

Uma maneira de diminuir o tempo de execução de uma aplicação paralela e mapear threads que compartilham memória em núcleos que compartilham cache (ALVES, 2009), reduzindo a latência de acesso a dados compartilhados. Além disso, e mais vantajoso manter tarefas comunicantes em núcleos em um mesmo socket do que em processadores distintos. Isso se deve não somente as latências, mas também porque isso reduz a sobrecarga imposta por protocolos de coerência (PADOIN et al, 2011).

Em Broquedis (2010) foi apresentado e avaliado o software Hardware Locality (hwloc) que colhe informações do hardware relacionadas aos núcleos, caches e

(20)

20

memorias e disponibiliza estas informações para aplicações de forma abstrata. Onde com a utilização de aplicações MPI e OpenMP foram feitas avaliações do hwloc. Com informações fornecidas pelo software foi realizado o mapeamento das aplicações de forma estática e dinâmica. Comparando o mapeamento estático dos processos em relação com as informações fornecidas pelo hwloc também utilizando o algoritmo de Biparticionamento Recursivo Dual conseguiu-se ganhos de até 26% no tempo de execução de aplicações.

2.2.2 Mapeamento Cluster

Um cluster é definido como sendo um conjunto de computadores que trabalham interligados por uma rede com objetivo comum. Neste contexto, cada computador do cluster é chamado de nó. E segundo (CHAI et al, 2007) em clusters onde os nós são computadores SMPs (Symmetric Multiprocessors) ou baseados em processadores multicore, o tempo de comunicação entre processos varia muito de acordo com o processador para onde eles foram mapeados.

O mapeamento de processos em cluster multicore foi explorado por Dummeler, Raulber, Runger (2008). Onde foi desenvolvida uma técnica de mapeamento com o modelo de programação de Multiprocessor-task combinado com diferentes equações para realizar o mapeamento, assim exigindo que a programações esteja no modelo Multiprocessor-task e não sendo empregadas em aplicações fora deste modelo.

Outro trabalho desenvolvido com mapeamento em cluster foi desenvolvido por Zhang, Yuan, Srinivasan (2010) onde se realiza o mapeamento de processos MPI em clusters Simétricos Multiprocessados (SPM) com nós de multicores (CMPs). Este mapeamento é feito através da minimização do número de comunicações inter-nó. Para isso é feito o cálculo de comunicação inter-nó em todos os mapeamentos possíveis. Tendo como conclusão de que a razão entre comunicação inter-nó e inter-chip deve ser considerada para o cálculo de mapeamento em cluster.

2.3 Balanceamentos de Carga

O balanceamento de Carga é a distribuição de processamento e comunicação em um sistema paralelo de modo que nenhum processador fique mais carregado do que outros. Pode ser tratado como um subconjunto de escalonamento. O balanceamento

(21)

21

de carga e o escalonamento fazem com que seja maximizado o desempenho das aplicações mantendo o tempo de ociosidade e a comunicação entre processos tão baixos quanto possível.

Segundo (NOGUEIRA, 1998), por balanceamento de carga, entenda-se, doravante, o conjunto de ações que procuram redistribuir a carga computacional entre maquinas com vistas a melhorar o desempenho de um sistema distribuído ou paralelo.

Na Figura 2 podemos ver a execução não balanceada onde a thread 0 fica sobrecarregada e a thread 3 com pouca carga atribuída. Já com a utilização de balanceadores de carga podemos notar que todos os núcleos possuem cargas parecidas.

Figura 2 – Exemplos de distribuição de tarefas entre as quatro threads.

Fonte: https://software.intel.com/pt-br/articles/load-balance-and-parallel-performance.

2.4 Migração de Processos

A migração de processos é a ação de transferir um processo que está em execução em um processador para outro. A migração consiste em extrair o estado do processo no nó origem, transferi-lo ao nó destino e atualizar as conexões com os nós comunicantes. O estado transferido inclui o espaço de endereços do processo, ponto de execução, estado da comunicação e informações relevantes ao Sistema Operacional. Quando a migração ocorre, duas instâncias do processo existem: uma no nó origem e outro no nó destino. Esta segunda instancia, será a que permanecerá com processo migrado.

(22)

22

Segundo (RAVASI, 2009) no contexto de sistemas computacionais distribuídos, a migração de processos é necessária quando o sistema se encontra em estado onde a distribuição das tarefas entre os nós é ineficiente ou indesejada, em geral prejudicado o desempenho do sistema. A migração de processos permite modificar a distribuição das tarefas entre os nós, a fim de atingir um certo objetivo. Pode-se listar comuns para a migração dos processos: balanceamento dinâmico de carga, aproximação dos processos aos recursos que acessam, tolerância a falhas e administração do sistema:

 Balanceamento dinâmico de carga: Pode ser implementado através de políticas de escalonamento preemptivas, sem a necessidade de se conhecer a aplicação. A política pode simplesmente observar o estado do sistema e o comportamento do processo, e tomar a decisão baseado nessas métricas.

 Aproximação dos processos aos recursos que acessam: Essa motivação implica na utilização de agentes móveis e migração proativa, onde o próprio processo sabe onde encontrar o recurso necessário e comanda sua própria migração para o computador onde pode acessa-lo mais facilmente. Também é possível a aplicação desse objeto através de migração reativa, envolvendo um escalonador ou gerenciador externo à aplicação. Nesse caso, ao processo é envolver um escalonador ou gerenciador externo à aplicação. Nesse caso, ao processo é atribuído um espaço de endereçamento que inclui dados não-locais ao computador onde é executado.

 Tolerância a falhas: Quando uma falha parcial é detectada e o sistema ainda está em condições de realizar a migração, os processos ativos podem ser migrados a outros computadores e, então, o computador defeituoso é retirado do conjunto de nós ativos do ambiente paralelo distribuído. Uma falha imediata do sistema também pode ser tolerada com a utilização da migração de processos, através da técnica de checkpointing. Que consiste basicamente de uma migração parcial do processo, realizada periodicamente durante sua execução. O estado do processo é gravado em um arquivo e enviado para um servidor de arquivos, sem interromper a execução do processo.

 Administração do sistema: A migração de processos permite uma administração de sistemas mais robusta, pois computadores podem ser

(23)

23

desligados ou reiniciados para manutenção sem perda dos processos em execução.

2.5 Ambientes de Programação

Os ambientes de programação demonstrado serão ambientes que possibilitam a utilização de balanceadores de carga, como o Charm++, Anahy, Cuda, Opencl, Sofa e XKAAPI . Contendo uma descrição detalhada do ambiente Charm++.

2.5.1 Charm++

O Charm++ é um ambiente para programação paralela orientada a objetos baseado na linguagem C++. Foi desenvolvido na University of Illinois - Parallel Programming Laboratory, a primeira versão foi lançada em 1993.

O que diferencia o Charm++ de outras soluções para programação paralela, as quais são baseadas em conceitos como a passagem de mensagens ou memória compartilhada é que em Charm++ a comunicação é orientada a chegada de mensagens. Essa comunicação, ao nível do programador, é vista como chamadas assíncronas a métodos de objetos remotos numa abordagem semelhante a utilizada por Java RMI, porém em Java RMI as chamadas são síncronas (Charm++ Manual 2015).

Um programa em Charm++ consiste de um número de objetos distribuídos espalhados através do número de processadores disponíveis. Assim, a unidade básica de computação paralela em Charm++ é o objeto distribuído, chamado de

chare, que pode ser criado em qualquer dos processadores disponíveis e pode ser

acessado de outro processador remotamente (PILLA e MENESES, 2015).

Seu modelo de execução é baseado nos preceitos de execução direcionada por mensagens assíncronas, sobredecomposição da aplicação e migrabilidade dos chares, que pode ser criado em qualquer processador disponível e pode ser acessado por processadores remotos, o sistema mantém um ”work-pool” composto pelos Chares e mensagens para Chares existentes. O runtime system (RTS) pode escolher vários itens, de forma não determinística, desse pool e executá-los. Os métodos de entrada são não-preemptivos.

(24)

24

Figura 3 - Representação gráfica de um ambiente Charm++.

Fonte: Laboratory 2011.

2.5.1.1 Mapeamento de Processos em Charm++

CHARM++ inclui diferentes implementações de checkpoint (Meneses 2014). A implementação baseada em discos em rede é empregada para a execução particionada da aplicação e para a análise post mortem. O sistema de execução descarrega o estado de todos os chares em arquivos na rede em um sistema de arquivos compartilhado. Esse mecanismo costuma saturar a largura de banda da rede de interconexão e aumentar o sobrecusto do checkpoint. Entretanto, os dados são considerados seguros e os checkpoints podem ter tamanhos arbitrários. CHARM++ possibilita o resumo da execução da aplicação com um número diferentes de recursos computacionais, o que também permite execuções com expansão e encolhimento destes.

A segunda implementação de checkpoints em CHARM++ é baseada em armazenamento local. Esse mecanismo é empregado para a recuperação de falhas durante o tempo de execução da aplicação. O sistema de execução descarrega o estado dos chares para um meio de armazenamento local nos nós sendo utilizados, podendo isso ser feito em memória principal ou secundária (PILLA e MENESES, 2015).

2.5.1.2 Migração de Processos em Charm++

Uma das características do modelo de execução de CHARM++ é a migrabilidade. A migrabilidade em CHARM++ envolve a habilidade de mover chares entre unidades de processamento da plataforma paralela. Para possibilitar que chares sejam

(25)

25

migrados, métodos de empacotamento e desempacotamento precisam ser implementados. A Essa migrabilidade possibilita tolerância a falhas em aplicações em CHARM++. Uma aplicação que realiza checkpointing de seus chares pode se prevenir ou se recuperar de uma falha através da migração ou reinicialização dos chares afetados em outros recursos computacionais da plataforma. Através de uma combinação de checkpointing com a manutenção de logs de mensagens, aplicações em CHARM++ podem inclusive se recuperar de uma falha sem precisar da interrupção e reinicialização da aplicação por completo (PILLA e MENESES, 2015). A combinação de migrabilidade com sobredecomposição permite a migração de chares para o balanceamento de carga da aplicação na plataforma. Dado que a carga computacional de chares pode ser desconhecida durante a inicialização da aplicação, ou pode ser dinâmica e mudar durante a execução da aplicação, o mapeamento inicial de chares para unidades de processamento pode não ser ideal. Nesse contexto, algoritmos de balanceamento de carga externos à aplicação podem ser usados para migrar chares de unidades de processamento sobrecarregadas para outras ociosas, melhorando o desempenho da aplicação. O mesmo pode ser feito para aprimorar a comunicação entre chares, assim como reduzir o consumo de potência ou temperatura das unidades de processamento (ACUN et al, 2014).

2.5.1.3 Balanceamento de Carga em Charm++

Charm++ oferece balanceamento de carga dinâmico. Ao criar um chare, a localização não precisa ser indicada: o kernel irá colocar o chare no processador menos carregado disponível. O arcabouço de balanceamento de carga de CHARM++ (Sinha and Kale 1993) é uma das partes mais importantes de seu sistema. Através de classes de balanceadores de carga, desenvolvidas independentemente de aplicações, é possível reorganizar chares em uma plataforma de forma a equalizar a carga de trabalho entre as unidades de processamento (PILLA e MENESES, 2015), reduzir o tempo de comunicação entre chares, reduzir o consumo de potência em unidades de processamento mais ociosas, entre outros. CHARM++ disponibiliza dezenas de algoritmos de balanceamento de carga para uso por desenvolvedores.

O balanceamento de carga em CHARM++ é baseado na medição do tempo de atividade dos chares e das unidades de processamento. Ele é baseado no princípio da persistência, o qual indica, através de observações, que a carga computacional e

(26)

26

os padrões de comunicação de aplicações científicas tendem a persistir ao longo do tempo; e que o passado recente da aplicação é um bom preditor de seu futuro próximo.

O balanceamento de carga pode ser realizado em arquitetura centralizada, totalmente distribuída, ou hierárquica. Em abordagens centralizadas, a carga e a comunicação estrutura inteira da máquina são acumuladas para um único ponto, normalmente o processador 0, seguido de um processo de tomada de decisão para determinar a nova distribuição dos chares objetos. Este balanceamento de carga centralizado requer sincronização, que pode incorrer em uma sobrecarga e atrasos. No entanto, devido ao fato de que o processo de decisão tem um elevado grau de conhecimento sobre toda a plataforma, ele tende a ser mais preciso (Charm++ Manual 2015).

Em abordagens distribuídas, os dados de carga só são trocados entre os processadores vizinhos. Não há nenhuma sincronização global. No entanto, eles não irão, em geral, proporcionar um restabelecimento imediato para o equilíbrio de carga, o processo é iterativo até que o equilíbrio de carga possa ser alcançado (Charm++ Manual 2015).

Em abordagens hierárquicas, os processadores são divididos em conjuntos autônomos independentes de grupos de processadores e estes grupos são organizados em hierarquias, descentralizando assim a tarefa de balanceamento de carga. Usa diferentes estratégias para ser usada para equilibrar a carga sobre os processadores dentro de cada grupo de processador, e os processadores em todos os grupos de uma forma hierárquica (Charm++ Manual 2015).

Abaixo estão alguns dos principais balanceadores de carga centralizados disponíveis e suas breves descrições:

 RandCentLB: aleatoriamente atribui objetos para os cores do processador (Charm++ Manual 2015).

 GreedyLB: O balancedor de carga GreedyLB reatribui os chares de forma gulosa. O algoritmo iterativamente mapeia o chare com maior tempo de execução para o núcleo com menor carga de trabalho. Sendo assim, o algoritmo não considera as comunicações entre chares. Apesar disso, esta estratégia possui um bom desempenho devido a sua simplicidade e velocidade (Charm++ Manual 2015).

(27)

27

 GreedyCommLB: O balanceador de carga GreedyCommLB utiliza o mesmo conceito do BC GreedyLB onde reatribui os chares de forma gulosa e iterativamente mapeiam o chare com maior tempo de execução para o núcleo com menor carga de trabalho. Considerando as comunicações entre chares (Charm++ Manual 2015).

 TopoCentLB: Estende um algoritmo guloso e utiliza a topologia do processador em conta (Charm++ Manual 2015).

 RefineLB: RefineLB é um balanceador de carga que visa melhorar o equilíbrio de carga (Charm++ Manual 2015), de forma incremental ajustando o objeto existente, trabalha movendo objetos que estão longe dos processadores mais sobrecarregados, normalmente, possui um limite fixado em 1,003 vezes a carga média em todos os processadores e qualquer processador é considerado sobrecarregado se esta carga estiver acima. Seu custo computacional é baixo porque se limita apenas a processadores sobrecarregados. Que são examinados resultando em apenas alguns objetos migrados.

 RefineCommLB: Estende o RefineLB, mas leva em conta a comunicação entre os chares (Charm++ Manual 2015).

 RefineTopoLB: Mesma ideia como em RefineLB, mas leva a topologia do processador em conta (Charm++ Manual 2015).

 ComboCentLB: Um equilibrador de carga especial que pode ser utilizado para combinar qualquer número de balanceamento de carga centralizadas acima mencionados (Charm++ Manual 2015).

Listados abaixo estão os balanceadores de carga distribuídos:

 NeighborLB: Um balanceador de carga em que cada processador tenta calcular a média de sua carga apenas entre os seus vizinhos (Charm++ Manual 2015).

 WSLB: Um balanceador de carga para clusters de estações de trabalho, que podem detectar mudanças de carga em desktops e ajuste de carga, sem interferir com o uso da área de trabalho do outro (Charm++ Manual 2015). Um exemplo de uma estratégia hierárquica pode ser encontrado em:



HybridLB: Este utiliza GreedyLB no nível inferior e RefineLB na raiz (Charm++ Manual 2015).

(28)

28

2.5.2 Anahy

Anahy e um ambiente de programação que explora PAD (Processamento de Alto Desempenho) em aplicações altamente paralelas. O ambiente apresenta dois modelos de execução: Anahy SMP para maquinas multiprocessadas (SMP’s) e Anahy D para aglomerado de computadores (BENITEZ e BARCELLOS, 2007). O Anahy SMP apresenta um modelo de execução que permite alcançar uma utilização eficiente de recursos computacionais disponíveis, alcançando bons índices de desempenho para aplicações com granularidade. Anahy D estende Anahy SMP, viabilizando a execução distribuída de aplicações Anahy em arquiteturas dotadas de memória compartilhada distribuída.

2.5.3 Cuda

CUDA é uma arquitetura de computação paralela de propósito geral desenvolvida pela NVIDIA que permite utilizar os recursos do mecanismo de computação paralela das unidades de processamento gráfico (GPUs) da NVIDIA. Utilizando tais recursos é possível acelerar o processamento numérico de aplicações de tal forma que permite resolver muitos problemas computacionais complexos como aqueles encontrados em Computação Científica em uma fração do tempo necessário utilizando uma CPU (BURIOL, 2009).

Segundo Acosta (2011) propõe uma biblioteca de balanceamento dinâmico de carga que permite que o código paralelo seja adaptado para sistemas heterogêneos utilizando alocação de recursos CUDA. O algoritmo visa evitar desequilíbrios de carga entre as threads da GPU. Para resolver as diferenças de tempo na execução do código paralelo, é utilizado um esquema iterativo, onde uma operação de cálculo é realizada para cada iteração. Cada processador irá executar cálculos de acordo com o tamanho da tarefa alocada. Após, uma operação de comunicação coletiva é realizada onde todos os processadores podem sincronizar os dados antes de prosseguir para a próxima iteração. Cada processador pode saber em tempo de execução quanto tempo será utilizado para executar a tarefa atribuída. O balanceamento de carga é obtido comparando o tempo de execução real de tarefas para cada processador com a redistribuição de tarefas subsequentes (KAUER e SIQUEIRA, 2012).

(29)

29

2.5.4 OpenCL

O OpenCL é um padrão aberto, definido pelo Khronos Group, para programação em dispositivo genérico (TUPINAMBÁ, 2012). A linguagem de programação do OpenCL é derivada da linguagem C99, mas com algumas extensões para suportar a sua arquitetura. À linguagem C99, foram acrescidos novos tipos de dados, escalares e vetoriais, e novas palavras reservadas, para qualificar tipo e o controle de acesso à memória e para qualificar as funções. É uma API independente de plataforma que permite aproveitar as arquiteturas de computação paralelas disponíveis, como CPUs multicore e GPUs, tendo sido desenvolvida objetivando a portabilidade.

2.5.5 Sofa

SOFA (Simple Ontology Framework API), é uma API construída em java com o propósito de proporcionar uma linguagem de especificação de conhecimento baseada em ontologias. Pode ser aplicada em projetos de web semântica, recuperação de informação, bases de conhecimento etc. SOFA providencia um modelo abstrato e simples independente da especificação de representação utilizada pela ontologia, o que possibilita a utilização de diversas linguagens tanto isoladas quanto em conjunto (JULIANI et al, 2005).

A API Sofa possui algumas funcionalidades que são:



Um modelo de objeto abstrato para representação de ontologias;



Um mecanismo de inferência genérico;



Ferramentas para gravação de ontologias para diversos modelos;



Mecanismo para interoperabilidade de ontologias;



Ferramentas para representação externa de ontologias;



Mecanismo para validação de ontologias;



Ferramentas para busca de ontologias, entre outras.

Mas as principais vantagens da utilização da API são a redução do tempo e custo de desenvolvimento por tratar-se de uma implementação das tarefas mais comuns relativas ao processamento de ontologias e aumento da flexibilidade do software desenvolvido, pois trata-se de um modelo abstrato de tratar com ontologias.

(30)

30

2.5.6 XKAAPI

XKaapi e um ambiente de programação que oferece paralelismo de tarefas com dependencias em arquiteturas multi-CPU e multi-GPU (LIMA e MAILARD, 2012). O XKaapi é uma reimplementarão do KAAPI com suporte ao paralelismo de tarefas de grão fino, e inclui um conjunto de ABIs (QUARK e libGOMP) e APIs (C, Fortran e C++). Sua interface C++ suporta a definição de diferentes implementações de uma tarefa através de uma Task Signature. Ela permite descrever os parâmetros de uma tarefa e seus modos de acesso (leitura, escrita, etc.), assim como suas especializações para cada processador, CPU ou GPU. O modelo de programação abstrai o cálculo de dependências, o mapeamento de tarefas, assim como o gerenciamento de memória.

(31)

31

3 PROPOSTA E METODOLOGIA

Neste capítulo serão apresentados a proposta do que se pretende com a realização deste trabalho, também o ambiente de teste utilizado, os benchmarks, os balanceadores de carga e a metodologia utilizada para a realização dos testes.

3.1 Proposta

Como o objetivo da computação paralela é rodar o máximo de processos ao mesmo tempo e com a evolução dos processadores tornou possível à execução de processos em mais de um núcleo com a utilização de ambientes de paralelização. Com a paralelização acabou ocorrendo muitas vezes sobrecarga em algum núcleo tornando necessária a utilização de Balanceadores de Carga. E neste trabalho propõem-se a explanar um estudo de como se obter um melhor desempenho dos processos em cada núcleo com a utilização de Balanceadores de Carga. E para demostrar os resultados propõem se a utilizar o ambiente de programação Charm++, para realizar testes utilizando balanceadores de carga em aplicações desbalanceadas, para analisar se há ou não ganho de desempenho e se houver qual do balanceador possui o melhor desempenho.

3.2 Ambiente de Teste

O Ambiente de teste utilizado para a realização dos testes está equipado com um processador Intel Core I5 modelo I5-3317U, 4GB de memória RAM DD3, HD de 500GB e utilizando o Sistema Operacional Linux Ubuntu versão 14.04 LTS.

Este processador foi desenvolvido pela Intel, pertencendo a 3º geração dos Core I5 e possui 4 cores de processamento sendo 2 físicos e mais 2 cores hyper-treading (que é uma tecnologia que emula núcleos lógicos fazendo com que algumas tarefas sejam executadas com o dobro de núcleos) e frequência de 1,7GHz a 2,6GHz.

3.3 Benchmarks

Para análise de desempenho dos balanceadores de carga foram utilizados dois benchmarks o Stencil3d e o lb-test. Os resultados dos testes representam o tempo médio das execuções.

(32)

32

3.3.1 Stencil3d

O Stencil3d foi desenvolvido por Abhinav S Bhatele no ano de 2010 e é integrante no ambiente do Charm++. Foi desenvolvido para a medição de carga periódica, pois a carga de alguns chares muda através de iterações dependendo do índice do chare.

Seu funcionamento consiste em criar uma matriz tridimensional (Figura 4), onde cada objeto é responsável pela computação de um bloco de dados 3D, e cada objeto comunica com seis vizinhos, dois em cada dimensão e mapeia um bloco 3D de objetos juntos em um processador.

Figura 4 – Demonstração do funcionamento do benchmark Stencil3d

Fonte: Charm++ Manual 2015.

Para a realização dos testes de desempenho com o Benchmark Stencil3d foram utilizadas as cargas conforme a Tabela 1.

Tabela 1 – Carga Benchmark Stencil3d

Benchmark Stencil3d

Carga Qtd Arrays Qtd Blocos Qtd Iterações

1 64 32 1000

2 128 32 1000

3 128 64 1000

(33)

33

3.3.2 Benchmark lb_tests

O lb_test foi desenvolvido por Orion Sky Lawlor no ano de 1999 e consta no ambiente do Charm++. O lb_test foi desenvolvido especialmente para testes de balanceamento de carga, sendo um benchmark sintético, onde é possível escolher diferentes cargas computacionais e padrões de comunicação, funcionando de maneira. Proporcionando um cenário onde é possível criar uma quantidade de processo distribuído, para controlar o desequilíbrio de carga, e também para usar diferentes padrões de comunicação entre os processadores. Para executar os testes, ter usado um diagrama de comunicação aleatório.

Tabela 2 – Carga Benchmark lb_test

Benchmark lb_test

Elementos Iterações Impressão Sincronização Primeiro nó em espera

Ultimo nó em espera

1000 1000 10 40 10 1000

Fonte: Autoria Própria

3.4 Balanceadores de Carga Utilizados

Para medir o ganho computacional foram utilizados balanceadores centralizados que são o RefineLB, GreedyLB, RefineCommLB e GreedyCommLB.

(34)

34

4 RESULTADOS

Neste Capítulo serão demonstrados os resultados obtidos com os benchmarks e balanceadores de cargas apresentados no Capítulo 3.

4.1 Testes Benchmark Stencil3d

Serão demonstrados os resultados obtidos conforme as cargas da Tabela 1, demonstrando sua execução com 2 e 4 threads de execução e um comparativo de cada carga.

4.1.1 Testes Carga 1

A primeira carga utilizada onde foi configurado o Benchmark Stencil3d a executar com 64 arrays e 32 bloks realizando 1000 iterações. Nas Figuras 5 e 6 estão demonstrados os testes realizados com duas e quatro threads respectivamente e após na Figura 7 a evolução dos tempos de execução de sequencial a 20 threads de execução.

Figura 5 – Execução Benchmark Stencil3d utilizando duas threads com carga 1.

Na Figura 5 o Balanceador de carga RefineLB obtém um desempenho de 5% mais rápido se comparada a execução sem a utilização de balanceadores. Onde todos os Balanceadores de carga obtiveram tempo de execução menor que sem a utilização de BCs. 44,96 _42,72 _43,88 _43,35 44,89 0 5 10 15 20 25 30 35 40 45 50

Sem BC RefineLB GreedyLB RefineCommLB GreedyCommLB

Tem p o d e E xec u ção ( s) Balanceadores

(35)

35

O segundo teste demonstrado é os resultados obtidos com a utilização de quatro Threads onde foram utilizados os quatro cores do processador.

Figura 6 – Execução Benchmark Stencil3d utilizando quatro threads

Neste teste todos os balanceadores obtiveram desempenho melhor que sem a utilização de BC’s, obtendo um ganho de desempenho de 9 a 12% para os BC’s. Onde os dois BCs Refine obtiveram o melhor rendimento tanto em comparação com os BC’s Greedy. 46,45 41,08 42,43 42,18 41,26 0 5 10 15 20 25 30 35 40 45 50

(36)

36

Figura 7 – Comparação de tempos Benchmark Stencil3d carga 1.

A Figura 7 demonstra um comparativo com a diferença de tempo de execução entre os balanceadores e demonstra uma diminuição no tempo de execução frente a execução sequencial e uma grande perda de desempenho dos BC’s RefineLB e RefineCommLB a partir da execução com mais de 10 Threads e uma perda de desempenho dos Balanceadores GreedyLB e GreedyCommLB a partir de 15 Threads de execução.

4.1.2 Teste Carga 2

O Segundo teste demonstra os resultados obtidos com o aumento da carga de arrays de 64 arrays para 128, mantendo o número de bloks em 32 e realizando 1000 iterações. Demostrado nas Figuras 8 e 9 estão os testes realizados utilizando 2 Threads e 4 Threads respectivamente e após um comparativo da evolução desde sequencial a 20 Threads de execução Figura 10.

0 20 40 60 80 100 120 1 2 3 4 5 10 15 20 Tem p o d e Execu ção (s) Threads

Comparação Benchmark Stencil3d

(37)

37

Figura 8 – Execução Benchmark Stencil3d utilizando duas threads Carga 2.

Neste teste utilizando a carga de 128 arrays, 32 blocks e 1000 iterações os BC’s obtiveram um desempenho de até 4% frente a execução sem Balanceador.

Outro teste realizado usando quatro threads onde o Stencil3D é executado nos quatro cores.

Figura 9 – Execução Benchmark Stencil3d utilizando quatro threads Carga 2.

358,23 _346,13 _347,69 _346,07 _352,94 0 50 100 150 200 250 300 350 400

Benchmark Stencil3d 2 Threads

264,71 247,71 253,86 248,52 254,06 0 50 100 150 200 250 300

(38)

38

Com a utilização de 4 Threads de execução os BC’s obtiveram um desempenho de 5 a 7% frente a execução sem Balanceador. Onde o BC RefineLB e RefineCommLB obtiveram um desempenho de cerca de 3% melhor que os BC’s GreedyLB e GreedyCommLB.

Figura 10 – Comparação de tempos Benchmark Stencil3d carga 2.

A Figura 10 demonstra um comparativo com a diferença de tempo de execução entre os balanceadores. Nela pode-se observar uma diminuição no tempo de execução frente a execução sequencial. O tempo se mantendo constante após a utilização de 4 Threads.

4.1.3 Teste Carga 3

O próximo teste demontra os resultados obtidos com o aumento da carga de arrays de 64 arrays em 128 e dobrando o valor da carga de blocks de 32 para 64 e realizando 1000 iterações. Demostrado nas Figuras 11 e 12 estão os testes realizados utilizando 2 Threads e 4 Threads respectivamente e após na Figura 13 um comparativo da evolução desde sequencial a 20 Threads de execução.

0 100 200 300 400 500 1 2 3 4 5 10 15 20 Tem p o d e E xec u são (s) Threads

Comparação Benchmark Stencil3d

(39)

39

Figura 11 – Execução Benchmark Stencil3d utilizando duas threads Carga 3

Na Figura 11 podemos observar um ganho no tempo de execução com a utilização dos BC’s. Com desempenho de até 5% melhor no tempo de execução.

Outro teste realizado usando quatro threads onde o Stencil3D é executado nos quatro cores.

Figura 12 – Execução Benchmark Stencil3d utilizando quatro threads Carga 3.

405,67 _386,58 _390,39 386,18 388,85 0 50 100 150 200 250 300 350 400 450

Benchmark Stencil3d 2 Threads

370,97 339,03 348,14 341,43 347,91 0 50 100 150 200 250 300 350 400

Te m p o d e E xe cu ção ( s) Balanceadores

(40)

40

Com a utilização de 4 Threads de execução os BC’s obtiveram um desempenho de até 9% melhor frente a execução sem Balanceador.

Figura 13 – Comparação de tempos Figura Benchmark Stencil3d Carga 3.

A Figura 13 demonstra um comparativo com a diferença de tempo de execução entre os balanceadores. Demonstrando um ganho computacional comparado com sequencial e mantendo-se constante após 10 Threads de execução.

4.2 Teste Benchmark lb_test

Utilizando o Benchmark lb_test com as configurações da Tabela 2, foram realizados os testes no benchmark com utilização de 2 e 4 Threads conforme Figuras 14 e 15 e um comparativo com os testes de sequencial a 20 Threads de execução Figura 16. O benchmark lb_test foi configurado para realizar 1000 iterações, com carga de 1000 elementos onde imprime o tempo a cada 10 iterações e realiza o balanceamento de carga a cada 40 iterações.

0 100 200 300 400 500 1 2 3 4 5 10 15 20 Tem p o d e E xec u ção ( s) Balanceadores

Comparação Benchmark Stencil3d

(41)

41

Figura 14 – Execução benchmark lb_test utilizando duas threads

Pode se observar na Figura 14 que o uso de balanceadores de carga não obteve desempenho satisfatório, obtendo um aumento no tempo de execução de até 3% frente à execução sem balanceador.

Onde o que menos ganho de tempo de execução foi o RefineLB e com maior ganho no tempo de execução foi o GreedyCommLB. Isso ocorre, pois, o desbalanceamento é pequeno em 2 cores.

Figura 15 – Execução benchmark lb_test utilizando quatro threads

107,35 107,81 109,07 110,39 109,217 0 20 40 60 80 100 120

Benchmark lb_test 2 Threads

59,92 _58,4 59,84 _58,91 59,84 0 10 20 30 40 50 60 70

(42)

42

Na figura 15 com a utilização de quatro Threads de execução com o Benchmark lb_test com a utilização dos BC’s obtiveram desempenho superior frente à execução sem BC, com aproximadamente 2% de ganho de desempenho.

Com a utilização de quatro threads de processamento os balanceadores acabaram gerando um ganho pelo fato de todos os cores estarem em funcionamento e com a utilização dos balanceadores nenhum ficou ocioso, trabalhando com cargas parecidas.

Figura 16 – Comparação Benchmark lb_test.

A Figura 16 demonstra uma comparação dos tempos de execução do Benchmark que obteve um desempenho parecidos mesmo com ou sem utilização de Balanceadores. 0 50 100 150 200 250 1 2 3 4 5 10 15 20 Tem p o d e E xec u ção ( s) Threads

Comparação Benchmark lb_test

(43)

43

CONCLUSÃO

Neste trabalho foi abordado os conceitos da evolução dos processadores, onde os atuais possuem mais de um núcleo programável, podendo executar vários processos ou programas paralelamente. Esta evolução gerou um problema de que um ou mais núcleos do processador acabam ficando ociosos, por causa dos programas terem sidos criados a ser executados de forma sequencial. Para resolver isso foram desenvolvidos ambientes de programação como Charm++, que possibilita mapear os processos em sua execução, podendo se recuperar de falhas, realizar o balanceamento de carga e migração de threads.

Para analisar este problema, a realização dos testes realizados neste trabalho onde se utilizou o ambiente de programação Charm++ e os Balanceadores de Carga RefineLB, RefineCommLB, GreedyLB e GreedyCommLB que demonstraram um desempenho satisfatório utilizando o Benchmark Stencil3d e razoável com o Benchmark lb_test. Nos testes realizados no Benchmark Stencil3d os Balanceadores de Carga obtiveram desempenho de até 12% melhor que os sem a utilização de Balanceadores, tanto com duas e quatro threads o balanceador de carga RefineLB obteve um melhor rendimento frente aos outros balanceadores. No Bencmark lb_test os Balanceadores de Carga não obtiveram um bom resultado com a execução do Benchmarck com duas Threads os Balanceadores demoraram cerca de 3% a mais que sem a utilização, mas na execução com quatro Threads o desempenho foi de até 2% mais rápido.

No Capítulo 5 onde demonstra os comparativos das execuções com cada carga, pode se observar nos resultados que a utilização de Balanceadores de Carga não gera mais ganho de desempenho com sua utilização nas execuções de mais de 10 Threads, onde os Balanceadores de carga não obtêm um desempenho bom quanto com 2 e 4 Threads de execução eles acabam perdendo tempo em organizar as Threads. E quando a carga utilizada é baixa pode ter um grande aumento no seu tempo de execução, com cargas maiores se mantem constante.

Portanto os Balanceadores de Carga podem ser utilizados para se obter ganho de desempenho em aplicações paralelas, desde que levado em consideração o modelo de programação escolhido, pois os balanceadores de carga variam dependendo de sua aplicação. E o número de threads de execução utilizados na aplicação.

(44)

44

Como trabalhos futuros:

 Testar os mesmos benchmarks e balanceadores em um computador com maior poder computacional, para ver o comportamento dos balanceadores com maior poder computacional.

 Fazer o mapeamento dos chares e calcular o ganho computacional de se mapear e balancear a carga;

 Criação de um balanceador de carga;

 Utilização de outro ambiente paralelo para comparativo dos ambientes paralelos comparando seu tempo de execução de processos, com e sem balanceamento de carga e com a utilização.

(45)

45

REFERÊNCIAS

ACUN, B., GUPTA, A., JAIN, N., LANGER, A., MENON, H., MIKIDA, E., NI, X., ROBSON, M., SUN, Y., TONONI, E., WESOLOWSKI, L., and KALE, L. (2014). Parallel Programming with Migratable Objects: Charm++ in Practice. In Proceedings of the International Conference on High Performance Computing, Networking, Storage and Analysis, SC ’14, New York, NY, USA. ACM.

AVELAR, Cíntia P.; Penna, Pedro H.; FREITAS, Henrique C. . Algoritmo Kmeans para Mapeamento Estático de Processos em Redes-em-Chip. In: Simpósio em Sistemas Computacionais de Alto Desempenho (WSCAD), 2014, São José dos Campos. Belo Horizonte: Pontifica Universidade Católica de Minas Gerais, 2011. p 204 - 215.

BENITEZ, Epifanio Dinis; BARCELLOS, Marinho Pilla. AVC: Anahy Virtual Computer. 2007. Programa de Pós-graduação em Computação Aplicada. Universidade do Vale do Rio dos Sinos. São Leopoldo, Rio Grande do Sul.

BROOKSHEAR, J. Glenn. Ciência da Computação uma visão abrangente. 11. ed. Porto Alegre: Bookman Editora LTDA, 2013. p 576.

CARINGI, Augusto Mecking. Escalonamento Estático de Processos de Aplicações Paralelas MPI em Maquinas Agregadas Heterogêneas com Auxilio de Históricos de Monitoração. 2006. Dissertação (Mestrado em Ciência da Computação) – Programa de Pós-Graduação em Ciência da Computação, Pontifica Universidade Católica do Rio Grande do Sul, Porto Alegre.

CHAI, L., GAO, Q., PANDA, D. (2007). Understanding the Impact of Multi-Core Archi-tecture in Cluster Computing: A Case Study with Intel Dual-Multi-Core System. In Cluster Computing and the Grid, pags 471–478.

Charm++ Manual (2015). The Charm++ Parallel Programing System Manual. http://charm.cs.illinois.edu/manuals/html/charm++/manual.html/. Acessado em maio de 2015.

CRUZ, Eduardo H. M., PADOIN, Edson L., BOITO, Francieli Z., NAVAUX, Philippe. Avaliando Consumo de Energia no Mapeamento de Processos. 2011. Artigo. ERAD-RS 2011.

FEDOROVA, Alexandra; SELTZER, Margo; SMITH, Michael D.. Cache-Fair Thread Scheduling for Multicore Processors. Harvard University, Sun Microsystems.

(46)

46

FERREIRA, Manuela Klanovicz. Mapeamento Estático de Processos MPI com Emparelhamento Perfeito de Custo Máximo em Cluster Homogêneo de Multi-cores. 2012. Dissertação (mestrado) – Programa de Pós-Graduação em Computação, Universidade Federal do Rio Grande do Sul, Porto Alegre.

GOMES, Roberto de Quadros. MIGBSP++: Balanceamento de Carga Eficiente para Aplicações Paralelas em Fases. 2014. Dissertação (Mestrado) - Programa Interdisciplinar de Pós Graduação em Computação Aplicada, Universidade do Vale do Rio dos Sinos – UNISINOS, São Leopoldo.

JULIANI, Jordan Pauleski; de BETTIO, Raphael Winckler; BOGO, Luis Henrique ; RODRIGUES Alejandro Martins , FULBER, Heleno. A Utilização da API SOFA para o Desenvolvimento de uma Aplicação de Web Semântica: Um Estudo de Caso Envolvendo as Ontologias Estado, Região e Cidade. 2005. Dissertação (Pós Graduação Engenharia e Gestão do Conhecimento) Universidade Federal de Santa Catarina, Florianópolis, Santa Catarina.

KAUER, Anderson Uilian; de SIQUEIRA, Mozart Lemos; Balanceamento de Carga em Sistemas Paralelos Heterogêneos Baseados em GPU. 2012. Artigo UNILASALLE – Centro Universitário La Salle, Canoas, Rio Grande do Sul.

LIMA, João V. F. ; MAILARD, Nicolas. Implementação da PLASMA para Arquiteturas Heterogêneas Multi-CPU e Multi-GPU em XKAAPI. 2013. Artigo. Instituto de Informatica. Uiversidade Federal do Rio Grande do Sul. Porto Alegre. Rio Grande do Sul.

MEIRA, Marcos Vinícius. Política de Escalonamento de Processos em Linux. In; Campo Dig. 2008. Campo Mourão. Campo Mourão: Faculdade Integrado de Campo Mourão, 2008 v.1,n.2, p. 56 - 64.

NOGUEIRA, Mauro Lúcio Baioneta. ROBIN HOOD Um Ambiente para a Avaliação de Politicas de Balanceamento de Carga. 1998. Dissertação (Mestrado em Ciência da Computação) – Curso de Pós Graduação em Ciência da Computação, Universidade Federal do Rio Grande do Sul, Porto Alegre.

OLIVEIRA, Poliana A. C.; AVELAR, Cíntia P.; GUIMARÃES, Silvio Jamil F.; FREITAS, Henrique C. A Greedy Heuristic for Process Mapping on Networks-on-Chip. In: Simpósio em Sistemas Computacionais de Alto Desempenho (WSCAD-SSC), 2011, Vitória. Belo Horizonte: Pontifica Universidade Católica de Minas Gerais, 2011. p 1 - 8.

(47)

47

PADOIN, Edson L., CRUZ, Eduardo H. M., BOITO, Francieli Z., MOREIRA, Francis B., PILLA, Laercio L., KASSICK, Rodrigo V., NAVAUX, Philippe O. A.. Avaliação de um Modelo de Consumo Energético Aplicado ao Mapeamento de Processos. Artigo (Instituto de Informática) Universidade Federal do Rio Grande do Sul (UFRGS). Porto Alegre. Rio Grande do Sul.

PILLA, Laércio Lima; MENESES, Esteban, Programação Paralela em Charm++, 2015, Curso(Erad 2015).

RAVASI, Juliano Ferraz. JUMP: Uma politica de escalonamento unificada com migração de processos. 2009. Dissertação (Mestrado em Ciências) – Ciências de Computação e Matemática Computacional, Instituto de Ciências Matemáticas e de Computação – ICMC – USP, São Carlos.

SALES, Péricles da Silva Bastos. Avaliação de Desempenho de Ferramentas de Renderização de Imagens em Clusters openMosix e Arquiteturas Multicore. 2008. Dissertação (Trabalho de Conclusão de Curso) – Engenharia da Computação, Escola Politécnica de Pernambuco, Recife.

SILBERSCHATZ, Abraham; GALVIN, Peter Baer; GAGNE, Greg. Sistemas Operacionais com Java. 7. ed. Rio de Janeiro: Elsevier Editora LTDA, 2008. p 673.

SILVA, Samuel Reghim. Análise da Escalabilidade de aplicações em computadores multicore. 2013. Dissertação (Pós Graduação em Ciência da Computação) – Centro de Ciências Exatas e de Tecnologia, Universidade Federal de São Carlos, São Carlos.

TANENBAUM, Andrew S.; WOODHULL, Albert S.. Sistemas Operacionais Projeto e Implantação. 3. ed. Porto Alegre: Artmed Editora S A, 2008. p 990.

TUPINAMBÁ, André. Programação em GPU utilizando OpenCL. 2012. Artigo.

(48)

48

ANEXO A

Lista testes realizados:



Benchmark Stencil 3d Carga 1. ./charmrun ./stencil3d 64 32

./charmrun +p1 ./stencil3d 64 32 +balancer RefineLB ./charmrun +p1 ./stencil3d 64 32 +balancer GreedyLB ./charmrun +p1 ./stencil3d 64 32 +balancer RefineCommLB ./charmrun +p1 ./stencil3d 64 32 +balancer GreedyCommLB ./charmrun +p2 ./stencil3d 64 32 +balancer RefineLB

./charmrun +p2 ./stencil3d 64 32 +balancer GreedyLB ./charmrun +p2 ./stencil3d 64 32 +balancer RefineCommLB ./charmrun +p2 ./stencil3d 64 32 +balancer GreedyCommLB ./charmrun +p3 ./stencil3d 64 32 +balancer RefineLB

./charmrun +p5 ./stencil3d 64 32 +balancer GreedyLB ./charmrun +p5 ./stencil3d 64 32 +balancer RefineCommLB ./charmrun +p5 ./stencil3d 64 32 +balancer GreedyCommLB ./charmrun +p10 ./stencil3d 64 32 +balancer RefineLB ./charmrun +p10 ./stencil3d 64 32 +balancer GreedyLB ./charmrun +p10 ./stencil3d 64 32 +balancer RefineCommLB ./charmrun +p10 ./stencil3d 64 32 +balancer GreedyCommLB ./charmrun +p15 ./stencil3d 64 32 +balancer RefineLB

(49)

49

./charmrun +p20 ./stencil3d 64 32 +balancer GreedyLB ./charmrun +p20 ./stencil3d 64 32 +balancer RefineCommLB ./charmrun +p20 ./stencil3d 64 32 +balancer GreedyCommLB



Benchmark Stencil 3d Carga 2. ./charmrun ./stencil3d 128 32

./charmrun +p1 ./stencil3d 128 32 +balancer RefineLB ./charmrun +p1 ./stencil3d 128 32 +balancer GreedyLB ./charmrun +p1 ./stencil3d 128 32 +balancer RefineCommLB ./charmrun +p1 ./stencil3d 128 32 +balancer GreedyCommLB ./charmrun +p2 ./stencil3d 128 32 +balancer RefineLB

./charmrun +p15 ./stencil3d 128 32 +balancer GreedyLB ./charmrun +p15 ./stencil3d 128 32 +balancer RefineCommLB ./charmrun +p15 ./stencil3d 128 32 +balancer GreedyCommLB