UNIVERSIDADE REGIONAL DO NOROESTE DO ESTADO DO
RIO GRANDE DO SUL
DCEEng
DEPARTAMENTO DE CI ˆ
ENCIAS EXATAS E ENGENHARIAS
CURSO DE GRADUAC
¸ ˜
AO EM CI ˆ
ENCIA DA COMPUTAC
¸ ˜
AO
BALANCEAMENTO DE CARGA EM SISTEMAS
MULTIPROCESSADORES UTILIZANDO O MODELO DE
PROGRAMAC
¸ ˜
AO CHARM++
Guilherme Henrique Schiefelbein Arruda
Santa Rosa - RS
2015
BALANCEAMENTO DE CARGA EM SISTEMAS
MULTIPROCESSADORES UTILIZANDO O MODELO DE
PROGRAMAC
¸ ˜
AO CHARM++
Projeto apresentado na disciplina de Tra-balho de Conclus˜ao de Curso do curso de Ciˆencia da Computac¸˜ao da Universidade do Noroeste do Estado do RS como requisito b´asico para apresentac¸˜ao do Trabalho de Conclus˜ao de Curso.
Orientador: Edson Luiz Padoin Banca: Rog´erio Samuel de Moura Martins
Santa Rosa - RS
2015
Sum´ario
Lista de Figuras 3 Lista de Tabelas 3 Lista de abreviaturas 4 1 Introduc¸˜ao 6 1.1 Contexto . . . 6 1.2 Problema . . . 6 1.3 Definic¸˜ao da Proposta . . . 7 1.4 Organizac¸˜ao do Trabalho . . . 7 2 Estado da Arte 8 2.1 Irregularidades nas Aplicac¸˜oes Paralelas . . . 82.2 Balanceamento de Carga . . . 8
2.3 Ambientes de Programac¸˜ao e Balanceadores de Carga . . . 9
2.3.1 Charm++ . . . 12
2.3.1.1 Entidades de Charm++ . . . 13
2.3.1.2 Troca de Mensagens . . . 14
2.3.1.3 Modelo de Execuc¸˜ao . . . 15
2.3.1.4 Avaliac¸˜ao do Charm++ para Sistemas Multiprocessadores 17 2.3.1.5 Balanceadores de Carga . . . 18
2.3.1.6 Migrabilidade e o Framework PUP . . . 21
2.3.1.7 Tolerˆancia a Falhas . . . 22
3 Balanceador de Carga AverageLB 23 3.1 Metodologia de Implementac¸˜ao . . . 23
3.1.1 Balanceamento de Carga Centralizado . . . 23
3.1.2 Detalhes da Estrat´egia . . . 24
3.2 Algoritmo do AverageLB . . . 25
4 Resultados 27 4.1 Definic¸˜ao do Hardware Utilizado . . . 27
4.3 An´alise de Objetos Migrados . . . 29
5 Conclus˜ao 31
Lista de Figuras
1 Elementos do framework de um balanceador de carga . . . 9
2 Diferentes vis˜oes entre os m´etodos da decomposic¸˜ao de um problema . . 12
3 Comunicac¸˜ao entre objetos chares . . . 13
4 Exemplo de um vetor bidimensional . . . 14
5 Diferentes vis˜oes da comunicac¸˜ao em um vetor de chares . . . 15
6 Processo de compilac¸˜ao do Charm++ . . . 16
7 Modelo da estrat´egia em ´arvore de trˆes n´ıveis baseada em um token . . . 20
8 Exemplo do funcionamento do m´etodo PUP . . . 21
9 Processo de equil´ıbrio de cargas executado pelo BC proposto . . . 24
10 Cargas dos processadores com valor pr´oximo `a MAG . . . 25
11 Comparac¸˜ao do tempo m´edio de execuc¸˜ao entre diferentes balanceadores de carga para o benchmark lb test . . . 27
12 Comparac¸˜ao entre o tempo que cada BC levou para executar cada passo do benchmark lb test . . . 28
13 Comparac¸˜ao do tempo m´edio de execuc¸˜ao entre diferentes balanceadores de carga para o benchmark Stencil3D . . . 28
14 Comparac¸˜ao entre o tempo que cada BC levou para executar cada passo do benchmark lb test . . . 29
15 Comparac¸˜ao do total de migrac¸˜oes realizadas por diferentes balanceado-res de carga para o benchmark lb test . . . 29
16 Comparac¸˜ao do total de migrac¸˜oes realizadas por diferentes balanceado-res de carga para o benchmark Stencil3D . . . 30
Lista de Tabelas
1 Principais parˆametros utilizadas pelo AverangeLB . . . 25Lista de abreviaturas
AMPI Adaptive Message Passing Interface API Interface de Programac¸˜ao de Aplicativo BC Balanceador de Carga
CAD Computac¸˜ao de Alto Desempenho CMP Carga M´edia por Processador FEM M´etodo Finito de Elementos HPC High Performance Computing MAG M´edia Aritm´etica Geral
MIMD Multiple Instructions Multiple Data MPI Message Passing Interface
NAMD Nanoscale Molecular Dynamics NUMA Acesso N˜ao-Uniforme `a Mem´oria PObC++ Parallel Object C++
PUP Pack and Unpack
PVM M´aquina Virtual Paralela RMI Invocac¸˜ao Remota de M´etodo UDP User Datagram Protocol
Agradecimentos
Agradec¸o a Deus, `a minha esposa, meus pais, irm˜aos, amigos e familiares pela presenc¸a, apoio, incentivo, companheirismo, motivac¸˜ao e por toda a confianc¸a que de-positaram em mim. Agradec¸o aos meus professores, `a Universidade Regional do Noro-este do Estado do Rio Grande do Sul pelo apoio, pelos ensinamentos te´oricos, pr´aticos e formac¸˜ao acadˆemica.
Agradec¸o especialmente ao meu orientador, professor Dr. Edson Luiz Padoin, que me orientou no desenvolvimento deste trabalho com muita competˆencia, empenho, gene-rosidade e paciˆencia. Agradec¸o tamb´em ao membro da banca, professor Rog´erio Samuel de Moura Martins, que me apoiou e incentivou muito durante a graduac¸˜ao. Agradec¸o aos meus colegas que estiveram ao meu lado durante a graduac¸˜ao.
Guilherme Henrique Schiefelbein Arruda
1. Introduc¸˜ao
1.1. Contexto`
A medida que a produc¸˜ao de software avanc¸a, ocorre um crescimento da de-manda por processamento computacional. A necessidade de alto desempenho fez com que sistemas computacionais fossem desenvolvidos para suprir esta necessidade. Desde a d´ecada de 40, onde os computadores eram dif´ıceis de programar devido `as limitac¸˜oes tecnol´ogicas da ´epoca, a necessidade de um recurso mais eficiente e simples de manipular as instruc¸˜oes destas m´aquinas j´a era desejado. A falta de uma linguagem de programac¸˜ao de alto n´ıvel resultava em programas desenvolvidos em linguagem de m´aquina, tornando sua interpretac¸˜ao e depurac¸˜ao praticamente imposs´ıvel [Baranauskas 1993].
A partir do momento em que o hardware comec¸ou a evoluir, foi poss´ıvel criar linguagens de programac¸˜ao de paradigma procedural. Este era o que melhor se adequava ao uso da arquitetura de Von Neumann como soluc¸˜ao de um problema que a pr´opria m´aquina resolvia. Uma destas linguagens, que ainda ´e utilizada nos dias atuais, ´e o C [Kernighan et al. 1988]. Desde ent˜ao, a criac¸˜ao de programas ficou muito mais f´acil uma vez que o programador escrevia uma s´erie de procedimentos para a m´aquina executar [Baranauskas 1993].
Por´em, as linguagens estruturais ainda possu´ıam muitas limitac¸˜oes. O desejo de criar algo diferente j´a estava presente. A ideia de orientac¸˜ao a objetos podia ser identifi-cada nas structs, um tipo de vari´avel especial da linguagem C que cont´em outras vari´aveis de tipos diferentes [Kernighan et al. 1988]. Assim, a orientac¸˜ao a objetos permitia par-ticionar o projeto de um programa em diversos m´odulos. Isso facilitava o desenvolvi-mento do software e reduzia seu custo de manutenc¸˜ao, al´em de permitir o reuso de c´odigo [Gudwin 1997].
Um dos componentes de hardware que apresentou uma grande evoluc¸˜ao foi o processador. Este deixou de ser single core e passou a contar com v´arios n´ucleos, propor-cionando a execuc¸˜ao simultˆanea de diversas aplicac¸˜oes. Com isso, foi poss´ıvel construir computadores pessoais, sistemas embarcados e at´e supercomputadores. Isso abriu as por-tas para a programac¸˜ao paralela, pois possibilitou que as aplicac¸˜oes fossem divididas em partes e inseridas nos n´ucleos das unidades de processamento [Pilla and Meneses 2015].
1.2. Problema
A modelagem de um problema complexo pode trazer alguns problemas, como o desbalanceamento de carga e excessiva comunicac¸˜ao entre tarefas [Padoin et al. 2014]. Estes s˜ao dois dos principais fatores que comprometem o desempenho do processador. A ausˆencia da ferramenta adequada para equilibrar as cargas implica na sobrecarga de alguns n´ucleos. Dessa maneira, algumas unidades de processamento trabalham muito mais que as outras. O resultado disso ´e que as aplicac¸˜oes levam mais tempo para executar, al´em de elevar a temperatura e o consumo de energia. A uni˜ao destes problemas impede que todo o potencial do processador seja aproveitado.
Desde ent˜ao, diversos programas paralelos s˜ao constru´ıdos para que seja poss´ıvel utilizar todo o potencial dos sistemas computacionais atuais. Infelizmente, a programac¸˜ao paralela ainda ´e dif´ıcil de aplicar em plataformas de desenvolvimento. ´E poss´ıvel utili-zar algumas interfaces de programac¸˜ao de aplicativos (APIs) espec´ıficos para desenvol-ver programas paralelos, facilitando esse trabalho para aplicac¸˜oes regulares e ambientes
homogˆeneos [Pilla and Meneses 2015]. Como exemplo destas ferramentas pode-se ci-tar o OpenMP [Chandra 2001] e o MPI [Dongarra et al. 1996]. Por´em, utiliz´a-las em aplicac¸˜oes dinˆamicas ou ambientes vari´aveis pode acarretar em perda de desempenho [Pilla and Meneses 2015].
Embora exista a proposta de um novo BC para reduc¸˜ao do consumo de energia [Padoin et al. 2014] e uma avaliac¸˜ao de adequac¸˜ao da plataforma Charm++ [Pilla et al. 2011], estas n˜ao visam equilibrar o tempo de execuc¸˜ao dos processadores. Isso pode reduzir o desempenho do sistema, al´em de permitir que um processador trabalhe mais do que o outro.
1.3. Definic¸˜ao da Proposta
Ser´a utilizado o modelo de programac¸˜ao Charm++ pelo fato de ser a ferramenta mais indicada para trabalhar com ambientes multiprocessadores. Com este modelo, ser´a criado um novo balanceador de carga (BC) que faz uso de uma estrat´egia, baseada em m´edias aritm´eticas, a qual permite equilibrar as cargas e o tempo de execuc¸˜ao entre os processadores, impedindo que um deles fique ocioso ou sobrecarregado. Assim, o BC proposto foi denominado AverageLB.
O motivo pelo qual ser´a utilizado um balanceador de carga se d´a porque cont´em m´etodos espec´ıficos para trabalhar com os processadores. Estes m´etodos permitem dividir uma aplicac¸˜ao em objetos migr´aveis, denominados chares, e inseri-los em v´arias unidades de processamento. O BC proposto faz uso de uma abordagem centralizada, a qual manter´a os n´ucleos ocupados pelo m´aximo de tempo poss´ıvel, evitando a perda de eficiˆencia.
1.4. Organizac¸˜ao do Trabalho
Nesta Sec¸˜ao, foram apresentadas informac¸˜oes introdut´orias sobre o contexto, o problema e a proposta do trabalho. A segunda Sec¸˜ao apresenta o estado da arte do am-biente paralelo, bem como os sistemas de alto desempenho, o modelo de programac¸˜ao Charm++ e seus componentes. Ser˜ao abordados trabalhos referentes `a estes t´opicos, mas o destaque principal s˜ao os balanceadores de carga.
Na terceira Sec¸˜ao ser´a demonstrado o pseudoc´odigo do algoritmo do AverangeLB e seus principais parˆametros. A quarta Sec¸˜ao explica a proposta do BC, seu funciona-mento e a metodologia utilizada para desenvolvˆe-lo. A quinta Sec¸˜ao demostrar´a os resul-tados obtidos com este algoritmo, bem como as expectativas alcanc¸adas por ele. Assim, a sexta Sec¸˜ao apresenta as conclus˜oes, discuss˜oes e contribuic¸˜oes que este trabalho pro-porcionou. Por fim, ser˜ao apresentadas as referˆencias bibliogr´aficas que nortearam este trabalho.
2. Estado da Arte
A presente situac¸˜ao do ambiente paralelo mostra uma grande preocupac¸˜ao com os sistemas computacionais de alto desempenho (CAD) ou High Performance Computing (HPC). Este fator ´e consequˆencia do objetivo destes sistemas de atingir a escala do exa-flop, como pode ser visto na lista dos 500 melhores supercomputadores [Dongarra et al. 1994]. Aplicac¸˜oes paralelas est˜ao sendo constru´ıdas para m´aquinas que possuem centenas de milhares de processadores, pois necessitam obter resultados precisos no menor tempo poss´ıvel.
2.1. Irregularidades nas Aplicac¸˜oes Paralelas
Existem aplicac¸˜oes 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´em de apresentar padr˜oes de carga dinˆamicos. Uma alternativa para estas aplicac¸˜oes irregulares seria incorporar t´ecnicas de balanceamento de carga dinˆamico em sua estrutura, o que tornaria necess´ario realizar mudanc¸as na estrutura da aplicac¸˜ao [Bhandarkar et al. 2001].
Por´em, o sistema de execuc¸˜ao do MPI n˜ao suporta balanceamento de carga dinˆamico. Dessa forma, uma outra alternativa seria converter estas aplicac¸˜oes utilizando uma lingua-gem de programac¸˜ao paralela orientada a objetos, como o Charm++. Este suporta eficien-temente as t´ecnicas de balanceamento de carga dinˆamica para aplicac¸˜oes irregulares base-ado na migrac¸˜ao de objetos. Contudo, esta convers˜ao ´e muito onerosa uma vez que as ar-quiteturas das m´aquinas que rodam estes paradigmas s˜ao diferentes [Bhandarkar et al. 2001].
A t´ecnica adotada por [Bhandarkar et al. 2001] para aplicar o balanceamento de carga dinˆamico em aplicac¸˜oes irregulares foi utilizar o Adaptive MPI (AMPI), que ´e se-melhante ao MPI, por´em usa orientac¸˜ao 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´ario dividir a aplicac¸˜ao em v´arias partes pequenas, chamadas de chunks.
Estes chunks eram mapeados e remapeados a fim de balancear as cargas atrav´es dos processadores. Por isso, chunks foram implementados como objetos para que os balanceadores de cargas do Charm++ os reconhecessem como chares. Com este m´etodo, os autores conseguiram converter duas grandes aplicac¸˜oes cient´ıficas. Como resultado, constataram que o overhead apresentado pelo AMPI ´e muito pequeno, al´em das m´ınimas mudanc¸as realizadas no c´odigo original. A partir da´ı, o AMPI comec¸ou a ser amplamente utilizado juntamente com Charm++ para otimizar aplicac¸˜oes irregulares.
2.2. Balanceamento de Carga
A maioria das aplicac¸˜oes paralelas envolve simulac¸˜ao com comportamentos dinˆamicos ou c´alculos baseados em diversas f´ormulas complexas. Estes dois fatores principais con-duzem a aplicac¸˜ao para um desbalanceamento de carga devido `a grande quantidade de tarefas e vari´aveis. Um exemplo disso ´e a simulac¸˜ao do m´etodo finito de elementos (FEM) a qual envolve geometria dinˆamica e utiliza t´ecnicas adaptativas para resolver grandes problemas irregulares. Devido `a este desbalanceamento da carga de trabalho, as grandes m´aquinas paralelas n˜ao conseguem obter o aproveitamento desejado. Portanto, algoritmos de balanceamento s˜ao t˜ao importantes, especialmente para aplicac¸˜oes onde a
quantidade de computac¸˜oes deve aumentar significativamente `a medida que a simulac¸˜ao evolui [Kale and Zheng 2009, UIUC 2015].
O problema do equil´ıbrio de cargas envolve a tomada de decis˜ao sobre a inserc¸˜ao de tarefas computacionais rec´em-criadas em processadores, ou migrar tarefas existentes entre processadores uniformemente. Para que os algoritmos balanceadores de carga pos-sam tomar melhores decis˜oes relacionadas ao balanceamento de carga, ´e essencial que o sistema de execuc¸˜ao fornec¸a heur´ısticas e informac¸˜oes sobre a carga do sistema mais atua-lizadas. Alguns ambientes de programac¸˜ao adotam uma metodologia baseada na medic¸˜ao das cargas dos objetos que executam em cada processador. Para isso, o BC coleta automa-ticamente estat´ısticas da carga computacional e da comunicac¸˜ao destes objetos e armazena estas informac¸˜oes 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 ´unico processador. Nela, ´e poss´ıvel identificar que no topo existem estrat´egias distintas. O BC deve escolher entre uma delas para utilizar durante a execuc¸˜ao. No centro, est˜ao o gerenciador do BC e o banco de dados que devem informar `as estrat´egias o momento em que elas devem realizar um balanceamento de carga. Quando isso acontece, elas comec¸am a obter informac¸˜oes sobre os estados dos objetos e de suas cargas, armazenando estes dados no banco de dados. Com isso, as estrat´egias podem decidir o momento certo de migrar os objetos e assim alcanc¸ar o equil´ıbrio final das cargas. Os tipos de estrat´egias dispon´ıveis variam entre centralizada, distribu´ıda, h´ıbrida, incremental, entre outras. Nas pr´oximas sec¸˜oes, todo este processo ser´a visto na pr´atica, utilizando um ambiente de programac¸˜ao paralelo espec´ıfico.
2.3. Ambientes de Programac¸˜ao e Balanceadores de Carga
Atualmente existem diversos ambientes de programac¸˜ao paralela capazes de resol-ver os problemas de balanceamento de carga descritos na Sec¸˜ao 2.2. Abaixo, s˜ao citados
os principais ambientes que se encaixam nesta categoria:
• AMPI - Adaptive MPI [Huang et al. 2004] ´e uma extens˜ao do MPI constru´ıdo em cima do sistema de execuc¸˜ao do Charm++. Este ambiente implementa os processos MPI virtualizados atrav´es de threads migr´aveis `a n´ıvel de usu´ario, as quais podem ser mapeadas para um processador f´ısico. A raz˜ao principal para criar esta vers˜ao adaptada se deu pelo fato de que as implementac¸˜oes de MPI j´a n˜ao suportam a natureza dinˆamica das grandes aplicac¸˜oes paralelas, que envolvem simulac¸˜ao e comportamentos dinˆamicos que variam com o tempo. A ideia b´asica por tr´as do AMPI ´e separar a quest˜ao de mapear trabalho para os processadores da identificac¸˜ao do trabalho a ser feito em paralelo. Programas padr˜oes em MPI dividem a computac¸˜ao em P processos, um para cada P processadores. Em contra-partida, um programador em AMPI divide a computac¸˜ao em um grande n´umero de processadores virtuais, independente do n´umero de processadores f´ısicos. Isso permite uma s´erie de benef´ıcios, como a possibilidade de balancear automatica-mente as cargas computacionais, emular grandes m´aquinas em pequenas m´aquinas e a divis˜ao eficiente de trabalho entre o sistema e o programador, pois o progra-mador decido o que fazer em paralelo e o sistema decide quando e onde fazer isso;
• Charm++ - Charm++ [Kale and Krishnan 1993] ´e uma extens˜ao da linguagem C++, no qual proporciona um ambiente para programac¸˜ao paralela orientada a objetos. Proporciona uma divis˜ao clara entre objetos sequenciais e paralelos. Possui um modelo de execuc¸˜ao dirigido por mensagens. Os programas desen-volvidos neste ambiente s˜ao completamente port´aveis e rodam sem necessidade de mudanc¸a em todas as m´aquinas com arquitetura MIMD. Suporta estrat´egias de balanceamento de carga dinˆamico, que ´e necess´ario quando h´a computac¸˜oes paralelas irregulares e onde a carga ´e dividida desigualmente entre as unidades de processamento. Charm++ possui objetos concorrentes chamados de chares, que representam pequenas tarefas. S˜ao instanciados a partir de uma classe da mesma maneira que objetos em C++, por isso possuem seus pr´oprios m´etodos e vari´aveis. Por´em, as vari´aveis s˜ao privadas, o que significa que um chare n˜ao 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´etodos. Seu sistema de execuc¸˜ao realiza um balanceamento de cargas dinˆamico, o qual objetiva a distribuic¸˜ao eficiente de cargas entre os processadores. Tamb´em possui pol´ıticas de tolerˆancia a falhas para manter est´avel a execuc¸˜ao de aplicac¸˜oes para-lelas;
• Java paralelo - Parallel Java [Kal´e et al. 1997] ´e a vers˜ao paralela do Java criada para tornar esta linguagem de programac¸˜ao compat´ıvel com os clusters e servido-res paralelos a fim de aproveitar todo seu potencial computacional. Para criar esta vers˜ao, foi utilizado o framework Converse [Kal´e et al. 1996] o qual permite que m´odulos paralelos individuais sejam escritos utilizando diversos paradigmas em diferentes linguagens. Diante disso, esta vers˜ao paralela do Java foi constru´ıda utilizando bibliotecas e extens˜oes do C-MPI, Charm++ e um m´aquina virtual pa-ralela (PVM), resultando em uma nova aplicac¸˜ao com novos m´odulos escritos em Java. Em relac¸˜ao ao seu design, foram criados dois novos tipos de objetos, o
pri-meiro refere-se `a objetos remotos, similares aos chares em Charm++, os quais podem ser criados em processadores remotos e s˜ao acessados por meio proxies. J´a o segundo tipo referem-se aos grupos de objetos, que possuem ramificac¸˜oes em cada processador. Toda aplicac¸˜ao constru´ıda com o Java Paralelo deve ter uma classe main, a qual ´e iniciada no processador 0. Assim como em Charm++, os objetos remotos devem ser instanciados por uma classe remota, que devem conter m´etodos de entrada para permitir a comunicac¸˜ao entre os objetos. A invocac¸˜ao do m´etodo de um objeto ´e realizada pela API de invocac¸˜ao remota de m´etodo (RMI) do Java. O modelo de execuc¸˜ao tamb´em ´e 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 programac¸˜ao e a portabilidade das aplicac¸˜oes;
• PObC++ - Parallel Object C++ [Pinho and de Carvalho 2014] ´e uma linguagem que estende o C++, implementada sobre a biblioteca MPI e que introduz um novo estilo de programac¸˜ao paralela orientada a objetos, onde objetos s˜ao in-trinsecamente paralelos, ou seja, distribu´ıdos em um conjunto de unidades de processamento de um computador paralelo de mem´oria distribu´ıda. O motivo pelo qual este ambiente cont´em implementac¸˜oes de MPI ´e para habilitar a criac¸˜ao, comunicac¸˜ao e sincronizac¸˜ao de processos. J´a a extens˜ao em C++ ´e adotada por se tratar de uma linguagem disseminada e amplamente aceita na ´area de Computac¸˜ao 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´aquina paralela com mem´oria distribu´ıda. Comunicam-se atrav´es de invocac¸˜ao remota de m´etodo, onde a comunicac¸˜ao pode ser intra-objeto ou inter-objeto. Um p-objeto ´e instanciado por outro p-objeto pela instanciac¸˜ao coletiva de cada uma de suas unidades em unidades de processamento diferen-tes. Nenhuma comunicac¸˜ao acontece entre as unidades durante a instanciac¸˜ao. Comunicac¸˜oes ocorrem somente em invocac¸˜oes paralelas de m´etodos e o objeto chamador ´e respons´avel em criar um comunicador apropriado e passar para o m´etodo paralelo que ele deseja invocar.
Analisando os ambientes de programac¸˜ao descritos acima, o mais compat´ıvel com este trabalho ´e o Charm++. Al´em das informac¸˜oes descritas sobre ele, a principal raz˜ao para a escolhe deste ambiente ´e o seu framework de balanceamento de carga, que permite tanto criar um novo BC quanto utilizar um disponibilizado pelo ambiente. Abaixo est˜ao citados e descritos alguns BCs fornecidos pelo Charm++:
• BCs com estrat´egia centralizada:
– RefineLB: Move objetos dos processadores mais sobrecarregados para os menos carregados at´e atingir uma m´edia, que ´e definida atrav´es de um m´etodo espec´ıfico, limitando o n´umero do objetos migrados;
– RefineCommLB: Mesmo conceito do anterior, por´em leva em considerac¸˜ao a comunicac¸˜ao entre diferentes objetos enquanto tenta escolher o melhor processador que n˜ao esteja sobrecarregado para inserir um objeto;
– MetisLB: Uma estrat´egia que passa as informac¸˜oes das cargas e da comunicac¸˜ao para o Metis, que ´e uma biblioteca de particionamento de grafos, e utiliza o m´etodo 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´e que a carga de todos os processadores esteja pr´oxima `a carga m´edia;
– ComboCentLB: ´E utilizado para combinar quaisquer das estrategias acima. • BCs com estrat´egia Distribu´ıda:
– NeighborLB: Cada processador tenta obter uma carga media em relac¸˜ao aos seus vizinhos;
– WSLB: Um balanceamento para clusters de estac˜oes de trabalho que pode detectar mudanc¸as nas cargas das maquinas e ajustar estas carga sem in-terferir no trabalho do usu´ario.
• BC com estrat´egia h´ıbrida:
– HybridLB: Permite combinar dois ou mais balanceadores que possuem es-trat´egia centralizada. Esta eses-trat´egia permite dividir um grande n´umero de processadores em v´arios grupos, permitindo realizar um balanceamento de carga mais organizado e eficiente;
2.3.1. Charm++
Charm++ ´e uma extens˜ao da linguagem C++, no qual proporciona um ambiente para programac¸˜ao paralela orientada a objetos. Seu desenvolvimento foi feito pelo Labo-rat´orio de Programac¸˜ao Paralela da Universidade de Illinois, em 1993. Oferece suporte a diversas plataformas e permite que os programas desenvolvidos neste modelo execu-tem tanto em ambientes com mem´oria compartilhada quanto com distribu´ıda. Esta ferra-menta utiliza uma t´ecnica que consiste em dividir um problema em diversos componentes migr´aveis, que s˜ao executados em v´arios processadores [Kale and Krishnan 1993]. A Fi-gura 2 demonstra a diferenc¸a entre a maneira como o usu´ario visualiza a interac¸˜ao entre estes objetos e a maneira como eles s˜ao distribu´ıdos pelo Charm++. Estes componentes migr´aveis s˜ao chamados de objetos chares.
Figura 2. Diferentes vis ˜oes entre os m ´etodos da decomposic¸ ˜ao de um problema
2.3.1.1. Entidades de Charm++
Charess˜ao uma das entidades de Charm++ e referem-se aos objetos do C++ com seus atributos e dados privados, sendo instanciados atrav´es de uma classe chare. Isso significa que um chare n˜ao pode acessar as informac¸˜oes de outro diretamente. Para isso, a comunicac¸˜ao entre eles ´e feita atrav´es da troca de mensagens, como mostra a Figura 3. Por definic¸˜ao, uma mensagem ´e formada por um conjunto de dados. Em Charm++, mensagens possuem a mesma sintaxe que a declarac¸˜ao de m´etodos da lin-guagem C++ [Kal´e et al. 1995].
Um chare pode manipular desde uma at´e v´arias mensagens que s˜ao enderec¸adas `a ele, por meio de um bloco de c´odigo espec´ıfico para manipulac¸˜ao de mensagens. En-tretanto, durante a sua vida ´util, um chare pode ter que lidar com mensagens do mesmo tipo de v´arias maneiras diferentes. Diante disso, Charm++ conta com uma func¸˜ao cha-mada de ponto de entrada, a qual cont´em um ´unico tipo de mensagem e um bloco de c´odigo em C++. Isso permite que o objeto tenha um ´unico tipo de mensagem associado `a v´arios pontos de entrada. Este detalhe ´e baseado no conceito de m´etodos em orientac¸˜ao `a objetos [Jyothi et al. 2004, Kal´e et al. 1995].
Tendo em vista os conceitos de orientac¸˜ao de objetos, um chare ´e similar `a um objeto, ou seja, proporciona encapsulamento de dados. Por´em, n˜ao proporciona outros objetos como parˆametro, tal como heranc¸a e polimorfismo. Mesmo assim, v´arios objetos s˜ao criados a partir de uma aplicac¸˜ao. A uni˜ao de todos estes objetos que formam um pro-grama ´e chamado espac¸o global de objetos. Cada novo objeto que ´e criado ou exclu´ıdo influencia este espac¸o, que pode mudar durante a execuc¸˜ao [Pilla and Meneses 2015, Kal´e et al. 1995].
Figura 3. Comunicac¸ ˜ao entre objetos chares
Fonte: [Pilla and Meneses 2015]
Outro ponto positivo proporcionado pelo C++ ´e a possibilidade de instanciar v´arios objetos da mesma classe ao mesmo tempo, utilizando um vetor de chares, que pode ter at´e seis dimens˜oes. Este m´etodo facilita a comunicac¸˜ao entre chares devido aos ´ındices l´ogicos 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´es de um Proxy. Os Proxies servem como manequins para a comunicac¸˜ao entre os objetos, pois eles n˜ao 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´em dos que j´a foram vistos anteriormente:
Figura 4. Exemplo de um vetor bidimensional
Fonte: [Pilla and Meneses 2015]
• Objetos sequenciais - S˜ao os objetos da linguagem C++ e podem ser acessados apenas localmente. N˜ao s˜ao identificados pelo sistema de execuc¸˜ao do Charm++; • Objetos concorrentes - S˜ao os chares que foram descritos anteriormente nesta Sec¸˜ao. chares diferem dos objetos do C++ pois eles podem ser criados assincro-namente por processadores remotos;
• Objetos replicados - Trˆes tipos podem ser inclu´ıdos neste item:
– Vetor de chares - Representa v´arios objetos indexados em um vetor, como visto anteriormente nesta Sec¸˜ao;
– Grupo de chares - ´E uma colec¸˜ao 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´o multi-processador com mem´oria compartilhada;
• Objetos compartilhados - Como Charm++ n˜ao permite o uso de vari´aveis glo-bais (para manter a portabilidade entre uma grande variedade de m´aquinas), s˜ao utilizadas vari´aveis somente leitura. Estas permitem o compartilhamento de da-dos entre toda-dos os objetos e podem ser acessadas de qualquer chare em qualquer processador;
• Mensagens - ´E a entidade utilizada para realizar a comunicac¸˜ao entre objetos compartilhados. Fornecem argumentos de dados para a invocac¸˜ao remota de m´etodo ass´ıncrono;
Al´em dos chares que executam nos processadores para resolver um problema, todo programa Charm++ possui um objeto principal chamado main chare, que repre-senta o in´ıcio da aplicac¸˜ao. Tamb´em ´e respons´avel por algumas func¸˜oes, como a criac¸˜ao de outros chares, recebimento de parˆametros do usu´ario, coordenac¸˜ao das etapas de computac¸˜ao, al´em de iniciar vari´aveis globais somente leitura.
2.3.1.2. Troca de Mensagens
Devidos aos chares possu´ırem dados privados, sua comunicac¸˜ao ´e feita por troca de mensagens expl´ıcitas atrav´es de chamadas remotas de m´etodos. Essa abordagem con-trola as informac¸˜oes que cada objeto tem acesso, permitindo separar os m´etodos privados de cada chare dos que devem ser compartilhados. Como ilustrado na Figura 3, o envio da
vari´avel massa do objeto A para o B ´e feito atrav´es de um m´etodo p´ublico localizado na classe do objeto B o qual ´e invocado pelo objeto A. Estes m´etodos p´ublicos que podem ser invocados s˜ao chamados de m´etodos de entrada, que podem receber mensagens com dados simples, estruturas de dados ou at´e mesmo nenhum dado [Pilla and Meneses 2015, Kale and Zheng 2009].
Esta troca de mensagem entre chares ´e feita de forma ass´ıncrona onde um m´etodo 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´em disso, o ob-jeto que possui seu m´etodo chamado n˜ao pode comec¸ar a execut´a-lo imediatamente, pois ele deve aguardar o objeto que invocou seu m´etodo terminar de executar para que seja sua vez de entrar em execuc¸˜ao. O benef´ıcio de utilizar uma abordagem ass´ıncrona ´e que a
ne-cessidade de uma sincronizac¸˜ao entre o emissor e o receptor ´e 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 comunicac¸˜ao entre os objetos. Em con-sequˆencia disso, se um objeto for movido de um processador para outro, os outros ob-jetos do vetor n˜ao precisam tomar consciˆencia desta migrac¸˜ao, como mostra a Figura 5. O sistema possui um mecanismo autom´atico que encaminha mensagens assim que necess´ario, armazenando as informac¸˜oes de localizac¸˜ao em cache para evitar custos des-necess´arios [Kale and Zheng 2009].
Figura 5. Diferentes vis ˜oes da comunicac¸ ˜ao em um vetor de chares
Fonte: [Kale and Zheng 2009]
2.3.1.3. Modelo de Execuc¸˜ao
Charm++ possui um modelo de execuc¸˜ao ou kernel formado pelo sistema de troca de mensagens ass´ıncronas, particionamento da aplicac¸˜ao em um grande n´umero de chares e pela migrabilidade destes objetos. Em relac¸˜ao `as mensagens, o ambiente de execuc¸˜ao filtra as mensagens enviadas, identifica para qual chare foi enviada e as coloca em uma fila de mensagens. Esta fila ajuda o ambiente `a decidir quando um objeto ser´a escalonado em uma unidade de processamento [Pilla and Meneses 2015].
Enquanto um chare ´e criado, n˜ao ´e necess´ario especificar em qual dos processa-dores ele ser´a inserido. O pr´oprio kernel do Charm++ ir´a decidir a localizac¸˜ao do objeto, que provavelmente ser´a colocado no processador menos carregado. Al´em disso, o mo-delo de execuc¸˜ao conta com um balanceamento de cargas dinˆamico, que pode migrar tanto objetos concorrentes quanto replicados para outros processadores. Para isso, uma aplicac¸˜ao Charm++ deve ter pelo menos um mainchare, o qual representa o chare princi-pal que ´e respons´avel por criar os objetos vistos na Sec¸˜ao 2.3.1.1 e coordenar a execuc¸˜ao da aplicac¸˜ao [Jyothi et al. 2004].
Para realizar a comunicac¸˜ao entre objetos descrita na Sec¸˜ao 2.3.1.2, o programa-dor define alguns m´etodos dos objetos C++ como m´etodos de entrada e os descreve em um arquivo separado cuja extens˜ao termina em .ci. Estes arquivos s˜ao chamados de ar-quivos de interface o qual especifica quais func¸˜oes podem ser invocadas remotamente por outro chare dentro do espac¸o global de objetos [Acun et al. 2014]. No ato da compilac¸˜ao, al´em dos arquivos de cabec¸alho (extens˜ao .h) e c´odigo (extens˜oes .C ou .CPP) da lingua-gem 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˜ao gerados dois novos arquivos, um que cont´em a definic¸˜ao (extens˜ao .def.h) e o outro que cont´em a declarac¸˜ao (extens˜ao .decl.h) base-ado no arquivo de interface. Assim, o arquivo de declarac¸˜ao deve ser inclu´ıdo no ar-quivo de cabec¸alho da aplicac¸˜ao e o arar-quivo de definic¸˜ao deve ser inserido no arar-quivo que cont´em o c´odigo da aplicac¸˜ao. Estas inclus˜oes devem ser feitas para ”amarrar” o c´odigo da aplicac¸˜ao no sistema de execuc¸˜ao do Charm++. Em seguida, o compilador charmc ´e utilizado novamente para gerar o arquivo de objeto (extens˜ao .o) que faz a ligac¸˜ao de todos os outros arquivos. Quando o compilador finalmente cria o arquivo execut´avel, um outro programa, denominado charmrun, deve ser utilizado para executar a aplicac¸˜ao.
Figura 6. Processo de compilac¸ ˜ao do Charm++
Fonte: [UIUC 2015]
Em relac¸˜ao ao particionamento da aplicac¸˜ao, permite reduzir o tempo que a pla-taforma paralela permanece ociosa, fazendo com que o sistema de execuc¸˜ao gerencie melhor o escalonamento dos chares, pois alguns podem estar prontos para executar en-quanto que outros aguardam a chamada de seus m´etodos. Essa caracter´ıstica ´e muito ben´efica para plataformas de larga escala. J´a a migrabilidade permite que o ambiente de execuc¸˜ao mova chares que est˜ao em processadores sobrecarregados para os que possuem pouca carga de trabalho. Para isso, conta com m´etodos de empacotamento e desempaco-tamento [Pilla and Meneses 2015].
Al´em disso, possibilita tolerˆancia `a falhas atrav´es de uma t´ecnica denominada checkpointing, onde ´e tirado um screenshot do estado atual do ambiente permitindo que
o sistema retorne `a este ponto caso ocorra alguma falha. Estas caracter´ısticas tornam o sistema de execuc¸˜ao maduro e otimizado que pode ser utilizado em diferentes plataformas [Pilla and Meneses 2015].
2.3.1.4. Avaliac¸˜ao do Charm++ para Sistemas Multiprocessadores
Charm++ ´e uma grande ferramenta, a qual permite criar uma s´erie de algorit-mos para corrigir os problemas das aplicac¸˜oes paralelas. Tamb´em permite desenvolver aplicac¸˜oes cient´ıficas complexas, como o NAMD [Nelson et al. 1996]. Por isso, os re-sultados de diversos trabalhos realizados em cima deste modelo por si pr´oprios j´a o ava-liam como sendo adequados para sistemas multiprocessadores. Mesmo assim, vale res-saltar o trabalho de [Pilla et al. 2011], o qual apresenta uma avaliac¸˜ao da adequac¸˜ao do Charm++ para arquiteturas multicore com mem´oria hier´arquica. Segundo os autores, o mecanismo de comunicac¸˜ao do Charm++ n˜ao migra os dados no primeiro n´o NUMA que os acessa, acarretando em um posicionamento de dados ruim nas aplicac¸˜oes constru´ıdas com este modelo.
Assim, ´e importante avaliar o impacto destas decis˜oes no desempenho final de m´aquinas NUMA. Para isso, os autores utilizaram duas m´aquinas para realizar os experi-mentos, sendo que a primeira possu´ıa oito processadores AMD Opteron dual-cores onde cada n´ucleo possu´ıa caches L1 e L2 privadas, e a segunda com quatro processadores Intel XeonX7560 octa-cores onde cada n´ucleo possu´ıa caches L1 e L2 privadas com adic¸˜ao de uma terceira cache L3 compartilhada no processador. A vers˜ao do Charm++ utilizada foi a 6.2.1, junto com trˆes benchmarks disponibilizados por ele para avaliar os testes.
Para m´aquinas NUMA, o modelo permite a utilizac¸˜ao de duas vers˜oes de comunicac¸˜ao: uma baseada na troca de datagramas UDP e outra via troca de ponteiros. O resultado obtido pelos autores utilizando o benchmarks jacobi2D avaliou a execuc¸˜ao de 100 cha-rescom estes dois tipos de comunicac¸˜ao. Estes resultados mostram que quanto maior o n´umero de n´ucleos, menor o tempo de iterac¸˜oes, o que representa caracter´ıstica de esca-labilidade.
Outro resultado obtido de um teste semelhante, o qual consiste em um experi-mento utilizando 200 chares e o benchmark kNeighbor que contava com trˆes vizinhos comunicantes. O tempo de iterac¸˜ao ´e reduzido para a mem´oria compartilhada `a medida que o n´umero de n´ucleos aumenta. No entanto, com o UDP ocorre uma oscilac¸˜ao, onde o tempo de iterac¸˜ao comec¸a a aumentar, atinge seu m´aximo com 8 n´ucleos e entra em decl´ınio quando o n´umero de n´ucleos passa para 16. Esta reduc¸˜ao ocorre em func¸˜ao do aumento de vias de comunicac¸˜ao e da divis˜ao da carga de trabalho.
Estes fatores n˜ao ocorrem porque existe um grande n´umero de n´ucleos acessando o mesmo banco de mem´oria, j´a que as m´aquinas NUMA32 possuem oito n´ucleos por n´o enquanto que as NUMA16 possuem apenas dois. Diante disso, os autores constatam que utilizar diferentes tipos de comunicac¸˜ao n˜ao causam grande impacto para aplicac¸˜oes com computac¸˜ao intensiva. A diferenc¸a est´a nas aplicac¸˜oes que realizam muitas comunicac¸˜oes entre os cluster de m´aquinas NUMA. Para estas, seria necess´ario implementar um es-quema h´ıbrido de comunicac¸˜ao, onde o UPD seria utilizado para a comunicac¸˜ao entre as m´aquinas e a comunicac¸˜ao por mem´oria compartilhada seria usada internamente `a
ma-quina NUMA.
Este ´ultimo teste exp˜oe o problema do m´ultiplo acesso `a mem´oria, que pode pre-judicar a escalabilidade das aplicac¸˜oes. Uma soluc¸˜ao para isso seria garantir um acesso eficiente `a mem´oria utilizando uma t´ecnica auxiliar como, por exemplo, o balanceamento de carga.
Diante disso, os autores realizaram um experimento com alguns BCs disponibili-zados pelo Charm++: GreedyLB, MetisLB e ScotchLB. O GreedyLB distribui os chares conforme o algoritmo guloso, procurando a cada iterac¸˜ao o chare que com o maior tempo de execuc¸˜ao 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´apido, j´a que n˜ao considera a comunicac¸˜ao entre os objetos. Os outros dois BCs s˜ao baseados em es-trat´egias espec´ıficas que consideram os tempos de execuc¸˜ao e grafo de comunicac¸˜ao para otimizar as aplicac¸˜oes [Pilla et al. 2011].
Os autores obtiveram mais resultados atrav´es da utilizac¸˜ao dos benchmarks lb test e jacobi2D fornecidos pelo Charm++. Para o primeiro benchmark, foram utilizados 200 chares com tempo m´ınimo e m´aximo de computac¸˜ao de 50 e 200ms e um grafo de comunicac¸˜ao aleat´orio. O resultado disto mostra que o uso de BCs leva a melhoras para as duas m´aquinas. Por´em, os BCs voltados para grafos de comunicac¸˜ao levaram vantagem.
J´a o segundo benchmark constatou que os BCs obtiveram uma eficiˆencia de apro-ximadamente 90% devido `a reduc¸˜ao das comunicac¸˜oes externas aos n´ucleos. Este n´umero s´o n˜ao foi maior porque os BCs n˜ao tinham conhecimento da hierarquia do cache e da mem´oria das m´aquinas. Outro problema refese `a quantidade m´edia de migrac¸˜oes re-alizadas pelos BCs, que varia de 92 `a 98% pois o mapeamento inicial dos chares n˜ao ´e considerado. Por isso os autores consideraram necess´ario avaliar o impacto que es-tas migrac¸˜oes causam nas aplicac¸˜oes, uma vez que elas resultam em c´opias de mem´oria atrav´es de n´os NUMA.
Finalmente, para aumentar o desempenho de uma aplicac¸˜ao Charm++ em sistemas multiprocessadores, n˜ao basta apenas escolher o melhor tipo de comunicac¸˜ao ou melhorar a afinidade de mem´oria, tamb´em ´e necess´ario utilizar BCs que conhec¸am a arquitetura da m´aquina, considerem o mapeamento inicial dos chares e evitem migrac¸˜oes excessivas para ser poss´ıvel obter uma eficiˆencia maior que 90%.
2.3.1.5. Balanceadores de Carga
Devido ao fato do sistema de execuc¸˜ao do Charm++ migrar os chares, existe a pos-sibilidade de realizar um balanceamento de carga. Durante a execuc¸˜ao de uma aplicac¸˜ao criada a partir deste modelo, ´e realizado um balanceamento de carga dinˆamico, onde os charess˜ao migrados dos processadores sobrecarregados para os que possuem uma carga menor [Zheng et al. 2006]. O framework de balanceamento de carga do Charm++ exe-cuta em background e ´e encarregado de coletar informac¸˜oes da carga de trabalho e da comunicac¸˜ao dos objetos em cada unidade de processamento.
Ap´os a coleta, ele faz uso destas informac¸˜oes para equilibrar a carga de trabalho entre os processadores. Para isso, ele conta com diversos BCs que utilizam estrat´egias
sofisticadas para otimizar o balanceamento. O processo de migrac¸˜ao 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´egias de balanceamento de carga do Charm++ baseiam-se em uma heur´ıstica conhecida como princ´ıpio da persistˆencia, onde a carga de certas aplicac¸˜oes tendem a per-sistir com o tempo. Isso resultou no desenvolvimento de novas estrat´egias mensur´aveis, que utilizam as informac¸˜oes do passado para chegar `a um futuro pr´oximo [Zheng et al. 2010]. Estrat´egias mensur´aveis armazenam informac¸˜oes da carga de cada objeto em um tipo de banco de dados em cada processador. Este banco de dados ´e acessado v´arias vezes durante a execuc¸˜ao, onde verifica-se a existˆencia de um desbalanceamento de carga.
Dessa forma, ´e poss´ıvel obter informac¸˜oes das cargas atrav´es de um m´etodo au-tom´atico e independente. Charm++ ainda apresenta trˆes variac¸˜oes desta estrat´egia, con-forme [Zheng et al. 2010]:
• Centralizada: Toda a estrutura de carga da m´aquina fica em um ´unico proces-sador, seguido de um processo de tomada de decis˜ao que vai determinar a nova distribuic¸˜ao dos objetos Charm++. Costuma ser a melhor abordagem para com-putadores que n˜ao possuam tantos processadores;
• Distribu´ıda: A carga ´e trocada somente com processadores vizinhos, o que torna esta abordagem totalmente escal´avel. No entanto, podem produzir um balance-amento de carga ruim devido `a uma poss´ıvel falta de informac¸˜oes em grandes m´aquinas;
• Hier´arquica: Processadores s˜ao divididos em v´arios grupos independentes e autˆonomos, organizados em diferentes hierarquias. V´arias estrat´egias podem ser usadas para balancear as cargas tanto dos processadores dentro dos grupos quanto os de todos os grupos de forma hier´arquica.
Com base nestas variac¸˜oes, a mais adequada para o cen´ario atual ´e a hier´arquica, pois n˜ao apresenta problemas com um grande n´umero de processadores. Este detalhe ´e ressaltado nos trabalhos de [Pilla et al. 2012] e [Zheng et al. 2010], onde s˜ao propostos dois BCs hier´arquicos. O primeiro, denominado NucoLB (Non-Uniform COmmunication costs Load Balancer), foi desenvolvido para sistemas multiprocessadores que apresentam acesso n˜ao-uniforme `a mem´oria (NUMA). Este BC objetiva maximizar o uso dos cores, para evitar que fiquem ociosos, e minimizar os custos de comunicac¸˜ao pela aplicac¸˜ao.
Isso ´e feito atrav´es de uma heur´ıstica que combina informac¸˜oes da topologia NUMA e da aplicac¸˜ao para reduzir o desbalanceamento de aplicac¸˜oes paralelas. De-mais informac¸˜oes s˜ao obtidas atrav´es 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 execuc¸˜ao no processador que possui o menor custo a cada iterac¸˜ao. Estas tarefas s˜ao consideradas os charesde Charm++. Para realizar os testes, foram utilizadas trˆes plataformas multi-core com diferentes caracter´ısticas NUMA.
Os resultados obtidos pelos autores mostram que o BC proposto realmente apri-mora a performance das aplicac¸˜oes Charm++, onde os speedups est˜ao 1.19 acima dos BCs existentes. Este n´umero foi obtido atrav´es da baixa taxa de tarefas migradas, que
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ˆencia em 4% e a comunicac¸˜ao em 6% devido `a distribuic¸˜ao da carga sobre os cores e mantendo a comunicac¸˜ao entre os charespr´oximos.
J´a o segundo BC [Zheng et al. 2010] procura dividir os processadores em grupos independentes e autˆonomos, baseado na organizac¸˜ao de uma ´arvore bin´aria com v´arios n´ıveis. A estrat´egia ´e utilizar uma abordagem de ´arvore top down de trˆes n´ıveis junto com um token, como pode ser visto na Figura 7. Cada n´ıvel da ´arvore ´e composto por grupos de processadores, onde o n´o 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 ´egia em ´arvore de tr ˆes n´ıveis baseada em um token
Fonte: [Zheng et al. 2010]
O resultado obtido pelo BC hier´arquico (HybridLB), em relac¸˜ao ao uso de mem´oria, mostra que este tipo de abordagem utiliza menos mem´oria, se comparado com os BCs centralizados. Outro fator ´e que quanto mais processadores s˜ao adicionados aos grupos, menor ´e o uso da mem´oria, ao contr´ario da abordagem centralizada. O speedup adquirido por este BC foi de 6.2 com 2.048 cores e 145 com 8.192 cores. Dessa forma, o tempo para o algoritmo realizar o balanceamento de carga tamb´em foi reduzido. Estes resultados comprovam que uma estrat´egia hier´arquica, que utiliza mais de um BC para equilibrar as cargas dos grupos de processadores, ´e muito mais eficiente para supercomputadores.
Al´em do desbalanceamento de carga, outro grande problema dos sistemas HPCs ´e 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 `a do Top500 [Dongarra et al. 1994], mas que mostra os supercomputadores que fazem uso da computac¸˜ao sustent´avel. Um trabalho relacionado `a reduc¸˜ao do consumo de energia ´e o de [Padoin et al. 2014].
Este descreve um balanceador de carga (BC) que usa a demanda de potˆencia e o consumo de energia na tomada de decis˜oes, baseado no modelo de programac¸˜ao Charm++. Utilizando informac¸˜oes do sistema e do pr´oprio modelo, o balanceador possui uma estrat´egia centralizada que consiste em atualizar a frequˆencia de cada core do
pro-cessador. Com base na carga de cada unidade de processamento, a demanda de potˆencia m´edia ´e reduzida e o resultado ´e a diminuic¸˜ao de energia utilizada.
Para realizar este trabalho, o autor utilizou um equipamento com 24 processado-res, devido aos diferentes n´ıveis de frequˆencia, que permite realizar uma grande quanti-dade de testes. Tamb´em foram selecionados benchmarks oferecidos pelo pr´oprio modelo e diferentes BCs. O resultado que o autor obteve mostra que ajustar a frequˆencia das unidades de processamento proporciona uma economia de energia significativa.
Outro trabalho que pode ser destacado ´e o de [Hsiang and Sato 1993], que prop˜oe uma nova t´ecnica, denominada auto-escalonamento uniforme, para balanceamento de carga em sistemas multiprocessadores. O objetivo ´e resolver alguns problemas referen-tes `a restric¸˜ao dos programas paralelos que foram balanceados pelo auto-escalonamento normal (n˜ao uniforme). Primeiramente, ´e 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ˆes modelos e ana-lisa os resultados obtidos. Diante disso, observou-se uma melhoria no balanceamento de carga dos processadores utilizando a t´ecnica proposta. Essa melhoria ´e decorrente do paralelismo aninhado e dos compiladores paralelos oferecidos pelo auto-escalonamento uniforme.
2.3.1.6. Migrabilidade e o Framework PUP
Como visto anteriormente, Charm++ permite que objetos concorrentes sejam mi-grados de um processador para outro. Para uma aplicac¸˜ao tornar um chare migr´avel, o programador deve utilizar o m´etodo de empacotamento e desempacotamento de mensa-gens, ou Pack and UnPack (PUP) em inglˆes. Neste m´etodo, todo o objeto ´e serializado a partir de um stream de bytes fornecido pelo sistema de execuc¸˜ao. Como mostra a Fi-gura 8, este processo tˆem se tornado conveniente pelo Charm++ atrav´es da utilizac¸˜ao 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 ´etodo PUP
Fonte: [Acun et al. 2014]
O m´etodo PUP leva apenas um parˆametro, o qual refere-se `a uma instˆancia da classe PUP::er. A sua func¸˜ao ´e obter o estado do objeto. A classe pupper executa as operac¸˜oes de empacotamento, desempacotamento, escrita no disco e convers˜ao para uma forma interpret´avel sobre os dados do objeto. Quando a mensagem contento o es-tado do objeto ´e recebida pelo novo processador, uma nova instˆancia da classe ´e criada atrav´es da chamada de um construtor de migrac¸˜oes. Sua tarefa ´e simplesmente criar uma instˆancia n˜ao-inicializada da classe. Ent˜ao, o m´etodo de desempacotamento ´e invocado contendo os ponteiros para a mensagem e para o novo objeto migrado. Assim, o m´etodo
apenas extrai os dados do objeto empacotado, criando um novo objeto no novo processa-dor [Acun et al. 2014, Jyothi et al. 2004].
2.3.1.7. Tolerˆancia a Falhas
A grande maioria das aplicac¸˜oes paralelas envolvem grandes softwares de simulac¸˜ao, previs˜ao do tempo, dinˆamica molecular, entre outros. Devido `a esta grande proporc¸˜ao e alto poder de processamento, uma m´aquina que suporta estas aplicac¸˜oes deve ficar em constante funcionamento a fim de obter um ´otimo resultado no menor espac¸o de tempo poss´ıvel. Por conta disso, caso uma falha ocorra durante o processamento, toda a computac¸˜ao feita por ela ser´a perdida. No intuito de evitar este desperd´ıcio de computac¸˜ao e tempo, Charm++ apresenta um protocolo de tolerˆancia a falhas baseado na t´ecnica de checkpointe restart [Acun et al. 2014].
O programador especifica no c´odigo da aplicac¸˜ao o intervalo de tempo em que o m´etodo de checkpoint ser´a chamado. Este, por sua vez, salva o estado da computac¸˜ao e grava-o em um arquivo no disco. Caso acontec¸a de alguns processadores falhar, toda a aplicac¸˜ao ´e reiniciada pelo m´etodo restart e retorna para o ´ultimo estado salvo pelo m´etodo de checkpoint. Uma vez que o c´odigo do Charm++ ´e independente da localizac¸˜ao f´ısica dos chares, a aplicac¸˜ao pode ser reiniciada em um n´umero diferente de processado-res que estava rodando antes. Esta abordagem permite uma grande flexibilidade para o es-calonador de uma grande m´aquina no momento me que a falha ocorre [Kale and Zheng 2009].
3. Balanceador de Carga AverageLB
A grande motivac¸˜ao para criar algoritmos para corrigir o desbalanceamento de carga vem do fato de que o problema do balanceamento de cargas ´e do tipo NP-Completo [Leung 2004]. Diante disso, o algoritmo do AverageLB foi constru´ıdo baseado na es-trat´egia definida na Sec¸˜ao 3.1.2. A t´ecnica de migrac¸˜ao de chares presente neste algo-ritmo ´e uma adaptac¸˜ao da estrat´egia gulosa, pois ´e a m´edia aritm´etica da carga de cada processador quem decide quais objetos devem ser migrados. Isso evita migrac¸˜oes desne-cess´arias.
A escolha desta t´ecnica ´e 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´edia para controlar as migrac¸˜oes colabora para um balanceamento de carga mais preciso, pois a migrac¸˜ao de tarefas ´e um processo caro. Combinando uma segunda m´edia aritm´etica com a estrat´egia de controle de migrac¸˜oes, o n´umero de objetos migrados e o tempo que o algoritmo leva para realizar o balanceamento s˜ao bem pequenos. Se o objetivo ´e atingir o equil´ıbrio entre as cargas, a m´edia aritm´etica ´e totalmente compat´ıvel.
3.1. Metodologia de Implementac¸˜ao
Nesta Sec¸˜ao, ser´a apresentado o balanceador de carga proposto, sua estrat´egia, objetivos e demais detalhes que justifiquem seu desenvolvimento. Tamb´em ser´a discutida a abordagem centralizada a qual serve como base para a sua execuc¸˜ao. Por ´ultimo, haver´a uma comparac¸˜ao entre o BC proposto e os BCs disponibilizados pelo Charm++.
3.1.1. Balanceamento de Carga Centralizado
O BC proposto foi desenvolvido utilizando o framework de balanceamento de car-gas disponibilizado pelo Charm++. Possui uma abordagem centralizada, o que significa que a estrutura de cargas e de comunicac¸˜ao da m´aquina, al´em de um processo de tomada de decis˜ao, ficam armazenadas em um ´unico ponto. A escolha de uma abordagem centra-lizada se deu pelo fato desta realizar um balanceamento mais preciso em relac¸˜ao `as outras abordagens. Apesar de trabalhar muito bem com alguns milhares de processadores, pode enfrentar problemas de escalabilidade principalmente em m´aquinas paralelas com pouca mem´oria.
Durante o processo de execuc¸˜ao, o BC coleta dados dos processadores e da aplicac¸˜ao e os armazena em um banco de dados de balanceamento de cargas. Dentre estas informac¸˜oes, destacam-se o n´umero total de objetos, a carga total de cada processador, a carga de cada objeto e o n´umero total de processadores. A ideia deste BC ´e utilizar estas informac¸˜oes para criar duas vari´aveis que v˜ao conter m´edias aritm´eticas. Estas ser˜ao usadas para con-trolar quais chares devem ser migrados e qual valor cada processador deve ter para estar em equil´ıbrio.
Devido `a esta t´ecnica de equil´ıbrio de cargas atrav´es de m´edias, 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´oxima Sec¸˜ao descreve como funciona a estrat´egia deste balanceador.
3.1.2. Detalhes da Estrat´egia
Para que o tempo de execuc¸˜ao dos processadores fossem equilibrados, foi utilizada uma estrat´egia baseada na m´edia aritm´etica de suas cargas. Primeiramente, o algoritmo extrai a quantidade de objetos e o total de carga de cada processador. Neste ponto, j´a ´e poss´ıvel perceber que estas duas vari´aveis s˜ao desproporcionais devido ao modo como os objetos s˜ao distribu´ıdos pelas aplicac¸˜oes. O pr´oximo passo ´e calcular a carga m´edia por processador (CMP), que ´e feito dividindo o somat´orio das cargas de cada objeto pelo n´umero total de objetos de cada processador, como mostra a seguinte equac¸˜ao:
CM P = Σ cargas n objetos
Esta vari´avel ´e 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´edia s˜ao migrados, enquanto que os demais permanecem executando em seu processador de origem. Em seguida, ´e calculada a m´edia aritm´etica geral (MAG), que servir´a como limitante para equilibrar as cargas dos processadores. Para efetuar este c´alculo, ´e feito a soma da carga de cada processador e o resultado ´e dividido pelo n´umero de processadores, conforme a equac¸˜ao abaixo:
M AG = carga total processadores n processadores
Com estas duas vari´aveis definidas o BC comec¸a o processo de equil´ıbrio das cargas, que ´e ilustrado na Figura 9. A imagem apresenta dois processadores, X e Y, que foram selecionados pelo BC atrav´es de um m´etodo. Este m´etodo ´e respons´avel por mapear as unidades de processamento e selecionar a primeira que se encontra abaixo da MAG, que neste caso ´e representado por Y. J´a o X representa o primeiro processador que est´a acima da MAG.
Figura 9. Processo de equil´ıbrio de cargas executado pelo BC proposto
Ap´os esta selec¸˜ao, o BC mapeia os chares do processador X a fim de identifi-car aqueles que se encontram acima do seu CMP. Uma vez identificados, inicia-se um processo de migrac¸˜ao que mover´a os chares do processador X para o Y at´e que a carga
de Y possua um valor pr´oximo `a MAG. Quando isso acontecer, o BC busca o pr´oximo processador Y abaixo da m´edia geral. O mesmo vale para o processador X.
Figura 10. Cargas dos processadores com valor pr ´oximo `a MAG
A partir do momento que a carga de um processador est´a equilibrada, este n˜ao pode ser mapeado novamente pelo m´etodo descrito anteriormente. Esta restric¸˜ao evita que o BC trabalhe desnecessariamente, al´em da redundˆancia que poderia acarretar em um balanceamento de carga incompleto. Desenvolver algoritmos com t´ecnicas eficientes ´e muito importante para evitar que o pr´oprio balanceador se torne um gargalo para a performance. Dessa forma, a otimizac¸˜ao gerada por um balanceamento de carga eficiente n˜ao pode ser ofuscada pelo alto custo do pr´oprio processo de balanceamento.
O processo de balanceamento ´e encerrado quando n˜ao existe mais processadores a serem mapeados e as cargas de todas as unidades de processamento possuem um valor pr´oximo `a MAG, como mostra a Figura 10. Mesmo que o n´umero de chares entre X e Y seja diferente, o que realmente importa ´e o valor total da carga destes objetos.
3.2. Algoritmo do AverageLB
O algoritmo do AverangeLB ´e apresentado na Tabela 2 a qual demonstra o cami-nho tomado pelo balanceador para chegar ao equil´ıbrio das cargas.
Tabela 1. Principais par ˆametros utilizadas pelo AverangeLB Parˆametro Definic¸˜ao
MP Mapeamento dos Processadores
MO Mapeamento dos Chares
CM P Carga m´edia por processador M AG M´edia aritm´etica geral
t Processador Menor que a M AG k Processador Maior que a M AG
o Chareavulso
migrarObj(o, k, t) Migrar chare o de k para t
verif icaCarga(t) Verifica se a carga de t continua abaixo da m´edia verif icaCarga(k) Verifica se a carga de k continua acima da m´edia
A cada iterac¸˜ao, o algoritmo realiza um mapeamento dos processadores MP e
do mapeamento correspondente, o primeiro t que est´a abaixo da M´edia Aritm´etica Geral (M AG) e o segundo k que est´a acima desta mesma m´edia. A partir da´ı, o algoritmo analisa os chares que est˜ao executando no processador k e comec¸a a migrar aqueles que possuem uma carga maior que a Carga M´edia do Processador (CM P ).
Tabela 2. Algoritmo do AverangeLB Algoritmo 1: AverangeLB 1 while MP 6= ∅ { 2 t ← MP < M AG 3 k ← MP > M AG 4 o ← MO | o ∈ Mk 5 if cargaObj(o) > CM P 6 migrarObj(o, k, t) 7 if verif icaCarga(k) = false 8 MP − k
9 if verif icaCarga(t) = false 10 MP − t
11 }
Atrav´es do m´etodo verif icaCarga(), o algoritmo verifica as cargas dos proces-sadores t e k para que seus valores n˜ao ultrapassem a m´edia. Quando o valor de um deles estiver pr´oximo `a M AG, este ´e retirado do mapeamento e um novo processador ´e buscado, repetindo o processo at´e que todas as cargas estejam em equil´ıbrio. A Tabela 1 sumariza os principais parˆametros que o BC utiliza.
Quanto maior o n´umero de processadores que a m´aquina possui, maior o tempo de execuc¸˜ao do algoritmo. Por isso, o uso de um balanceador de carga que utiliza uma abor-dagem centralizada ´e recomendado para sistemas paralelos que possuem uma quantidade satisfat´oria de mem´oria, mas que n˜ao possuam centenas de milhares de processadores. Para esta ´ultima vari´avel, recomenda-se uma abordagem hier´arquica.
4. Resultados
Nesta Sec¸˜ao, s˜ao apresentados os detalhes da m´aquina utilizada, os resultados obtidos pelo balanceador proposto e uma comparac¸˜ao do BC proposto com os BCs dis-ponibilizados pelo Charm++.
4.1. Definic¸˜ao do Hardware Utilizado
A plataforma em que o balanceador proposto foi executado cont´em um proces-sador octa-core Intel Core i7 3830QM e um total de 8 GB de mem´oria RAM. Nesta m´aquina, foram instalados o sistema operacional Fedora 21 Linux cuja vers˜ao do kernel ´e 4.0.4-202.fc21.x86 64, a vers˜ao 6.5.1 do modelo de programac¸˜ao paralela Charm++, a vers˜ao 4.9.2 do compilador gcc para a linguagem C++ e um editor de c´odigo para realizar a implementac¸˜ao do algoritmo.
4.2. An´alise de Desempenho
Charm++ possui diversos balanceadores de carga com diferentes estrat´egias que trabalham tanto com as cargas das unidades de processamento quanto a comunicac¸˜ao en-tre os chares, conforme mostrado na Sec¸˜ao 2.3. Denen-tre estes balanceadores, o GreedyLB e o RefineLB foram utilizados a fim de comparar seus tempos de execuc¸˜ao com o Avera-geLB. Na plataforma descrita na Sec¸˜ao 4.1, foi utilizado o benchmark lb test por se tratar de uma ferramenta bastante utilizada para avaliar balanceadores de carga, al´em de ser dis-ponibilizada pelo pr´oprio Charm++. Com ela, os trˆes balanceadores foram submetidos `a dez simulac¸˜oes consecutivas utilizando 100 chares, 150 iterac¸˜oes feitas por cada tarefa e a sincronizac¸˜ao do balanceador de carga definido `a cada 10 iterac¸˜oes. A Figura 11 mostra o gr´afico resultante desta simulac¸˜ao, que apresenta o tempo m´edio de execuc¸˜ao entre eles.
Figura 11. Comparac¸ ˜ao do tempo m ´edio de execuc¸ ˜ao entre diferentes balancea-dores de carga para o benchmark lb test
Ao observar esta imagem, ´e poss´ıvel identificar que o tempo m´edio de execuc¸˜ao de cada BC ´e equivalente, pois todos levaram mais de 7 segundos para executar. O que muda entre os tempos ´e o valor em milissegundos que ´e maior para o GreedyLB e menor para o RefineLB. O c´alculo do tempo total de execuc¸˜ao de cada balanceador ´e feito atrav´es do somat´orio 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
Figura 12. Comparac¸ ˜ao entre o tempo que cada BC levou para executar cada passo do benchmark lb test
avaliados. Na Figura 12 ´e poss´ıvel perceber a equivalˆencia entre os valores de tempo. Isso mostra um desempenho equilibrado para os trˆes BCs dentro do benchmark lb test.
Al´em do lb test, foi utilizado um segundo benchmark, denominado Stencil3D para analisar o desempenho dos balanceadores. Esta an´alise ocorreu atrav´es de um teste que utiliza uma matriz de trˆes dimens˜oes onde ´e feita a comunicac¸˜ao entre cada um dos seus vizinhos. Foram analisados os tempos m´edios de execuc¸˜ao e de cada passo que cada balanceador efetuou a fim de comparar com os resultados do lb test. Na Figura 13 ´e poss´ıvel ver que neste benchmark, o AverageLB obteve um desempenho minimamente superior pois seu tempo m´edio de execuc¸˜ao ´e menor que o dos outros balanceadores.
Figura 13. Comparac¸ ˜ao do tempo m ´edio de execuc¸ ˜ao entre diferentes balancea-dores de carga para o benchmark Stencil3D
J´a 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´apido que os demais, resultando em seu desempenho superior. O principal detalhe que influencia no tempo de execuc¸˜ao de cada passo ´e a quantidade de objetos que s˜ao migrados de um processador para o outro, pois ´e uma tarefa bastante custosa. A Sec¸˜ao 4.3 apresenta uma an´alise desta vari´avel que mostra o quanto ela infuencia no desempenho e no tempo de execuc¸˜ao de cada balanceador.
Figura 14. Comparac¸ ˜ao entre o tempo que cada BC levou para executar cada passo do benchmark lb test
4.3. An´alise de Objetos Migrados
A partir dos resultados anteriores foi realizada uma simulac¸˜ao com os mesmos ba-lanceadores nas mesmas ferramentas, comparando o total de objetos que cada algoritmo migrou de um processador para outro. Em relac¸˜ao ao benchmark lb test, a Figura 15 mostra que o GreedyLB realiza um imenso n´umero de migrac¸˜oes. Isso ´e consequˆencia da estrat´egia gulosa que migra objetos do processador mais carregado para o menos carregado. J´a os dois outros dois balanceadores comparados apresentam n´umeros bem pr´oximos pelo fato de possu´ırem um limitante para controlar a quantidade de objetos mi-grados. Isso mostra que as m´edias aritm´eticas calculadas pelo AverageLB possuem um papel fundamental para evitar migrac¸˜oes desnecess´arias.
Figura 15. Comparac¸ ˜ao do total de migrac¸ ˜oes realizadas por diferentes balance-adores de carga para o benchmark lb test
No segundo benchmark, a quantidade de migrac¸˜oes foi bem menor se comparado com o primeiro. Isso ocorreu porque nesta ferramenta, as cargas entre os processadores j´a possuem um equil´ıbrio maior. Por´em, tanto o GreedyLB quanto o RefineLB realizaram
migrac¸˜oes equivalentes, por volta de uma migrac¸˜ao por cada passo. J´a o AverageLB efe-tuou menos que 60% das migrac¸˜oes, conforme ilustrado na Figura 16. A m´edia aritm´etica que representa a carga m´edia por processador (CMP) do AverageLB foi a grande res-pons´avel por limitar o n´umero de migrac¸˜oes.
Figura 16. Comparac¸ ˜ao do total de migrac¸ ˜oes realizadas por diferentes balance-adores de carga para o benchmark Stencil3D
5. Conclus˜ao
A maioria das aplicac¸˜oes paralelas envolve comportamentos dinˆamicos ou c´alculos baseados em diversas f´ormulas complexas. Empresas e instituic¸˜oes buscam adquirir uma infraestrutura suficiente para suportar tais aplicac¸˜oes. A presente situac¸˜ao do ambiente paralelo mostra uma grande preocupac¸˜ao com os sistemas computacionais de alto desem-penho (CAD). Este fator ´e consequˆencia do objetivo destes sistemas de atingir a escala do exaflop. Por conta disso, existe um grande investimento em m´aquinas que possuem cen-tenas de milhares de processadores, pois necessitam obter resultados precisos no menor tempo poss´ıvel.
O grande problema por tr´as disso ´e que muitas vezes n˜ao h´a uma preocupac¸˜ao com o desbalanceamento de carga gerado por estas aplicac¸˜oes, ou at´e mesmo pelas pr´oprias m´aquinas, que tendem a sofrer com problemas de temperatura e consumo de energia. O desbalanceamento das cargas computacionais ´e o grande respons´avel por impedir que as m´aquinas paralelas aproveitem todo o seu desempenho. Diante deste grande problema, foi constru´ıdo um balanceador de carga baseado em uma estrat´egia que utiliza m´edias aritm´eticas para equilibrar as cargas em cada processador. O modelo de programac¸˜ao Charm++ foi escolhido como ambiente para desenvolver este BC.
O motivo da escolha deste ambiente est´a relacionado com o seu conjunto de ferra-mentas que engloba v´arios tipos de frameworks, pol´ıticas e benchmarks os quais auxiliam a criac¸˜ao de aplicac¸˜oes e algoritmos de alto desempenho e portabilidade, fatores que fo-ram herdados pela sua extens˜ao com a linguagem C++. Neste trabalho, o ffo-ramework de balanceamento de carga foi explorado devido ao balanceador de carga proposto. Atrav´es desta ferramenta, foi poss´ıvel construir um algoritmo, baseado em uma abordagem centra-lizada, utilzando uma estrat´egia que visa utilizar duas m´edias aritm´eticas para equilibrar as cargas dos processadores.
Diante disso, este balanceador recebe o nome de AverangeLB. As m´edias s˜ao li-mitantes para controlar a taxa de migrac¸˜ao de objetos, pois ´e uma tarefa muito custosa e que muitas vezes ´e ignorada por algoritmos de balanceamento de carga. Testes com este balanceador mostram seu desempenho ´e equivalente se comparado aos outros balancea-dores com os quais este foi analisado na Sec¸˜ao 4. Al´em disso, a quantidade de migrac¸˜oes que o balanceador realiza ´e consideravelmente pequena, chegando at´e ser a menor em um dos testes realizados. Isso mostra que as m´edias utilizadas por ele est˜ao realmente con-trolando a quantidade de migrac¸˜oes e carga total de cada processador, colaborando para um balanceamento de carga ´agil e preciso.
Os pr´oximos passos deste trabalho est˜ao voltados para a comunicac¸˜ao entre os objetos, onde pretende-se considerar esta vari´avel a qual possui relac¸˜ao direta com o desbalanceamento de cargas. Tamb´em objetiva-se realizar testes nas grandes m´aquinas paralelas, a fim de resolver problemas reais, utilizando uma nova abordagem para este ba-lanceador como, por exemplo, a h´ıbrida que mostrou-se ser a mais indicada para sistemas com centenas de milhares de processadores.
Referˆencias
Acun, B., Gupta, A., Jain, N., Langer, A., Menon, H., Mikida, E., Ni, X., Robson, M., Sun, Y., Totoni, E., et al. (2014). Parallel programming with migratable ob-jects: Charm++ in practice. In High Performance Computing, Networking, Storage and Analysis, SC14: International Conference for, pages 647–658. IEEE.
Baranauskas, M. C. C. (1993). Procedimento, func¸˜ao, objeto ou l´ogica? linguagens de programac¸˜ao vistas pelos seus paradigmas. Computadores e Conhecimento: Repen-sando a Educac¸˜ao. Campinas, SP, Gr´afica Central da Unicamp.
Bhandarkar, M., Kal´e, L. V., de Sturler, E., and Hoeflinger, J. (2001). Adaptive load balancing for mpi programs. In Computational Science-ICCS 2001, pages 108–117. Springer.
Chandra, R. (2001). Parallel programming in OpenMP. Morgan Kaufmann.
Dongarra, J. J., Meuer, H. W., and Strohmaier, E. (1994). Top500 supercomputer sites. Dongarra, J. J., Otto, S. W., Snir, M., and Walker, D. (1996). A message passing standard
for mpp and workstations. Communications of the ACM, 39(7):84–90.
Feng, W.-c. and Cameron, K. W. (2007). The green500 list: Encouraging sustainable supercomputing. Computer, 40(12):50–55.
Gudwin, R. R. (1997). Linguagens de programac¸˜ao. Campinas: DCA/FEEC/UNICAMP. Hsiang, H. T. and Sato, L. M. (1993). Um auto-escalonamento para sistemas
multipro-cessadores. Anais do V SBAC. Florian´opolis. Set.
Huang, C., Lawlor, O., and Kale, L. V. (2004). Adaptive mpi. In Languages and Compi-lers for Parallel Computing, pages 306–322. Springer.
Jyothi, R., Lawlor, O. S., and Kal´e, L. V. (2004). Debugging support for charm++. In Pa-rallel and Distributed Processing Symposium, 2004. Proceedings. 18th International, page 264. IEEE.
Kal´e, L., Ramkumar, B., Sinha, A., and G¨ursoy, A. (1995). The charm parallel program-ming language and system: Part i-description of language features.
Kal´e, L. V., Bhandarkar, M., Bh, M., and Wilmarth, T. (1997). Design and implementation of parallel java with global object space.
Kal´e, L. V., Bhandarkar, M., Jagathesan, N., Krishnan, S., and Yelon, J. (1996). Con-verse: An interoperable framework for parallel programming. In Parallel Processing Symposium, 1996., Proceedings of IPPS’96, The 10th International, pages 212–217. IEEE.
Kale, L. V. and Krishnan, S. (1993). CHARM++: a portable concurrent object oriented system based on C++, volume 28. ACM.
Kale, L. V. and Zheng, G. (2009). Charm++ and ampi: Adaptive runtime strategies via migratable objects. Advanced Computational Infrastructures for Parallel and Distri-buted Applications, pages 265–282.
Kernighan, B. W., Ritchie, D. M., and Ejeklint, P. (1988). The C programming language, volume 2. prentice-Hall Englewood Cliffs.
