UNIJUÍ UNIVERSIDADE REGIONAL DO NOROESTE DO ESTADO DO RIO GRANDE DO SUL DCEEng DEPARTAMENTO DE CIÊNCIAS EXATAS E ENGENHARIAS

Transcrição

1 UNIJUÍ UNIVERSIDADE REGIONAL DO NOROESTE DO ESTADO DO RIO GRANDE DO SUL DCEEng DEPARTAMENTO DE CIÊNCIAS EXATAS E ENGENHARIAS CURSO DE GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO BALANCEAMENTO DE CARGA EM SISTEMAS MULTIPROCESSADORES UTILIZANDO O MODELO DE PROGRAMAÇÃO CHARM++ Guilherme Henrique Schiefelbein Arruda Santa Rosa - RS 2015

2 GUILHERME HENRIQUE SCHIEFELBEIN ARRUDA BALANCEAMENTO DE CARGA EM SISTEMAS MULTIPROCESSADORES UTILIZANDO O MODELO DE PROGRAMAÇÃO CHARM++ Projeto apresentado na disciplina de Trabalho de Conclusão de Curso do curso de Ciência da Computação da Universidade do Noroeste do Estado do RS como requisito básico para apresentação do Trabalho de Conclusão de Curso. Orientador: Edson Luiz Padoin Banca: Rogério Samuel de Moura Martins Santa Rosa - RS 2015

3 1 Sumário Lista de Figuras 3 Lista de Tabelas 3 Lista de abreviaturas 4 1 Introdução Contexto Problema Definição da Proposta Organização do Trabalho Estado da Arte Irregularidades nas Aplicações Paralelas Balanceamento de Carga Ambientes de Programação e Balanceadores de Carga Charm Entidades de Charm Troca de Mensagens Modelo de Execução Avaliação do Charm++ para Sistemas Multiprocessadores Balanceadores de Carga Migrabilidade e o Framework PUP Tolerância a Falhas Balanceador de Carga AverageLB Metodologia de Implementação Balanceamento de Carga Centralizado Detalhes da Estratégia Algoritmo do AverageLB Resultados Definição do Hardware Utilizado Análise de Desempenho

4 2 4.3 Análise de Objetos Migrados Conclusão 31 Referências 32

5 3 Lista de Figuras 1 Elementos do framework de um balanceador de carga Diferentes visões entre os métodos da decomposição de um problema Comunicação entre objetos chares Exemplo de um vetor bidimensional Diferentes visões da comunicação em um vetor de chares Processo de compilação do Charm Modelo da estratégia em árvore de três níveis baseada em um token Exemplo do funcionamento do método PUP Processo de equilíbrio de cargas executado pelo BC proposto Cargas dos processadores com valor próximo à MAG Comparação do tempo médio de execução entre diferentes balanceadores de carga para o benchmark lb test Comparação entre o tempo que cada BC levou para executar cada passo do benchmark lb test Comparação do tempo médio de execução entre diferentes balanceadores de carga para o benchmark Stencil3D Comparação entre o tempo que cada BC levou para executar cada passo do benchmark lb test Comparação do total de migrações realizadas por diferentes balanceadores de carga para o benchmark lb test Comparação do total de migrações realizadas por diferentes balanceadores de carga para o benchmark Stencil3D Lista de Tabelas 1 Principais parâmetros utilizadas pelo AverangeLB Algoritmo do AverangeLB

6 4 Lista de abreviaturas AMPI Adaptive Message Passing Interface API Interface de Programação de Aplicativo BC Balanceador de Carga CAD Computação de Alto Desempenho CMP Carga Média por Processador FEM Método Finito de Elementos HPC High Performance Computing MAG Média Aritmética Geral MIMD Multiple Instructions Multiple Data MPI Message Passing Interface NAMD Nanoscale Molecular Dynamics NUMA Acesso Não-Uniforme à Memória PObC++ Parallel Object C++ PUP Pack and Unpack PVM Máquina Virtual Paralela RMI Invocação Remota de Método UDP User Datagram Protocol

7 5 Agradecimentos Agradeço a Deus, à minha esposa, meus pais, irmãos, amigos e familiares pela presença, apoio, incentivo, companheirismo, motivação e por toda a confiança que depositaram em mim. Agradeço aos meus professores, à Universidade Regional do Noroeste do Estado do Rio Grande do Sul pelo apoio, pelos ensinamentos teóricos, práticos e formação acadêmica. Agradeço especialmente ao meu orientador, professor Dr. Edson Luiz Padoin, que me orientou no desenvolvimento deste trabalho com muita competência, empenho, generosidade e paciência. Agradeço também ao membro da banca, professor Rogério Samuel de Moura Martins, que me apoiou e incentivou muito durante a graduação. Agradeço aos meus colegas que estiveram ao meu lado durante a graduação. Guilherme Henrique Schiefelbein Arruda Santa Rosa, julho de 2015.

8 6 1. Introdução 1.1. Contexto À medida que a produção de software avança, ocorre um crescimento da demanda por processamento computacional. A necessidade de alto desempenho fez com que sistemas computacionais fossem desenvolvidos para suprir esta necessidade. Desde a década de 40, onde os computadores eram difíceis de programar devido às limitações tecnológicas da época, a necessidade de um recurso mais eficiente e simples de manipular as instruções destas máquinas já era desejado. A falta de uma linguagem de programação de alto nível resultava em programas desenvolvidos em linguagem de máquina, tornando sua interpretação e depuração praticamente impossível [Baranauskas 1993]. A partir do momento em que o hardware começou a evoluir, foi possível criar linguagens de programação de paradigma procedural. Este era o que melhor se adequava ao uso da arquitetura de Von Neumann como solução de um problema que a própria máquina resolvia. Uma destas linguagens, que ainda é utilizada nos dias atuais, é o C [Kernighan et al. 1988]. Desde então, a criação de programas ficou muito mais fácil uma vez que o programador escrevia uma série de procedimentos para a máquina executar [Baranauskas 1993]. Porém, as linguagens estruturais ainda possuíam muitas limitações. O desejo de criar algo diferente já estava presente. A ideia de orientação a objetos podia ser identificada nas structs, um tipo de variável especial da linguagem C que contém outras variáveis de tipos diferentes [Kernighan et al. 1988]. Assim, a orientação a objetos permitia particionar o projeto de um programa em diversos módulos. Isso facilitava o desenvolvimento do software e reduzia seu custo de manutenção, além de permitir o reuso de código [Gudwin 1997]. Um dos componentes de hardware que apresentou uma grande evolução foi o processador. Este deixou de ser single core e passou a contar com vários núcleos, proporcionando a execução simultânea de diversas aplicações. Com isso, foi possível construir computadores pessoais, sistemas embarcados e até supercomputadores. Isso abriu as portas para a programação paralela, pois possibilitou que as aplicações fossem divididas em partes e inseridas nos núcleos das unidades de processamento [Pilla and Meneses 2015] Problema A modelagem de um problema complexo pode trazer alguns problemas, como o desbalanceamento de carga e excessiva comunicação entre tarefas [Padoin et al. 2014]. Estes são dois dos principais fatores que comprometem o desempenho do processador. A ausência da ferramenta adequada para equilibrar as cargas implica na sobrecarga de alguns núcleos. Dessa maneira, algumas unidades de processamento trabalham muito mais que as outras. O resultado disso é que as aplicações levam mais tempo para executar, além de elevar a temperatura e o consumo de energia. A união destes problemas impede que todo o potencial do processador seja aproveitado. Desde então, diversos programas paralelos são construídos para que seja possível utilizar todo o potencial dos sistemas computacionais atuais. Infelizmente, a programação paralela ainda é difícil de aplicar em plataformas de desenvolvimento. É possível utilizar algumas interfaces de programação de aplicativos (APIs) específicos para desenvolver programas paralelos, facilitando esse trabalho para aplicações regulares e ambientes

9 7 homogêneos [Pilla and Meneses 2015]. Como exemplo destas ferramentas pode-se citar o OpenMP [Chandra 2001] e o MPI [Dongarra et al. 1996]. Porém, utilizá-las em aplicações dinâmicas ou ambientes variáveis pode acarretar em perda de desempenho [Pilla and Meneses 2015]. Embora exista a proposta de um novo BC para redução do consumo de energia [Padoin et al. 2014] e uma avaliação de adequação da plataforma Charm++ [Pilla et al. 2011], estas não visam equilibrar o tempo de execução dos processadores. Isso pode reduzir o desempenho do sistema, além de permitir que um processador trabalhe mais do que o outro Definição da Proposta Será utilizado o modelo de programação Charm++ pelo fato de ser a ferramenta mais indicada para trabalhar com ambientes multiprocessadores. Com este modelo, será criado um novo balanceador de carga (BC) que faz uso de uma estratégia, baseada em médias aritméticas, a qual permite equilibrar as cargas e o tempo de execução entre os processadores, impedindo que um deles fique ocioso ou sobrecarregado. Assim, o BC proposto foi denominado AverageLB. O motivo pelo qual será utilizado um balanceador de carga se dá porque contém métodos específicos para trabalhar com os processadores. Estes métodos permitem dividir uma aplicação em objetos migráveis, denominados chares, e inseri-los em várias unidades de processamento. O BC proposto faz uso de uma abordagem centralizada, a qual manterá os núcleos ocupados pelo máximo de tempo possível, evitando a perda de eficiência Organização do Trabalho Nesta Seção, foram apresentadas informações introdutórias sobre o contexto, o problema e a proposta do trabalho. A segunda Seção apresenta o estado da arte do ambiente paralelo, bem como os sistemas de alto desempenho, o modelo de programação Charm++ e seus componentes. Serão abordados trabalhos referentes à estes tópicos, mas o destaque principal são os balanceadores de carga. Na terceira Seção será demonstrado o pseudocódigo do algoritmo do AverangeLB e seus principais parâmetros. A quarta Seção explica a proposta do BC, seu funcionamento e a metodologia utilizada para desenvolvê-lo. A quinta Seção demostrará os resultados obtidos com este algoritmo, bem como as expectativas alcançadas por ele. Assim, a sexta Seção apresenta as conclusões, discussões e contribuições que este trabalho proporcionou. Por fim, serão apresentadas as referências bibliográficas que nortearam este trabalho.

10 8 2. Estado da Arte A presente situação do ambiente paralelo mostra uma grande preocupação com os sistemas computacionais de alto desempenho (CAD) ou High Performance Computing (HPC). Este fator é consequência do objetivo destes sistemas de atingir a escala do exaflop, como pode ser visto na lista dos 500 melhores supercomputadores [Dongarra et al. 1994]. Aplicações paralelas estão sendo construídas para máquinas que possuem centenas de milhares de processadores, pois necessitam obter resultados precisos no menor tempo possível Irregularidades nas Aplicações Paralelas Existem aplicações que foram desenvolvidas utilizando linguagens procedurais, baseadas em um paradigma de troca de mensagem paralelo como, por exemplo, o MPI [Dongarra et al. 1996]. Isso torna sua estrutura irregular, além de apresentar padrões de carga dinâmicos. Uma alternativa para estas aplicações irregulares seria incorporar técnicas de balanceamento de carga dinâmico em sua estrutura, o que tornaria necessário realizar mudanças na estrutura da aplicação [Bhandarkar et al. 2001]. Porém, o sistema de execução do MPI não suporta balanceamento de carga dinâmico. Dessa forma, uma outra alternativa seria converter estas aplicações utilizando uma linguagem de programação paralela orientada a objetos, como o Charm++. Este suporta eficientemente as técnicas de balanceamento de carga dinâmica para aplicações irregulares baseado na migração de objetos. Contudo, esta conversão é muito onerosa uma vez que as arquiteturas das máquinas que rodam estes paradigmas são diferentes [Bhandarkar et al. 2001]. A técnica adotada por [Bhandarkar et al. 2001] para aplicar o balanceamento de carga dinâmico em aplicações irregulares foi utilizar o Adaptive MPI (AMPI), que é semelhante ao MPI, porém usa orientação a objetos para direcionar as mensagens. Com esta abordagem, o autor conseguiu fazer uso do framework para balanceamento de carga disponibilizado pelo Charm++, onde foi necessário dividir a aplicação em várias partes pequenas, chamadas de chunks. Estes chunks eram mapeados e remapeados a fim de balancear as cargas através dos processadores. Por isso, chunks foram implementados como objetos para que os balanceadores de cargas do Charm++ os reconhecessem como chares. Com este método, os autores conseguiram converter duas grandes aplicações científicas. Como resultado, constataram que o overhead apresentado pelo AMPI é muito pequeno, além das mínimas mudanças realizadas no código original. A partir daí, o AMPI começou a ser amplamente utilizado juntamente com Charm++ para otimizar aplicações irregulares Balanceamento de Carga A maioria das aplicações paralelas envolve simulação com comportamentos dinâmicos ou cálculos baseados em diversas fórmulas complexas. Estes dois fatores principais conduzem a aplicação para um desbalanceamento de carga devido à grande quantidade de tarefas e variáveis. Um exemplo disso é a simulação do método finito de elementos (FEM) a qual envolve geometria dinâmica e utiliza técnicas adaptativas para resolver grandes problemas irregulares. Devido à este desbalanceamento da carga de trabalho, as grandes máquinas paralelas não conseguem obter o aproveitamento desejado. Portanto, algoritmos de balanceamento são tão importantes, especialmente para aplicações onde a

11 9 quantidade de computações deve aumentar significativamente à medida que a simulação evolui [Kale and Zheng 2009, UIUC 2015]. O problema do equilíbrio de cargas envolve a tomada de decisão sobre a inserção de tarefas computacionais recém-criadas em processadores, ou migrar tarefas existentes entre processadores uniformemente. Para que os algoritmos balanceadores de carga possam tomar melhores decisões relacionadas ao balanceamento de carga, é essencial que o sistema de execução forneça heurísticas e informações sobre a carga do sistema mais atualizadas. Alguns ambientes de programação adotam uma metodologia baseada na medição das cargas dos objetos que executam em cada processador. Para isso, o BC coleta automaticamente estatísticas da carga computacional e da comunicação destes objetos e armazena estas informações em um banco de dados. Este banco de dados vai ajudar o BC a decidir quando e onde migrar os objetos [Jyothi et al. 2004]. Figura 1. Elementos do framework de um balanceador de carga Fonte: [Kale and Zheng 2009] A Figura 1 mostra os elementos do framework dos BCs em um único processador. Nela, é possível identificar que no topo existem estratégias distintas. O BC deve escolher entre uma delas para utilizar durante a execução. No centro, estão o gerenciador do BC e o banco de dados que devem informar às estratégias o momento em que elas devem realizar um balanceamento de carga. Quando isso acontece, elas começam a obter informações sobre os estados dos objetos e de suas cargas, armazenando estes dados no banco de dados. Com isso, as estratégias podem decidir o momento certo de migrar os objetos e assim alcançar o equilíbrio final das cargas. Os tipos de estratégias disponíveis variam entre centralizada, distribuída, híbrida, incremental, entre outras. Nas próximas seções, todo este processo será visto na prática, utilizando um ambiente de programação paralelo específico Ambientes de Programação e Balanceadores de Carga Atualmente existem diversos ambientes de programação paralela capazes de resolver os problemas de balanceamento de carga descritos na Seção 2.2. Abaixo, são citados

12 10 os principais ambientes que se encaixam nesta categoria: AMPI - Adaptive MPI [Huang et al. 2004] é uma extensão do MPI construído em cima do sistema de execução do Charm++. Este ambiente implementa os processos MPI virtualizados através de threads migráveis à nível de usuário, as quais podem ser mapeadas para um processador físico. A razão principal para criar esta versão adaptada se deu pelo fato de que as implementações de MPI já não suportam a natureza dinâmica das grandes aplicações paralelas, que envolvem simulação e comportamentos dinâmicos que variam com o tempo. A ideia básica por trás do AMPI é separar a questão de mapear trabalho para os processadores da identificação do trabalho a ser feito em paralelo. Programas padrões em MPI dividem a computação em P processos, um para cada P processadores. Em contrapartida, um programador em AMPI divide a computação em um grande número de processadores virtuais, independente do número de processadores físicos. Isso permite uma série de benefícios, como a possibilidade de balancear automaticamente as cargas computacionais, emular grandes máquinas em pequenas máquinas e a divisão eficiente de trabalho entre o sistema e o programador, pois o programador decido o que fazer em paralelo e o sistema decide quando e onde fazer isso; Charm++ - Charm++ [Kale and Krishnan 1993] é uma extensão da linguagem C++, no qual proporciona um ambiente para programação paralela orientada a objetos. Proporciona uma divisão clara entre objetos sequenciais e paralelos. Possui um modelo de execução dirigido por mensagens. Os programas desenvolvidos neste ambiente são completamente portáveis e rodam sem necessidade de mudança em todas as máquinas com arquitetura MIMD. Suporta estratégias de balanceamento de carga dinâmico, que é necessário quando há computações paralelas irregulares e onde a carga é dividida desigualmente entre as unidades de processamento. Charm++ possui objetos concorrentes chamados de chares, que representam pequenas tarefas. São instanciados a partir de uma classe da mesma maneira que objetos em C++, por isso possuem seus próprios métodos e variáveis. Porém, as variáveis são privadas, o que significa que um chare não pode acessar um atributo de outro diretamente. Para isso, ele deve enviar uma mensagem ao objeto que deseja se comunicar, invocando um de seus métodos. Seu sistema de execução realiza um balanceamento de cargas dinâmico, o qual objetiva a distribuição eficiente de cargas entre os processadores. Também possui políticas de tolerância a falhas para manter estável a execução de aplicações paralelas; Java paralelo - Parallel Java [Kalé et al. 1997] é a versão paralela do Java criada para tornar esta linguagem de programação compatível com os clusters e servidores paralelos a fim de aproveitar todo seu potencial computacional. Para criar esta versão, foi utilizado o framework Converse [Kalé et al. 1996] o qual permite que módulos paralelos individuais sejam escritos utilizando diversos paradigmas em diferentes linguagens. Diante disso, esta versão paralela do Java foi construída utilizando bibliotecas e extensões do C-MPI, Charm++ e um máquina virtual paralela (PVM), resultando em uma nova aplicação com novos módulos escritos em Java. Em relação ao seu design, foram criados dois novos tipos de objetos, o pri-

13 11 meiro refere-se à objetos remotos, similares aos chares em Charm++, os quais podem ser criados em processadores remotos e são acessados por meio proxies. Já o segundo tipo referem-se aos grupos de objetos, que possuem ramificações em cada processador. Toda aplicação construída com o Java Paralelo deve ter uma classe main, a qual é iniciada no processador 0. Assim como em Charm++, os objetos remotos devem ser instanciados por uma classe remota, que devem conter métodos de entrada para permitir a comunicação entre os objetos. A invocação do método de um objeto é realizada pela API de invocação remota de método (RMI) do Java. O modelo de execução também é dirigido por mensagens, onde um escalonador retira mensagens de uma fila. Todos estes componentes podem ser utilizados para criar programas paralelos aproveitando a grande linguagem de alto nível que o Java se tornou, facilitando a programação e a portabilidade das aplicações; PObC++ - Parallel Object C++ [Pinho and de Carvalho 2014] é uma linguagem que estende o C++, implementada sobre a biblioteca MPI e que introduz um novo estilo de programação paralela orientada a objetos, onde objetos são intrinsecamente paralelos, ou seja, distribuídos em um conjunto de unidades de processamento de um computador paralelo de memória distribuída. O motivo pelo qual este ambiente contém implementações de MPI é para habilitar a criação, comunicação e sincronização de processos. Já a extensão em C++ é adotada por se tratar de uma linguagem disseminada e amplamente aceita na área de Computação de Alto Desempenho (CAD). PObC++ utiliza objetos paralelos, chamados de p- objeto, constituídos de um conjunto de unidades, cada uma localizada em um processador de uma máquina paralela com memória distribuída. Comunicam-se através de invocação remota de método, onde a comunicação pode ser intra-objeto ou inter-objeto. Um p-objeto é instanciado por outro p-objeto pela instanciação coletiva de cada uma de suas unidades em unidades de processamento diferentes. Nenhuma comunicação acontece entre as unidades durante a instanciação. Comunicações ocorrem somente em invocações paralelas de métodos e o objeto chamador é responsável em criar um comunicador apropriado e passar para o método paralelo que ele deseja invocar. Analisando os ambientes de programação descritos acima, o mais compatível com este trabalho é o Charm++. Além das informações descritas sobre ele, a principal razão para a escolhe deste ambiente é o seu framework de balanceamento de carga, que permite tanto criar um novo BC quanto utilizar um disponibilizado pelo ambiente. Abaixo estão citados e descritos alguns BCs fornecidos pelo Charm++: BCs com estratégia centralizada: RefineLB: Move objetos dos processadores mais sobrecarregados para os menos carregados até atingir uma média, que é definida através de um método específico, limitando o número do objetos migrados; RefineCommLB: Mesmo conceito do anterior, porém leva em consideração a comunicação entre diferentes objetos enquanto tenta escolher o melhor processador que não esteja sobrecarregado para inserir um objeto; RandCentLB: Insere objetos nos processadores de forma aleatória;

14 12 MetisLB: Uma estratégia que passa as informações das cargas e da comunicação para o Metis, que é uma biblioteca de particionamento de grafos, e utiliza o método de particionamento recursivo de grafos nele para balancear as cargas; GreedyLB: Utiliza um algoritmo guloso, sempre migrando um objeto mais pesado para o processador com a menor carga até que a carga de todos os processadores esteja próxima à carga média; ComboCentLB: É utilizado para combinar quaisquer das estrategias acima. BCs com estratégia Distribuída: NeighborLB: Cada processador tenta obter uma carga media em relação aos seus vizinhos; WSLB: Um balanceamento para clusters de estacões de trabalho que pode detectar mudanças nas cargas das maquinas e ajustar estas carga sem interferir no trabalho do usuário. BC com estratégia híbrida: HybridLB: Permite combinar dois ou mais balanceadores que possuem estratégia centralizada. Esta estratégia permite dividir um grande número de processadores em vários grupos, permitindo realizar um balanceamento de carga mais organizado e eficiente; Charm++ Charm++ é uma extensão da linguagem C++, no qual proporciona um ambiente para programação paralela orientada a objetos. Seu desenvolvimento foi feito pelo Laboratório de Programação Paralela da Universidade de Illinois, em Oferece suporte a diversas plataformas e permite que os programas desenvolvidos neste modelo executem tanto em ambientes com memória compartilhada quanto com distribuída. Esta ferramenta utiliza uma técnica que consiste em dividir um problema em diversos componentes migráveis, que são executados em vários processadores [Kale and Krishnan 1993]. A Figura 2 demonstra a diferença entre a maneira como o usuário visualiza a interação entre estes objetos e a maneira como eles são distribuídos pelo Charm++. Estes componentes migráveis são chamados de objetos chares. Figura 2. Diferentes visões entre os métodos da decomposição de um problema Fonte: [Pilla et al. 2011]

15 Entidades de Charm++ Chares são uma das entidades de Charm++ e referem-se aos objetos do C++ com seus atributos e dados privados, sendo instanciados através de uma classe chare. Isso significa que um chare não pode acessar as informações de outro diretamente. Para isso, a comunicação entre eles é feita através da troca de mensagens, como mostra a Figura 3. Por definição, uma mensagem é formada por um conjunto de dados. Em Charm++, mensagens possuem a mesma sintaxe que a declaração de métodos da linguagem C++ [Kalé et al. 1995]. Um chare pode manipular desde uma até várias mensagens que são endereçadas à ele, por meio de um bloco de código específico para manipulação de mensagens. Entretanto, durante a sua vida útil, um chare pode ter que lidar com mensagens do mesmo tipo de várias maneiras diferentes. Diante disso, Charm++ conta com uma função chamada de ponto de entrada, a qual contém um único tipo de mensagem e um bloco de código em C++. Isso permite que o objeto tenha um único tipo de mensagem associado à vários pontos de entrada. Este detalhe é baseado no conceito de métodos em orientação à objetos [Jyothi et al. 2004, Kalé et al. 1995]. Tendo em vista os conceitos de orientação de objetos, um chare é similar à um objeto, ou seja, proporciona encapsulamento de dados. Porém, não proporciona outros objetos como parâmetro, tal como herança e polimorfismo. Mesmo assim, vários objetos são criados a partir de uma aplicação. A união de todos estes objetos que formam um programa é chamado espaço global de objetos. Cada novo objeto que é criado ou excluído influencia este espaço, que pode mudar durante a execução [Pilla and Meneses 2015, Kalé et al. 1995]. Figura 3. Comunicação entre objetos chares Fonte: [Pilla and Meneses 2015] Outro ponto positivo proporcionado pelo C++ é a possibilidade de instanciar vários objetos da mesma classe ao mesmo tempo, utilizando um vetor de chares, que pode ter até seis dimensões. Este método facilita a comunicação entre chares devido aos índices lógicos do vetor. Um exemplo disso pode ser visto na Figura 4, que representa um vetor bidimensional S. Dessa forma, o chare S[i][j] se comunicaria com seus vizinhos S[i-1][j] e S[i][j-1] através de um Proxy. Os Proxies servem como manequins para a comunicação entre os objetos, pois eles não se enxergam diretamente [Pilla and Meneses 2015]. Segundo [Jyothi et al. 2004], Charm++ possui as seguintes categoria de objetos que fazem parte de suas entidades, além dos que já foram vistos anteriormente:

16 14 Figura 4. Exemplo de um vetor bidimensional Fonte: [Pilla and Meneses 2015] Objetos sequenciais - São os objetos da linguagem C++ e podem ser acessados apenas localmente. Não são identificados pelo sistema de execução do Charm++; Objetos concorrentes - São os chares que foram descritos anteriormente nesta Seção. chares diferem dos objetos do C++ pois eles podem ser criados assincronamente por processadores remotos; Objetos replicados - Três tipos podem ser incluídos neste item: Vetor de chares - Representa vários objetos indexados em um vetor, como visto anteriormente nesta Seção; Grupo de chares - É uma coleção de objetos onde existe um representante do grupo em cada processador. Todos os membros do grupo compartilham um mesmo nome; Nodegroup de chares - Possuem um membro do grupo em cada nó multiprocessador com memória compartilhada; Objetos compartilhados - Como Charm++ não permite o uso de variáveis globais (para manter a portabilidade entre uma grande variedade de máquinas), são utilizadas variáveis somente leitura. Estas permitem o compartilhamento de dados entre todos os objetos e podem ser acessadas de qualquer chare em qualquer processador; Mensagens - É a entidade utilizada para realizar a comunicação entre objetos compartilhados. Fornecem argumentos de dados para a invocação remota de método assíncrono; Além dos chares que executam nos processadores para resolver um problema, todo programa Charm++ possui um objeto principal chamado main chare, que representa o início da aplicação. Também é responsável por algumas funções, como a criação de outros chares, recebimento de parâmetros do usuário, coordenação das etapas de computação, além de iniciar variáveis globais somente leitura Troca de Mensagens Devidos aos chares possuírem dados privados, sua comunicação é feita por troca de mensagens explícitas através de chamadas remotas de métodos. Essa abordagem controla as informações que cada objeto tem acesso, permitindo separar os métodos privados de cada chare dos que devem ser compartilhados. Como ilustrado na Figura 3, o envio da

17 15 variável massa do objeto A para o B é feito através de um método público localizado na classe do objeto B o qual é invocado pelo objeto A. Estes métodos públicos que podem ser invocados são chamados de métodos de entrada, que podem receber mensagens com dados simples, estruturas de dados ou até mesmo nenhum dado [Pilla and Meneses 2015, Kale and Zheng 2009]. Esta troca de mensagem entre chares é feita de forma assíncrona onde um método de entrada invocado por outro chare possui retorno imediato, impedindo que o objeto que envia uma mensagem pare de executar para esperar por uma resposta. Além disso, o objeto que possui seu método chamado não pode começar a executá-lo imediatamente, pois ele deve aguardar o objeto que invocou seu método terminar de executar para que seja sua vez de entrar em execução. O benefício de utilizar uma abordagem assíncrona é que a necessidade de uma sincronização entre o emissor e o receptor é removida [Pilla and Meneses 2015]. Um dos pontos mais importantes da troca de mensagens ocorre nos vetores de chares, onde o sistema atua como mediador da comunicação entre os objetos. Em consequência disso, se um objeto for movido de um processador para outro, os outros objetos do vetor não precisam tomar consciência desta migração, como mostra a Figura 5. O sistema possui um mecanismo automático que encaminha mensagens assim que necessário, armazenando as informações de localização em cache para evitar custos desnecessários [Kale and Zheng 2009]. Figura 5. Diferentes visões da comunicação em um vetor de chares Fonte: [Kale and Zheng 2009] Modelo de Execução Charm++ possui um modelo de execução ou kernel formado pelo sistema de troca de mensagens assíncronas, particionamento da aplicação em um grande número de chares e pela migrabilidade destes objetos. Em relação às mensagens, o ambiente de execução filtra as mensagens enviadas, identifica para qual chare foi enviada e as coloca em uma fila de mensagens. Esta fila ajuda o ambiente à decidir quando um objeto será escalonado em uma unidade de processamento [Pilla and Meneses 2015].

18 16 Enquanto um chare é criado, não é necessário especificar em qual dos processadores ele será inserido. O próprio kernel do Charm++ irá decidir a localização do objeto, que provavelmente será colocado no processador menos carregado. Além disso, o modelo de execução conta com um balanceamento de cargas dinâmico, que pode migrar tanto objetos concorrentes quanto replicados para outros processadores. Para isso, uma aplicação Charm++ deve ter pelo menos um mainchare, o qual representa o chare principal que é responsável por criar os objetos vistos na Seção e coordenar a execução da aplicação [Jyothi et al. 2004]. Para realizar a comunicação entre objetos descrita na Seção , o programador define alguns métodos dos objetos C++ como métodos de entrada e os descreve em um arquivo separado cuja extensão termina em.ci. Estes arquivos são chamados de arquivos de interface o qual especifica quais funções podem ser invocadas remotamente por outro chare dentro do espaço global de objetos [Acun et al. 2014]. No ato da compilação, além dos arquivos de cabeçalho (extensão.h) e código (extensões.c ou.cpp) da linguagem C++, o compilador do Charm++ (charmc) utiliza um tradutor que faz a leitura do arquivo de interface, como mostra a Figura 6. Como resultado da leitura, são gerados dois novos arquivos, um que contém a definição (extensão.def.h) e o outro que contém a declaração (extensão.decl.h) baseado no arquivo de interface. Assim, o arquivo de declaração deve ser incluído no arquivo de cabeçalho da aplicação e o arquivo de definição deve ser inserido no arquivo que contém o código da aplicação. Estas inclusões devem ser feitas para amarrar o código da aplicação no sistema de execução do Charm++. Em seguida, o compilador charmc é utilizado novamente para gerar o arquivo de objeto (extensão.o) que faz a ligação de todos os outros arquivos. Quando o compilador finalmente cria o arquivo executável, um outro programa, denominado charmrun, deve ser utilizado para executar a aplicação. Figura 6. Processo de compilação do Charm++ Fonte: [UIUC 2015] Em relação ao particionamento da aplicação, permite reduzir o tempo que a plataforma paralela permanece ociosa, fazendo com que o sistema de execução gerencie melhor o escalonamento dos chares, pois alguns podem estar prontos para executar enquanto que outros aguardam a chamada de seus métodos. Essa característica é muito benéfica para plataformas de larga escala. Já a migrabilidade permite que o ambiente de execução mova chares que estão em processadores sobrecarregados para os que possuem pouca carga de trabalho. Para isso, conta com métodos de empacotamento e desempacotamento [Pilla and Meneses 2015]. Além disso, possibilita tolerância à falhas através de uma técnica denominada checkpointing, onde é tirado um screenshot do estado atual do ambiente permitindo que

19 17 o sistema retorne à este ponto caso ocorra alguma falha. Estas características tornam o sistema de execução maduro e otimizado que pode ser utilizado em diferentes plataformas [Pilla and Meneses 2015] Avaliação do Charm++ para Sistemas Multiprocessadores Charm++ é uma grande ferramenta, a qual permite criar uma série de algoritmos para corrigir os problemas das aplicações paralelas. Também permite desenvolver aplicações científicas complexas, como o NAMD [Nelson et al. 1996]. Por isso, os resultados de diversos trabalhos realizados em cima deste modelo por si próprios já o avaliam como sendo adequados para sistemas multiprocessadores. Mesmo assim, vale ressaltar o trabalho de [Pilla et al. 2011], o qual apresenta uma avaliação da adequação do Charm++ para arquiteturas multicore com memória hierárquica. Segundo os autores, o mecanismo de comunicação do Charm++ não migra os dados no primeiro nó NUMA que os acessa, acarretando em um posicionamento de dados ruim nas aplicações construídas com este modelo. Assim, é importante avaliar o impacto destas decisões no desempenho final de máquinas NUMA. Para isso, os autores utilizaram duas máquinas para realizar os experimentos, sendo que a primeira possuía oito processadores AMD Opteron dual-cores onde cada núcleo possuía caches L1 e L2 privadas, e a segunda com quatro processadores Intel Xeon X7560 octa-cores onde cada núcleo possuía caches L1 e L2 privadas com adição de uma terceira cache L3 compartilhada no processador. A versão do Charm++ utilizada foi a 6.2.1, junto com três benchmarks disponibilizados por ele para avaliar os testes. Para máquinas NUMA, o modelo permite a utilização de duas versões de comunicação: uma baseada na troca de datagramas UDP e outra via troca de ponteiros. O resultado obtido pelos autores utilizando o benchmarks jacobi2d avaliou a execução de 100 chares com estes dois tipos de comunicação. Estes resultados mostram que quanto maior o número de núcleos, menor o tempo de iterações, o que representa característica de escalabilidade. Outro resultado obtido de um teste semelhante, o qual consiste em um experimento utilizando 200 chares e o benchmark kneighbor que contava com três vizinhos comunicantes. O tempo de iteração é reduzido para a memória compartilhada à medida que o número de núcleos aumenta. No entanto, com o UDP ocorre uma oscilação, onde o tempo de iteração começa a aumentar, atinge seu máximo com 8 núcleos e entra em declínio quando o número de núcleos passa para 16. Esta redução ocorre em função do aumento de vias de comunicação e da divisão da carga de trabalho. Estes fatores não ocorrem porque existe um grande número de núcleos acessando o mesmo banco de memória, já que as máquinas NUMA32 possuem oito núcleos por nó enquanto que as NUMA16 possuem apenas dois. Diante disso, os autores constatam que utilizar diferentes tipos de comunicação não causam grande impacto para aplicações com computação intensiva. A diferença está nas aplicações que realizam muitas comunicações entre os cluster de máquinas NUMA. Para estas, seria necessário implementar um esquema híbrido de comunicação, onde o UPD seria utilizado para a comunicação entre as máquinas e a comunicação por memória compartilhada seria usada internamente à ma-

20 18 quina NUMA. Este último teste expõe o problema do múltiplo acesso à memória, que pode prejudicar a escalabilidade das aplicações. Uma solução para isso seria garantir um acesso eficiente à memória utilizando uma técnica auxiliar como, por exemplo, o balanceamento de carga. Diante disso, os autores realizaram um experimento com alguns BCs disponibilizados pelo Charm++: GreedyLB, MetisLB e ScotchLB. O GreedyLB distribui os chares conforme o algoritmo guloso, procurando a cada iteração o chare que com o maior tempo de execução e movendo este para a unidade de processamento que possui a menor carga de trabalho. Este BC apresenta um bom desempenho por ser simples e rápido, já que não considera a comunicação entre os objetos. Os outros dois BCs são baseados em estratégias específicas que consideram os tempos de execução e grafo de comunicação para otimizar as aplicações [Pilla et al. 2011]. Os autores obtiveram mais resultados através da utilização dos benchmarks lb test e jacobi2d fornecidos pelo Charm++. Para o primeiro benchmark, foram utilizados 200 chares com tempo mínimo e máximo de computação de 50 e 200ms e um grafo de comunicação aleatório. O resultado disto mostra que o uso de BCs leva a melhoras para as duas máquinas. Porém, os BCs voltados para grafos de comunicação levaram vantagem. Já o segundo benchmark constatou que os BCs obtiveram uma eficiência de aproximadamente 90% devido à redução das comunicações externas aos núcleos. Este número só não foi maior porque os BCs não tinham conhecimento da hierarquia do cache e da memória das máquinas. Outro problema refere-se à quantidade média de migrações realizadas pelos BCs, que varia de 92 à 98% pois o mapeamento inicial dos chares não é considerado. Por isso os autores consideraram necessário avaliar o impacto que estas migrações causam nas aplicações, uma vez que elas resultam em cópias de memória através de nós NUMA. Finalmente, para aumentar o desempenho de uma aplicação Charm++ em sistemas multiprocessadores, não basta apenas escolher o melhor tipo de comunicação ou melhorar a afinidade de memória, também é necessário utilizar BCs que conheçam a arquitetura da máquina, considerem o mapeamento inicial dos chares e evitem migrações excessivas para ser possível obter uma eficiência maior que 90% Balanceadores de Carga Devido ao fato do sistema de execução do Charm++ migrar os chares, existe a possibilidade de realizar um balanceamento de carga. Durante a execução de uma aplicação criada a partir deste modelo, é realizado um balanceamento de carga dinâmico, onde os chares são migrados dos processadores sobrecarregados para os que possuem uma carga menor [Zheng et al. 2006]. O framework de balanceamento de carga do Charm++ executa em background e é encarregado de coletar informações da carga de trabalho e da comunicação dos objetos em cada unidade de processamento. Após a coleta, ele faz uso destas informações para equilibrar a carga de trabalho entre os processadores. Para isso, ele conta com diversos BCs que utilizam estratégias

21 19 sofisticadas para otimizar o balanceamento. O processo de migração de objetos precisa ser feito por outro framework, chamado de PUP (Pack-and-UnPack), que empacota o objeto e o insere em um buffer serializado para que este possa ser desempacotado posteriormente [Zheng et al. 2006]. As estratégias de balanceamento de carga do Charm++ baseiam-se em uma heurística conhecida como princípio da persistência, onde a carga de certas aplicações tendem a persistir com o tempo. Isso resultou no desenvolvimento de novas estratégias mensuráveis, que utilizam as informações do passado para chegar à um futuro próximo [Zheng et al. 2010]. Estratégias mensuráveis armazenam informações da carga de cada objeto em um tipo de banco de dados em cada processador. Este banco de dados é acessado várias vezes durante a execução, onde verifica-se a existência de um desbalanceamento de carga. Dessa forma, é possível obter informações das cargas através de um método automático e independente. Charm++ ainda apresenta três variações desta estratégia, conforme [Zheng et al. 2010]: Centralizada: Toda a estrutura de carga da máquina fica em um único processador, seguido de um processo de tomada de decisão que vai determinar a nova distribuição dos objetos Charm++. Costuma ser a melhor abordagem para computadores que não possuam tantos processadores; Distribuída: A carga é trocada somente com processadores vizinhos, o que torna esta abordagem totalmente escalável. No entanto, podem produzir um balanceamento de carga ruim devido à uma possível falta de informações em grandes máquinas; Hierárquica: Processadores são divididos em vários grupos independentes e autônomos, organizados em diferentes hierarquias. Várias estratégias podem ser usadas para balancear as cargas tanto dos processadores dentro dos grupos quanto os de todos os grupos de forma hierárquica. Com base nestas variações, a mais adequada para o cenário atual é a hierárquica, pois não apresenta problemas com um grande número de processadores. Este detalhe é ressaltado nos trabalhos de [Pilla et al. 2012] e [Zheng et al. 2010], onde são propostos dois BCs hierárquicos. O primeiro, denominado NucoLB (Non-Uniform COmmunication costs Load Balancer), foi desenvolvido para sistemas multiprocessadores que apresentam acesso não-uniforme à memória (NUMA). Este BC objetiva maximizar o uso dos cores, para evitar que fiquem ociosos, e minimizar os custos de comunicação pela aplicação. Isso é feito através de uma heurística que combina informações da topologia NUMA e da aplicação para reduzir o desbalanceamento de aplicações paralelas. Demais informações são obtidas através do framework disponibilizado pelo Charm++, uma vez que o NucoLB foi construído em cima desta plataforma. Possui um algoritmo de escalonamento do tipo greedy, que escalona a tarefa com maior tempo de execução no processador que possui o menor custo a cada iteração. Estas tarefas são consideradas os chares de Charm++. Para realizar os testes, foram utilizadas três plataformas multi-core com diferentes características NUMA. Os resultados obtidos pelos autores mostram que o BC proposto realmente aprimora a performance das aplicações Charm++, onde os speedups estão 1.19 acima dos BCs existentes. Este número foi obtido através da baixa taxa de tarefas migradas, que

22 20 foi 11 vezes menor que os demais balanceadores. Assim, o BC proposto pelos autores de [Pilla et al. 2012] cumpriu seu objetivo, reduzindo a latência em 4% e a comunicação em 6% devido à distribuição da carga sobre os cores e mantendo a comunicação entre os chares próximos. Já o segundo BC [Zheng et al. 2010] procura dividir os processadores em grupos independentes e autônomos, baseado na organização de uma árvore binária com vários níveis. A estratégia é utilizar uma abordagem de árvore top down de três níveis junto com um token, como pode ser visto na Figura 7. Cada nível da árvore é composto por grupos de processadores, onde o nó raiz representa o líder do grupo. O token representa os objetos sendo migrados de um grupo para o outro. Assim, os autores utilizaram um algoritmo de BC do tipo greedy no primeiro nível e outro algoritmo de BC baseado em refinamento no segundo nível. Figura 7. Modelo da estratégia em árvore de três níveis baseada em um token Fonte: [Zheng et al. 2010] O resultado obtido pelo BC hierárquico (HybridLB), em relação ao uso de memória, mostra que este tipo de abordagem utiliza menos memória, se comparado com os BCs centralizados. Outro fator é que quanto mais processadores são adicionados aos grupos, menor é o uso da memória, ao contrário da abordagem centralizada. O speedup adquirido por este BC foi de 6.2 com cores e 145 com cores. Dessa forma, o tempo para o algoritmo realizar o balanceamento de carga também foi reduzido. Estes resultados comprovam que uma estratégia hierárquica, que utiliza mais de um BC para equilibrar as cargas dos grupos de processadores, é muito mais eficiente para supercomputadores. Além do desbalanceamento de carga, outro grande problema dos sistemas HPCs é o grande consumo de energia. As pesquisas atuais se mostram preocupadas com este fator, como pode ser visto na Green500 [Feng and Cameron 2007], uma lista semelhante à do Top500 [Dongarra et al. 1994], mas que mostra os supercomputadores que fazem uso da computação sustentável. Um trabalho relacionado à redução do consumo de energia é o de [Padoin et al. 2014]. Este descreve um balanceador de carga (BC) que usa a demanda de potência e o consumo de energia na tomada de decisões, baseado no modelo de programação Charm++. Utilizando informações do sistema e do próprio modelo, o balanceador possui uma estratégia centralizada que consiste em atualizar a frequência de cada core do pro-

23 21 cessador. Com base na carga de cada unidade de processamento, a demanda de potência média é reduzida e o resultado é a diminuição de energia utilizada. Para realizar este trabalho, o autor utilizou um equipamento com 24 processadores, devido aos diferentes níveis de frequência, que permite realizar uma grande quantidade de testes. Também foram selecionados benchmarks oferecidos pelo próprio modelo e diferentes BCs. O resultado que o autor obteve mostra que ajustar a frequência das unidades de processamento proporciona uma economia de energia significativa. Outro trabalho que pode ser destacado é o de [Hsiang and Sato 1993], que propõe uma nova técnica, denominada auto-escalonamento uniforme, para balanceamento de carga em sistemas multiprocessadores. O objetivo é resolver alguns problemas referentes à restrição dos programas paralelos que foram balanceados pelo auto-escalonamento normal (não uniforme). Primeiramente, é feito um comparativo entre os esquemas de auto-escalonamento normal, uniforme sem prioridade e uniforme com prioridade. Em seguida, o autor realiza testes de desempenho entre os três modelos e analisa os resultados obtidos. Diante disso, observou-se uma melhoria no balanceamento de carga dos processadores utilizando a técnica proposta. Essa melhoria é decorrente do paralelismo aninhado e dos compiladores paralelos oferecidos pelo auto-escalonamento uniforme Migrabilidade e o Framework PUP Como visto anteriormente, Charm++ permite que objetos concorrentes sejam migrados de um processador para outro. Para uma aplicação tornar um chare migrável, o programador deve utilizar o método de empacotamento e desempacotamento de mensagens, ou Pack and UnPack (PUP) em inglês. Neste método, todo o objeto é serializado a partir de um stream de bytes fornecido pelo sistema de execução. Como mostra a Figura 8, este processo têm se tornado conveniente pelo Charm++ através da utilização do operador pipe tanto para os tipos de dados quanto para as classes [Zheng et al. 2006, Jyothi et al. 2004]. Figura 8. Exemplo do funcionamento do método PUP Fonte: [Acun et al. 2014] O método PUP leva apenas um parâmetro, o qual refere-se à uma instância da classe PUP::er. A sua função é obter o estado do objeto. A classe pupper executa as operações de empacotamento, desempacotamento, escrita no disco e conversão para uma forma interpretável sobre os dados do objeto. Quando a mensagem contento o estado do objeto é recebida pelo novo processador, uma nova instância da classe é criada através da chamada de um construtor de migrações. Sua tarefa é simplesmente criar uma instância não-inicializada da classe. Então, o método de desempacotamento é invocado contendo os ponteiros para a mensagem e para o novo objeto migrado. Assim, o método

24 22 apenas extrai os dados do objeto empacotado, criando um novo objeto no novo processador [Acun et al. 2014, Jyothi et al. 2004] Tolerância a Falhas A grande maioria das aplicações paralelas envolvem grandes softwares de simulação, previsão do tempo, dinâmica molecular, entre outros. Devido à esta grande proporção e alto poder de processamento, uma máquina que suporta estas aplicações deve ficar em constante funcionamento a fim de obter um ótimo resultado no menor espaço de tempo possível. Por conta disso, caso uma falha ocorra durante o processamento, toda a computação feita por ela será perdida. No intuito de evitar este desperdício de computação e tempo, Charm++ apresenta um protocolo de tolerância a falhas baseado na técnica de checkpoint e restart [Acun et al. 2014]. O programador especifica no código da aplicação o intervalo de tempo em que o método de checkpoint será chamado. Este, por sua vez, salva o estado da computação e grava-o em um arquivo no disco. Caso aconteça de alguns processadores falhar, toda a aplicação é reiniciada pelo método restart e retorna para o último estado salvo pelo método de checkpoint. Uma vez que o código do Charm++ é independente da localização física dos chares, a aplicação pode ser reiniciada em um número diferente de processadores que estava rodando antes. Esta abordagem permite uma grande flexibilidade para o escalonador de uma grande máquina no momento me que a falha ocorre [Kale and Zheng 2009].

25 23 3. Balanceador de Carga AverageLB A grande motivação para criar algoritmos para corrigir o desbalanceamento de carga vem do fato de que o problema do balanceamento de cargas é do tipo NP-Completo [Leung 2004]. Diante disso, o algoritmo do AverageLB foi construído baseado na estratégia definida na Seção A técnica de migração de chares presente neste algoritmo é uma adaptação da estratégia gulosa, pois é a média aritmética da carga de cada processador quem decide quais objetos devem ser migrados. Isso evita migrações desnecessárias. A escolha desta técnica é baseada na ideia de atingir o estado de equilíbrio dos processadores rapidamente, sem partir diretamente para os chares mais carregados. O uso de uma média para controlar as migrações colabora para um balanceamento de carga mais preciso, pois a migração de tarefas é um processo caro. Combinando uma segunda média aritmética com a estratégia de controle de migrações, o número de objetos migrados e o tempo que o algoritmo leva para realizar o balanceamento são bem pequenos. Se o objetivo é atingir o equilíbrio entre as cargas, a média aritmética é totalmente compatível Metodologia de Implementação Nesta Seção, será apresentado o balanceador de carga proposto, sua estratégia, objetivos e demais detalhes que justifiquem seu desenvolvimento. Também será discutida a abordagem centralizada a qual serve como base para a sua execução. Por último, haverá uma comparação entre o BC proposto e os BCs disponibilizados pelo Charm Balanceamento de Carga Centralizado O BC proposto foi desenvolvido utilizando o framework de balanceamento de cargas disponibilizado pelo Charm++. Possui uma abordagem centralizada, o que significa que a estrutura de cargas e de comunicação da máquina, além de um processo de tomada de decisão, ficam armazenadas em um único ponto. A escolha de uma abordagem centralizada se deu pelo fato desta realizar um balanceamento mais preciso em relação às outras abordagens. Apesar de trabalhar muito bem com alguns milhares de processadores, pode enfrentar problemas de escalabilidade principalmente em máquinas paralelas com pouca memória. Durante o processo de execução, o BC coleta dados dos processadores e da aplicação e os armazena em um banco de dados de balanceamento de cargas. Dentre estas informações, destacam-se o número total de objetos, a carga total de cada processador, a carga de cada objeto e o número total de processadores. A ideia deste BC é utilizar estas informações para criar duas variáveis que vão conter médias aritméticas. Estas serão usadas para controlar quais chares devem ser migrados e qual valor cada processador deve ter para estar em equilíbrio. Devido à esta técnica de equilíbrio de cargas através de médias, o BC proposto foi chamado de AverageLB. Foi criado para se adaptar melhor com a tarefa de equilibrar cargas de processadores sem precisar utilizar dois ou mais BCs diferentes para isso. A próxima Seção descreve como funciona a estratégia deste balanceador.

26 Detalhes da Estratégia Para que o tempo de execução dos processadores fossem equilibrados, foi utilizada uma estratégia baseada na média aritmética de suas cargas. Primeiramente, o algoritmo extrai a quantidade de objetos e o total de carga de cada processador. Neste ponto, já é possível perceber que estas duas variáveis são desproporcionais devido ao modo como os objetos são distribuídos pelas aplicações. O próximo passo é calcular a carga média por processador (CMP), que é feito dividindo o somatório das cargas de cada objeto pelo número total de objetos de cada processador, como mostra a seguinte equação: CMP = Σ cargas n objetos Esta variável é usada para fazer o controle de quais objetos devem ser migrados de um processador para outro, onde os objetos que possuem uma carga maior que a média são migrados, enquanto que os demais permanecem executando em seu processador de origem. Em seguida, é calculada a média aritmética geral (MAG), que servirá como limitante para equilibrar as cargas dos processadores. Para efetuar este cálculo, é feito a soma da carga de cada processador e o resultado é dividido pelo número de processadores, conforme a equação abaixo: MAG = carga total processadores n processadores Com estas duas variáveis definidas o BC começa o processo de equilíbrio das cargas, que é ilustrado na Figura 9. A imagem apresenta dois processadores, X e Y, que foram selecionados pelo BC através de um método. Este método é responsável por mapear as unidades de processamento e selecionar a primeira que se encontra abaixo da MAG, que neste caso é representado por Y. Já o X representa o primeiro processador que está acima da MAG. Figura 9. Processo de equilíbrio de cargas executado pelo BC proposto Após esta seleção, o BC mapeia os chares do processador X a fim de identificar aqueles que se encontram acima do seu CMP. Uma vez identificados, inicia-se um processo de migração que moverá os chares do processador X para o Y até que a carga

27 25 de Y possua um valor próximo à MAG. Quando isso acontecer, o BC busca o próximo processador Y abaixo da média geral. O mesmo vale para o processador X. Figura 10. Cargas dos processadores com valor próximo à MAG A partir do momento que a carga de um processador está equilibrada, este não pode ser mapeado novamente pelo método descrito anteriormente. Esta restrição evita que o BC trabalhe desnecessariamente, além da redundância que poderia acarretar em um balanceamento de carga incompleto. Desenvolver algoritmos com técnicas eficientes é muito importante para evitar que o próprio balanceador se torne um gargalo para a performance. Dessa forma, a otimização gerada por um balanceamento de carga eficiente não pode ser ofuscada pelo alto custo do próprio processo de balanceamento. O processo de balanceamento é encerrado quando não existe mais processadores a serem mapeados e as cargas de todas as unidades de processamento possuem um valor próximo à MAG, como mostra a Figura 10. Mesmo que o número de chares entre X e Y seja diferente, o que realmente importa é o valor total da carga destes objetos Algoritmo do AverageLB O algoritmo do AverangeLB é apresentado na Tabela 2 a qual demonstra o caminho tomado pelo balanceador para chegar ao equilíbrio das cargas. Tabela 1. Principais parâmetros utilizadas pelo AverangeLB Parâmetro M P M O CMP MAG t k o migrarobj(o, k, t) verificacarga(t) verificacarga(k) Definição Mapeamento dos Processadores Mapeamento dos Chares Carga média por processador Média aritmética geral Processador Menor que a MAG Processador Maior que a MAG Chare avulso Migrar chare o de k para t Verifica se a carga de t continua abaixo da média Verifica se a carga de k continua acima da média A cada iteração, o algoritmo realiza um mapeamento dos processadores M P e dos chares em execução M O. Em seguida, são identificados dois processadores dentro

28 26 do mapeamento correspondente, o primeiro t que está abaixo da Média Aritmética Geral (MAG) e o segundo k que está acima desta mesma média. A partir daí, o algoritmo analisa os chares que estão executando no processador k e começa a migrar aqueles que possuem uma carga maior que a Carga Média do Processador (CMP ). Tabela 2. Algoritmo do AverangeLB Algoritmo 1: AverangeLB 1 while M P { 2 t M P < MAG 3 k M P > MAG 4 o M O o M k 5 if cargaobj(o) > CM P 6 migrarobj(o, k, t) 7 if verif icacarga(k) = false 8 M P k 9 if verif icacarga(t) = false 10 M P t 11 } Através do método verif icacarga(), o algoritmo verifica as cargas dos processadores t e k para que seus valores não ultrapassem a média. Quando o valor de um deles estiver próximo à MAG, este é retirado do mapeamento e um novo processador é buscado, repetindo o processo até que todas as cargas estejam em equilíbrio. A Tabela 1 sumariza os principais parâmetros que o BC utiliza. Quanto maior o número de processadores que a máquina possui, maior o tempo de execução do algoritmo. Por isso, o uso de um balanceador de carga que utiliza uma abordagem centralizada é recomendado para sistemas paralelos que possuem uma quantidade satisfatória de memória, mas que não possuam centenas de milhares de processadores. Para esta última variável, recomenda-se uma abordagem hierárquica.

29 27 4. Resultados Nesta Seção, são apresentados os detalhes da máquina utilizada, os resultados obtidos pelo balanceador proposto e uma comparação do BC proposto com os BCs disponibilizados pelo Charm Definição do Hardware Utilizado A plataforma em que o balanceador proposto foi executado contém um processador octa-core Intel Core i7 3830QM e um total de 8 GB de memória RAM. Nesta máquina, foram instalados o sistema operacional Fedora 21 Linux cuja versão do kernel é fc21.x86 64, a versão do modelo de programação paralela Charm++, a versão do compilador gcc para a linguagem C++ e um editor de código para realizar a implementação do algoritmo Análise de Desempenho Charm++ possui diversos balanceadores de carga com diferentes estratégias que trabalham tanto com as cargas das unidades de processamento quanto a comunicação entre os chares, conforme mostrado na Seção 2.3. Dentre estes balanceadores, o GreedyLB e o RefineLB foram utilizados a fim de comparar seus tempos de execução com o AverageLB. Na plataforma descrita na Seção 4.1, foi utilizado o benchmark lb test por se tratar de uma ferramenta bastante utilizada para avaliar balanceadores de carga, além de ser disponibilizada pelo próprio Charm++. Com ela, os três balanceadores foram submetidos à dez simulações consecutivas utilizando 100 chares, 150 iterações feitas por cada tarefa e a sincronização do balanceador de carga definido à cada 10 iterações. A Figura 11 mostra o gráfico resultante desta simulação, que apresenta o tempo médio de execução entre eles. Figura 11. Comparação do tempo médio de execução entre diferentes balanceadores de carga para o benchmark lb test Ao observar esta imagem, é possível identificar que o tempo médio de execução de cada BC é equivalente, pois todos levaram mais de 7 segundos para executar. O que muda entre os tempos é o valor em milissegundos que é maior para o GreedyLB e menor para o RefineLB. O cálculo do tempo total de execução de cada balanceador é feito através do somatório do tempo de cada passo que o BC executa dentro do benchmark. Diante disso, foram extraídos os tempos de cada passo realizado por cada um dos balanceadores

30 28 Figura 12. Comparação entre o tempo que cada BC levou para executar cada passo do benchmark lb test avaliados. Na Figura 12 é possível perceber a equivalência entre os valores de tempo. Isso mostra um desempenho equilibrado para os três BCs dentro do benchmark lb test. Além do lb test, foi utilizado um segundo benchmark, denominado Stencil3D para analisar o desempenho dos balanceadores. Esta análise ocorreu através de um teste que utiliza uma matriz de três dimensões onde é feita a comunicação entre cada um dos seus vizinhos. Foram analisados os tempos médios de execução e de cada passo que cada balanceador efetuou a fim de comparar com os resultados do lb test. Na Figura 13 é possível ver que neste benchmark, o AverageLB obteve um desempenho minimamente superior pois seu tempo médio de execução é menor que o dos outros balanceadores. Figura 13. Comparação do tempo médio de execução entre diferentes balanceadores de carga para o benchmark Stencil3D Já a Figura 14 mostra o motivo pelo qual o AverageLB se saiu melhor que os demais algoritmos. Ao analisar esta imagem, percebe-se que o BC proposto neste trabalho conseguiu executar quase todos os passos mais rápido que os demais, resultando em seu desempenho superior. O principal detalhe que influencia no tempo de execução de cada passo é a quantidade de objetos que são migrados de um processador para o outro, pois é uma tarefa bastante custosa. A Seção 4.3 apresenta uma análise desta variável que mostra o quanto ela infuencia no desempenho e no tempo de execução de cada balanceador.

31 29 Figura 14. Comparação entre o tempo que cada BC levou para executar cada passo do benchmark lb test 4.3. Análise de Objetos Migrados A partir dos resultados anteriores foi realizada uma simulação com os mesmos balanceadores nas mesmas ferramentas, comparando o total de objetos que cada algoritmo migrou de um processador para outro. Em relação ao benchmark lb test, a Figura 15 mostra que o GreedyLB realiza um imenso número de migrações. Isso é consequência da estratégia gulosa que migra objetos do processador mais carregado para o menos carregado. Já os dois outros dois balanceadores comparados apresentam números bem próximos pelo fato de possuírem um limitante para controlar a quantidade de objetos migrados. Isso mostra que as médias aritméticas calculadas pelo AverageLB possuem um papel fundamental para evitar migrações desnecessárias. Figura 15. Comparação do total de migrações realizadas por diferentes balanceadores de carga para o benchmark lb test No segundo benchmark, a quantidade de migrações foi bem menor se comparado com o primeiro. Isso ocorreu porque nesta ferramenta, as cargas entre os processadores já possuem um equilíbrio maior. Porém, tanto o GreedyLB quanto o RefineLB realizaram

32 30 migrações equivalentes, por volta de uma migração por cada passo. Já o AverageLB efetuou menos que 60% das migrações, conforme ilustrado na Figura 16. A média aritmética que representa a carga média por processador (CMP) do AverageLB foi a grande responsável por limitar o número de migrações. Figura 16. Comparação do total de migrações realizadas por diferentes balanceadores de carga para o benchmark Stencil3D