proposta e desenvolvimento de um algoritmo … · sjf: short job first tgsa: traditional gang...
Post on 05-Oct-2018
218 Views
Preview:
TRANSCRIPT
PONTIFÍCIA UNIVERSIDADE CATÓLICA DE MINAS GERAIS
Pós-graduação em Engenharia Elétrica
PROPOSTA E DESENVOLVIMENTO DE UM ALGORITMO
RECONFIGURÁVEL DE ESCALONAMENTO PARALELO DE
TAREFAS
Luís Fabrício Wanderley Góes
Belo Horizonte
2004
Luís Fabrício Wanderley Góes
PROPOSTA E DESENVOLVIMENTO DE UM ALGORITMO
RECONFIGURÁVEL DE ESCALONAMENTO PARALELO DE
TAREFAS
Dissertação apresentada ao Programa de Pós-graduação em Engenharia Elétrica, da Pontifícia Universidade Católica de Minas Gerais, como requisito parcial para obtenção do título de Mestre em Engenharia Elétrica. Orientador: Carlos Augusto Paiva da Silva Martins
Belo Horizonte
2004
LISTA DE SIGLAS
AA: Alto Tempo de Execução e Alto Grau de Paralelismo
AB: Alto Tempo de Execução e Baixo Grau de Paralelismo
ACM: Association for Computer Machinery
ADLs: Architectural Description Languages
BA: Baixo Tempo de Execução e Alto Grau de Paralelismo
BB: Baixo Tempo de Execução e Baixo Grau de Paralelismo
CCC: Camada de Controle de Configuração
ClusterSim: Cluster Simulation Tool
Conf.: Configuração
CPU: Computing Processor Unit
DAG: Direct Acyclic Graph
DHC: Distributed Hierarchical Control
FCFS: First-Come-First-Served
FPGAs: Field-Programmable Gate Arrays
GM-NAA I/O: General Motors – North American Aviation
GSDC: Grupo de Sistemas Digitais e Computacionais
IBM: International Business Machines
IEE: Institute of Electrical Engineers
IEEE: Institute of Electrical and Electronics Engineers
JSDESLib: Java Simple Discrete Event Simulation Library
MPI: Message Passing Interface
NASA: National Aeronautics and Space Administration
PPGEE: Programa de Pós-Graduação em Engenharia Elétrica
PUC-MG: Pontifícia Universidade Católica de Minas Gerais
RGSA: Reconfigurable Gang Scheduling Algorithm
SJF: Short Job First
TGSA: Traditional Gang Scheduling Algorithms
LISTA DE FIGURAS FIGURA 1 Diagrama de um ambiente com escalonamento paralelo estático de tarefas…........................................................................................................................33 FIGURA 2 Diagrama de um ambiente com escalonamento paralelo dinâmico de tarefas…………………………………………………………………………………….…….34 FIGURA 3 Arquitetura da JSDESLib ............................................................................51 FIGURA 4 Padrões de comunicação: (a) Um para todos ponto-a-ponto; (b) Um paratodos broadcast; (c) Todos para um; (d) Todos para todos…………………………53 FIGURA 5 Arquitetura em camadas do ClusterSim.......................................................61 FIGURA 6 Tela principal do ambiente gráfico do ClusterSim ........................................62 FIGURA 7 Editores de tarefa e processo ......................................................................64 FIGURA 8 Editores de aglomerado e nodo ...................................................................67 FIGURA 9 Diagrama de troca de eventos entre as entidades.......................................70 FIGURA 10 Tarefas da carga de trabalho para verificação do ClusterSim: (a) Tarefa 1; (b) Tarefa 2....................................................................................................................71 FIGURA 11 Diagrama de execução das tarefas usando o algoritmo Round-Robin……………………………………………………………………………………………72 FIGURA 12 Diagrama de execução das tarefas usando o algoritmo FCFS..................73 FIGURA 13 Diagrama de execução das tarefas usando o algoritmo de escalonamento de gangues com primeiro encaixe.................................................................................74 FIGURA 14 A arquitetura geral de um algoritmo reconfigurável composto de três camadas: Camada de Controle de Configuração (CCC), Camada Reconfigurável (CR) e Camada Básica (CB) ..................................................................................................81 FIGURA 15 Definição formal de um algoritmo reconfigurável .......................................83 FIGURA 16 Uma configuração do Algoritmo Reconfigurável de Escalonamento de Gangues ........................................................................................................................83 FIGURA 17 Exemplo de classificação de um log em sub-cargas, durante o tempo, por nível de predominância de um tipo de tarefa.................................................................86
LISTA DE GRÁFICOS
GRÁFICO 1 Utilização média em relação aos esquemas de empacotamento............104 GRÁFICO 2 Utilização média em relação aos esquemas de desfragmentação..........105 GRÁFICO 3 Utilização média em relação ao nível de multiprogramação para cargas AA-BB……………………………………………………………………………………..….106 GRÁFICO 4 Utilização média em relação ao nível de multiprogramação para cargas AB-BA……...................................................................................................................106 GRÁFICO 5 Utilização média em relação às políticas de remoção.............................107 GRÁFICO 6 Tempo de reação médio em relação aos esquemas de empacotamento............................................................................................................110 GRÁFICO 7 Tempo de reação médio em relação aos esquemas de desfragmentação..........................................................................................................111 GRÁFICO 8 Tempo de reação médio em relação ao nível de multiprogramação.........................................................................................................112 GRÁFICO 9 Tempo de reação médio às políticas de remoção...................................113 GRÁFICO 10 Tempo de resposta médio em relação aos esquemas de empacotamento............................................................................................................115 GRÁFICO 11 Tempo de resposta médio em relação aos esquemas de desfragmentação.........................................................................................................115 GRÁFICO 12 Tempo de resposta médio em relação ao nível de multiprogramação.........................................................................................................116 GRÁFICO 13 Tempo de resposta médio em relação às políticas de remoção para cargas AA- BB……………………………………………………………………..………....117 GRÁFICO 14 Tempo de resposta médio em relação às políticas de remoção (cargas AB-BA).........................................................................................................................118
LISTA DE QUADROS QUADRO 1 Fases e etapas da pesquisa ......................................................................27 QUADRO 2 Matriz de Ousterhou ..................................................................................37 QUADRO 3 Esquemas de desfragmentação da Matriz de Ousterhout .........................39 QUADRO 4 Trecho de código de uma entidade............................................................50
LISTA DE TABELAS
TABELA 1 Tempo de chegada dos eventos..................................................................53 TABELA 2 Tempo de resposta de cada tarefa obtido na simulação .............................74 TABELA 3 Latência e vazão da rede Fast Ethernet ......................................................76 TABELA 4 Tempo de transmissão por tamanho de mensagem....................................77 TABELA 5 Implementação da CCC...............................................................................85 TABELA 6 Características da arquitetura do aglomerado de computadores.................96 TABELA 7 Tempo de execução dos tipos de tarefas (segundos) .................................98 TABELA 8 Descrição dos tipos de carga de trabalho....................................................99 TABELA 9 Configurações do RGSA............................................................................101 TABELA 10 Utilização média.......................................................................................103 TABELA 11 Tempo de reação médio (segundos) .......................................................109 TABELA 12 Tempo de resposta médio (segundos) ....................................................114 TABELA 13 Slowdown médio......................................................................................119 TABELA 14 Tempo de simulação médio (segundos) ..................................................121 TABELA 15 Melhoria, em porcentagem (%), no desempenho do RGSA em relação às configurações para uma carga composta das 12 cargas de trabalho .........................122 TABELA 16 Melhoria, em porcentagem (%), no desempenho do RGSA em relação às configurações para uma carga composta das cargas AB60 e BA60...........................123
RESUMO
Na pesquisa apresentada nesta dissertação, definimos, propomos, desenvolvemos e implementamos um algoritmo reconfigurável de escalonamento paralelo de tarefas, chamado RGSA (Reconfigurable Gang Scheduling Algorithm), e por meio de simulação, verificamos e analisamos o desempenho do RGSA. O uso de conceitos de computação reconfigurável em algoritmos de escalonamento paralelo de tarefas visa aumentar a flexibilidade e adaptabilidade deles às variações nas arquiteturas paralelas e cargas de trabalho. Com isso, melhora-se também o desempenho do sistema paralelo, principalmente diminuindo o tempo de resposta, tempo de reação e slowdown das tarefas, e aumentando a utilização dos recursos computacionais (processadores, dispositivos de E/S etc.) das arquiteturas paralelas. Os objetivos principais desta pesquisa são: definir, propor, desenvolver e implementar um algoritmo reconfigurável de escalonamento paralelo de tarefas (RGSA - Reconfigurable Gang Scheduling Algorithm); analisar o desempenho do RGSA por meio de simulação; propor, desenvolver e implementar uma ferramenta de simulação de escalonamento paralelo de tarefas em aglomerados de computadores (ClusterSim - Cluster Simulation Tool); propor, desenvolver e implementar uma biblioteca de simulação discreta por eventos (JSDESLib - Java Simple Discrete Event Simulation Library). A pesquisa apresentada nesta dissertação é composta de cinco fases: planejamento e escolha do tema da pesquisa; desenvolvimento da biblioteca de simulação JSDESLib; desenvolvimento da ferramenta de simulação ClusterSim; desenvolvimento do algoritmo reconfigurável RGSA e finalização (documentação, conclusões etc.) da pesquisa. As principais contribuições desta pesquisa são: a proposta, implementação e análise de desempenho do algoritmo RGSA; a proposta e implementação da ferramenta de simulação ClusterSim; a proposta e implementação da biblioteca JSDESLib.
Palavras-chave: Escalonamento paralelo de tarefas; Computação reconfigurável;
Aglomerado de computadores.
ABSTRACT
In this master thesis, we define, propose, develop and implement a reconfigurable parallel job scheduling algorithm, called RGSA (Reconfigurable Gang Scheduling Algorithm), and we verify and analyze the performance of the RGSA through simulation. The use of reconfigurable computing concepts in parallel job scheduling tries to increase their flexibility and adaptability under the variations of parallel architectures and workloads. As a result, the parallel system’s performance is increased, reducing the response time, reaction time and slowdown of the parallel jobs and increasing the utilization of the parallel architectures’ computational resources (processors, I/O devices etc.). The main objectives of this research are: to define, propose, develop and implement a reconfigurable parallel job scheduling algorithm (RGSA – Reconfigurable Gang Scheduling Algorithm); to analyze the performance of RGSA through simulation; to propose, develop and implement a parallel job scheduling simulation tool for cluster computing (ClusterSim – Cluster Simulation Tool); to propose, develop and implement a discrete event simulation library (JSDESLib – Java Simple Discrete Event Simulation Library). The research presented in this master thesis is composed of fives stages: design and choice of the research topic; development of the simulation library JSDESLib; development of the simulation tool ClusterSim; development of the reconfigurable algorithm RGSA and the research conclusions. The main contributions of this research are: the proposal, implementation and performance analysis of RGSA algorithm; the proposal and implementation of the ClusterSim simulation tool and the proposal and development of the JSDESLib simulation library. Keywords: parallel job scheduling; reconfigurable computing; cluster computing.
DECLARAÇÃO
Eu declaro que esta dissertação é fruto do meu trabalho e não foi submetida de
maneira alguma à outra universidade ou instituto de educação, como documento
obrigatório para obtenção de títulos ou conclusão de qualquer tipo de curso. As
informações derivadas de publicações ou quaisquer trabalhos realizados por outros
autores são devidamente referenciadas no texto.
Luís Fabrício Wanderley Góes
Belo Horizonte, 21 de maio de 2004.
Agradecimentos
Primeiramente, eu agradeço a Dona Bete (minha mãe) e a Quel
(minha noiva), pelo carinho, amizade, atenção, paciência, dedicação
e amor. Eu também agradeço a todos os meus amigos e familiares
que sempre me suportaram. Agradeço à Pontifícia Universidade
Católica de Minas Gerais, Pró-Reitoria de Pesquisa e de Pós-
Graduação, Programa de Pós-Graduação em Engenharia Elétrica e
CAPES pela infra-estrutura, apoio financeiro e incentivo.
Eu gostaria de agradecer aos professores que contribuíram para a
minha formação profissional e moral. Em especial, eu agradeço ao
Carlos (meu orientador) pela amizade, honestidade, bondade,
sinceridade e experiência, que serviram de exemplo para a minha
formação como pesquisador e ser humano.
Por último, eu gostaria de agradecer aos meus amigos e
companheiros do Grupo de Sistemas Digitais e Computacionais pelo
apoio técnico e psicológico, pelos momentos de bobeira e
seriedade, pela orientação e desorientação e tudo mais.
2
SUMÁRIO 1 INTRODUÇÃO ...........................................................................................................13 1.1 Histórico .................................................................................................................13 1.2 Contexto .................................................................................................................15 1.3 Problemas ..............................................................................................................17 1.4 Objetivos e Metas ..................................................................................................19 1.4.1 Objetivos Principais ..............................................................................................19 1.4.2 Objetivos Intermediários .......................................................................................20 1.4.3 Metas..........................................................................................................................20 1.5 Relevância..............................................................................................................20 1.6 Motivação ...............................................................................................................22 1.7 Escopo....................................................................................................................23 1.8 Estrutura da Dissertação ......................................................................................23 2 MATERIAIS E MÉTODOS .........................................................................................25 2.1 Materiais .................................................................................................................25 2.2 Fases da Pesquisa.................................................................................................26 2.3 Métodos, Abordagens e Técnicas........................................................................28 3 ESTADO DA ARTE....................................................................................................29 3.1 Processamento Paralelo .......................................................................................29 3.1.1 Arquitetura Paralela ..............................................................................................29 3.1.2 Carga de Trabalho...............................................................................................30 3.2 Escalonamento Paralelo de Tarefas ....................................................................32 3.2.1 Escalonamento Paralelo Estático .........................................................................33 3.2.2 Escalonamento Paralelo Dinâmico .......................................................................34 3.2.3 Escalonamento de Gangues ................................................................................36 3.2.3.1 Aspectos de Implementação ..........................................................................37 3.2.3.2 Tipos de Escalonamento de Gangues ...........................................................39 3.3 Computação Reconfigurável ................................................................................41 3.3.1 Hardware Reconfigurável .....................................................................................41 3.3.2 Software Reconfigurável.......................................................................................42 3.4 Simulação...............................................................................................................44 3.4.1 Tipos de Simulação ..............................................................................................45 3.4.2 Softwares para Simulação....................................................................................46 4 DESENVOLVIMENTO DA BIBLIOTECA DE SIMULAÇÃO JSDESLIB...................48 4.1 Introdução ..............................................................................................................48 4.2 Trabalhos Relacionados .......................................................................................48 4.3 Proposta da Biblioteca JSDESLib........................................................................49 4.4 Arquitetura e Implementação da Biblioteca JSDESLib ......................................50 4.5 Verificação e Teste da Biblioteca JSDESLib.......................................................52 4.6 Conclusões ............................................................................................................54
5 DESENVOLVIMENTO DA FERRAMENTA DE SIMULAÇÃO CLUSTERSIM...........56 5.1 Introdução ..............................................................................................................56 5.2 Trabalhos Relacionados .......................................................................................56 5.3 Proposta e Implementação da Ferramenta ClusterSim......................................59 5.3.1 Arquitetura do ClusterSim.....................................................................................60 5.3.1.1 Ambiente Gráfico.............................................................................................61 5.3.1.1.1 Carga de Trabalho..........................................................................................62 5.3.1.1.2 Arquitetura ......................................................................................................65 5.3.1.1.3 Módulo Estatístico e de Desempenho ............................................................68 5.3.1.2 Entidades do ClusterSim ................................................................................68 5.3.1.3 Núcleo do ClusterSim .....................................................................................70 5.4 Verificação e Teste da Ferramenta ClusterSim...................................................71 5.5 Validação do Modelo de Simulação .....................................................................75 5.6 Conclusões ............................................................................................................78 6 DESENVOLVIMENTO DO ALGORITMO RECONFIGURÁVEL RGSA.....................80 6.1 Introdução ..............................................................................................................80 6.2 Proposta e Implementação do Algoritmo Reconfigurável RGSA......................80 6.3 Trabalhos Relacionados .......................................................................................87 6.3.1 Arquiteturas Paralelas e Cargas de Trabalho.......................................................88 6.3.2 Algoritmos de Escalonamento de Gangues..........................................................90 6.3.3 Softwares Reconfiguráveis de Escalonamento ....................................................91 6.3.4 Trabalhos Relacionados ao Problema..................................................................92 6.4 Teste e Verificação da Implementação do Algoritmo RGSA .............................92 6.5 Resultados da Análise de Desempenho..............................................................93 6.5.1 Seleção de Métricas, Arquitetura e Carga de Trabalho........................................93 6.5.1.1 Métricas ............................................................................................................93 6.5.1.2 Arquitetura .......................................................................................................96 6.5.1.3 Carga de Trabalho ...........................................................................................97 6.5.2 Planejamento dos Experimentos ........................................................................100 6.5.3 Apresentação e Análise dos Resultados ............................................................102 6.5.3.1 Análise da Utilização .....................................................................................102 6.5.3.2 Análise do Tempo de Reação .......................................................................108 6.5.3.3 Análise do Tempo de Resposta....................................................................113 6.5.3.4 Análise do Slowdown ...................................................................................118 6.5.3.5 Análise do Tempo de Simulação.................................................................120 6.5.3.6 Análise do RGSA ...........................................................................................121 6.6 Conclusões ..........................................................................................................124 7 CONCLUSÕES ........................................................................................................126 7.1 Discussão dos Resultados .................................................................................126 7.2 Principais Contribuições ....................................................................................129 7.3 Trabalhos Futuros ...............................................................................................130 7.4 Conclusão Geral ..................................................................................................131 REFERÊNCIAS...........................................................................................................132
13
1 INTRODUÇÃO
Na pesquisa apresentada nesta dissertação, definimos, propomos,
desenvolvemos e implementamos um algoritmo reconfigurável de escalonamento
paralelo de tarefas, chamado RGSA (Reconfigurable Gang Scheduling Algorithm), e
por meio de simulação, verificamos e analisamos o desempenho do RGSA. O uso
de conceitos de computação reconfigurável em algoritmos de escalonamento
paralelo de tarefas visa aumentar a flexibilidade e adaptabilidade deles às variações
nas arquiteturas paralelas e cargas de trabalho. Com isso, melhora-se também o
desempenho do sistema paralelo, principalmente diminuindo o tempo de resposta,
tempo de reação e slowdown das tarefas, e aumentando a utilização dos recursos
computacionais (processadores, dispositivos de E/S etc.) das arquiteturas paralelas.
Neste primeiro capítulo apresentamos os seguintes tópicos: histórico,
contexto, problemas, objetivos e metas, relevância, motivação, escopo e estrutura da
dissertação.
1.1 Histórico
O escalonamento é um problema no qual um algoritmo aloca tarefas aos
recursos disponíveis, de acordo com várias restrições e procurando melhorar o
desempenho tanto das tarefas, quanto dos recursos (EL-REWINI; ALI; LEWIS, 1995;
FEITELSON, 1994). Na década de 50, as práticas de escalonamento já eram
necessárias para a utilização apropriada de homens, máquinas e materiais em um
programa de manufatura. O bom retorno de investimentos estava ligado ao
atendimento das necessidades dos consumidores e à utilização ótima do
equipamento (GRAVEL; KAVANAGT, 1957). Em meados dos anos 50, surgiu o
primeiro sistema operacional, o GM-NAA I/O (General Motors – North American
Aviation), desenvolvido para a arquitetura IBM 704 (COMPUTER, 2007). Nesse
sistema, as tarefas ou aplicações (consumidores) eram executadas seqüencialmente
sem interrupções (sistema em lote com mono-programação) no processador
(recurso) do IBM 704 (COMPUTER, 2007; HWANG; XU, 1998; PATTERSON;
14
HENNESSY, 1998). Consideramos essa estratégia como a forma mais simplificada
de escalonamento, na qual os consumidores utilizam o recurso de forma exclusiva
até executarem todo o trabalho. A única preocupação nesse tipo de escalonamento
está na ordenação das tarefas em uma fila de espera, por meio de prioridades.
Como exemplos desses algoritmos de escalonamento, podemos citar o First-In-First-
Out e Shortest Job First. No final da década de 60, surgiu o primeiro sistema
operacional de tempo compartilhado, no qual várias tarefas e usuários
compartilhavam o mesmo recurso (COMPUTER, 2007; HWANG; XU, 1998). A partir
de então, os escalonadores dos sistemas operacionais passaram a utilizar
algoritmos mais complexos, que levavam em consideração o intervalo de tempo que
cada tarefa poderia ocupar um processador, além da ordem de execução. Os
algoritmos de escalonamento deveriam atender às necessidades dos usuários e ao
mesmo tempo maximizarem a utilização do processador. O algoritmo de
escalonamento mais simples utilizado nessas arquiteturas é o Round-Robin, no qual
consideramos um intervalo de tempo fixo para a execução de cada tarefa em um
processador.
No início da década de 70 tornou-se operacional o primeiro computador
vetorial, o ILLIAC IV, instalado no Ames Research Center da NASA. Ele atingia uma
velocidade de 200 milhões de instruções por segundo com os seus 64 elementos de
processamento (COMPUTER, 2007). Desde então, os algoritmos de escalonamento
passaram a resolver um problema bidimensional envolvendo o tempo e o espaço. O
compartilhamento de tempo se refere à utilização de um recurso ao longo do tempo
por vários consumidores. Já o compartilhamento de espaço se preocupa com a
distribuição espacial dos consumidores sobre os recursos, independentemente do
tempo (FEITELSON, 1994). Até então, as arquiteturas eram compostas de
processadores homogêneos em ambientes bem controlados, enquanto as tarefas
possuíam um comportamento bem determinado e eram geralmente projetadas para
executarem exclusivamente em uma arquitetura determinada. Os algoritmos de
escalonamento não precisavam lidar com falhas na arquitetura, heterogeneidade de
recursos, escalabilidade, dinamicidade e adaptabilidade. Caso ocorresse uma falha,
essa era corrigida e as aplicações eram reiniciadas.
Com a evolução dos processadores, redes de interconexão, memórias,
sistemas operacionais, linguagens e outros componentes de computador, surgiram
novas arquiteturas paralelas e distribuídas (aglomerados de computadores, sistemas
15
peer-to-peer, grades computacionais etc.) e a possibilidade de resolver problemas
mais complexos (ALMASI; GOTTLIEB, 1994; BUYYA, 1999; HWANG; XU, 1998;
BUYYA, 1999; HWANG; XU, 1998). A partir do final dos anos 80, iniciou-se uma
competição entre Japão e Estados Unidos para a construção de arquiteturas cada
vez mais poderosas, para a solução de problemas complexos científicos, de
engenharia e da indústria, que utilizam modelos computacionais para a simulação de
fenômenos físicos.
Desde 1993, essa competição vem sendo documentada pelo site TOP500, no
qual, a cada ano, as arquiteturas são avaliadas através do benchmark Linpack e
classificadas de acordo com a velocidade de processamento (SUPERCOMPUTERS
, 1991). Os escalonadores têm um papel fundamental no desempenho dessas
arquiteturas, tanto no aumento da utilização dos processadores, dispositivos de E/S
etc., quanto na diminuição do tempo de resposta, tempo de reação e slowdown das
tarefas, que podem ser requisições de busca, transações bancárias, programas
paralelos etc. (BUYYA, 1999; HWANG; XU, 1998; EL-REWINI; ALI; LEWIS, 1995).
Nos últimos anos, as necessidades dos usuários em relação ao custo, tempo
e qualidade de serviço tornaram-se muito complexas. Da mesma forma, o
investimento das empresas, indústrias e universidades em sistemas computacionais
de alto desempenho (arquiteturas paralelas) tem aumentado. Entre esses dois lados
estão os algoritmos de escalonamento, que tentam atender às necessidades dos
usuários e das instituições. Seja em um sistema bancário, uma indústria
automobilística, um laboratório de uma universidade ou um site de busca, sempre
existirá o problema de escalonamento, no qual um algoritmo tem o compromisso de
alocar recursos computacionais de forma eficiente às tarefas dos usuários (BUYYA,
1999; HWANG; XU, 1998; EL-REWINI; ALI; LEWIS, 1995).
1.2 Contexto
Atualmente, com a evolução das arquiteturas paralelas, a expansão da
Internet, o aumento de usuários com suas diferentes necessidades e serviços
oferecidos pelas instituições, somados à própria complexidade inerente ao problema
de escalonamento, criou-se um cenário caótico (BUY, 2002; EL-REWINI; ALI;
16
LEWIS, 1995; FEITELSON, 1994; FRACHTENBERG, et al., 2003; GÓES;
MARTINS, 2003; KWOK; AHMAD, 1999). Esse cenário de natureza estocástica e
dinâmica cria uma necessidade de adaptação contínua dos algoritmos de
escalonamento às variações nas arquiteturas e cargas de trabalho. Por essas
razões, vários trabalhos têm sido realizados nos últimos anos com o intuito de
aumentar a flexibilidade, adaptabilidade e desempenho dos algoritmos de
escalonamento paralelo de tarefas (EL-REWINI; ALI; LEWIS, 1995) (FEITELSON,
1994; FEITELSON; RUDOLPH, 1997; WISEMAN; FEITELSON, 2003;
FRACHTENBERG, et al., 2003; KWOK; AHMAD, 1999). Uma das alternativas, que
ainda não foi explorada, é o uso de conceitos de computação reconfigurável em
algoritmos de escalonamento paralelo de tarefas.
A computação reconfigurável surgiu nos últimos anos como um paradigma
que tem o compromisso de preencher o espaço existente entre implementações em
software e hardware, atingindo maior desempenho que o software e mantendo um
maior grau de flexibilidade em relação ao hardware. Os dispositivos reconfiguráveis,
incluindo os FPGAs (Field-programmable gate arrays), contêm um arranjo de
elementos computacionais ou blocos construtivos, nos quais a funcionalidade é
determinada por meio da programação de bits de configuração. Dessa forma, ao
longo do tempo, o dispositivo pode implementar comportamentos diferentes e não
previamente determinados. Em decorrência disso, várias soluções de problemas em
diferentes áreas do conhecimento têm sido melhoradas principalmente em relação à
flexibilidade e adaptabilidade (COMPTON; HAUCK, 2002; DEHON, 2000; MARTINS
et al., 2002a).
A proposta desta pesquisa consiste na utilização de conceitos de computação
reconfigurável em um algoritmo de escalonamento paralelo de tarefas, ou seja,
empregar conceitos similares aos utilizados na composição, funcionamento e
utilização dos dispositivos de hardware reconfigurável, diretamente na estrutura e
lógica do algoritmo. Em decorrência disso, o algoritmo de escalonamento passa a ter
seu comportamento alterado dinamicamente, por meio da configuração da sua
forma, assumindo configurações mais adequadas às arquiteturas e cargas de
trabalho, aumentando a sua flexibilidade, adaptabilidade e desempenho.
17
1.3 Problemas
O problema principal abordado nesta dissertação é a falta de flexibilidade e
adaptabilidade dos algoritmos de escalonamento paralelo de tarefas, que levam a
uma baixa utilização das arquiteturas paralelas e a um alto tempo de resposta das
tarefas. Devido à heterogeneidade da carga de trabalho e o comportamento
dinâmico dessas arquiteturas, apenas um algoritmo tradicional ou um conjunto pré-
determinado de algoritmos de escalonamento paralelo de tarefas não garante
desempenho ideal ou desejado para grande parte das situações existentes. O uso
de conceitos de computação reconfigurável em algoritmos de escalonamento
paralelo de tarefas fornece a possibilidade deles assumirem, idealmente, infinitas
configurações não pré-determinadas, aumentando a flexibilidade e a adaptabilidade
dos algoritmos. Conseqüentemente, aumenta-se o desempenho das tarefas e
arquiteturas paralelas, pois para cada situação específica, uma configuração ideal
do algoritmo de escalonamento será utilizada.
No nosso levantamento bibliográfico, que consistiu de consultas nas
máquinas de busca Google, Yahoo, Altavista e Lycos, nas bibliotecas digitais do
IEEE, IEE e ACM, em livros e artigos, encontramos poucos trabalhos em relação à
aplicação de conceitos de computação reconfigurável em softwares e principalmente
em algoritmos. Nos trabalhos encontrados Bhatia (1997); Bruneton; Coupaye;
Stefani (2002); Compton; Hauck (2002); Ducasse; Hofmann; Nierstrasz (2000);
Hadlich; Neumann (1997); Lesley; Fekete (2001); Martins et al. (2002a);
Papadopoulos; Arbab (2000); Paula; Justo; Cunha (2000); Roxby; Prada; Charlwood
(1999); Salzmann (2002); Yamamoto et al. (2000), vislumbramos poucas
semelhanças com a nossa proposta, mas nenhum trabalho com a mesma solução.
Também pesquisamos palavras relacionadas como adaptabilidade, dinamicidade e
flexibilidade, e alguns conceitos de engenharia de software que apresentavam idéias
possivelmente relevantes ao nosso trabalho, como a arquitetura de software, teoria
de componentes e frameworks. Ao final desse levantamento, não encontramos
nenhum trabalho equivalente a nossa proposta. Portanto, surgiu mais um problema
relacionado com a falta de material a respeito do uso de conceitos de computação
reconfigurável em softwares e principalmente em algoritmos.
18
O problema de escalonamento paralelo de tarefas envolve elementos
computacionais (processadores, redes de comunicação, etc.) que podem ter um
custo financeiro alto, dificultando ou impossibilitando o uso de experimentação para
analisar o desempenho dos algoritmos de escalonamento. A natureza estocástica, a
complexidade das cargas de trabalho e de alguns desses elementos dificulta a
descrição precisa do comportamento do sistema computacional por meio de um
modelo matemático. Portanto, a simulação aparece como uma técnica com menor
custo financeiro, maior precisão e controle sobre o sistema computacional.
Uma simulação pode ser desenvolvida utilizando-se bibliotecas de simulação,
linguagens de simulação ou ferramentas de simulação de propósito-específico. A
alternativa que possibilita a obtenção de resultados com o menor tempo de
desenvolvimento é o uso de ferramentas de simulação de propósito-específico
(escalonamento paralelo de tarefas). Na literatura estudada (Bodhanwala, et al.
(2001); Buy (2002); Casanova (2001); Law; Kelton (1991); Low (1999); A Collection
(2003); Sulistio; Yeo; Buyya (2004), encontramos apenas uma ferramenta (SRGSim)
Bodhanwala, et al. (2001), desenvolvida pelo Schark Group, com características
interessantes (escalonamento estático e dinâmico, modelagem da carga de trabalho
com distribuições probabilísticas etc.), que simula algoritmos de escalonamento
paralelo de tarefas em arquiteturas paralelas. Apesar dessas vantagens, o SRGSim
não possui as seguintes características desejáveis: interface gráfica, enfoque
didático, suporte a nodos heterogêneos, descrição estrutural da carga de trabalho
etc. Então, optamos por implementar uma nova ferramenta de simulação de
escalonamento paralelo de tarefas, especificamente em aglomerados de
computadores, pois é uma arquitetura de baixo custo, alto desempenho e
escalabilidade. Portanto, foi necessário selecionar uma biblioteca ou linguagem de
simulação como suporte para o desenvolvimento desta ferramenta.
Entre as bibliotecas e linguagens de simulação, as bibliotecas são mais
portáteis, flexíveis e fáceis de se utilizar. A desvantagem principal das bibliotecas é a
falta de recursos de compilação (otimização, checagem e análise de código). Apesar
de encontrarmos a maioria das funcionalidades desejadas nas bibliotecas de
simulação estudadas Law; Kelton (1991); Low (1999); Macnab; Howell (1996); A
Collection (2003); Sulistio; Yeo; Buyya (2004), optamos por implementar uma nova
biblioteca. Os motivos são: a inclusão de novas funcionalidades; a obtenção de
maior controle sobre a implementação; a simplificação e automatização de algumas
19
funcionalidades encontradas nas bibliotecas estudadas e a facilidade e rapidez de
implementação de uma biblioteca de simulação.
Em suma, a partir do problema principal, surgiram os seguintes problemas
secundários:
- Falta de material sobre o uso de conceitos de computação reconfigurável em
softwares e principalmente em algoritmos.
- Falta de uma ferramenta de simulação de escalonamento paralelo de tarefas
com todas as características desejáveis.
- Falta de uma biblioteca de simulação com todas as características
desejáveis.
1.4 Objetivos e Metas
Neste tópico, apresentamos os objetivos principais, objetivos intermediários e
metas da pesquisa apresentada nesta dissertação.
1.4.1 Objetivos Principais
Baseado nos problemas levantados, destacamos os objetivos principais da
pesquisa apresentada nesta dissertação, por ordem de importância:
- Definir, propor, desenvolver e implementar um algoritmo reconfigurável de
escalonamento paralelo de tarefas (RGSA - Reconfigurable Gang Scheduling
Algorithm).
- Analisar o desempenho do RGSA por meio de simulação.
- Propor, desenvolver e implementar uma ferramenta de simulação de
escalonamento paralelo de tarefas em aglomerados de computadores (ClusterSim -
Cluster Simulation Tool).
- Propor, desenvolver e implementar uma biblioteca de simulação discreta por
eventos (JSDESLib – Java Simple Discrete Event Simulation Library).
20
1.4.2 Objetivos Intermediários
Dentre os objetivos intermediários da pesquisa apresentada nesta
dissertação, destacamos os que julgamos mais importantes, por ordem cronológica:
- Estudar e analisar as características de bibliotecas de simulação.
- Verificar e testar a biblioteca de simulação JSDESLib.
- Estudar e analisar as características de ferramentas de simulação de
escalonamento paralelo de tarefas.
- Verificar e testar a ferramenta de simulação ClusterSim.
- Validar o modelo de simulação da ferramenta ClusterSim.
- Verificar e testar o algoritmo reconfigurável RGSA.
1.4.3 Metas
Dentre as possíveis metas ou resultados esperados a serem alcançados na
pesquisa apresentada nesta dissertação, destacamos os que julgamos mais
importantes, por ordem cronológica:
- Implementação da biblioteca de simulação JSDESLib.
- Implementação da ferramenta de simulação ClusterSim.
- Implementação do algoritmo reconfigurável RGSA.
- Análise de desempenho do algoritmo reconfigurável RGSA.
- Documentação em formato hipermídia de toda a pesquisa.
- Publicação de artigos em congressos e revistas, nacionais e internacionais.
1.5 Relevância
O problema de escalonamento de tarefas está presente em diversas áreas,
nas quais existe uma decisão de alocar recursos computacionais de forma eficiente
às tarefas dos usuários (EL-REWINI; ALI; LEWIS, 1995; FEITELSON, 1994).
21
Portanto, o estudo de escalonamento de tarefas pode beneficiar universidades,
indústrias, empresas e os usuários dos serviços oferecidos por essas entidades.
A criação de políticas ou algoritmos de escalonamento paralelo mais flexíveis
e adaptáveis pode aumentar muito o desempenho das arquiteturas paralelas. Além
disso, arquiteturas de baixo custo, mas com alto desempenho obtido por meio de
otimizações nos algoritmos de escalonamento, poderão ser utilizadas no lugar de
arquiteturas com alto custo financeiro. O uso de conceitos de computação
reconfigurável nos algoritmos de escalonamento paralelo de tarefas pode gerar a
flexibilidade e a adaptabilidade necessárias para se alcançar um alto desempenho
computacional.
De uma maneira geral, a computação reconfigurável tem sido pouco estudada
no Brasil. E principalmente o uso de conceitos de computação reconfigurável em
software e algoritmos tem sido pouco trabalhado tanto no Brasil quanto no mundo.
Portanto, essa pesquisa estará gerando conhecimento novo que poderá ter
abrangência mundial.
A ferramenta de simulação ClusterSim poderá ser utilizada para fins de
ensino e aprendizado em disciplinas como processamento paralelo e distribuído,
arquitetura de computadores etc. Um primeiro artigo sobre o assunto foi publicado
IEEE Frontiers in Education Conference 2003. A biblioteca de simulação será
utilizada na disciplina de arquitetura de computadores no curso de Ciência da
Computação da PUC Minas, para que os alunos desenvolvam suas próprias
ferramentas de simulação.
Várias das contribuições desta pesquisa podem ser utilizadas em outras
dissertações, textos, artigos e monografias dentro do Grupo de Sistemas Digitais e
Computacionais (GSDC), Programa de Pós-Graduação em Engenharia Elétrica
(PPGEE) e da própria PUC. Uma abordagem para o desenvolvimento de algoritmos
reconfiguráveis está sendo projetada em conjunto com outros alunos, no qual cada
aluno a utilizará para fins específicos relacionados com o tema de sua dissertação. A
ferramenta de simulação será estendida para atender as necessidades de outros
alunos.
22
1.6 Motivação
A motivação principal para a realização desta pesquisa iniciou-se com a
experiência adquirida durante a realização de projetos de iniciação científica. No
primeiro projeto (MARTINS, 2001), houve um primeiro contato com os sistemas
computacionais paralelos, dedicados e reconfiguráveis, no qual desenvolvemos
alguns programas paralelos, uma ferramenta de análise de desempenho (Prober) e
publicamos nossos primeiros artigos (MARTINS et al., 2001; GÓES; RAMOS;
MARTINS, 2001a; GÓES; RAMOS; MARTINS, 2001b; RAMOS; GÓES; MARTINS,
2001). No segundo projeto Martins; Góes e Ramos (2002), implementamos um
aglomerado de computadores que utilizava redes de alta velocidade e conceitos de
imagem de sistema único. Ainda neste projeto, estudamos e analisamos sistemas de
gerenciamento de tarefas com ênfase nos escalonadores de tarefas.
Nesse período, o Prober foi aperfeiçoado e também foram implementados
novos programas paralelos (convolução de imagens, redes neurais etc.) utilizando
modelos de passagem de mensagens e variáveis compartilhadas, com o objetivo de
analisar o desempenho do aglomerado. Com os resultados obtidos, foram
publicados mais alguns artigos em congressos nacionais e internacionais
(MARTINS, et al., 2002; GÓES; RAMOS; MARTINS, 2002a; GÓES et al., 2002b;
GÓES; RAMOS; MARTINS, 2002c; GÓES; RAMOS; MARTINS, 2002d; RAMOS;
GÓES; MARTINS, 2002a; RAMOS; GÓES; MARTINS, 2002b). Portanto, a
experiência adquirida juntamente com o crescente interesse na área de
processamento paralelo (PENHA, et al., 2003; POUSA, et al., 2003), principalmente
em escalonamento de tarefas e também o ingresso no mestrado, serviram de
motivação para a realização desta pesquisa.
Atualmente, os algoritmos de escalonamento de tarefas são pouco flexíveis e
adaptáveis (EL-REWINI; ALI; LEWIS, 1995; WISEMAN; FEITELSON, 2003;
FRACHTENBERG, et al., 2003; KWOK; AHMAD, 1999). Como conseqüência,
muitas vezes o tempo de resposta, tempo de reação e slowdown das tarefas são
altos e as arquiteturas paralelas possuem uma baixa utilização. Com o uso de
computação reconfigurável, um sistema computacional pode adquirir maior
adaptabilidade, flexibilidade e desempenho (DEHON, 2000; MARTINS et al., 2002a).
Portanto, essas vantagens do uso de computação reconfigurável nos motivaram a
23
aplicá-las em algoritmos de escalonamento paralelo de tarefas. Além disso, na
literatura consultada, não encontramos a aplicação de computação reconfigurável
em algoritmos de uma maneira geral. Portanto, existe a possibilidade de uma
contribuição inédita. Além das motivações descritas, a própria relevância da
pesquisa é uma importante motivação.
1.7 Escopo
O escopo desta pesquisa pode ser definido em relação a quatro aspectos:
econômicos e sociais, científicos e técnicos.
Em relação aos aspectos econômicos e sociais, essa pesquisa visa apenas
fins acadêmicos de ensino e aprendizado. As ferramentas desenvolvidas e a
documentação da pesquisa serão disponibilizadas gratuitamente e devem ser
utilizadas como mecanismos de auxílio ao aprendizado em disciplinas relacionadas
com os temas da pesquisa (processamento paralelo, arquitetura de computadores,
redes de computadores etc.).
Em relação aos aspectos científicos, esta pesquisa se limita a propor,
implementar e analisar um algoritmo de escalonamento paralelo de tarefas para
aglomerados de computadores. Na pesquisa utiliza-se a técnica de simulação e
também, em menor escala, a experimentação e a execução analítica para a
verificação e validação do ClusterSim.
Em relação aos aspectos técnicos, esta pesquisa se limita a implementar uma
biblioteca de simulação discreta por eventos, uma ferramenta de simulação de
escalonamento paralelo de tarefas em aglomerados de computadores, um algoritmo
reconfigurável de escalonamento de tarefas e realizar alguns experimentos reais.
1.8 Estrutura da Dissertação
Esta dissertação está estruturada em sete capítulos. O primeiro capítulo
descreve principalmente os problemas, objetivos, relevância e escopo da
24
dissertação. O segundo capítulo apresenta os materiais e métodos utilizados durante
a pesquisa. O terceiro capítulo apresenta o estado da arte sobre escalonamento
paralelo de tarefas, computação reconfigurável e simulação. Em seguida vêm os
capítulos 4, 5 e 6, os quais estão relacionados com cada uma das contribuições
principais desta pesquisa. O quarto capítulo apresenta o desenvolvimento (proposta,
implementação e verificação) da biblioteca de simulação JSDESLib. O quinto
capítulo apresenta o desenvolvimento (proposta, implementação, verificação e
validação) da ferramenta de simulação ClusterSim. O sexto capítulo apresenta o
desenvolvimento (proposta, implementação, verificação e análise de desempenho)
do algoritmo reconfigurável RGSA. Por último, o sétimo capítulo apresenta as
conclusões, a discussão dos resultados, as principais contribuições e os trabalhos
futuros. As referências bibliográficas e os anexos estão localizados no final deste
documento.
25
2 MATERIAIS E MÉTODOS
Neste capítulo apresentamos os materiais, fases, métodos, abordagens e
técnicas utilizadas para a realização desta pesquisa.
2.1 Materiais
Os materiais utilizados nesta pesquisa estão divididos em quatro grupos:
equipamentos, aplicativos e ferramentas de desenvolvimento, aplicativos e
ferramentas desenvolvidas, materiais de estudo e consulta. A justificativa para o uso
dos materiais citados abaixo é apresentada nos capítulos nos quais eles são
utilizados.
- Equipamentos
- Computador pessoal Intel Pentium
- Aglomerado de Computadores AMD com Switch Gigabit Ethernet Dell
- Aplicativos e Ferramentas de Desenvolvimento
- Compilador NetBeans
- Compilador JDK 1.4.1
- Compilador Microsoft Visual C++
- Ferramenta de análise de desempenho Prober 2.0
- Biblioteca de passagem de mensagem MPICH
- Biblioteca PAPI 2.3
- Benchmark Sandra 2003
- Aplicativos e Ferramentas Desenvolvidas
- Biblioteca de simulação JSDESLib
26
- Ferramenta de simulação ClusterSim
- Materiais de Estudo e Consulta
- Sites de busca Google, Yahoo, Altavista e Lycos
- Artigos dos grupos de pesquisa relacionados
- Bibliotecas digitais da ACM, IEEE e IEE
- Livros científicos e didáticos
2.2 Fases da Pesquisa
Esta pesquisa é composta de cinco fases: planejamento e escolha do tema da
pesquisa, desenvolvimento da biblioteca de simulação JSDESLib, desenvolvimento
da ferramenta de simulação ClusterSim, desenvolvimento do algoritmo
reconfigurável RGSA e finalização da pesquisa. Cada fase é dividida em um
conjunto de etapas gerais (Quadro 1).
27
Fase 1 - Escolha do Tema e Planejamento da Pesquisa 1.1 Escolha do tema da pesquisa 1.2 Definição dos problemas iniciais da pesquisa 1.3 Definição de objetivos e metas 1.4 Levantamento bibliográfico inicial das áreas relacionadas com o tema 1.5 Planejamento de estudos e fases da pesquisa 1.6 Estudo da teoria ou conhecimento prévio relativo ao tema
Fase 2 - Desenvolvimento da Biblioteca de Simulação JSDESLib 2.1 Levantamento bibliográfico de bibliotecas de simulação 2.2 Estudo e seleção de bibliotecas de simulação 2.3 Análise comparativa das bibliotecas de simulação selecionadas 2.4 Proposta e implementação da biblioteca de simulação JSDESLib 2.5 Verificação e teste da biblioteca de simulação JSDESLib 2.6 Conclusões, documentação, escrita e submissão de artigos sobre a JSDESLib
Fase 3 - Desenvolvimento da Ferramenta de Simulação ClusterSim 3.1 Levantamento bibliográfico de ferramentas de simulação 3.2 Estudo e seleção de ferramentas de simulação 3.3 Análise comparativa das ferramentas de simulação selecionadas 3.4 Proposta do modelo de simulação da ferramenta ClusterSim 3.5 Proposta da arquitetura e implementação da ferramenta de simulação ClusterSim 3.6 Verificação e teste da ferramenta de simulação ClusterSim 3.7 Validação do modelo de simulação da ferramenta ClusterSim por meio de experimentos 3.8 Conclusões, documentação, escrita e submissão de artigos sobre o ClusterSim
Fase 4 - Desenvolvimento do Algoritmo Reconfigurável RGSA 4.1 Levantamento bibliográfico de computação reconfigurável e algoritmos de escalonamento
paralelo de tarefas 4.2 Estudo de computação reconfigurável e principalmente algoritmos reconfiguráveis 4.3 Estudo de algoritmos de escalonamento paralelo de tarefas e principalmente escalonamento
de gangues 4.4 Seleção e implementação de algoritmos de escalonamento paralelo de tarefas 4.5 Análise dos algoritmos de escalonamento paralelo de tarefas selecionados 4.6 Proposta e implementação do algoritmo reconfigurável RGSA 4.7 Verificação e teste da implementação do algoritmo RGSA 4.8 Seleção de métricas, arquitetura e carga de trabalho 4.9 Planejamento de experimentos 4.10 Teste, apresentação e análise de desempenho do algoritmo reconfigurável RGSA 4.11 Conclusões, documentação, escrita e submissão de artigos sobre o RGSA
Fase 5 - Finalização da Pesquisa 5.1 Discussão dos resultados finais 5.2 Conclusões finais 5.3 Elaboração do texto final da dissertação 5.4 Preparação de material para apresentação da dissertação 5.5 Escrita e submissão de artigos com os resultados finais 5.6 Planejamento de trabalhos futuros para a tese de doutorado 5.7 Defesa da dissertação de mestrado
Quadro 1: Fases e etapas da pesquisa Fonte: Dados da pesquisa
28
2.3 Métodos, Abordagens e Técnicas
Os métodos, abordagens e técnicas utilizados em cada uma das fases são
baseados principalmente nos seguintes trabalhos:
- Método de estudo de simulação apresentado em (LAW; KELTON, 1991).
- Abordagem para análise de desempenho de sistemas computacionais
apresentada em (JAIN, 1991).
- Métodos utilizados nos Projetos FIP 2001 e 2002 (MARTINS, 2001;
MARTINS; GÓES; RAMOS, 2002).
- Métodos e abordagens extraídos de artigos sobre desenvolvimento,
implementação e análise de desempenho de algoritmos de escalonamento paralelo
de tarefas (FEITELSON; RUDOLPH, 1992; WISEMAN; FEITELSON, 2003;
FRANKE, H., et. al., 1999; FRACHTENBERG, et al., 2003; ZHANG, et al., 2000;
ZHOU et al., 1999).
- Técnicas de verificação de implementações apresentadas em (JAIN, 1991;
LAW; KELTON, 1991).
- Abordagens de validação de modelos de simulação apresentadas em (JAIN,
1991; LAW; KELTON, 1991).
Somente nos capítulos desta dissertação referentes a cada fase da pesquisa
serão apresentados e discutidos: os detalhes sobre os métodos específicos,
abordagens de validação, técnicas de verificação, seleção de métricas, critérios de
avaliação, fatores, níveis e carga de trabalho.
29
3 ESTADO DA ARTE
Neste terceiro capítulo, apresentamos o estado da arte sobre escalonamento
paralelo de tarefas, computação reconfigurável e simulação. Este capítulo inicia-se
com uma introdução sobre processamento paralelo, descrevendo possíveis cargas
de trabalho e arquiteturas de um sistema computacional paralelo. Além disso,
discutimos diversas formas de modelagem da carga de trabalho. Em seguida,
apresentamos uma visão geral sobre escalonamento paralelo de tarefas. Dentro do
tópico de escalonamento paralelo, aprofundamos na classe de algoritmos de
escalonamento de gangues, nos quais aplicaremos os conceitos de computação
reconfigurável como proposta de solução do problema principal. Então,
apresentamos os conceitos de computação reconfigurável e classificamos os
trabalhos correlatos. Por último, descrevemos alguns tipos de simulação existentes,
enfatizando a simulação discreta por eventos.
3.1 Processamento Paralelo
Atualmente, o processamento paralelo é amplamente utilizado na indústria e no
meio acadêmico para a resolução de problemas complexos, que demandam alto
desempenho computacional. Normalmente, um sistema computacional paralelo é
composto de uma arquitetura paralela (aglomerado de computadores,
multiprocessador, etc.) e por uma carga de trabalho (tarefas paralelas, em lote e
interativas). As tarefas de uma carga de trabalho são executas em uma arquitetura
paralela (ALMASI; GOTTLIEB, 1994; BUYYA, 1999; HWANG; XU, 1998).
3.1.1 Arquitetura Paralela
Dentre os modelos de computadores descritos pela taxonomia de Flynn,
destacamos o modelo de computador paralelo MIMD (múltiplas instruções múltiplos
30
dados), no qual múltiplas instruções são executadas por vários elementos de
processamento, sobre diferentes conjuntos de dados. As arquiteturas paralelas
MIMD podem ser classificadas em duas classes principais: multiprocessador e
multicomputador. Um multiprocessador é composto por um conjunto de
processadores que compartilham uma memória física e um mesmo espaço de
endereçamento. Nessa classe de arquitetura, os processos de uma mesma tarefa se
comunicam por meio de escritas e leituras em variáveis compartilhadas na memória
(ALMASI; GOTTLIEB, 1994; BUYYA, 1999; HWANG; XU, 1998). Ao contrário dos
multiprocessadores, os multicomputadores são compostos de nodos com memórias
físicas independentes, ou seja, não compartilham um mesmo espaço de
endereçamento. Para um processo acessar um dado na memória de um nodo
remoto é necessária à troca de mensagens entre os nodos por meio de uma rede de
interconexão (BUYYA, 1999; HWANG; XU, 1998).
Entre os multicomputadores, destacamos a arquitetura de aglomerado de
computadores ou cluster. Todos os nodos de um aglomerado trabalham
coletivamente como um sistema único para prover serviços ininterruptos e eficientes.
Cada nodo pode ser um multiprocessador simétrico (SMP), estação de trabalho ou
computador pessoal independente. Geralmente, aglomerados possuem um baixo
custo financeiro, pois são construídos utilizando-se componentes de hardware COTS
(commodity-off-the-shelf) e software livre disponível (BUYYA, 1999; HWANG; XU,
1998). Uma apresentação e análise mais detalhadas sobre arquiteturas paralelas
podem ser encontradas em (ALMASI; GOTTLIEB, 1994; HWANG; XU, 1998).
3.1.2 Carga de Trabalho
A carga de trabalho de um sistema computacional paralelo é composta
basicamente de um conjunto de tarefas. Na literatura são encontradas algumas
definições para tarefa (ou “job”) (FEITELSON, 1994; TANENBAUM; WOODHULL,
2000). No contexto desta pesquisa, vamos definir tarefa como um conjunto de
processos relacionados entre si para a solução de um ou vários problemas, ou
simplesmente, uma aplicação paralela.
31
Estas tarefas são caracterizadas por um padrão de chegada, grau de
paralelismo, estrutura interna (barreiras, número de instruções, número de bytes
lidos e escritos na memória, requisitos de E/S, padrão de comunicação etc.) etc
(FEITELSON; RUDOLPH, 1997; FEITELSON, 2002). Uma tarefa pode ser modelada
de duas formas: por um conjunto de equações que descrevem seu comportamento
ou pela especificação de sua estrutura interna. Por meio de simulação ou métodos
analíticos detalhados, as tarefas modeladas são executadas e então as métricas de
desempenho (tempo de execução, tempo de reação etc.) são calculadas
(FEITELSON; RUDOLPH, 1997).
Existem duas fontes para se obter os dados sobre as tarefas: por meio de
logs de contabilidade ou pela coleta de dados específicos para um modelo de carga
(FEITELSON, 2002). Atualmente, os logs de execução são a fonte mais disponível
desses dados. Em Parallel (2005 ) são disponibilizados diversos logs de execução
de diferentes cargas de trabalho em diferentes arquiteturas paralelas. Geralmente,
esses logs possuem informações sobre o grau de paralelismo das tarefas, tempo de
chegada das tarefas, consumo total de recursos, tempo de execução das tarefas etc.
Apesar disso, existe muito pouca informação disponível sobre a estrutura interna
dessas tarefas executadas (FEITELSON; RUDOLPH, 1997; FEITELSON, 2002).
A partir de um log, podemos utilizá-lo como um trace para dirigir uma
simulação. O uso diretamente de um trace tem a vantagem de representar o sistema
com maior fidelidade, incluindo eventos incomuns e outras complexidades. As
principais desvantagens do uso de trace são: reflete uma carga de trabalho
específica, que geralmente não é representativa em outro sistema; nem sempre os
traces disponíveis possuem todos os dados necessários; existem casos nos quais a
carga de trabalho é dependente do sistema, não sendo representativa até mesmo
para o próprio sistema com outras configurações (FEITELSON, 2002).
Uma alternativa ao uso de traces é a coleta de dados para modelos de cargas
de trabalho (FEITELSON, 2003b). Se algum dado necessário não está disponível, é
necessário coletá-lo ou medi-lo, geralmente por meio de instrumentação. O maior
problema da instrumentação é ser intrusiva, interferindo no desempenho ou até
modificando o comportamento do sistema (FEITELSON, 2002). O mecanismo de
instrumentação menos intrusivo e mais preciso é o uso de contadores de hardware.
Os modelos de carga de trabalho apresentam uma série de vantagens sobre
os traces: é possível mudar os parâmetros do modelo um de cada vez, para
32
investigação da influência de cada parâmetro, enquanto mantém os outros
constantes; experimentos podem ser repetidos em situações estatísticas similares
(executar com diferentes sementes); a própria modelagem aumenta o nosso
entendimento, que pode levar a novos projetos. A abordagem mais comum utilizada
na modelagem da carga de trabalho é criar um resumo estatístico (uma ou um
conjunto de distribuições) da carga observada. Mas essa abordagem perde toda a
informação estrutural das tarefas. Um outro caminho é a modelagem da estrutura
interna das tarefas para criação de tarefas sintéticas parametrizadas (BATAT;
FEITELSON, 2000; FEITELSON, 2002; WISEMAN; FEITELSON, 2003;
FRACHTENBERG, et al., 2003). As tarefas sintéticas são usadas para testar
questões bem específicas, limitando fatores irrelevantes (neste contexto) que são
encontrados em aplicações reais (BATAT; FEITELSON, 2000).
Tanto os modelos de carga quanto os traces para sistemas paralelos
apresentam alguns problemas: falta de dados sobre E/S; falta da descrição da
estrutura interna das tarefas; não possuem feedback (seqüência de tarefas
dependentes); as falhas e interrupções do sistema não estão disponíveis (CHAPIN
et al., 1999). Mas de uma maneira mais ampla, o principal problema é o alcance de
uma alta representatividade, seja a modelagem mais complexa ou menos detalhada
(FEITELSON, 2002).
3.2 Escalonamento Paralelo de Tarefas
O escalonamento paralelo de tarefas é um problema no qual um algoritmo
procura alocar, ao longo do tempo, as diversas tarefas pertencentes a uma carga de
trabalho aos processadores de uma arquitetura paralela. Existem dois tipos
principais de escalonamento paralelo: estático e dinâmico (CAMPOS, 1999; EL-
REWINI; ALI; LEWIS, 1995; FEITELSON, 1994; KWOK; AHMAD, 1999; YAMI,
2001).
33
3.2.1 Escalonamento Paralelo Estático
O escalonamento paralelo estático consiste em atribuir tarefas para
elementos de processamento (mapeamento), de forma a minimizar o tempo total de
execução das tarefas.
Figura 1: Diagrama de um ambiente com escalonamento paralelo estático de tarefas. Fonte: Desenho de Luís Fabrício Wanderley Góes
No escalonamento estático, o mapeamento de tarefas na arquitetura ocorre
antes do início da execução (Figura 1). Uma vez iniciado o processamento, as
tarefas permanecem nos processadores aos quais foram alocadas, até que a
execução paralela seja encerrada, ou seja, as estratégias de escalonamento estático
são não-preemptivas. Portanto, o algoritmo de escalonamento precisa ter um bom
conhecimento sobre o tipo das tarefas, o tempo de execução das tarefas, as
relações de dependência e os padrões de comunicação entre as mesmas. A decisão
de escalonamento neste caso é geralmente centralizada e não adaptativa
34
(CAMPOS, 1999; EL-REWINI; ALI; LEWIS, 1995; KWOK; AHMAD, 1999; YAMI,
2001). Nesta pesquisa não detalharemos o escalonamento paralelo estático,
portanto o termo escalonamento paralelo será usado como sinônimo de
escalonamento paralelo dinâmico no restante do texto.
3.2.2 Escalonamento Paralelo Dinâmico
No escalonamento paralelo dinâmico, poucas suposições podem ser feitas sobre
as tarefas antes da execução, por esse motivo, as decisões de escalonamento
devem ser tomadas em tempo de execução.
Figura 2: Diagrama de um ambiente com escalonamento paralelo dinâmico de tarefas Fonte: Desenho de Luís Fabrício Wanderley Góes
35
A idéia básica do escalonamento paralelo de tarefas é realizar a ordenação e
a alocação dos processos de uma tarefa durante a execução da mesma (Figura 2).
A meta de um algoritmo de escalonamento paralelo não inclui apenas a minimização
do tempo de execução da tarefa, mas também a minimização da sobrecarga de
escalonamento, ou seja, o tempo gasto para coleta de informações, distribuição ou
até migração das tarefas. Nesse caso, o escalonamento pode ser preemptivo,
distribuído e/ou adaptativo (CAMPOS, 1999; FEITELSON, 1994; KWOK; AHMAD,
1999; YAMI, 2001).
No escalonamento paralelo de tarefas, os processadores podem ser
compartilhados por meio de compartilhamento de espaço e compartilhamento de
tempo. Esses tipos de compartilhamento utilizam mecanismos amplamente
independentes ou ortogonais, possibilitando uma combinação entre eles
(FEITELSON, 1994; HWANG; XU, 1998).
No compartilhamento de espaço, várias tarefas podem executar em partições
disjuntas ou grupos de nodos simultaneamente. Essa partição da arquitetura
paralela visa à diminuição da sobrecarga na troca de contexto, na qual no máximo
um processo é atribuído a um nodo em um dado momento. Apesar da partição de
nodos ser dedicada a apenas uma tarefa, a interconexão e o sistema de E/S podem
ser compartilhados pelas tarefas (FEITELSON, 1994; HWANG; XU, 1998). Uma
técnica de otimização de compartilhamento de espaço é chamada backfilling. Na
técnica de backfilling conservativa, tarefas são escalonadas para executar assim que
possível, contanto que elas não retardem uma tarefa que chegou mais cedo, ou
seja, ela tenta atribuir nodos inutilizados para tarefas que estão atrás na fila, ao
invés de mantê-los desocupados (FRANKE, H., et. al., 1999; HWANG; XU, 1998;
ZHANG, et al., 2000; ZHOU; BREN, 2001). Existe uma outra técnica chamada
backfilling agressivo, na qual as tarefas, para serem escalonadas, só não podem
atrasar o início da primeira tarefa da fila (FRANKE, et. al., 1999). As principais
vantagens do backfilling são: aumento da utilização do sistema e diminuição do
tempo de resposta das tarefas. A principal desvantagem é que o escalonador
necessita de uma estimativa de tempo de término da tarefa, geralmente indicada
pelo usuário (estimativas erradas podem levar a grandes erros no escalonamento)
(FRANKE, et. al., 1999; ZHANG, et al., 2000 ).
No compartilhamento de tempo, várias tarefas são atribuídas para um mesmo
nodo, ocorrendo troca de contexto entre elas (FEITELSON, 1994; HWANG; XU,
36
1998). O escalonamento de gangues (gang scheduling) é um tipo de combinação
dos compartilhamentos de espaço e tempo (FEITELSON, 1994).
3.2.3 Escalonamento de Gangues
O escalonamento de gangues foi introduzido por Ousterhout (1982) com o
nome de co-escalonamento. O seu objetivo era o uso eficiente de espera ocupada
para tarefas de sincronização de grão fino. O escalonamento de gangues é uma
combinação de três características: i) processos são agrupados em gangues; ii) os
processos de uma tarefa executam simultaneamente em processadores distintos; iii)
todos os processos de uma gangue são interrompidos (preempted) e re-escalonados
ao mesmo tempo, utilizando-se compartilhamento de tempo. Um grupo de processos
que se comunicam com muita freqüência deve ser escalonado ao mesmo tempo,
portanto esses processos devem ser agrupados em uma gangue. Normalmente,
todos os processos de uma tarefa paralela são considerados uma gangue
(FEITELSON, 1994).
As principais vantagens do escalonamento de gangues são: i) provê tempo de
resposta interativo para tarefas com baixo tempo de execução, por meio de
preempção; ii) evita que tarefas com alto tempo de execução monopolizem os
processadores; iii) aumenta a utilização do sistema na alocação de recursos
(FEITELSON, 1994; JETTE, 1997); iv) uma estimativa do tempo de término de uma
tarefa é desnecessária (ao contrário do backfilling) (ZHANG, et al., 2000 ); v) tarefas
podem ser iniciadas sem ter que esperar que todos os processadores requeridos
sejam desocupados (JETTE, 1997).
Como principais desvantagens, podemos destacar: i) a preempção aumenta a
sobrecarga na troca de contexto e pode reduzir o desempenho da cache
(FEITELSON, 1994); ii) necessidade de memória e disco adicional, porque várias
tarefas compartilham os mesmos processadores (BATAT; FEITELSON, 2000); iii)
fragmentação de tarefas (FRANKE, H., et. al., 1999; ZHOU, et al., 1999); iv)
enquanto processos realizam E/S ou comunicação bloqueante, os processadores
ficam ociosos (escalonamento de gangues restrito) (WISEMAN; FEITELSON, 2003).
37
3.2.3.1 Aspectos de Implementação
Para representar a alocação das tarefas aos processadores ao longo do
tempo, Ousterhout (1982) propôs uma matriz onde as colunas são os processadores
e as linhas são as fatias de tempo (Quadro 2). Durante cada fatia de tempo, os
processos de cada tarefa devem executar simultaneamente em seus respectivos
processadores. Portanto, devemos nos preocupar com cincos aspectos: número de
fatias de tempo, coordenação dos processos, esquema de empacotamento dos
processos, esquema de desfragmentação e pressão na memória (FEITELSON,
1994; FEITELSON, 1996; OUSTERHOUT, 1982; ZHANG, et al., 2000 ).
Processador 1 Processador 2 Processador 3 Processador 4
Fatia 1 Tarefa 1 Tarefa 1 Tarefa 1
Fatia 2 Tarefa 2 Tarefa 2 Tarefa 3
Fatia 3 Tarefa 4 Tarefa 4
Quadro 2: Matriz de Ousterhout Fonte: Dados da pesquisa
Cada fatia de tempo cria a ilusão de uma máquina dedicada às tarefas. O
número de fatias de tempo determina o nível de multiprogramação, ou seja, o
número de máquinas virtuais dedicadas. Portanto, quanto maior o número de fatias,
mais tarefas concorrem por um mesmo processador e conseqüentemente os tempos
de resposta das tarefas se tornam maiores que em uma máquina dedicada. Ao
mesmo tempo, uma tarefa demora menos tempo esperando na fila para começar a
ser executada. Dessa forma, tarefas com baixo tempo de execução, que esperariam
por muito tempo na fila, podem ser imediatamente executadas e terminadas em
menor tempo (FEITELSON, 1996; ZHANG, et al., 2000 ).
A coordenação dos processos é realizada por meio da troca de contexto
múltipla, em que geralmente um controlador central obriga todos os processadores a
realizarem troca de contexto ao mesmo tempo. Para isso, é necessário que a
diferença entre o tempo de início da primeira e o tempo de término da última troca de
contexto seja minimizada (FEITELSON, 1994). Geralmente existe um deamon local
38
em cada nodo, que é responsável por garantir a execução do escalonamento
necessário para a coordenação global (FRACHTENBERG, et al., 2003).
A troca de contexto múltipla pode ser implementada por meio de diversos
mecanismos: i) hardware de propósito específico; ii) broadcast de interrupções em
software; iii) relógios sincronizados; iv) sinais do sistema operacional; v) mudança de
prioridades dos processos (FEITELSON; RUDOLPH, 1992; FEITELSON, 1994).
Ao longo do tempo, novas tarefas são inseridas na matriz de Ousterhout,
enquanto outras tarefas são retiradas assim que terminam a execução. Essa
movimentação pode gerar fragmentação de tarefas nas fatias de tempo, ou seja, as
fatias de tempo subutilizarem os processadores disponíveis. Por meio de esquemas
de empacotamento, as tarefas são alocadas aos processadores (inseridas na matriz
de Ousterhout), procurando minimizar a fragmentação das tarefas.
Os algoritmos de empacotamento podem ser divididos em cinco categorias:
baseados na capacidade, baseados na esquerda-direita, baseados na carga,
baseados no companheiro (buddy) e baseados em migração (FEITELSON, 1996).
Os dois algoritmos de empacotamento mais difundidos são: primeiro encaixe (first fit)
e melhor encaixe (best fit). No primeiro encaixe, as fatias de tempo (slots) são
vasculhadas seqüencialmente, a primeira fatia com capacidade suficiente para
executar a tarefa é escolhida. Já no melhor encaixe, a fatia com a menor capacidade
que seja suficiente é escolhida. Outro algoritmo interessante é o baseado no
companheiro (FEITELSON, 1996; ZHOU et al., 1999). Ele é implementado por
meios de um controle hierárquico distribuído (DHC) composto por controladores que
organizam os processadores como um sistema companheiro. Um controlador
distinto é associado com cada bloco de processadores. O tamanho de cada bloco é
uma potência de dois. Um controlador no nível i coordena atividades envolvendo os
processadores da sua sub-árvore. Existem conexões laterais entre os controladores
de um mesmo nível para balanceamento de carga (FEITELSON; RUDOLPH, 1990;
FEITELSON; RUDOLPH, 1995a; FEITELSON, 1996).
Após ocorrer a fragmentação, existem alguns esquemas de desfragmentação
ou de re-empacotamento que podem ser utilizados, como escalonamento alternativo
e unificação de fatias (slot unification) (FEITELSON, 1994; FEITELSON, 1996;
ZHOU et al., 1999) (Quadro 3). No escalonamento alternativo uma tarefa é
escolhida para executar em mais de uma fatia, mas nos mesmos processadores,
diminuindo o tempo de resposta. Na unificação de fatias, quando uma tarefa termina,
39
existe a possibilidade que outras tarefas na mesma fatia usem processadores que
são distintos daqueles que são usados por tarefas de outras fatias. Isso possibilita a
unificação de duas fatias, reduzindo o número de fatias usadas em um e melhorando
a fração de execução de cada tarefa (FEITELSON, 1996).
Matriz de Ousterhout (estado inicial))
Processador 1 Processador 2 Processador 3 Processador 4
Fatia 1 Tarefa 1 Tarefa 1 Tarefa 1
Fatia 2 Tarefa 2 Tarefa 2 Tarefa 3
Fatia 3 Tarefa 4 Tarefa 4
Matriz de Ousterhout (escolamento alternativo))
Processador 1 Processador 2 Processador 3 Processador 4
Fatia 1 Tarefa 1 Tarefa 1 Tarefa 1 Tarefa 3
Fatia 2 Tarefa 2 Tarefa 2 Tarefa 3
Fatia 3 Tarefa 2 Tarefa 2 Tarefa 4 Tarefa 4
Matriz de Ousterhout (unificação de fatias)
Processador 1 Processador 2 Processador 3 Processador 4
Fatia 1 Tarefa 1 Tarefa 1 Tarefa 1 Tarefa 3
Fatia 2 Tarefa 2 Tarefa 2 Tarefa 4 Tarefa 4
Quadro 3: Esquemas de desfragmentação da Matriz de Ousterhout Fonte: Dados da pesquisa
Outro problema com o escalonamento de gangues é a pressão na memória,
que causa paginação e degrada o desempenho. A solução mais simples desse
problema é executar somente um subconjunto de tarefas, deixando as demais
esperando em uma fila (BATAT; FEITELSON, 2000).
3.2.3.2 Tipos de Escalonamento de Gangues
Existem diversos tipos de escalonamento de gangues além do tradicional ou
restrito, dentre os quais podemos destacar: escalonamento de famílias,
escalonamento preguiçoso de gangues, escalonamento emparelhado de gangues,
40
co-escalonamento dinâmico, co-escalonamento implícito, co-escalonamento flexível
e outros (FEITELSON, 1994; WISEMAN; FEITELSON, 2003; FRACHTENBERG, et
al., 2003; KARATZA, 2002). O escalonamento de famílias é uma variação do
escalonamento de gangues, em que o número de processos pode ser maior que o
número de processadores (FEITELSON, 1994). Já no escalonamento preguiçoso de
gangues cada tarefa possui um tempo de espera. Quando esse tempo é excedido, a
prioridade da tarefa é aumentada e os processos de baixa prioridade são
interrompidos, para que a tarefa execute. Após executar por um determinado tempo
sem interrupções, ela se torna candidata a ser interrompida, caso outra tarefa com
alta prioridade esteja esperando (FEITELSON, 1994).
O escalonamento emparelhado de gangues procura casar pares de gangues,
ou seja, executar duas gangues nos mesmos processadores, sendo uma gangue
caracterizada por um maior número de instruções de CPU e outra por instruções de
E/S. Como instruções de CPU e E/S utilizam dispositivos diferentes, as duas
gangues não interferem nas suas execuções, aumentando a utilização do sistema
(WISEMAN; FEITELSON, 2003).
O co-escalonamento procura escalonar e coordenar um grupo de processos
simultaneamente entre processadores distintos, mas se ele não consegue, ele
escalona apenas um subgrupo de processos (FEITELSON, 1994; PETRINI; FENG,
2000; SOLSONA, et al., 2001). No co-escalonamento dinâmico ou explícito, se uma
mensagem chega para um processo diferente do que está em execução, ele pode
interromper o processo atual e escalonar o processo receptor da mensagem
(PETRINI; FENG, 2000) (SOLSONA, et al., 2001). Uma variação do co-
escalonamento dinâmico, chamado co-escalonamento implícito, não se preocupa
com a coordenação global dos processos de uma gangue, deixando cada
escalonador local tomar as suas próprias decisões (FRACHTENBERG, et al., 2003)
(FEITELSON, 1994) (PETRINI; FENG, 2000) (SOLSONA, et al., 2001). Nele, um
processo que espera por uma mensagem, aguarda por um tempo determinado. Se a
mensagem chegar dentro desse tempo, o processo continua sua execução, senão
ele é interrompido (PETRINI; FENG, 2000; SOLSONA, et al., 2001).
Por último, o co-escalonamento flexível monitora a granularidade e a atividade
de comunicação de cada tarefa, usando escalonamento de gangues somente nas
tarefas que necessitam dele. Os processos de outras tarefas, que podem ser
escalonados sem restrições, são usados em processadores ociosos, no intuito de
41
diminuir a fragmentação (FRACHTENBERG, et al., 2003).
3.3 Computação Reconfigurável
A computação reconfigurável é um paradigma que tem o compromisso de
preencher o espaço existente entre as implementações em software e hardware,
atingindo maior desempenho que o software e mantendo um maior grau de
flexibilidade em relação ao hardware (COMPTON; HAUCK, 2002). Vários trabalhos
Compton; Hauck (2002); Ducasse; Hofmann; Nierstrasz (2000); Lesley; Fekete
(2001) Papadopoulos; Arbab (2000); Martins et al. (2002a) utilizam a palavra
“reconfiguração” como um sinônimo para flexibilidade, adaptabilidade e composição.
De acordo com Compton; Hauck (2002); Dehon; Wawrzynek (1999); Martins et al.
(2002a) Papadopoulos; Arbab (2000), relacionamos a palavra reconfiguração com o
aspecto de composição. Podemos definir um sistema reconfigurável como um
sistema composto de blocos construtivos ou componentes (unidades básicas de
computação) interconectados, em que o comportamento do sistema é determinado
pela topologia de interconexão entre os blocos construtivos e a lógica de
funcionamento de cada um deles. Então, o comportamento do sistema pode mudar
dinamicamente de acordo com a sua forma ou conexão espacial (DEHON;
WAWRZYNEK, 1999). Como conseqüência, o sistema se torna mais flexível e
adaptativo.
3.3.1 Hardware Reconfigurável
Os dispositivos de hardware reconfigurável, incluindo os FPGAs (field-
programmable gate arrays), contém um arranjo de elementos computacionais, nos
quais a funcionalidade é determinada pela programação de bits de configuração
(COMPTON; HAUCK, 2002; MARTINS et al., 2002a). Esses elementos, conhecidos
como blocos lógicos (ou construtivos), são conectados usando um conjunto de
recursos de roteamento que também são programáveis. Dessa maneira, circuitos
42
digitais podem ser mapeados para o hardware reconfigurável, computando funções
lógicas do circuito dentro dos blocos lógicos e usando o roteamento configurável
para conectar os blocos e formar o circuito necessário (COMPTON; HAUCK, 2002;
MARTINS et al., 2002a).
3.3.2 Software Reconfigurável
Um sistema computacional tradicional é dividido em camadas: aplicação,
algoritmo, linguagem, compilador, sistema operacional, arquitetura, conjunto de
instruções e micro-arquitetura (PATTERSON; HENNESSY, 1998). Os conceitos de
reconfiguração podem ser aplicados não somente aos dispositivos reconfiguráveis
(FPGAs etc.), mas em qualquer uma dessas camadas. Atualmente, esses conceitos
são principalmente utilizados nas camadas de aplicação, compilador (geração de
código executável), arquitetura, conjunto de instruções e micro-arquitetura. Podemos
dividir os trabalhos relacionados com computação reconfigurável (ou que
mencionam a palavra reconfiguração) em quatro grupos, onde os três primeiros
grupos representam a classe de software reconfigurável e o último grupo está mais
relacionado com hardware reconfigurável:
- Lógica Implementada ou Softwares de Configuração dos Dispositivos
Reconfiguráveis (BHATIA, 1997; COMPTON; HAUCK, 2002; HADLICH; NEUMANN,
1997; ROXBY; PRADA; CHARLWOOD, 1999; YAMAMOTO et al. 2000):
Nesse primeiro grupo, os trabalhos se referem aos softwares utilizados para
criação de configurações para o hardware reconfigurável e também a própria lógica
implementada por essas configurações (uma generalização do termo reconfigurável,
do hardware para o software). Esses softwares suportam desde a criação de
circuitos manualmente até sistemas completos e automatizados de projeto de
circuitos. Também estão incluídos neste grupo, os softwares que utilizam os
dispositivos de hardware reconfigurável para realização de processamento massivo
(cálculos matemáticos complexos etc.) durante a sua execução. O objetivo principal
desse grupo é criar configurações e utilizar os dispositivos de hardware
reconfigurável (FPGAs etc.).
43
- Arquitetura de Software Distribuída Reconfigurável (BRUNETON; COUPAYE;
STEFANI, 2002; CLARK, 1991; DUCASSE; HOFMANN; NIERSTRASZ, 2000;
LESLEY; FEKETE, 2001; PAPADOPOULOS; ARBAB, 2000; PAULA; JUSTO;
CUNHA, 2000; SALZMANN, 2002; STEWART; KHOSLA, 1996):
Neste grupo, a arquitetura do software é composta de duas entidades:
componentes (unidade primária de computação) e conectores (especifica os padrões
de interação e comunicação entre os componentes). Geralmente, cada componente
é um processo que se comunica com o ambiente por meio de interfaces bem
definidas. Um mecanismo de interface bastante interessante é o uso de portas de
entrada e saída. Esse mecanismo é principalmente utilizando em sistemas de tempo
real, dirigidos por controle e evento.
Essa idéia de conectar componentes ou módulos concretizou-se nas
linguagens para descrição de arquiteturas de software. As primeiras linguagens
foram as MILs (module interconnection languages), com a idéia de criar módulos e
interconectá-los. Depois vieram as ADLs (architectural description languages)
(PAPADOPOULOS; ARBAB, 2000), essas linguagens permitiam a descrição apenas
do software estático. Para descrever explicitamente os protocolos complexos de
coordenação entre os componentes do software, existem as linguagens de
coordenação e de arquitetura de software.
O problema principal abordado por este grupo de trabalhos é como descrever
e permitir que uma aplicação distribuída possa remover, adicionar e atualizar
módulos ou componentes do software dinamicamente, sem a necessidade de
reiniciar a aplicação. Geralmente, os ambientes distribuídos são extremamente
estocásticos, ou seja, comunicação e componentes podem ser perdidos. Portanto,
atualizações são necessárias para adaptação às novas configurações do ambiente e
aplicações de tempo real, muitas vezes, não podem ser interrompidas etc.
- Reconfiguração do Código Executável (ANCONA; LAGORIO; ZUCCA, 2002;
CANDEA; JONES, 1998; GAL; FRÖHLICH; FRANZ, 2002; KAMIN, 2001):
Neste grupo de trabalhos, os conceitos de reconfiguração são utilizados no
código executável da aplicação. O objetivo principal é permitir que após a
44
compilação e início da execução da aplicação, novos módulos (códigos) executáveis
sejam conectados ao código executável principal da aplicação. Dentre as técnicas
existentes, destacamos: recompilação dinâmica, compilação separada de código e
carregamento dinâmico. Na recompilação dinâmica, em tempo de execução, um
gerador de código traduz o código intermediário da aplicação em código de
máquina. Durante essa geração, o código pode ser otimizado, adaptado, expandido
ou alterado. Na compilação separada de código, um fragmento de código não pode
ser compilado isoladamente, mas pode ser compilado por meio de um ambiente, em
que existe informação sobre fragmentos que ainda estão faltando. Então, esses
fragmentos podem ser acrescentados ou conectados em tempo de execução. A
máquina virtual da linguagem Java permite o carregamento dinâmico de classes,
através do mecanismo User Class Loader.
- Reconfiguração em Hardware (BAXTER; ICARUS, 1999; CLARK, 1991; DEHON;
WAWRZYNEK, 1999; GAJJALAPURNA; BHATIA, 1998; WIGLEY; KEARNEY, 2001;
COMPTON; HAUCK, 2002; MARTINS et al., 2002a):
Os trabalhos mais importantes deste grupo estão nas camadas de arquitetura,
conjunto de instruções, micro-arquitetura e nos próprios dispositivos de hardware
reconfigurável. Nesta pesquisa, não entraremos em detalhes sobre este grupo.
No primeiro grupo, apesar de serem utilizadas expressões como “software
reconfigurável”, nós não consideramos que realmente são utilizados softwares
reconfiguráveis. Eles servem apenas como ferramentas para a configuração do
dispositivo de hardware reconfigurável ou são as próprias lógicas implementadas
representadas como bits (bitsream). Por último, é importante ressaltar que não
foram encontrados trabalhos que utilizassem conceitos de computação
reconfigurável na camada de algoritmo.
3.4 Simulação
Existem três classes de técnicas de análise de desempenho: experimentação,
modelagem analítica e simulação (JAIN, 1991). A experimentação sempre necessita
45
de um ambiente real, portanto, no contexto desta pesquisa, um aglomerado de
computadores pode ser muito caro, ou pode não existir. Além disso, o nível de
precisão varia muito, porque muitos parâmetros podem ser exclusivos daquele
experimento; geralmente ambientes reais são instáveis, dificultando a repetição dos
experimentos; é difícil o isolamento de partes, módulos e níveis do aglomerado etc.
Já a modelagem analítica precisa de muitas simplificações e suposições, além de
um especialista em modelagem. Apesar disso, um modelo analítico tem baixo custo
e pode ser usado para validar modelos de simulação e experimentação. Sistemas
complexos do mundo real com elementos estocásticos podem ser caros e também
de difícil descrição por meio de um modelo matemático. Então a técnica de
simulação aparece como uma alternativa com custo menor que a experimentação e
com menos simplificações que um modelo analítico (JAIN, 1991; LAW; KELTON,
1991).
Os modelos de simulação podem ser classificados de acordo com três
dimensões: estático ou dinâmico; determinístico ou estocástico; contínuo ou discreto.
Um modelo de simulação estático é a representação de um sistema em um instante
de tempo, enquanto o dinâmico representa um sistema à medida que ele evolui no
tempo. Em modelos determinísticos, a saída é conhecida uma vez que o conjunto de
entrada e as relações no modelo tenham sido especificadas. Quando um sistema
necessita de entrada aleatórias, o modelo de simulação se torna estocástico. Um
modelo é dito discreto quando as variáveis de estado do sistema mudam em pontos
específicos no tempo, enquanto em um modelo contínuo, as variáveis de estado do
sistema mudam continuamente (LAW; KELTON, 1991).
3.4.1 Tipos de Simulação
Existem quatro tipos de simulação mais conhecidos: emulação, Monte Carlo,
dirigida por fluxo (trace) e discreta por eventos (JAIN, 1991; LAW; KELTON, 1991). A
emulação é um tipo de simulação que simula um sistema utilizando outro,
geralmente, usando carga de trabalho real. As questões de projeto para emulação
estão geralmente relacionadas com o hardware. O Monte Carlo é uma simulação
estática, ou seja, a simulação de um fenômeno probabilístico que não muda suas
46
características com o tempo (não possui um eixo de tempo). A simulação dirigida por
fluxos utiliza um trace (um arquivo ordenado pelo tempo de eventos em um sistema
real) como entrada. As principais vantagens desse tipo de simulação são: fácil
validação (comparação com a carga real), entrada determinística e carga de trabalho
precisa. As desvantagens principais são: alta complexidade (modelo muito
detalhado) e baixa representatividade, ou seja, um trace de um sistema pode não
ser uma carga de trabalho representativa em outro sistema (JAIN, 1991; LAW;
KELTON, 1991).
A simulação discreta por eventos se preocupa com a modelagem de um
sistema que evolui ao longo do tempo, por meio de uma representação na qual as
variáveis de estado mudam em pontos discretos no tempo. Esses pontos são os
instantes em que os eventos ocorrem. Cada evento é definido como uma ocorrência
instantânea que pode mudar o estado do sistema (BUY, 2002; JAIN, 1991; LAW;
KELTON, 1991). Dentro do contexto desta pesquisa, a simulação discreta por
eventos é a mais interessante, pois um sistema paralelo evolui ao longo do tempo,
mudando de estado em pontos discretos no tempo.
3.4.2 Softwares para Simulação
Em uma simulação, utiliza-se um computador para executar um modelo
numericamente e os resultados são coletados para se estimar as verdadeiras
características desejadas do modelo (JAIN, 1991). Isso fornece um ambiente mais
detalhado, flexível e controlado. Dessa forma, analistas podem comparar algumas
alternativas com diversas cargas de trabalho. Além disso, existem várias tipos de
software que auxiliam no desenvolvimento de simulações: linguagens de simulação
(SIMSCRIPT (LAW; KELTON, 1991; SLAM; LAW; KELTON, 1991; LOW, 1999; A
COLLECTION, 2003; etc.), simuladores específicos ou ferramentas de simulação
(Gridsim (BUY, 2002), Simgrid (CASANOVA, 2001), SRGSim (BODHANWALA, et
al., 2001) (A COLLECTION, 2003 ) (SULISTIO; YEO; BUYYA, 2004; etc.) e
bibliotecas de simulação (SimJava, JSIM (LOW, 1999; MACNAB; HOWELL, 1996; A
COLLECTION, 2003; SULISTIO; YEO; BUYYA, 2004; etc.).
47
As linguagens de simulação poupam tempo no desenvolvimento da
simulação, porque elas possuem diversos mecanismos de simulação como avanço
de tempo, agendamento de eventos etc. Mas os programadores perdem tempo para
aprender a linguagem. Além disso, eles precisam de um novo compilador, perdendo
flexibilidade e portabilidade em relação a uma linguagem de programação de
propósito geral. As ferramentas de simulação são otimizadas para uma classe de
problemas, por isso não demandam tempo de desenvolvimento. Mas não existe uma
ferramenta de simulação desenvolvida para cada classe de problema existente, com
os requisitos desejados pelo usuário.
Já as bibliotecas de simulação são altamente portáteis (usam uma linguagem
de programação de propósito geral) e flexíveis. O programador precisa aprender
apenas um pequeno conjunto de métodos para construir a sua simulação. Portanto,
elas são um tipo de software fácil de usar e implementar. Além disso, o programador
pode criar uma simulação com todos os seus requisitos desejados. As principais
desvantagens das bibliotecas de simulação é o alto tempo gasto no
desenvolvimento da simulação, falta de otimização, checagem e análise de
compilador.
48
4 DESENVOLVIMENTO DA BIBLIOTECA DE SIMULAÇÃO JSDESLIB
Neste capítulo, apresentamos a proposta, desenvolvimento, implementação e
verificação da biblioteca de simulação discreta por eventos denominada JSDESLib.
4.1 Introdução
No contexto desta pesquisa, a biblioteca de simulação JSDESLib (Java
Simple Discrete Event Simulation Library) tem como objetivo principal fornecer
mecanismos básicos de simulação discreta por eventos, para que seja o núcleo para
o desenvolvimento da ferramenta de simulação ClusterSim. Além disso, ela é uma
biblioteca baseada em Java, simplificada e de fácil utilização, utilizada no
desenvolvimento de ferramentas baseadas em simulação discreta por eventos.
4.2 Trabalhos Relacionados
Dentre as diversas bibliotecas de simulação existentes, tais como JSIM,
ParaSol, SimKit, SimJava etc (LOW, 1999; A COLLECTION, 2003; SULISTIO; YEO;
BUYYA, 2004), estamos interessados em bibliotecas com as seguintes
características: implementação paralela, orientação por objetos, implementação em
Java, simulação discreta por eventos, simplicidade e facilidade de uso. A biblioteca
que melhor se adequou aos nossos requisitos foi o SimJava (MACNAB; HOWELL,
1996; SULISTIO; YEO; BUYYA, 2004).
O SimJava é uma biblioteca de simulação baseada em Java. Ele possui um
núcleo de simulação discreta por eventos e provê animação visual dos objetos
durante a simulação. Além disso, ele simula redes estáticas de entidades ativas
executadas em paralelo, que se comunicam através do envio de eventos por portas.
Cada porta de uma entidade é conectada à porta de outra entidade, por onde são
passados os eventos. A simulação é gerenciada pelo Sim_system que mantém uma
49
fila de eventos ordenada por tempo. As entidades utilizam três métodos básicos para
controlarem o seu comportamento dentro da simulação: schedule ( ), wait ( ) e hold
(t). O método schedule ( ) envia um evento para a entidade conectada a uma
determinada porta. Já o método wait ( ) faz com que uma entidade espere por um
evento. Por último, o método hold (t) bloqueia uma entidade por t unidades de tempo
de simulação. A simulação termina quando a fila de eventos se torna vazia
(MACNAB; HOWELL, 1996; SULISTIO; YEO; BUYYA, 2004).
Apesar do SimJava atender nossos principais requisitos, ele possui as
seguintes desvantagens: o uso de portas limita os eventos a apenas um destinatário
por porta, ou seja, não suporta o broadcast e nem multicast de um evento; o método
hold (t) é desnecessário na maioria das implementações e o uso explícito do método
wait ( ) pelo programador pode causar erros de sincronização na execução da
simulação. Além disso, o desenvolvimento de um conjunto básico de mecanismos de
simulação discreta por eventos não requer muito tempo e esforço. Portanto, com o
objetivo de simplificar o desenvolvimento de ferramentas de simulação, eliminar
algumas funcionalidades desnecessárias, acrescentar algumas novas
funcionalidades otimizadas e obtermos maior controle sobre a implementação,
optamos por desenvolver uma nova biblioteca de simulação, aproveitando algumas
características encontradas no SimJava.
4.3 Proposta da Biblioteca JSDESLib
A biblioteca de simulação paralela JSDESLib é baseada em simulação
discreta por eventos. Seu principal objetivo é simplificar a construção de ferramentas
de simulação discreta por eventos. Ela implementa o mecanismo de avanço para o
próximo tempo, no qual o relógio de simulação é avançado para o tempo do evento
mais eminente na fila de eventos. Ela também gerencia a comunicação entre as
entidades da simulação. Cada entidade possui um método body(), onde são
implementadas as ações para o tratamento de um evento (Quadro 4). O método
simSchedule ( ) é responsável por agendar um novo evento.
As principais características da biblioteca de simulação são:
- A biblioteca de simulação possui um método padrão para programação da
50
simulação. O método body ( ) é composto de uma estrutura de seleção, na qual o
programador utiliza apenas o método simSchedule ( ) para programar o
comportamento das entidades (Quadro 4). Principalmente por esse motivo, a
JSDESLib é uma biblioteca de fácil utilização.
- Chamadas de espera (wait ( ) não são necessárias, porque o método body
( ) das entidades recebe eventos automaticamente do simulador, até o fim da
simulação. Isso evita que usuários cometam erros de programação.
- Os eventos da fila são ordenados por tempo de relógio, então as entidades
que não interagem com outras entidades, podem escalonar todos os seus eventos
no mesmo momento.
- Um evento pode possuir mais de um destinatário.
Quadro 4: Trecho de código de uma entidade Fonte: Dados da pesquisa
4.4 Arquitetura e Implementação da Biblioteca JSDESLib
A JSDESLib é composta por cinco classes: Simulator, SimEntity, SimBarrier,
SimTags e SimEvent. A Figura 3 mostra a arquitetura da JSDESLib, na qual
entidades geram e recebem eventos por meio do simulador. A classe Simulator é
responsável por gerenciar a fila de eventos (instâncias da classe SimEvent) e
conseqüentemente a interação entre as entidades de simulação. Cada evento
class Entidade extends SimEntity { public void body(SimEvent event) { switch (event.getTag()) { case EVENT_A: . simSchedule(responseEvent); . break; default: . . . break; } } }
51
representa um acontecimento importante em um determinado instante de tempo que
muda o estado do sistema, até mesmo gerando novos eventos. Um evento deve
conter a identificação da entidade emissora, o instante de tempo em que o evento
vai ocorrer a partir do instante atual, a identificação do evento, as entidades
destinatárias e dados.
Figura 3: Arquitetura da JSDESLib
Fonte: Desenho de Luís Fabrício Wanderley Góes
As entidades devem se comunicar somente por meio de eventos, por isso,
dados são transmitidos juntos com os eventos. A fila de eventos é ordenada por
tempo, em que o relógio da simulação é sempre avançado para o tempo do evento
mais eminente. A simulação termina quando não existem mais eventos na fila ou um
certo tempo de simulação, definido pelo usuário, for atingido. A classe Simulator
também realiza a reciclagem de eventos, já que o coletor de lixo do JVM tende a
alocar mais memória para máquina virtual ao invés de recolher os objetos não mais
utilizados. Com isso, muitas vezes, a simulação ultrapassa o limite de memória,
interrompendo a simulação. A reciclagem de eventos reutiliza objetos da classe
SimEvent, que são os mais utilizados, sem a necessidade da intervenção do coletor
de lixo.
52
A classe SimEntity representa uma entidade de simulação. Como exemplo de
entidade, podemos citar um usuário, aglomerado ou nodo. No JSDESLib, cada
entidade é uma thread independente, possibilitando o uso de paralelismo. A classe
SimBarrier é responsável por sincronizar as entidades e o simulador. Quando o
simulador executa, ele remove o primeiro evento da fila e acorda as entidades
destinatárias. Então, o simulador bloqueia até que todas as entidades tenham
executado as suas respectivas ações sobre o evento. A classe SimTags apenas
define as constantes utilizadas na simulação como as etiquetas dos eventos.
4.5 Verificação e Teste da Biblioteca JSDESLib
Após a implementação da biblioteca JSDESLib, ela foi testada e verificada por
meio de técnicas de projeto orientado por objetos e execução de casos
simplificados. Como casos exemplos, simulamos a troca de eventos entre n
entidades, usando diferentes padrões de comunicação. Para cada exemplo,
utilizamos uma distribuição uniforme entre 0 e 100, para determinar os tempos de
chegada de cada evento nas entidades destino. Ao chegar um evento, a entidade
destino exibe o momento da chegada do evento. Esses testes têm o objetivo de
analisar a ordem de chegada e o número de eventos recebidos por cada entidade.
Com isso, podemos verificar tanto o funcionamento correto da ordenação da fila de
eventos, quanto à distribuição correta dos eventos para os destinatários.
Nesses testes de verificação, criamos apenas um tipo de evento chamado
chegada de evento. Os padrões de comunicação utilizados foram: um para todos
ponto-a-ponto, um para todos broadcast, todos para um, e todos para todos (Figura
4). O número de entidades variou em 2, 4, 8, 16 e 32.
53
Figura 4: Padrões de comunicação: (a) Um para todos ponto-a-ponto; (b) Um para todos broadcast; (c) Todos para um; (d) Todos para todos Fonte: Desenho de Luís Fabrício Wanderley Góes
Para todos os testes realizados, verificamos o funcionamento correto da
biblioteca tanto em relação à ordenação correta dos eventos, como na distribuição
correta dos eventos. Na Tabela 1, podemos observar o tempo de chegada dos
eventos, em cada entidade destino, para cada padrão de comunicação, com n = 4.
No caso do padrão todos para todos, esperamos que o número de eventos
recebidos por entidade seja igual a n-1, ou seja, para n = 4 seria 4 - 1 = 3.
TABELA 1
Tempo de chegada dos eventos
Padrão de Comunicação
Entidade
Um para Todos Ponto-a-Ponto
Um para Todos Broadcast Todos para Um Todos para Todos
Entidade 1 Nenhum Nenhum Evento 0: 72.96 Evento 2: 78.37 Evento 1: 86.69
Evento 6: 28.46 Evento 3: 62.27 Evento 9: 71.96
Entidade 2 Evento 0: 72.96 Evento 0: 72.96 Nenhum Evento 7: 24.49 Evento 10: 42.67 Evento 0: 72.96
Entidade 3 Evento 1: 86.69 Evento 0: 72.96 Nenhum Evento 4: 19.18 Evento 11: 75.21 Evento 1: 86.69
Entidade 4 Evento 2: 78.37 Evento 0: 72.96 Nenhum Evento 8: 15.07 Evento 5: 21.68 Evento 2: 78.37
Fonte: Dados da pesquisa
54
De acordo com a Tabela 1, como esperado, a distribuição dos eventos foi de
acordo com cada padrão de comunicação e os eventos destinados a uma mesma
entidade também chegaram na ordem cronológica. Ressaltamos que o número do
evento não tem relação com o tempo de chegada. Além dos testes descritos, a
biblioteca foi exaustivamente testada, em diversas situações, ao longo do
desenvolvimento da ferramenta ClusterSim.
4.6 Conclusões
De acordo com os objetivos desta pesquisa, a biblioteca de simulação
JSDESLib foi proposta, desenvolvida, implementada e verificada. A JSDESLib é uma
biblioteca que se limita a apenas fornecer os mecanismos básicos de simulação
discreta por eventos, tendo como maiores vantagens e contribuições: a simplicidade
e facilidade de uso; e uma implementação paralela e otimizada. O programador
necessita aprender obrigatoriamente apenas o método simSchedule ( ) para
desenvolver uma simulação, pois a JSDESLib automatiza a sincronização das
entidades e a distribuição dos eventos. Além da facilidade de uso, a implementação
da JSDESLib é otimizada, suportando paralelismo entre entidades e reciclagem de
eventos. O coletor de lixo do JVM tende a alocar mais memória para a máquina
virtual ao invés de recolher objetos não mais utilizados. Com isso, muitas vezes, a
simulação ultrapassa o limite de memória, interrompendo a simulação. A reciclagem
de eventos reutiliza objetos da classe SimEvent, que são os mais utilizados, sem a
necessidade da intervenção do coletor de lixo.
Como contrapeso à simplicidade e facilidade de uso, que são as
características principais da JSDESLib, ela não possui várias funcionalidades
encontradas nos trabalhos relacionados como: animação visual de objetos,
implementação distribuída, simulação hierárquica, etc. Mas é importante ressaltar,
que algumas dessas funcionalidades poderiam ser implementadas sem prejudicar a
facilidade de uso da JSDESLib.
A biblioteca JSDESLib, por não ser o enfoque principal da pesquisa, foi pouco
explorada e pode ser melhorada em muitos aspectos, entre os quais destacamos:
implementação distribuída utilizando sockets ou Java RMI; uso de consistência
55
relaxada na execução dos eventos; simulação hierárquica, permitindo a utilização de
múltiplos níveis ou filas de eventos etc.
56
5 DESENVOLVIMENTO DA FERRAMENTA DE SIMULAÇÃO CLUSTERSIM
Neste capítulo, apresentamos a proposta, o desenvolvimento, a
implementação, a verificação e a validação do ClusterSim, uma ferramenta de
simulação paralela discreta por eventos de escalonamento paralelo de tarefas em
aglomerados de computadores, desenvolvida em Java.
5.1 Introdução
No contexto desta dissertação, a ferramenta de simulação ClusterSim (Cluster
Simulation Tool) tem como objetivo principal fornecer um ambiente para simulação
de algoritmos de escalonamento paralelo de tarefas em aglomerados de
computadores. O ClusterSim é uma evolução do simulador RJSSim, que também
possui um enfoque didático. Por meio de seu ambiente gráfico, os usuários podem
facilmente construir, simular e analisar o desempenho de diferentes cargas de
trabalho e aglomerados de computadores.
5.2 Trabalhos Relacionados
Nos últimos anos, a simulação tem sido usada como uma técnica poderosa
para a análise de desempenho de sistemas computacionais (FEITELSON, 1996;
ZHANG, et al., 2000; ZHOU et al., 1999). Geralmente, os pesquisadores
desenvolvem ferramentas de simulação simplificadas de propósito específico e não
as descrevem com muito detalhe ou não disponibilizam os códigos fonte e os
binários. Na simulação de redes, aglomerados e grades, encontramos algumas
exceções que disponibilizam a documentação e o código fonte das ferramentas de
simulação desenvolvidas (BODHANWALA, et al., 2001; BUY, 2002; CASANOVA,
2001).
57
Dentre todos os trabalhos encontrados, a ferramenta de simulação de
escalonamento paralelo de tarefas, desenvolvida no Schark Group (SRGSim)
(BODHANWALA, et al., 2001), possui maior relação com o ClusterSim. Pois, ela
suporta a simulação de aglomerados com diferentes algoritmos de escalonamento
paralelo, topologias de rede e permite a modelagem de tarefas que utilizam
comunicação, processamento e E/S. Além dela, existem outras duas ferramentas de
simulação de escalonamento em arquiteturas em grade (GridSim e Simgrid) (BUY,
2002; CASANOVA, 2001), que apresentam características interessantes como a
modelagem de múltiplos usuários e nodos heterogêneos, um ambiente gráfico, etc.
Outras ferramentas de simulação podem ser encontradas em (A COLLECTION,
2003; (SULISTIO; YEO; BUYYA, 2004).
O GridSim é uma ferramenta de simulação baseada em Java e desenvolvida
na Monash University em Melbourne. Ele suporta modelagem e simulação discreta
por eventos de arquiteturas em grade heterogêneas, tal como mono ou
multiprocessadores, máquinas de memória compartilhada e distribuída, e
escalonamento de tarefas em sistemas paralelos e distribuídos (aglomerados de
computadores etc.). As principais características do GridSim são: modelagem de
arquiteturas de espaço e tempo compartilhados, interface para modelagem visual,
suporte a vários tipos de modelos de tarefas paralelas; as tarefas podem executar
instruções de CPU e E/S; co-existência de múltiplos usuários distribuídos;
escalonamento distribuído e alta portabilidade. O modelo de rede do GridSim é
simplificado e as tarefas não podem trocar mensagens entre si, além dos parâmetros
das tarefas serem descritos por constantes (não é possível usar um trace ou um
modelo probabilístico) (BUY, 2002; SULISTIO; YEO; BUYYA, 2002).
O Simgrid é uma ferramenta de simulação baseada em C++ e desenvolvida
na University of California em San Diego. Ele simula escalonamento de tarefas em
arquiteturas de tempo compartilhado, nas quais uma carga de trabalho pode ser
representada por constantes ou traces. O DAGSim é um simulador construído em
cima do SimGrid, que permite a representação de tarefas por meio de um Direct
Acyclic Graph (DAG). As principais características do Simgrid / DAGSim são:
escalonamento em DAGs, suporte à várias topologias de rede, predição com
comportamento de erro arbitrário e uso de simulação dirigida por fluxo (trace). No
modelo de simulação do Simgrid, as tarefas só possuem instruções de CPU e só
podem ser submetidas por um usuário. Além disso, o Simgrid não possui um
58
ambiente gráfico para modelagem da arquitetura em grade e ele utiliza mecanismos
simples de análise estatística (CASANOVA, 2001).
O SRGSim é uma ferramenta de simulação discreta por evento baseada em
Java e desenvolvida na University of California. Ele simula várias classes de
escalonamento de tarefas (dinâmico, estático e balanceamento de carga),
arquiteturas (aglomerados de computadores, MPPs etc.) e tarefas por meio de
modelos probabilísticos, constantes e DAGs. As principais características do
SRGSim são: provê um editor de DAG, as tarefas são descritas por traces, DAGs ou
modelos probabilísticos, as tarefas utilizam instruções de CPU, E/S e de
comunicação, várias topologias de rede podem ser simuladas e a ferramenta é
implementada de forma paralela utilizando sockets para comunicação. As principais
desvantagens são: possui apenas interface de texto, não possui implementação
multithreading, não suporta nodos heterogêneos e mecanismos que simulem as
funções de comunicação do Message Passing Interface (MPI) (BODHANWALA, et
al., 2001).
Apesar do SRGSim possuir um modelo de simulação probabilístico da carga
de trabalho bastante detalhado, o seu modelo não permite uma descrição estrutural
detalhada de uma tarefa, por meio de estruturas de repetição, diferentes funções de
comunicação etc. Além disso, a descrição probabilística da carga é menos
representativa, mas requer menor tempo de simulação. Portanto, a descrição
estrutural da carga torna a ferramenta ClusterSim mais representativa e com um
ambiente gráfico, ela facilita a sua utilização. Assim como o SRGSim, o ClusterSim
deve implementar funções de CPU, E/S e comunicação, que são essenciais para a
definição de padrões de comunicação, modelos de algoritmos e granularidade.
Em relação à arquitetura, tal como no Gridsim, o ClusterSim deve suportar
nodos heterogêneos. Mas também permitir a configuração de redes de interconexão
por meio de diversos parâmetros como topologia, latência etc., como o SRGSim e o
Simgrid.
Por último, a ferramenta ClusterSim necessita de um módulo estatístico e de
desempenho que forneça dados sobre as principais métricas para a análise de
desempenho dos algoritmos de escalonamento paralelo de tarefas.
59
5.3 Proposta e Implementação da Ferramenta ClusterSim
O ClusterSim (Cluster Simulation Tool) é uma ferramenta de simulação
paralela discreta por eventos de desempenho de escalonamento paralelo de tarefas,
em aglomerados de computadores, baseada em Java. Ele suporta modelagem
visual e simulação de aglomerados de computadores e das cargas de trabalho. Os
aglomerados são compostos de nodos mono ou multiprocessados, algoritmos de
escalonamento paralelo de tarefas, tecnologias e topologias de rede. As cargas de
trabalho são representadas por usuários, que submetem tarefas compostas por
processos, que são descritos por distribuições de probabilidades e pela estrutura
interna deles.
As principais características do ClusterSim são:
- Ambiente gráfico para modelagem de aglomerados e cargas de trabalho.
- O código fonte do ClusterSim é livre e suas classes podem ser estendidas,
provendo um mecanismo para a implementação de novos algoritmos de
escalonamento de tarefas, topologias de rede etc.
- As tarefas são representadas por estruturas de repetição e instruções de
CPU, E/S e comunicação. Dessa forma, a estrutura interna das tarefas representa as
das aplicações reais, possibilitando a implementação de qualquer modelo de
algoritmo paralelo e padrão de comunicação.
- Modelagem de aglomerados e nodos heterogêneos.
- As entidades de simulação (arquiteturas e usuários) são threads
independentes, provendo paralelismo.
- A maioria das funções de comunicação ponto a ponto e coletivas do MPI são
simuladas.
- A rede de interconexão entre os nodos é representada pela topologia,
latência, largura de banda, sobrecarga de protocolo, taxa de erro e MSS (maximum
segment size -tamanho máximo de segmento).
- Suporte a diversos algoritmos de escalonamento paralelo (compartilhamento
de espaço, escalonamento de gangues etc.) do aglomerado e também de cada nodo
(First-Come-First-Served (FCFS), etc.).
- Módulo estatístico e de desempenho que calcula diversas métricas.
- Suporte a diversas distribuições de probabilidade: normal, exponencial,
60
hiper-exponencial Erlang, uniforme etc. Elas são utilizadas para representar o
intervalo de chegada de tarefas e o grau de paralelismo dos processos.
- O tempo de duração da simulação e a semente podem ser especificados.
5.3.1 Arquitetura do ClusterSim
A arquitetura do ClusterSim é dividida em três camadas: ambiente gráfico,
entidades e núcleo (Figura 5). A primeira camada permite a modelagem e simulação
do aglomerado e da carga de trabalho por meio de um ambiente gráfico. Além disso,
ela provê dados estatísticos e de desempenho sobre cada simulação executada. A
segunda camada é composta por três entidades: usuário, aglomerado de
computadores e nodo. Essas entidades se comunicam por meio de troca de eventos
suportada pela biblioteca JSDESLib, que compõe o camada núcleo.
61
Figura 5 Arquitetura em camadas do ClusterSim Fonte: Desenho de Luís Fabrício Wanderley Góes
5.3.1.1 Ambiente Gráfico
O ambiente gráfico foi implementado utilizando o pacote swing do Java e o
compilador NetBeans 3.4.1, pela portabilidade e orientação por objetos providos pela
linguagem Java. Ele é composto de uma tela de configuração e execução da
simulação, três editores da carga de trabalho (usuário, tarefa e processo) e três
editores da arquitetura (aglomerado, nodo e processador). Por meio desse ambiente,
é possível modelar, executar, salvar e modificar diversos experimentos e ambientes
62
de simulação (Figura 6).
Assim como os editores do ambiente gráfico, o modelo de simulação é
dividido em carga de trabalho e arquitetura. No resto deste tópico, descrevemos o
modelo de simulação juntamente com o ambiente gráfico.
Figura 6: Tela principal do ambiente gráfico do ClusterSim
Fonte: Desenho de Luís Fabrício Wanderley Góes
5.3.1.1.1 Carga de Trabalho
Baseado nos trabalhos relacionados já apresentados, optamos por criar um
modelo de carga de trabalho híbrido usando distribuições probabilísticas para
representar certos parâmetros, como o grau de paralelismo e intervalo de chegada,
e a descrição da estrutura interna das tarefas. Nós julgamos que o uso do tempo de
execução das tarefas como um parâmetro, apesar de encontrado nos logs, é restrito
a uma configuração de carga de trabalho e arquitetura. Além disso, ele é
influenciado por diversos fatores como a carga, capacidade de processamento dos
63
nodos, sobrecarga na rede etc. Portanto, o tempo de execução deve ser calculado
durante a execução de uma simulação, de acordo com a carga de trabalho e
arquitetura simulada, ao invés de ser amostrado com base em outros contextos
específicos. Suponha que em uma determinada arquitetura, as tarefas gastam em
média 10 minutos de tempo de execução. Se simularmos a execução das mesmas
tarefas em uma arquitetura teoricamente 10 vezes mais rápida, esse valor não seria
mais representativo.
No lugar do parâmetro tempo de execução, utilizamos a representação
explícita da estrutura interna de cada tarefa. Essa abordagem possui diversas
vantagens: i) as tarefas reais podem ser representadas diretamente, sem
modificação nas suas estruturas; ii) o tempo de execução de cada processo é
calculado dinamicamente, influenciado apenas pelo ambiente em teste; iii) o
comportamento das tarefas se torna mais determinístico; iv) vários padrões de
comunicação e modelos de algoritmos paralelos podem ser implementados.
Diferentemente do tempo de execução, o grau de paralelismo é geralmente
indicado pelo programador que submete a tarefa. Portanto, ele normalmente não é
influenciado por fatores em tempo de execução. Então, o uso de uma distribuição
para representá-lo se torna bastante viável e representativo, apesar das variações
no número de nodos de um aglomerado.
Por último, o intervalo entre chegadas de tarefas também é representado por
uma distribuição de probabilidade, para evitar o uso de traces extensos. Além disso,
as distribuições exponenciais e mais recentemente a hiper-exponencial Erlang são
bastante utilizadas e aceitas pela comunidade acadêmica (FEITELSON; RUDOLPH,
1995a; JAIN, 1991; JETTE, 1997; SOLSONA, et al., 2001; ZHOU et al., 1999).
64
Figura 7: Editores de tarefa e processo Fonte: Desenho de Luís Fabrício Wanderley Góes
65
Para modelar a carga de trabalho é necessário utilizar três editores: usuário,
tarefa e processo. No editor de usuário é necessário especificar: o número de tarefas
a serem submetidas, a distribuição do intervalo de chegada e os tipos de tarefas.
Para cada tipo de tarefa deve-se especificar a sua probabilidade de submissão. A
soma destas probabilidades precisa ser igual a 100%. Os tipos de tarefas são
selecionados por meio do método de Monte Carlo, no qual um número aleatório
entre 0 e 1 é sorteado, indicando a tarefa a ser submetida. Para cada nova instância
de um tipo de tarefa submetida, novos valores são amostrados para o grau de
paralelismo de cada processo e intervalo de chegada.
O editor de tarefa (Figura 7) permite a especificação de uma tarefa por meio
de um grafo, no qual cada vértice é um processo e cada aresta representa a
comunicação entre dois processos. A partir do editor de tarefa, é possível editar
cada processo ativando o editor de processo (Figura 7).
No editor de processo são inseridas as instruções de CPU (qualquer instrução
que não seja para comunicação ou entrada e saída), E/S e MPI (comunicação) em
blocos de instruções e especificada a distribuição do grau de paralelismo. Cada
instrução tem a opção de ser paralelizada automaticamente de acordo com o grau
de paralelismo do processo ou dos processos com quem ele se comunica. Por
exemplo, suponha uma tarefa paralela que segue o modelo fazenda de processos.
Ela seria modelada com dois vértices: o processo mestre (grau de paralelismo igual
a 1) e o processo escravo (grau de paralelismo n). Se a opção de paralelização
estiver ativada na instrução de CPU do escravo, o número de instruções de CPU de
cada escravo seria igual ao número de instruções de CPU dividido pelo grau de
paralelismo n. Com isso, é possível verificar o ganho da paralelização de uma tarefa,
sem ter que implementar uma tarefa diferente para cada grau de paralelismo.
5.3.1.1.2 Arquitetura
Um aglomerado é composto de nodos homogêneos ou heterogêneos, redes
de interconexão, sistema de gerenciamento de tarefas, imagem de sistema único e
gerenciadores de passagem de mensagens e, em alguns casos, de memória
compartilhada distribuída. Cada nodo possui um ou mais processadores, uma
66
hierarquia de memórias, dispositivos de E/S e um sistema operacional (BUYYA,
1999; HWANG; XU, 1998). No nosso modelo de arquitetura, um aglomerado é
representado basicamente por nodos, um escalonador e uma rede de interconexão.
ProtocoloSobrecargaMSS
sagemTamanhoMenSobreCarga ×
=
(Equação 5.1)
( ) ( )610 daLarguraBan
TaxaErroSobreCargasagemTamanhoMenLatênciaissãoTempoTrasm
×+×++= 1
(Equação 5.2)
O escalonador implementa políticas de escalonamento paralelo como
compartilhamento de espaço, backfilling, escalonamento de gangues e outros. A
rede de interconexão é representada pelos seguintes parâmetros: latência (ns),
largura de banda (MB/s), sobrecarga de protocolo (bytes), taxa de erro (%), máximo
tamanho de segmento - MSS (bytes) e topologia (Figura 8 - Editor de Aglomerado).
Algumas topologias são suportadas, dentre elas destacamos: barramento e switch.
As equações 5.1 e 5.2 mostram a relação entre os parâmetros da rede para o
cálculo do tempo de transmissão de uma mensagem entre dois nodos
(PATTERSON; HENNESSY, 1998).
67
Figura 8: Editores de aglomerado e nodo
Fonte: Desenho de Luís Fabrício Wanderley Góes
No modelo de simulação do ClusterSim, cada nodo é representado pelos
seguintes parâmetros: escalonador, taxa de transferência da memória principal e
secundária e processadores (Figura 8). O escalonador implementa algoritmos
básicos como Round-Robin e FCFS. Além disso, ele implementa algoritmos que
garantam o funcionamento correto dos algoritmos de escalonamento paralelo do
aglomerado. A taxa de transferência da memória principal é utilizada pelo
68
gerenciador de MPI, ao receber e enviar dados. Já a taxa de transferência da
memória secundária serve para calcular o tempo gasto nas leituras e escritas das
instruções de E/S.
ruçõesNúmeroInstnstruçãoCiclosPorIFrequência
çãoTempoExecu ××= 1
(Equação 5.3)
Um nodo possui um ou mais processadores, em que cada processador é
representado pela freqüência do relógio e o número de ciclos por instrução. Para
calcular o tempo gasto para executar n instruções de um programa, o processador
utiliza a Equação 5.3.
5.3.1.1.3 Módulo Estatístico e de Desempenho
Para cada simulação executada, o ClusterSim fornece um log com o cálculo
de diversas métricas. As principais métricas calculadas são: tempo de resposta
médio dos processos e das tarefas; tempo de espera, submissão, início e finalização
de cada processo; slowdown médio das tarefas; utilização média por nodo; tempo de
reação médio das tarefas.
5.3.1.2 Entidades do ClusterSim
Cada entidade possui funções específicas dentro da simulação. As principais
entidades do ClusterSim são: usuário, aglomerado e nodo. O usuário é responsável
por submeter um determinado número de tarefas ao aglomerado seguindo um
padrão de intervalo de chegada. Além disso, cada tipo de tarefa possui uma
determinada probabilidade de ser submetida ao aglomerado. Essa submissão é
efetuada por meio da geração de um evento de chegada de tarefa. Ao receber esse
evento, o aglomerado deve decidir para quais nodos os processos da tarefa devem
69
ser encaminhados. Para isso, existe o escalonador do sistema de gerenciamento de
tarefas, que implementa determinado algoritmo de escalonamento paralelo. Outras
classes ou componentes importantes pertencentes à entidade aglomerado são: o
gerenciador de MPI, imagem de sistema único e rede de interconexão.
A imagem de sistema único funciona como um sistema operacional do
aglomerado, recebendo e encaminhando eventos para as classes responsáveis pelo
tratamento do evento. Além disso, ela gera periodicamente o evento de fim de fatia
de tempo, para indicar aos escalonadores de cada nodo, que mais uma fatia de
tempo se esgotou.
Para suportar passagem de mensagens entre os processos, as classes rede
e gerenciador de MPI implementam certos mecanismos básicos de comunicação.
Assim que um processo passa a executar uma função MPI (MPI_Send(),
MPI_Barrier() etc.), o gerenciador de MPI interpreta a função e caso seja uma função
de envio, ele aciona a classe rede, que gera um evento de chegada de mensagem.
O tempo gasto para a mensagem trafegar de um nodo para o outro depende da
topologia, parâmetros da tecnologia de rede e contenção. Quando um evento de
chegada de mensagem chega ao seu destino, o gerenciador de MPI gera um evento
de desbloqueio de processo, caso um processo esteja esperando. Caso contrário, a
mensagem é armazenada em uma fila de mensagens. Ao receber um evento de fim
de tarefa, o escalonador do aglomerado deve retirar a tarefa de execução. A Figura
9 mostra o diagrama de eventos do ClusterSim, detalhando a interação entre as
entidades usuário, aglomerado e nodo. Algumas classes foram omitidas no diagrama
para sua simplificação.
70
Figura 9: Diagrama de troca de eventos entre as entidades Fonte: Desenho de Luís Fabrício Wanderley Góes
Uma entidade aglomerado é composta de várias entidades nodo. Ao receber
um evento de chegada de tarefa, pela classe escalonador de nodo, o nodo
acrescenta os processos destinados a ele em uma fila de processos. A cada tique do
relógio global de simulação o escalonador é chamado para executar processos nos
processadores do nodo. Como cada processo é composto de instruções de CPU,
E/S e MPI (comunicação), ao final de cada uma dessas instruções um evento é
gerado. A cada processo é atribuído um quantum (intervalo de tempo), que quando
esgotado, deve gerar um evento de fim de quantum, para que o escalonador
execute as ações necessárias (trocar prioridades, retirar o processo da cabeça da
fila etc.). Quando o processador executa todas as instruções de um processo, um
evento de fim de processo é gerado para o escalonador.
5.3.1.3 Núcleo do ClusterSim
O núcleo é composto pela JSDESLib (Java Simple Discrete Event Simulation
Library), uma biblioteca multithread de simulação discreta por eventos em Java, que
tem como principal objetivo simplificar o desenvolvimento de ferramentas de
simulação baseadas em eventos, como já apresentado no capítulo 4 desta
dissertação.
71
5.4 Verificação e Teste da Ferramenta ClusterSim
Para verificar e testar a ferramenta, simulamos uma carga de trabalho simples
composta de duas tarefas e comparamos com a execução analítica da mesma
carga. Na Figura 5.6, cada grafo representa uma tarefa, no qual os nodos são os
processos e as arestas indicam troca de mensagens entre os processos. O valor em
cada nodo e aresta indica o tempo gasto em segundos para realizar o
processamento (instruções de CPU) ou comunicação. Por exemplo, a Tarefa 2
(Figura 10 (b)) representa uma fazenda de processos, na qual o processo mestre
envia dados para os escravos, que então processam esses dados e os retornam
para o processo mestre. Como o ClusterSim não utiliza o tempo de execução como
parâmetro de entrada, os tempos das tarefas foram convertidos para instruções de
CPU e bytes enviados.
Como uma arquitetura exemplo, criamos um aglomerado composto de 4
nodos homogêneos e um barramento, com a variação do algoritmo de
escalonamento paralelo (escalonamento de gangues, Round-Robin e FCFS). As
mensagens enviadas ao barramento são enfileiradas e enviadas uma a uma pela
ordem de chegada.
Figura 10: Tarefas da carga de trabalho para verificação do ClusterSim: (a) Tarefa 1; (b) Tarefa 2 Fonte: Desenho de Luís Fabrício Wanderley Góes
72
Nas Figuras 11, 12 e 13, podemos observar a execução analítica, passo a
passo, da carga de trabalho, para cada algoritmo de escalonamento paralelo. Cada
linha representa a execução dos processos das tarefas ao longo do tempo em um
nodo. É importante ressaltar que a rede de interconexão é um meio compartilhado e
permite que apenas uma mensagem seja enviada a cada momento.
Figura 11: Diagrama de execução das tarefas usando o algoritmo Round-Robin Fonte: Desenho de Luís Fabrício Wanderley Góes
O algoritmo Round-Robin apresentou o menor tempo de execução, pois ele
permite uma maior concorrência entre os processos de tarefas diferentes, ou seja,
quando um processo da tarefa 1 está comunicando, um processo da tarefa 2 pode
utilizar o processador. Já o FCFS, permite que apenas uma tarefa seja executada de
cada vez no aglomerado, portanto os recursos são pouco utilizados e as tarefas têm
um maior tempo de reação.
73
Figura 12: Diagrama de execução das tarefas usando o algoritmo FCFS Fonte: Desenho de Luís Fabrício Wanderley Góes
Por último, o algoritmo de escalonamento de gangues utilizou uma fatia de
tempo igual a 5 segundos e apresentou melhor resultado que o FCFS, mas pior que
o Round-Robin. O escalonamento de gangues obtém alto desempenho no
escalonamento de tarefas com baixa granularidade. As tarefas utilizadas no teste e
na verificação do ClusterSim se comunicam pouco e são caracterizadas pela alta
granularidade, mas apesar disso, o tempo de execução total foi menor que o FCFS,
pois o escalonamento de gangues permite a concorrência entre as tarefas,
aumentando a utilização dos recursos.
74
Figura 13: Diagrama de execução das tarefas usando o algoritmo de escalonamento de gangues com primeiro encaixe Fonte: Desenho de Luís Fabrício Wanderley Góes
A Tabela 2 mostra o tempo de resposta de cada tarefa obtido nas simulações
realizadas com o ClusterSim. Como observado, os valores são idênticos aos obtidos
pelo método analítico de execução. Com isso, verificamos o funcionamento correto
das principais funcionalidades e partes da ferramenta ClusterSim. Entre essas
funcionalidades e partes destacamos: geração, ordenação e entrega de eventos;
cálculo de tempo de transmissão e tempo de execução; algoritmos de
escalonamento; funções de comunicação ponto a ponto; instruções de CPU etc.
TABELA 2
Tempo de resposta de cada tarefa obtido na simulação
Algoritmo Tarefa
Escalonamento de Gangues Round-Robin FCFS
T1 65 60 45 T2 55 60 75
Fonte: Dados da pesquisa
75
As demais funcionalidades e partes não verificadas nesse exemplo, como
funções coletivas do MPI, instruções de E/S, outras tecnologias e topologias de rede
etc., foram verificadas exaustivamente por meio de testes individuais e mais
específicos. Esses testes não foram apresentados para simplificação da leitura e
entendimento do texto.
5.5 Validação do Modelo de Simulação
Depois da verificação das funcionalidades e componentes do simulador,
realizamos alguns experimentos reais para validação das partes de processamento
e comunicação do modelo de simulação implementado no ClusterSim.
Para validação do cálculo do tempo de processamento, instrumentamos o
código de uma aplicação de convolução de imagens seqüencial usando a biblioteca
PAPI. A aplicação de convolução é caracterizada por intenso cálculo matemático
utilizando-se matrizes. A biblioteca PAPI utiliza contadores de hardware para medir
com alta precisão as operações realizadas pelo processador e memória cache, por
exemplo, número de instruções, acessos a cache, etc.
Após instrumentar o código, executamos a aplicação com uma imagem com
resolução de 2048 x 2048 e uma máscara de convolução de 11 x 11, por 10
iterações, em um processador Intel Pentium III 1 GHz. Usando uma média
aritmética, extraímos as seguintes métricas necessárias para as simulações:
- Ciclos por Instrução (CPI) = 0.9997105
- Número de Instruções Executadas = 13328512173
- Tempo de Computação Total = 14.2053876 segundos
Para a simulação, modelamos e criamos uma máquina com um processador
com freqüência de 938 Mhz (freqüência real) e CPI médio de 0.9997105. Então,
criamos uma carga de trabalho (tarefa) que executava 13328512173 instruções de
CPU, para simular a aplicação de convolução. Após executarmos a simulação, o
simulador calculou o tempo de resposta da aplicação como 14.2053876 segundos,
exatamente como o medido. Portanto, validamos a parte de processamento do
ClusterSim. É importante ressaltar que se forem utilizadas cargas de trabalho
heterogêneas (diferentes conjuntos de instruções), o CPI pode mudar bastante.
76
Seria necessário executar diferentes aplicações e calcular um CPI médio para
aumentar a precisão da simulação.
Em relação à parte de comunicação, optamos por validar a função de
comunicação mais primitiva do MPI, o MPI_Rsend (), sobre o qual todas as outras
funções de comunicação (ponto-a-ponto e coletivas) são baseadas. Para isso
criamos um benchmark de rede para o cálculo da vazão máxima, latência e tempo
de transmissão de mensagens com tamanhos diferentes baseados no MPI_RSend
(). Então, executamos o benchmark em um aglomerado composto de dois nodos
conectados por meio de uma rede switch Gigabit Ethernet, configurado como Fast
Ethernet half-duplex, para simplificação. Usando o benchmark, que envia 100
mensagens iguais para dar maior confiança nas medidas, foram calculadas a
latência e a vazão com o mínimo e a média geométrica das execuções (Tabela 3).
TABELA 3
Latência e vazão da rede Fast Ethernet
Métrica Latência Vazão Máxima
Mínimo 0.179 ms 11.0516 MB/s Média Geométrica 0.243 ms 10.15504 MB/s Fonte: Dados da pesquisa
Depois de calculadas essas métricas, modelamos um aglomerado no
simulador e criamos uma carga de trabalho similar ao benchmark, variando o
tamanho da mensagem entre 0 bytes e 256 Kbytes, tanto na simulação quanto no
experimento real. Os resultados obtidos (tempo de transmissão) com os valores da
latência e vazão mínimo e médio estão mostrados na Tabela 4.
77
TABELA 4
Tempo de transmissão por tamanho de mensagem
Tamanho Mensagem Mínimo Média Geométrica
Simulação (s)
Real (s) Diferença (%)
Simulação
(s)
Real (s) Diferença (%)
0 1.79E-04 1.79E-04 0.00 2.43E-04 2.43E-04 0.10
1 1.79E-04 1.83E-04 1.87 2.43E-04 2.39E-04 1.74
2 1.79E-04 1.82E-04 1.28 2.43E-04 2.50E-04 2.56
4 1.79E-04 1.81E-04 0.90 2.43E-04 2.44E-04 0.35
8 1.80E-04 1.83E-04 1.52 2.44E-04 2.40E-04 1.42
16 1.80E-04 1.86E-04 2.98 2.45E-04 2.51E-04 2.43
32 1.82E-04 1.87E-04 2.47 2.46E-04 2.53E-04 2.66
64 1.85E-04 1.95E-04 4.99 2.49E-04 2.52E-04 1.26
128 1.91E-04 1.99E-04 3.99 2.56E-04 2.55E-04 0.42
256 2.02E-04 2.13E-04 4.86 2.68E-04 2.70E-04 0.68
512 2.25E-04 2.40E-04 5.91 2.93E-04 3.00E-04 2.14
1K 2.72E-04 3.12E-04 12.92 3.44E-04 3.65E-04 5.87
2K 3.70E-04 4.77E-04 22.51 4.50E-04 5.42E-04 16.86
4K 5.60E-04 6.47E-04 13.35 6.58E-04 7.28E-04 9.58
8K 9.47E-04 1.00E-03 5.71 1.08E-03 1.07E-03 0.99
16K 0.00172 0.001719 0.07 0.00192 0.001856 3.41
32K 0.00326 0.003144 3.70 0.003596 0.003561 0.99
64K 0.006341 0.006614 4.11 0.006949 0.00796 12.70
128K 0.012509 0.013312 6.03 0.013662 0.015571 12.26
256K 0.024845 0.025836 3.84 0.027086 0.029566 8.39
Fonte: Dados da pesquisa
78
Utilizando uma média aritmética das diferenças entre os valores medidos e
simulados encontramos 5.51% (mínimo) e 4.34% (média), com um desvio padrão de
5.42 e 4.92 respectivamente.
Com isso podemos dizer que a simulação da função MPI_RSend() foi
validada com experimentos reais envolvendo um benchmark. Consideramos a
diferença média de 5% aceitável, pois o modelo de simulação é simplificado, não
levando em conta: as pilhas de protocolos, o processamento das mesmas, possíveis
intervenções do sistema operacional, memória cache, cópias em buffers
intermediários e outros detalhes de um sistema real. Como a função MPI_Rsend()
serve como base (primitiva base) para todas as outras funções de envio executadas
pelo MPI, ou seja, todas as funções de envio são implementadas utilizando-se o
MPI_Rsend(), a validação da mesma leva a validação das outras funções coletivas
de envio do MPI e da parte de comunicação nos níveis mais baixos.
5.6 Conclusões
Neste capítulo, apresentamos a proposta, desenvolvimento, implementação,
verificação e validação da ferramenta de simulação ClusterSim. O ClusterSim
(Cluster Simulation Tool) é uma ferramenta de simulação paralela discreta por
eventos de desempenho de aglomerados de computadores, baseada em Java. Ele
possui um ambiente gráfico que facilita a modelagem e criação de aglomerados de
computadores e de cargas de trabalho (tarefas paralelas e usuários), para análise do
desempenho deles por meio de simulação. Um aglomerado de computadores é
composto por nodos homogêneos ou heterogêneos, um algoritmo de escalonamento
paralelo e uma rede de interconexão. Uma carga de trabalho é representada por
usuários que submetem tarefas modeladas por meio de distribuições probabilísticas
e descrições da estrutura interna dos processos.
Em relação aos trabalhos relacionados, o ClusterSim apresenta as seguintes
vantagens: ambiente gráfico para modelagem de aglomerados e cargas de trabalho;
um modelo híbrido (distribuições probabilísticas e descrições estruturais) de
representação da carga de trabalho que permite a modelagem de tarefas paralelas
reais, com instruções de repetição, CPU, MPI (comunicação) e E/S; módulo
79
estatístico e de desempenho que calcula diversas métricas (tempo médio de
resposta das tarefas, utilização média dos nodos etc.). Além dessas vantagens, o
Cluster possui o código fonte livre, possibilitando a extensão de suas classes para a
criação de novos algoritmos de escalonamento paralelo, topologias de rede etc.
O uso de um modelo híbrido de carga de trabalho torna a simulação mais
determinística que um modelo puramente probabilístico. Também elimina um erro
comumente cometido, o uso de parâmetros do modelo de desempenho, como tempo
de execução, no modelo da carga de trabalho, ao invés de utilizar as características
estruturais da carga, como o número de instruções.
A verificação e a validação do ClusterSim, por meio de métodos analíticos e
testes reais, mostrou que o ClusterSim provê mecanismos para repetição e
modificação de alguns parâmetros de experimentos sobre um ambiente controlado e
confiável. A validação completa do modelo de simulação de uma ferramenta por
meio de experimentos e/ou modelagem matemática é muito difícil, pois para cada
situação, os resultados teriam que ser re-validados. Então, optamos por validar
apenas os mecanismos básicos de comunicação e processamento do modelo de
simulação, pois são os mais utilizados pelo ClusterSim.
As principais desvantagens do ClusterSim são: modelo de simulação
complexo, que aumenta o tempo de simulação e o consumo de memória de acordo
com o número de tarefas submetidas; poucas implementações de topologias de
rede; não suporta a simulação de arquiteturas em grades; falta de um gerador de
gráficos estatísticos; não suporta simulação por meio de traces etc.
Algumas melhorias podem ser realizadas na ferramenta de simulação
ClusterSim, como: simulação em diferentes níveis de complexidade; a
implementação de novas topologias e tecnologias de rede; otimizações no código
para diminuição do tempo de simulação e utilização de memória; inserção de
recursos mais didáticos; a implementação de mecanismos de memória
compartilhada distribuída; simulação de arquiteturas em grades; a implementação
de um gerador de gráficos estatísticos; simulação por meio de traces etc.
80
6 DESENVOLVIMENTO DO ALGORITMO RECONFIGURÁVEL RGSA
Neste capítulo, apresentamos a definição, a proposta, o desenvolvimento, a
verificação e análise de desempenho do algoritmo reconfigurável de escalonamento
paralelo de tarefas nomeado como RGSA (Reconfigurable Gang Scheduling
Algorithm).
6.1 Introdução
Primeiramente, neste capítulo, apresentaremos a proposta do algoritmo
reconfigurável RGSA, para depois relacioná-la com os trabalhos correlatos. Dessa
forma, na comparação com os trabalhos correlatos, poderemos claramente destacar
as diferenças entre a nossa proposta e os trabalhos existentes. Em seguida,
apresentamos a implementação e a verificação do funcionamento do algoritmo
RGSA. Por último, mostramos os testes e a análise do desempenho do RGSA em
relação aos demais algoritmos tradicionais de escalonamento de gangues.
6.2 Proposta e Implementação do Algoritmo Reconfigurável RGSA
Estendendo a definição de hardware reconfigurável, definimos um algoritmo
reconfigurável como um algoritmo composto de blocos construtivos interconectados,
em que o comportamento do algoritmo é determinado pela topologia de interconexão
entre os blocos construtivos e a lógica de funcionamento de cada um deles. Então, o
comportamento do sistema pode mudar dinamicamente de acordo com a sua forma
ou conexão espacial.
Um algoritmo reconfigurável é composto por três camadas: Camada Básica
(CB), Camada Reconfigurável (CR) e Camada de Controle de Configuração (CCC),
como mostrado na Figura 14. A Camada Básica consiste de um conjunto de quadros
(frames) e estruturas de dados. Uma estrutura de dados pode ser uma lista, uma fila,
81
um arranjo ou alguma estrutura que armazene dados. Por exemplo, na Figura 15,
uma fila de espera (estrutura de dados) armazena tarefas (dados).
Figura 14: A arquitetura geral de um algoritmo reconfigurável composto de três camadas: Camada de Controle de Configuração (CCC), Camada Reconfigurável (CR) e Camada Básica (CB) Fonte: Desenho de Luís Fabrício Wanderley Góes
Um quadro representa uma parte ou fase de um algoritmo. Por exemplo, em
um algoritmo de escalonamento de gangues, um quadro pode representar um
esquema de empacotamento, que encaixa uma tarefa dentro da matriz de
Ousterhout, ou seja, ele é apenas uma parte do algoritmo de escalonamento de
gangues. Existem dois tipos de quadros: quadros de ação e de controle. Um quadro
de controle controla uma característica específica de uma estrutura de dados. Na
Figura 14, o Quadro de Níveis de Multiprogramação controla o nível de
multiprogramação da matriz de Ousterhout. Um quadro de ação é responsável por
processar ou mover dados entre ou dentro de estruturas de dados e quadros. Na
Figura 15, o Quadro de Esquemas de Empacotamento recebe uma tarefa do Quadro
82
de Políticas de Fila e a encaixa dentro na Matriz de Ousterhout.
A Camada Reconfigurável representa uma configuração ou instância da
Camada Básica, na qual todo quadro é preenchido com um ou mais blocos
construtivos em um certo momento. Por sua vez, um bloco construtivo é uma
possível implementação de um quadro específico. Por exemplo, o Quadro de
Esquemas de Desfragmentação, mostrado na Figura 16, pode ser preenchido com
diferentes esquemas de desfragmentação, como unificação de fatias e
escalonamento alternativo, um de cada vez ou vários simultaneamente. Então, cada
implementação de um esquema de desfragmentação é considerada um bloco
construtivo. Quando dois ou mais blocos construtivos preenchem simultaneamente
um quadro, eles são executados em seqüência ou em paralelo dependendo das
restrições do problema. O número máximo possível de blocos construtivos, que
preenchem um quadro, é o número de diferentes implementações conhecidas, por
exemplo, o número de esquemas de desfragmentação conhecidos.
A Camada de Controle de Configuração (CCC) escolhe os blocos construtivos
que preencherão cada quadro em um determinado instante, portanto ela controla a
troca de configuração, ou seja, a forma do algoritmo reconfigurável. Essa escolha é
feita baseada em parâmetros de entrada. Por exemplo, nós temos uma carga de
trabalho composta por tarefas longas e a métrica mais importante para o usuário é o
tempo de reação. Então, a CCC instanciará a configuração que reduza o tempo de
reação das tarefas longas. No nosso caso, a CCC deverá preencher o Quadro de
Níveis de Multiprogramação com o Bloco Construtivo Ilimitado, permitindo que uma
tarefa comece sua execução assim que submetida.
Um algoritmo pode ser considerado reconfigurável se: i) assumir diferentes
configurações durante a execução de uma carga de trabalho e ii) não assumir mais
de uma configuração em um mesmo instante da execução. A definição formal de um
algoritmo reconfigurável pode ser observada na Figura 15.
83
Figura 15: Definição formal de um algoritmo reconfigurável Fonte: Desenho de Luís Fabrício Wanderley Góes
Um algoritmo de escalonamento de gangues pode ser composto por quatro
partes: um esquema de empacotamento, um esquema de desfragmentação, uma
política de fila e um nível de multiprogramação. No RGSA, como mostrado na Figura
14, cada parte é um quadro diferente com dois possíveis blocos construtivos, para
simplificar o nosso estudo. Os três primeiros são quadros de ação e o último de
controle.
Figura 16: Uma configuração do Algoritmo Reconfigurável de Escalonamento de Gangues
Fonte: Desenho de Luís Fabrício Wanderley Góes
1 – (AR :⇔ ∀a ∈ A) (A ⊂ (F D)) α(fm) = bml
F = {f0, ... , fm}, D = {d0, ... , dp}, B = {b00, ... , bml} 2 – ¬ (AR :⇔ ai� �$5��⇔ aj), para i,j = 0 ... n, sendo i ≠ j, a ∈ A AR – algoritmo reconfigurável; A – conjunto de configurações; a – configuração ou algoritmo tradicional; F – conjunto de quadros; D – conjunto de estruturas de dados; B – conjunto de blocos; n – número de configurações; m – número total de quadros; p – número total de estruturas de dados; l – número total de blocos.
84
O Quadro de Esquemas de Empacotamento pode ser preenchido com dois
esquemas de empacotamento baseados na capacidade: primeiro encaixe ou melhor
encaixe. O Quadro de Esquemas de Desfragmentação pode ser preenchido com os
esquemas de desfragmentação: unificação de fatias e escalonamento alternativo. O
Quadro de Políticas de Fila pode usar as políticas First-Come-First-Served (FCFS)
ou Tarefa Menor Primeiro (Short Job First - SJF). Por último, o Quadro de Níveis de
Multiprogramação pode ser preenchido com os blocos de nível de multiprogramação
limitado ou ilimitado.
No RGSA, a CCC é implementada como uma tabela, como apresentada na
Tabela 14, figuraque sabe a priori qual a melhor configuração de acordo com alguns
parâmetros de entrada da carga de trabalho. Quando submetida, a carga de trabalho
precisa estar etiquetada com os seguintes parâmetros: tempo de execução (alto ou
baixo), grau de paralelismo (alto e baixo), grau de predominância (60%,80% ou
100%) e as métricas mais importantes (utilização (UT), tempo de reação (ReacT),
slowdown (SD), tempo de resposta (RespT) e/ou tempo de simulação(ST)). Então a
CCC avalia esses parâmetros e reconfigura o RGSA para a melhor configuração.
85
TABELA 5
Implementação da CCC
Parâmetros da Carga de Trabalho Caso
Métrica Tempo de Execução
Grau de Paralelismo
Grau de Predominância
Configuração
1 UT ou ST Alto Baixo 100 Conf 2
2 UT ou ST Baixo Alto 80 Conf 2
3 RespT Alto Alto 80 Conf 2
4 UT ou ST Baixo Baixo 100 Conf 4
5 RespT Baixo Baixo 80 Conf 4
6 UT ou ST Baixo Alto 100 Conf 5
7 ReacT Alto Alto 100 Conf 5
8 ReacT ou RespT ou SD Alto Baixo 80 Conf 5
9 RespT Baixo Alto 60 Conf 5
10 ReacT ou RespT Baixo Alto 80 Conf 5
11 ReacT Baixo Baixo 60 ou 80 ou 100 Conf 5
12 SD Baixo Baixo 100 Conf 5
13 SD ou ReacT Alto Alto 60 Conf 6
14 SD ou ReacT Alto Baixo 100 Conf 6
15 SD Baixo Baixo 60 ou 80 Conf 6
16 SD Alto Baixo 60 Conf 6
17 RespT Alto Alto 100 Conf 7
18 RespT Alto Baixo 100 Conf 7
19 RespT Baixo Baixo 100 Conf 7
20 UT ou ST Alto Baixo 80 Conf 8
21 UT ou ST Baixo Alto 60 Conf 8
22 RespT Alto Alto 60 Conf 8
23 RespT Baixo Alto 100 Conf 8
24 RespT Baixo Baixo 60 Conf 8
25 UT ou ST Alto Baixo 60 Conf 10
26 UT ou ST Alto Alto 60 ou 80 ou 100 Conf 11
27 UT ou ST Baixo Baixo 60 ou 80 Conf 11
28 ReacT Alto Alto 80 Conf 11
29 ReacT ou RespT Alto Baixo 60 Conf 11
30 SD Baixo Alto 60 Conf 11
31 ReacT ou SD Baixo Alto 100 Conf 12
32 SD Alto Alto 80 ou 100 Conf 12
33 SD Baixo Alto 80 Conf 12 Fonte: Dados da pesquisa
86
O backfilling necessita de uma estimativa do tempo de execução para todas
as tarefas com um parâmetro de entrada. Como descrito, o RGSA também necessita
de parâmetros de entrada, mas esses não precisam ser introduzidos diretamente por
cada usuário. Utilizando um histórico, dependendo da hora e dia, podemos
classificar ou dividir as cargas de trabalho em grupos, em um intervalo de tempo,
pelo grau de predominância de um tipo de tarefa. Por exemplo, na Figura 17, às
segundas-feiras, entre 0h e 6h, baseado em um log hipotético, notamos que todas
as tarefas executadas possuíam um alto tempo de execução e alto grau de
paralelismo (AA100%). No mesmo período, durante a noite, a métrica mais
importante é a utilização. De acordo com a implementação da nossa CCC, o RGSA
reconfiguraria para a configuração 11.
Figura 17: Exemplo de classificação de um log em sub-cargas, durante o tempo, por nível de predominância de um tipo de tarefa Fonte: Desenho de Luís Fabrício Wanderley Góes
Este processo de classificação pode ser realizado por um administrador do
sistema ou um sistema autônomo que examina arquivos de log e os classifica em
sub-cargas. Ao longo do tempo, a tabela da CCC poderá ser atualizada. Podemos
também utilizar tempos de ciclos ociosos para simular a última carga de trabalho
executada com diferentes configurações e atualizar a tabela para a melhor
configuração.
87
Como já é sabido, o comportamento do sistema tende a repetir ao longo do
tempo. Por exemplo, se na última segunda-feira a noite o RGSA encontrou que a
melhor configuração seria a 11, provavelmente esta configuração atingirá um bom
desempenho se ela for utilizada novamente no mesmo período.
A seleção da métrica mais importante pode ser feita de acordo com o grau de
predominância de tarefas interativas e batch em uma carga de trabalho. Para tarefas
interativas, os tempos de reação ou de resposta são geralmente mais importantes,
pois os usuários necessitam de uma resposta rápida. Para as tarefas em batch, a
utilização é mais importante, porque o administrador do sistema precisa utilizar o
máximo de recursos do sistema. A definição de limites entre tempo de execução e
grau de paralelismo altos e baixos devem ser determinados de acordo com cada
sistema.
6.3 Trabalhos Relacionados
Existem diversos trabalhos relacionados com o nosso trabalho (BATAT;
FEITELSON, 2000; FEITELSON; RUDOLPH, 1990; FEITELSON; NITZBERG, 1993;
FEITELSON; RUDOLPH, 1995a; FEITELSON, 1996; FEITELSON; RUDOLPH,
1997; FEITELSON, 2001; FEITELSON, 2002; WISEMAN; FEITELSON, 2003;
FRACHTENBERG, et al., 2003; JETTE, 1997; KARATZA, 2002; MONTANA, 2001;
PETRINI; FENG, 2000; SOLSONA, et al., 2001; SUBHLOK; VENKATARAMAIAH;
SINGH, 2002; ZHANG, et al., 2000; ZHOU et al., 1999; ZHOU; BREN, 2001). Esses
artigos podem ser divididos em quatro grupos: carga de trabalho e arquiteturas
utilizadas para análise de algoritmos de escalonamento paralelo, algoritmos de
escalonamento de gangues, softwares reconfiguráveis de escalonamento e
trabalhos relacionados com o problema.
Mesmo que muitos destes trabalhos não estejam diretamente relacionados
com o RGSA, eles fornecem informações sobre o tipo de carga e arquitetura
utilizadas para análise de desempenho de algoritmos de escalonamento de tarefas e
análises de algoritmos de escalonamento de gangues. Portanto, no tópico de
resultados da análise de desempenho, utilizaremos muitas informações encontradas
nesses trabalhos. Além desses, existem trabalhos que utilizam reconfiguração em
88
software para problemas de escalonamento em geral e escalonamento em máquinas
monoprocessadas, mas que não possuem características semelhantes com a nossa
proposta.
6.3.1 Arquiteturas Paralelas e Cargas de Trabalho
Inicialmente, vamos caracterizar a carga de trabalho utilizada para analisar
um algoritmo de escalonamento paralelo de tarefas. A carga de trabalho possui
como principais características o número de tarefas, tempo de execução, grau de
paralelismo e intervalo de chegada, além da estrutura interna. Nos próximos
parágrafos detalhamos e relacionamos os trabalhos encontrados com cada uma
dessas características.
Como já descrito, atualmente, não se encontram muitos dados sobre a
estrutura interna das tarefas. Apesar disso, a estrutura interna pode ser obtida com a
caracterização de aplicações reais e pseudo-aplicações encontradas em
benchmarks como o NPB (NAS Parallel Benchmark). Basicamente, a estrutura
interna de uma tarefa paralela pode ser modelada usando os modelos de algoritmo
paralelos existentes: paralelo por fases, pipeline, fazenda de processos (mestre
escravo), dividir e conquistar e reservatório de trabalho (HWANG; XU, 1998). Além
disso, é preciso definir a granularidade e o padrão de comunicação entre os
processos. A maioria das tarefas paralelas pode ser representada pelos modelos de
algoritmo paralelo por fases e mestre escravo (FRACHTENBERG, et al., 2003)
(PETRINI; FENG, 2000). Por exemplo, a maioria das tarefas do NPB é de
computação intensiva (alta granularidade), balanceadas e não gastam muito tempo
em comunicações bloqueantes e E/S. Os padrões de comunicação das tarefas do
NPB são: troca total e anel (SUBHLOK; VENKATARAMAIAH; SINGH, 2002). Como
outro exemplo, em (PETRINI; FENG, 2000), os padrões de comunicação das tarefas
utilizadas são: barreira, grade (cada processo troca mensagens com seus quatro
vizinhos) e troca total. Já a granularidade é bastante variável e definida pelo usuário.
O número de tarefas executadas em uma arquitetura paralela durante um
certo intervalo de tempo, encontrado nos logs disponíveis, varia entre 28490 e
201387 (FEITELSON, 2001; FEITELSON, 2002). Mas o número de tarefas
89
relevantes (retirando-se tarefas que não concluíram etc.) pode reduzir bastante esse
valor. Em testes de simulação com modelos analíticos esse número chega até
350000 tarefas em (FEITELSON; RUDOLPH, 1997). Alguns trabalhos com
simulação um pouco mais detalhada utilizam entre 100 e 10000 tarefas por
simulação (FEITELSON, 1996; ZHANG, et al., 2000; ZHOU et al., 1999). Para
testes de verificação de novas políticas de escalonamento de gangues, de 2 até 5
tarefas sintéticas são suficientes (BATAT; FEITELSON, 2000; WISEMAN;
FEITELSON, 2003; FRACHTENBERG, et al., 2003).
Quanto ao grau de paralelismo, algumas características foram identificadas:
tarefas com pequeno grau de paralelismo são mais comuns que as tarefas com
maior grau; geralmente o grau de paralelismo é uma potência de 2; mais de 100
processos por tarefa é um grau de paralelismo raro; vários usuários submetem uma
seqüência de tarefas com mesmo grau de paralelismo; muitas tarefas tem grau de
paralelismo igual a 32 (em máquinas de 128 e 256 processadores) (FEITELSON;
NITZBERG, 1993; FEITELSON, 1996; FEITELSON; RUDOLPH, 1997; FEITELSON,
2003b). Em Feitelson; Rudolph (1995a) Karatza (2002), o grau de paralelismo é
representado por uma distribuição uniforme, que pode ser alterada para amostrar
apenas potências de 2 (FEITELSON; RUDOLPH, 1995a). Em Zhang, et al. (2000 ),
tarefas com alto grau de paralelismo possuem mais que 32 processos.
O tempo de execução está diretamente relacionado com o grau de
paralelismo. Baseado nos logs disponíveis, quanto maior o grau de paralelismo,
maior o tempo de execução de uma tarefa, pois tarefas que utilizam poucos
processadores geralmente necessitam de executar por pouco tempo (FEITELSON;
NITZBERG, 1993; FEITELSON; RUDOLPH, 1997). Algumas características sobre o
tempo de execução foram levantadas: tarefas com grau de paralelismo pequeno
executam em menos de uma hora (FEITELSON, 2003b); poucas tarefas executam
em menos de 10 segundos (FEITELSON; NITZBERG, 1993). As tarefas que
executam abaixo de um certo limite (ex: 10 segundos) são chamadas interativas.
Acima deste limite, elas são chamadas tarefas em lote (FEITELSON; NITZBERG,
1993). O tempo médio de tarefas interativas, observado em (ZHOU et al., 1999), é 2
minutos. Em Feitelson; Rudolph (1995a) Karatza (2002) Solsona, et al (2001)), o
tempo de execução é representado por uma distribuição exponencial. Mas alguns
dos trabalhos Feitelson (2001) Zhang (et al., (2000) têm representado o tempo de
execução por uma distribuição hiper-exponencial Erlang proposta por (Jan97).
90
A distribuição hiper-exponencial Erlang também é usada para representar o
tempo de chegada de tarefas (JETTE, 1997). Em Batat; Feitelson (2000) Wiseman;
Feitelson (2003), todas as tarefas são disparadas no instante inicial do experimento.
Alguns trabalhos utilizam uma distribuição exponencial para representar o intervalo
de chegadas entre tarefas (FEITELSON; RUDOLPH, 1995a; SOLSONA, et al., 2001;
ZHOU et al., 1999).
O número de nodos das arquiteturas paralelas presentes nos logs e usadas
nas simulações e experimentos varia entre 16 e 1500 (em alguns casos, os nodos
são multiprocessados) (BATAT; FEITELSON, 2000; FEITELSON; RUDOLPH, 1990;
FEITELSON; NITZBERG, 1993; WISEMAN; FEITELSON, 2003; JETTE, 1997;
KARATZA, 2002; PETRINI; FENG, 2000; ZHANG, et al., 2000; ZHOU et al., 1999).
Os números mais típicos são 16, 32, 128 e 256 nodos respectivamente. As
especificações das arquiteturas variam muito, sendo difícil caracterizá-las.
6.3.2 Algoritmos de Escalonamento de Gangues
Em relação aos algoritmos de escalonamento de gangues, o nível de
multiprogramação pode ser limitado (2, 3, 5 etc) (JETTE, 1997) ou ilimitado
(FEITELSON, 1996). Cada fatia de tempo (quantum) varia entre 25ms, 1s e até 10
minutos (JETTE, 1997; WISEMAN; FEITELSON, 2003; FRACHTENBERG, et al.,
2003). A fatia de tempo deve ser grande o suficiente para minimizar a troca de
contexto e pequena suficiente para balancear a carga (PETRINI; FENG, 2000).
Em Feitelson (1996), várias conclusões são apresentadas em relação aos
esquemas de empacotamento: os baseados na capacidade e esquerda-direita
apresentam bom desempenho; os baseados na carga aumentam a fragmentação,
prejudicando muito o desempenho; os baseados no companheiro e migração
apresentam os melhores resultados, sendo que o baseado em migração não leva
em consideração a sobrecarga gerada pela migração. Nesse mesmo trabalho, a
unificação de fatias não melhorou o desempenho do sistema. Já o escalonamento
alternativo aumentou a utilização (entre 90% e 95% nos melhores casos, sem
considerar a troca de contexto) do sistema e diminuiu o tempo médio de resposta
das tarefas (FEITELSON, 1996). Ao contrário desse último trabalho, (ZHOU et al.,
91
1999) descobriu que o escalonamento alternativo não interfere no desempenho e a
unificação de fatias melhora o desempenho, devido à minimização do número de
fatias.
Em relação à pressão na memória, os resultados apresentados em (BATAT;
FEITELSON, 2000) apontam que a execução de todas as tarefas ao mesmo tempo é
mais ineficiente que deixar apenas um subconjunto de tarefas executando. Em
Zhou; Bren (2001), a limitação do número de tarefas com alto tempo de execução
executando sem limitar o nível de multiprogramação diminui a pressão na memória e
aumenta o desempenho médio das tarefas.
6.3.3 Softwares Reconfiguráveis de Escalonamento
Como apresentado no estudo do estado da arte, não foram encontrados
trabalhos sobre o uso de computação reconfigurável em algoritmos.
Em Candea; Jones (1998), é apresentado um sistema que permite o
carregamento dinâmico de algoritmos de escalonamento no núcleo do Windows NT.
Esse trabalho pode ser enquadrado no grupo de trabalhos relacionados com a
reconfiguração no código executável, portanto não é considerado um algoritmo
reconfigurável.
Em Montana (2001), é apresentado um escalonador “reconfigurável”, que
usando um algoritmo genético tenta encontrar uma solução ótima para um problema
genérico de escalonamento. O usuário especifica o problema por meio de alguns
parâmetros pré-estabelecidos. A palavra reconfiguração está associada ao fato de
poder mudar os valores dos parâmetros do problema. Portanto este escalonador não
é considerado realmente reconfigurável, de acordo com a nossa proposta. Além
disso, ele não é capaz de resolver problemas de escalonamento paralelo de tarefas.
Tal como Montana (2001), existem outros trabalhos que utilizam a palavra
reconfiguração com sentidos diferentes (ZHOU; ZHENG, 2000).
92
6.3.4 Trabalhos Relacionados ao Problema
Pela falta de trabalhos correlatos sobre o uso de computação reconfigurável
em algoritmos de escalonamento paralelo de tarefas, relacionamos o nosso trabalho
sob outros aspectos, que são diferentes do uso de reconfiguração. Para isso,
escolhemos dois trabalhos mais diretamente relacionados com o nosso problema,
mas que utilizam soluções diferentes (FRACHTENBERG, et al., 2003; FEITELSON,
1996).
Em Frachtenberg, et al. (2003), um algoritmo flexível de co-escalonamento é
proposto e implementado. Tal como a nossa proposta, ele utiliza um tratamento
diferente dependendo da carga de trabalho. O escalonamento de gangues é
utilizado somente em tarefas que necessitam dele, enquanto as outras podem ser
escalonadas sem restrição. Essa abordagem é limitada a duas opções de
escalonamento, além disso, o escalonamento de gangues utilizado é o tradicional,
sem modificações.
Em relação aos resultados experimentais, o trabalho Feitelson (1996) é o que
apresenta resultados mais próximos a nossa proposta. Ele compara diversos
esquemas de empacotamento e de desfragmentação, buscando um que seja o
melhor na média para as cargas de trabalho utilizadas. Portanto, ele não apresenta
a idéia de que um mesmo algoritmo possa assumir diversas configurações com
esquemas de empacotamento diferentes. Além disso, ele não varia outros
parâmetros como o nível de multiprogramação ou a política de remoção.
Depois do extenso levantamento bibliográfico e estudo dos trabalhos
relacionados, podemos dizer que a nossa proposta de escalonamento paralelo de
tarefas pode gerar uma contribuição inédita.
6.4 Teste e Verificação da Implementação do Algoritmo RGSA
A implementação do RGSA foi testada e verificada com sucessivos
experimentos utilizando exemplos como os apresentados na verificação do
ClusterSim. Ao final dos experimentos, a implementação do RGSA funcionou como o
93
esperado para todas as situações criadas e testadas.
6.5 Resultados da Análise de Desempenho
Neste tópico, apresentamos todos os resultados da análise de desempenho
do RGSA, obtidos por meio de simulação utilizando-se a ferramenta ClusterSim. O
nosso principal objetivo é mostrar que o uso de reconfiguração no algoritmo de
escalonamento de gangues apresenta melhor desempenho que nos algoritmos
tradicionais de escalonamento de gangues. Apenas um algoritmo tradicional não é
capaz de produzir o melhor resultado para todas as situações, para isso é
necessário um algoritmo reconfigurável que seja capaz de assumir diferentes formas
(configurações) em certos intervalos de tempo, de acordo com a carga de trabalho.
Como uma primeira etapa, descreveremos as métricas, arquitetura e carga de
trabalho utilizada nas simulações. Em seguida mostraremos o planejamento dos
experimentos, destacando as configurações utilizadas. Após a realização dos testes,
apresentaremos os resultados obtidos e analisaremos cada bloco das possíveis
configurações RGSA em relação a cada métrica utilizada. Por último, mostraremos,
analisaremos e discutiremos as vantagens e desvantagens do RGSA em relação
aos algoritmos tradicionais de escalonamento de gangues.
6.5.1 Seleção de Métricas, Arquitetura e Carga de Trabalho
6.5.1.1 Métricas
Para se analisar um algoritmo de escalonamento paralelo de tarefas,
podemos utilizar métricas bastante difundidas como utilização média, tempo médio
de resposta e tempo médio de reação de tarefas (FRANKE, H., et. al., 1999;
HWANG; XU, 1998; JAIN, 1991), ou então utilizar outras métricas como slowdown e
bounded-slowdown (FEITELSON; RUDOLPH, 1997; FEITELSON, 2001; ZHANG, et
94
al., 2000 ).
A utilização média mede a ocupação média dos nodos do aglomerado
durante um intervalo de tempo. A utilização média pode ser definida pela Equação
6.1, em que o Tempo Total é o intervalo de tempo para a execução da carga de
trabalho e CPU é o tempo em que pelo menos um processador do nodo ficou
ocupado. O valor da utilização é sempre entre 0 e 1 (FRANKE, H., et. al., 1999).
TempoTotalsocessadorePrNúmero
CPUMédiaUtilização Ocupado
×= ∑
(Equação 6.1)
O tempo de resposta média das tarefas (em segundos) é definido pela
Equação 6.2 (FRANKE, H., et. al., 1999) (JAIN, 1991). O tempo de resposta de cada
tarefa é o intervalo de tempo entre a sua submissão e finalização.
( )fasNúmeroTare
ssãoTempoSubmiizaçãoTempoFinalstaMédioTempoRespo ∑ −
=
(Equação 6.2)
O tempo de reação médio das tarefas é definido pela Equação 6.3 (FRANKE,
H., et. al., 1999; JAIN, 1991). O tempo de reação de uma tarefa é o intervalo de
tempo entre a sua submissão e o início de sua execução.
( )fasNúmeroTare
ssãoTempoSubmioTempoInícioMédioTempoReaçã ∑ −
=
(Equação 6.3)
O slowdown de uma tarefa é o tempo de resposta (tempo de reação + tempo
de execução) de uma tarefa em um sistema carregado dividido pelo tempo de
resposta em um sistema dedicado (tempo de execução). Na Equação 6.4 definimos
o slowndown médio das tarefas. Ele surgiu como uma solução para normalizar a
95
grande variação nos tempos de resposta das tarefas. Quanto mais próximo de 1,
melhor o slowdown de uma tarefa (FEITELSON; RUDOLPH, 1995a; FEITELSON,
2001; ZHANG, et al., 2000).
fasNúmeroTareçãoTarefaTempoExecu
faspostaTareReTempo
dioSlowdownMé∑
=
(Equação 6.4)
Por outro lado, essa normalização, tende a aumentar muito o slowdown de
tarefas curtas que esperam muito, pois o tempo de execução está no denominador.
Isso é resolvido com o uso da métrica bounded-slowdown. Ela é definida pela
Equação 6.5, onde �é um limite interativo para o tempo de execução de uma tarefa
considerada curta (FEITELSON, 2001; ZHANG, et al., 2000).
( )
= 1,
,maxmax
τçãoTempoExecuspostaReTempo
wdownBoundedSlo
(Equação 6.5)
Outras métricas mais específicas são utilizadas em outros trabalhos, dentre
elas destacamos: taxa de progresso (barreiras completas por segundo), taxa de
sucesso de casamentos entre tarefas, grau de co-escalonamento do sistema etc
(WISEMAN; FEITELSON, 2003; SOLSONA, et al., 2001).
Neste trabalho, optamos por utilizar as métricas: utilização média dos nodos,
tempo de resposta das tarefas, tempo de reação das tarefas, tempo de simulação e
slowdown médio das tarefas. Não utilizaremos o bounded-slowndown, pois é difícil
GHWHUPLQDU�XP�YDORU�SDUD�R�OLPLWH� ��TXH�WRUQH�RV�GDGRV�PDLV�UHSUHVHQWDWLYRV�VHP�VHU�tendencioso. Decidimos também utilizar o tempo de simulação médio para a
simulação, que mede o tempo gasto para a simulação da execução de uma
determinada carga de trabalho.
96
6.5.1.2 Arquitetura
O modelo de arquitetura selecionado para a simulação é um aglomerado
consistido de 16 nodos monoprocessados e um front-end com processadores Intel
Pentium III 1 GHz (freqüência real = 0.938 GHz) interconectados por um switch Fast
Ethernet. Esse número de nodos é comumente utilizado, além disso, reduz-se o
tempo de simulação para cada simulação. Aglomerados heterogêneos e com maior
número de nodos poderiam ser testados, mas aumentaria muito o número de
experimentos e os tempos de simulação. Por isso, utilizaremos apenas uma
arquitetura durante os testes. Na Tabela 5, apresentamos as características, e seus
respectivos valores, da arquitetura utilizada nas simulações. Esses valores foram
obtidos por meio de bibliotecas de desempenho e benchmarks (Sandra 2003, PAPI
2.3 etc.).
TABELA 6
Características da arquitetura do aglomerado de computadores
Característica Valor Característica Valor
Número de Processadores 16 + 1 Rede
Fast Ethernet
Freqüência do Processador 0.938 GHz Latência da Rede
0.179 ms
Ciclos por Instrução 0.9997105 Tamanho Máximo de Segmento 1460 bytes
Transferência da Memória Primária 11.146 MB/s Largura de Banda da
Rede(Vazão Máxima) 85 Mbps
Transferência da Memória Secundária 23.0 MB/s Sobrecarga de
Protocolo 58 bytes
Fonte: Dados da pesquisa
97
6.5.1.3 Carga de Trabalho
Uma carga de trabalho é composta de um conjunto de tipos de tarefas, suas
respectivas probabilidades de serem submetidas e estruturas internas, o número
total de tarefas e o intervalo de chegada entre elas. Devido à falta de informação
sobre a estrutura interna das tarefas, decidimos utilizar um conjunto sintético de
tarefas, mas ao mesmo tempo levando em consideração alguns aspectos
relacionados com as cargas de trabalho reais estudadas e analisadas.
Na literatura estudada não são encontrados dados a respeito do número de
instruções de cada tarefa, apenas sobre o tempo de execução. Como as tarefas no
ClusterSim são representadas pelo número de instruções ao invés do tempo de
execução, realizamos alguns testes preliminares. Para isso fixamos o modelo de
algoritmo como fazenda de processos (mestre/escravo) e o tamanho da mensagem
trocada entre o mestre e os escravos a cada iteração (16 KB). E variando o número
de instruções e a granularidade, determinamos tarefas com baixo e alto tempo de
execução. É importante ressaltar que tanto o número de instruções, quanto o
tamanho da mensagem é dividido pelo número de escravos e o processo mestre
apenas cuida da comunicação.
Na Tabela 6, apresentamos o tempo de execução de diferentes tipos de
tarefas utilizando os seguintes parâmetros:
- Granularidade Alta = 10 milhões de instruções
- Granularidade Baixa = 1 milhão de instruções
- Número de Instruções Alto = 1 bilhão de instruções
- Número de Instruções Baixo = 100 milhões de instruções
- Modelo de Algoritmo = Mestre/Escravo
- Tamanho da Mensagem = 16 KBytes
98
TABELA 7
Tempo de execução dos tipos de tarefas (segundos)
Grau de Paralelismo
Nº Instruções / Granularidade 1 4 5 16
Baixo / Baixo 106.92 27.38 22.22 9.43
Baixo / Alto 106.61 26.71 21.4 6.93
Alto / Baixo 1069.22 273.88 222.24 94.39
Alto / Alto 1066.13 267.19 214.06 69.38 Fonte: Dados da pesquisa
Como o grau de paralelismo é relativo ao número de processadores de um
aglomerado, fizemos uma proporção. Em máquinas paralelas com 128 e 256
processadores, tarefas com menos que 32 processos são consideradas pequenas.
Baseado na nossa arquitetura com 16 processadores, usando uma proporção,
consideramos tarefas com menos que 4 processos como pequenas e de 5 a 16
como grandes. Como apresentado nos trabalhos relacionados, utilizaremos uma
distribuição uniforme para representar o grau de paralelismo.
Para os próximos tópicos, utilizamos a seguinte notação para cada tipo de
tarefa: NI/Gr/GP, onde NI (Número de Instruções), Gr (Granularidade) e GP (Grau de
Paralelismo), que podem ter valor igual a A (Alto) ou B (Baixo). Com isso, temos
uma combinação de 8 tipos de tarefas diferentes.
Para testar as políticas de escalonamento de gangues, nós montamos 12
diferentes cargas de trabalho. Existem dois principais aspectos em que uma tarefa
pode influenciar no escalonamento de gangues: espaço e tempo. O espaço está
ligado ao grau de paralelismo de cada tarefa e o tempo ao resto dos fatores. Então
combinamos esses dois aspectos ortogonais para formar quatro tipos de carga de
trabalho, para tentar modelar a maior parte das cargas de trabalho possíveis. O
primeiro tipo é predominado por (a maioria das 60%, 80% ou 100%) tarefas com alto
grau de paralelismo e com uma estrutura que garanta um alto tempo de execução. O
segundo possui tarefas com alto grau de paralelismo e baixo tempo de execução. Já
o terceiro, possui a maioria das tarefas com baixo grau de paralelismo e alto tempo
de execução. Por último, o quarto tipo de carga de trabalho é predominado por
tarefas com baixo grau de paralelismo e com baixo tempo de execução. Cada um
99
desses tipos de carga de trabalho pode ser representado por uma porcentagem de
tarefas com as características principais da carga. Para cada tipo de carga, variamos
o grau de predominância em 60%, 80% e 100%. Por exemplo, a carga AA60 é
composta por 60% de tarefas do tipo A/*/A e 40% de outros tipos de tarefas. Na
Tabela 7, apresentamos as cargas de trabalho, as tarefas que as compõem e suas
respectivas probabilidades de serem submetidas.
TABELA 8
Descrição dos tipos de carga de trabalho
Carga de Trabalho
Tipo de Tarefa Porcentagem Carga de
Trabalho Tipo de Tarefa Porcentagem
AAA 30% BBA 30%
ABA 30% BAA 30%
BBB 20% AAB 20% AA60
BAB 20%
BA60
ABB 20%
AAA 40% BBA 40%
ABA 40% BAA 40%
BBB 10% AAB 10% AA80
BAB 10%
BA80
ABB 10%
AAA 50% BBA 50% AA100
ABA 50% BA100
BAA 50%
AAB 30% BBB 30%
ABB 30% BAB 30%
BBA 20% AAA 20% AB60
BAA 20%
BB60
ABA 20%
AAB 40% BBB 40%
ABB 40% BAB 40%
BBA 10% AAA 10% AB80
BAA 10%
BB80
ABA 10%
AAB 50% BBB 50% AB100
ABB 50% BB100
BAB 50% Fonte: Dados da pesquisa
100
Em todas as cargas utilizamos o número total de tarefas igual a 100 e o
intervalo de chegada representado por uma distribuição hiper-exponencial Erlang de
primeira ordem. Para simular uma carga mais pesada ou intensa, ou seja, maior
número de submissões de tarefas por intervalo de tempo, utilizamos um fator de
carga igual a 100. O intervalo de chegada é dividido por esse fator, intensificando a
submissão de tarefas. Este valor foi obtido através de testes preliminares.
6.5.2 Planejamento dos Experimentos
É importante notar que cada configuração do RGSA é um algoritmo
tradicional de escalonamento de gangues (Traditional Gang Scheduling Algorithm -
TGSA). Pois em um TGSA, suas partes são fixas e não podem ser alteradas durante
o tempo. Por exemplo, a Conf01 utiliza o primeiro encaixe, escalonamento
alternativo, nível de multiprogramação limitado e FCFS, e isso não pode mudar ao
longo do tempo. Até o fim do texto, os termos TGSA e configuração serão utilizados
como sinônimos.
Para avaliar o desempenho do algoritmo de escalonamento de gangues
reconfigurável (RGSA), utilizamos um modelo fatorial completo para realização dos
experimentos. Uma configuração do RGSA é composta por um esquema de
empacotamento, esquema de desfragmentação, nível de multiprogramação e uma
política de remoção. A Tabela 8 apresenta algumas das configurações possíveis do
RGSA. O valor do nível de multiprogramação limitado foi 3. Quando o nível de
multiprogramação é ilimitado, não faz sentido utilizar uma política de remoção, pois a
fila de espera não é utilizada.
101
TABELA 9
Configurações do RGSA
Configurações Esquema de Empacotamento
Esquema de Desfragmentação
Nível de Multiprogramação
Política de
Remoção
Conf 01 Primeiro Encaixe Escalonamento Alternativo Limitado FCFS
Conf 02 Primeiro Encaixe Escalonamento Alternativo Limitado SJF
Conf 03 Primeiro Encaixe Unificação Fatias Limitado FCFS
Conf 04 Primeiro Encaixe Unificação Fatias Limitado SJF
Conf 05 Primeiro Encaixe Escalonamento Alternativo Ilimitado Ñ Usado
Conf 06 Primeiro Encaixe Unificação Fatias Ilimitado Ñ Usado
Conf 07 Melhor Encaixe Escalonamento Alternativo Limitado FCFS
Conf 08 Melhor Encaixe Escalonamento Alternativo Limitado SJF
Conf 09 Melhor Encaixe Unificação Fatias Limitado FCFS
Conf 10 Melhor Encaixe Unificação Fatias Limitado SJF
Conf 11 Melhor Encaixe Escalonamento Alternativo Ilimitado Ñ Usado
Conf 12 Melhor Encaixe Unificação Fatias Ilimitado Ñ Usado
Fonte: Dados da pesquisa
Cada uma das 12 configurações do algoritmo RGSA foi testada com cada
uma das 12 cargas de trabalho utilizando 10 diferentes sementes de simulação, para
aumentar a confiabilidade estatística dos resultados. As sementes escolhidas foram:
51, 173, 19, 531, 211, 739, 413, 967, 733 e 13. Com isso, ao todo, foram realizadas
1440 simulações.
102
6.5.3 Apresentação e Análise dos Resultados
Esta seção foi organizada da seguinte maneira: para cada métrica utilizada,
apresentamos os valores médios obtidos para cada simulação (carga x
configuração) e também a análise de cada um dos blocos do RGSA em relação à
métrica. Ao final dessa seção, realizamos uma análise geral do algoritmo RGSA.
6.5.3.1 Análise da Utilização
A utilização é uma métrica muito importante do ponto de vista da utilização
dos recursos (processadores) de um aglomerado. Portanto, quanto maior a
utilização, menor a ociosidade do aglomerado. Na Tabela 6.6, apresentamos os
valores médios da utilização do aglomerado para as diferentes cargas de trabalho e
configurações do RGSA. É importante lembrar que cada configuração do RGSA é
considerada como um algoritmo tradicional de escalonamento de gangues.
Cada bloco do RGSA tem uma certa influência no desempenho do sistema.
Por isso, cada bloco do algoritmo deve ser analisado isoladamente. Para isso,
comparamos as linhas da Tabela 6.6 par a par. Por exemplo, para compararmos os
esquemas de empacotamento do bloco empacotador de tarefas, calculamos a
diferença entre a utilização média da Conf1 e Conf7, Conf2 e Conf8 etc., para cada
carga de trabalho. Usando esse procedimento, isolamos cada bloco do algoritmo. As
melhores configurações para cada carga de trabalho estão em destaque na Tabela
10. A camada CCC do RGSA reconfigura a camada reconfigurável de acordo com a
métrica e a carga de trabalho, para a melhor configuração encontrada nos testes
realizados.
103
TABELA 10
Utilização média
Fonte: Dados da pesquisa
Em relação ao esquema de empacotamento, quando o nível de
multiprogramação é ilimitado, o primeiro encaixe é bem melhor para as cargas AB e
BA. Em um primeiro momento, o esquema melhor encaixe encontra o melhor espaço
para uma tarefa, mas em longo prazo, essa decisão pode comprometer a entrada de
novas tarefas em posições mais apropriadas e até mesmo a eficácia dos esquemas
de desfragmentação. No caso de uma carga composta por tarefas AB e BA, essa
Cargas
Confg. AA60 AA80 AA100 AB60 AB80 AB100 BA60 BA80 BA100 BB60 BB80 BB100
Conf 01 0,5484 0,5747 0,5837 0,4310 0,4394 0,5415 0,3988 0,3886 0,5695 0,5237 0,4967 0,5314
Conf 02 0,6083 0,6253 0,6163 0,5588 0,5577 0,5663 0,5655 0,5241 0,6284 0,6042 0,6028 0,5527
Conf 03 0,5603 0,5704 0,5858 0,4164 0,4153 0,4983 0,3881 0,3544 0,5858 0,5275 0,5091 0,5105
Conf 04 0,6064 0,6254 0,6119 0,5405 0,5416 0,5169 0,5449 0,5032 0,6320 0,6015 0,6013 0,5685
Conf 05 0,6891 0,7137 0,6850 0,3258 0,4495 0,5082 0,3279 0,3376 0,6824 0,6636 0,6178 0,5118
Conf 06 0,6702 0,6851 0,6659 0,3000 0,4151 0,5022 0,2626 0,2500 0,6327 0,6515 0,6033 0,5205
Conf 07 0,5900 0,5992 0,6057 0,4139 0,4304 0,5508 0,3995 0,4055 0,6046 0,5580 0,5324 0,5414
Conf 08 0,6102 0,6235 0,6126 0,5573 0,5657 0,5631 0,5678 0,5131 0,6361 0,6142 0,6135 0,5655
Conf 09 0,5812 0,6003 0,6032 0,4700 0,4599 0,5392 0,4470 0,4262 0,5797 0,5489 0,5385 0,5411
Conf 10 0,6016 0,6177 0,6148 0,5656 0,5593 0,5632 0,5555 0,5046 0,6174 0,6048 0,6016 0,5659
Conf 11 0,6917 0,7140 0,6903 0,3309 0,3880 0,5063 0,2114 0,1886 0,6752 0,6651 0,6230 0,5030
Conf 12 0,6729 0,6849 0,6683 0,3053 0,3868 0,4926 0,2111 0,1747 0,6332 0,6519 0,5975 0,5279
104
chance de insucesso aumenta, pois as tarefas demoradas (longas) com baixo grau
de paralelismo, que restarem após a execução das tarefas curtas e com alto grau de
paralelismo, provavelmente ocuparão colunas em comum, dificultando a
desfragmentação da matriz. O primeiro encaixe, por sua vez, a princípio deixa a
matriz com mais espaços ociosos, além de aumentar o número de linhas da matriz,
mas em longo prazo isso facilitará a desfragmentação da matriz, pois as tarefas
terão menos colunas em comum.
Como observado no Gráfico 1, na média, quanto à utilização, o melhor
encaixe é um pouco melhor nos outros casos. Mas de uma maneira geral, podemos
concluir que os dois esquemas de empacotamento possuem desempenho
equivalente. Tal como a Figura 6.5, quando não especificado, o valor médio utilizado
é calculado como a média para todas as 12 cargas de trabalho.
Gráfico 1: Utilização média em relação aos esquemas de empacotamento. Fonte: Dados da pesquisa
Quanto ao esquema de desfragmentação, podemos notar que não existe uma
diferença significativa entre os dois esquemas de desfragmentação (Gráfico 2). Nas
cargas com nível de multiprogramação ilimitado, na média, o escalonamento
105
alternativo apresenta uma pequena vantagem. Pelo número maior de fatias ou linhas
da matriz, existe uma maior possibilidade de que uma tarefa seja executada em
diversas fatias diferentes, assim que outras tarefas forem terminando e deixando
espaços ociosos. Mas de uma maneira geral, podemos concluir que os esquemas de
desfragmentação utilizados são equivalentes, isso não quer dizer que eles não
interfiram no resultado. Eles são importantes, mas em um nível de igualdade.
Gráfico 2: Utilização média em relação aos esquemas de desfragmentação Fonte: Dados da pesquisa
Em relação ao nível de multiprogramação, tiramos duas conclusões: o
ilimitado é melhor para cargas AA e BB (Gráfico 3), mas é péssimo para cargas AB e
BA (Figura 6.8). Com nível de programação ilimitado, para cada nova tarefa que não
se encaixe na matriz, é criada uma linha nova. Como a taxa de chegada de tarefas é
alta, ao final da simulação, um número alto de linhas foi criado (É importante lembrar
que em cargas com predominância AA, as tarefas restantes são BB, ou seja, o caso
oposto.). Neste caso, as tarefas grandes são certamente as mais demoradas,
portanto mesmo quando as tarefas pequenas terminam, o espaço ocioso deixado
por elas é significativamente menor que o espaço ocupado pelas tarefas grandes, ou
seja, a fragmentação é bem pequena, maximizando a utilização do sistema.
106
Gráfico 3: Utilização média em relação ao nível de multiprogramação para cargas AA-
BB. Fonte: Dados da pesquisa
Gráfico 4: Utilização média em relação ao nível de multiprogramação para cargas AB-BA. Fonte: Dados da pesquisa
107
Quando cargas compostas de tarefas AB e BA são utilizadas, cada linha da
matriz será ocupada por tarefas com longa e curta duração. Ao longo do tempo, as
tarefas de curta duração irão acabar, deixando espaços ociosos na matriz, ou seja,
alta fragmentação. Esses espaços não serão preenchidos por novas tarefas, pois
todas já foram alocadas a matriz. Neste caso, as tarefas grandes não são
garantidamente as mais demoradas, por isso muito espaço na matriz pode ser
desperdiçado. Mesmo utilizando esquemas de desfragmentação, a fragmentação é
pouco reduzida.
Quanto às políticas de remoção da fila de espera, de acordo com a Gráfico 5,
a política SJF apresentou melhores resultados (maior utilização) em todos os casos,
pois removendo as tarefas pequenas (menor grau de paralelismo) primeiro, existe
uma maior probabilidade de haver fatias desocupadas na matriz de Ousterhout em
que elas se encaixem. No caso do FCFS, se a primeira tarefa for uma tarefa grande
(maior grau de paralelismo), ela acaba não entrando na matriz e impede que outras
tarefas pequenas possam ser executadas. Com isso, algumas fatias na matriz são
desperdiçadas, ficando ociosas e diminuindo a utilização do sistema.
Gráfico 5: Utilização média em relação às políticas de remoção
Fonte: Dados da pesquisa
108
Quando existe predominância da carga AA, a diferença entre as políticas
diminui, pois a maioria das tarefas é grande, ocupando boa parte de cada fatia e não
restando espaço para a entrada de outra tarefa grande na mesma fatia. Para cargas
homogêneas (com 100% de predominância), a diferença entre as políticas é também
reduzida, pois as tarefas possuem aproximadamente o mesmo grau de paralelismo
(alto ou baixo). Portanto, a escolha da primeira ou menor tarefa não influencia tanto
na utilização. Mas mesmo assim, a escolha da tarefa menor ainda apresenta
melhores resultados.
Devido ao alto tempo de execução, quando existe a predominância da carga AB,
pequenos espaços, geralmente localizados nas colunas finais da matriz, são
desperdiçados por um longo período de tempo utilizando-se a política FCFS. Já com
a política SJF, estes pequenos espaços são preenchidos por outras tarefas
pequenas que estão na fila de espera. Da mesma forma, utilizando-se a política
FCFS, a predominância da carga BA, faz com que a matriz tenha pequenos espaços
ociosos nas fatias por pequenos períodos de tempo, mas com grande freqüência.
Com o uso da política de remoção SJF, esses pequenos espaços nas fatias são
preenchidos por tarefas pequenas, aumentando a utilização do sistema.
6.5.3.2 Análise do Tempo de Reação
O tempo de reação é uma métrica muito importante do ponto de vista do
usuário interativo. Portanto, quanto menor o tempo de reação, menos tempo um
usuário esperará para que sua tarefa inicie a sua execução. Na Tabela 11
apresentamos os valores médios do tempo de reação das tarefas para as diferentes
cargas de trabalho e configurações do RGSA.
109
TABELA 11
Tempo de reação médio (segundos)
Cargas
Conf.
AA60 AA80 AA100 AB60 AB80 AB100 BA60 BA80 BA100 BB60 BB80 BB100
Conf01 3299.7 4129.5 4980.1 3785.1 5100.4 4621.6 2703.2 1345.8 295.2 2253.8 1244.2 298.8
Conf02 2082.2 3308.1 4878.4 4015.0 4641.3 4796.4 2860.0 1485.0 313.7 1050.2 492.6 267.0
Conf03 3212.7 4201.1 4982.1 3821.7 5076.7 5041.0 2782.8 1472.2 294.9 2238.7 1233.6 255.9
Conf04 2071.1 3363.9 4938.4 4139.6 4770.0 5602.2 2953.6 1592.5 303.2 1072.8 469.0 288.7
Conf05 11.9 13.6 20.3 6.9 4.5 3.7 9.3 11.3 12.9 6.9 5.1 3.3
Conf06 10.2 14.8 22.6 6.8 4.9 3.6 9.6 13.3 15.1 7.7 5.5 3.7
Conf07 3145.8 4014.0 4770.3 3971.1 5188.2 4499.6 2811.6 1217.3 301.5 2140.5 1156.0 259.8
Conf08 2066.3 3356.0 4941.8 3975.9 4513.3 4903.3 2896.7 1577.4 268.5 1054.1 498.4 284.2
Conf09 3126.0 3980.1 4829.9 3293.3 4788.8 4494.7 2254.2 1135.2 305.9 2193.9 1175.8 285.8
Conf10 2101.1 3415.4 4899.2 3910.6 4613.8 4859.0 2933.4 1564.1 301.3 1094.8 476.9 297.4
Conf11 11.4 12.8 26.5 6.5 5.2 4.9 9.0 13.3 13.7 8.0 6.8 4.1
Conf12 12.0 13.8 23.0 6.7 5.6 4.7 9.0 12.8 10.8 8.1 6.8 4.1
Fonte: Dados da pesquisa
Em relação aos esquemas de empacotamento, eles influenciam pouco no
tempo de reação das tarefas, pois eles dependem da nova tarefa que foi retirada da
fila de espera pela política de remoção. Apesar disso, a inserção de uma tarefa em
uma determinada posição da matriz pode permitir ou não a entrada de outra tarefa
em um curto período de tempo. Para essas simulações, os dois esquemas
selecionados são equivalentes (Gráfico 6).
110
Gráfico 6: Tempo de reação médio em relação aos esquemas de empacotamento
Fonte: Dados da pesquisa
Em relação aos esquemas de desfragmentação, eles também pouco
influenciam no tempo de reação, pois a desfragmentação ocorre após o início da
execução das tarefas. Mas mesmo assim, a unificação de fatias pode
ocasionalmente liberar uma nova linha após a unificação de duas linhas, quando se
utiliza o nível de multiprogramação limitado. O escalonamento alternativo também
pode permitir que uma tarefa, que entrou em uma fatia que está longe de ser
executada, possa ser executada antecipadamente em espaços ociosos de uma
outra fatia. Mesmo assim, na média, os dois esquemas escolhidos são equivalentes
(Gráfico 7).
111
Gráfico 7: Tempo de reação médio em relação aos esquemas de desfragmentação
Fonte: Dados da pesquisa
O nível de multiprogramação influencia diretamente o tempo de reação, pois
com um número ilimitado de linhas, sempre haverá espaço para uma nova tarefa
começar a ser executada sem ter que esperar na fila. Uma tarefa terá no máximo um
tempo de reação igual ao número de linhas da matriz (fatias de tempo) multiplicado
pelo quantum ou tempo de cada fatia. Em relação às demais configurações, que
possuem uma fila de espera e um nível de multiprogramação limitado, o tempo de
reação das configurações com nível de multiprogramação ilimitado é desprezível, ou
seja, o tempo de reação das configurações com nível limitado é bem maior (Gráfico
8).
112
Gráfico 8: Tempo de reação médio em relação ao nível de multiprogramação Fonte: Dados da pesquisa
Em relação às políticas de remoção, na média, como mostrado na Figura
6.13, a política de remoção SJF é melhor (menor tempo de reação) que a FCFS,
principalmente para uma carga composta de tarefas AA e BB. Quando não existe
espaço na matriz para a primeira tarefa, a política FCFS espera até que alguma(s)
tarefa(s) termine(m) e liberem espaço para a primeira tarefa da fila. Já a SJF remove
a menor tarefa da fila, assim que haja espaço para ela na matriz. Com isso, as
tarefas tendem a esperar menos tempo na fila, pois não dependem da primeira da
fila, apenas dos espaços existentes na matriz. Mas apesar disso, utilizando a política
SJF, as tarefas com alto grau de paralelismo podem ficar muito tempo na fila,
aumentando muito o seu tempo de reação e conseqüentemente o tempo médio de
reação das tarefas.
113
Gráfico 9: Tempo de reação médio às políticas de remoção
Fonte: Dados da pesquisa
6.5.3.3 Análise do Tempo de Resposta
O tempo de resposta é uma métrica dependente tanto do tempo de reação,
quanto do tempo de execução de uma tarefa. Portanto, quanto menor o tempo de
reação e o tempo de execução, menos tempo um usuário esperará para que uma
tarefa termine a sua execução. Na Tabela 12, apresentamos os valores médios do
tempo de resposta das tarefas para as diferentes cargas de trabalho e configurações
do RGSA.
114
TABELA 12
Tempo de resposta médio (segundos)
Cargas AA60 AA80 AA100 AB60 AB80 AB100 BA60 BA80 BA100 BB60 BB80 BB100
Conf 01 3531.9 4414.2 5307.2 4296.6 5812.8 5856.0 3037.4 1512.5 329.0 2428.0 1377.0 429.5
Conf 02 2362.9 3620.9 5230.3 4913.1 5797.2 6079.5 3438.2 1770.8 350.1 1288.3 681.4 421.1
Conf 03 3446.2 4490.3 5311.4 4379.7 5911.0 6398.3 3142.2 1666.4 328.8 2419.8 1371.3 396.3
Conf 04 2350.6 3678.3 5294.6 5055.1 5980.2 7036.5 3573.5 1893.9 339.9 1308.9 661.1 440.8
Conf 05 3423.8 5159.6 7263.9 3840.0 5388.3 7524.9 2072.2 842.0 507.8 2123.7 1096.1 529.9
Conf 06 3844.1 5586.3 7397.5 4496.9 5996.5 7747.7 2579.6 1063.4 455.9 2370.0 1242.7 553.9
Conf 07 3363.1 4285.5 5086.9 4454.4 5890.1 5749.4 3129.1 139.2 332.8 2309.3 1281.4 392.9
Conf 08 2342.7 3666.5 5295.8 4852.5 5648.7 6184.0 3466.4 1864.2 303.1 1285.6 685.3 435.9
Conf 09 3346.0 4252.5 5147.8 3887.7 5572.4 5773.6 2623.1 1323.4 338.6 2360.5 1307.3 422.9
Conf 10 2382.6 3734.5 5250.65 4806.7 5769.3 6155.1 3540.4 1867.4 337.0 1332.5 665.7 45.18
Conf 11 3406.7 5044.1 7341.2 3610.8 5620.8 7517.4 2758.4 1350.3 423.4 2153.2 1097.0 521.8
Conf 12 3768.2 5534.2 7482.4 4239.5 6149.2 7785.2 3026.6 1475.5 457.8 2323.9 1285.5 566.8
Fonte: Dados da pesquisa
Como mostrado nos Gráficos 10 e 11, tanto os esquemas de empacotamento
quanto os de desfragmentação possuem, na média, desempenho equivalente entre
si.
115
Gráfico 10: Tempo de resposta médio em relação aos esquemas de empacotamento
Fonte: Dados da pesquisa
Gráfico 11: Tempo de resposta médio em relação aos esquemas de desfragmentação
Fonte: Dados da pesquisa
116
O nível de multiprogramação influencia o tempo de resposta diretamente.
Quando o nível de multiprogramação é ilimitado, as tarefas têm um pequeno tempo
de reação, mas em compensação o tempo de execução tende a ser maior por
existirem mais fatias de tempo (maior concorrência). Ao final da execução de cada
tarefa, no tempo de execução da tarefa vem embutido o tempo de reação como se o
nível de multiprogramação fosse limitado. De acordo com o Gráfico 12, na média, as
configurações com nível de multiprogramação ilimitado tendem a ser pior que as
com nível limitado, ou seja, a concorrência entre as tarefas na matriz aumenta mais
o tempo de resposta do que a espera das tarefas na fila. Mas é importante ressaltar
que para certas cargas de trabalho, o contrário acontece.
Gráfico 12: Tempo de resposta médio em relação ao nível de multiprogramação
Fonte: Dados da pesquisa
Quanto às políticas de remoção, chegamos a duas conclusões: a política SJF
é melhor para as cargas AA e BB, e a política FCFS é melhor para as cargas BA e
AB. No primeiro caso (Gráfico 13), as tarefas BB são executadas em primeiro lugar,
terminando rapidamente e fazendo com que as tarefas AA esperem pouco tempo na
117
fila de espera, diminuindo o tempo de reação e consequentemente o tempo de
resposta médio das tarefas.
Gráfico 13: Tempo de resposta médio em relação às políticas de remoção para cargas AA-BB Fonte: Dados da pesquisa
No último caso (Gráfico 14), quando se utiliza a política SJF, as tarefas AB (alto
tempo de execução) são executadas em primeiro lugar, fazendo com que as tarefas
BA (baixo tempo de execução) tenham que esperar muito na fila de espera,
aumentando bastante o tempo de reação e consequentemente o tempo de resposta
médio das tarefas.
118
Gráfico 14: Tempo de resposta médio em relação às políticas de remoção (cargas AB-BA)
Fonte: Dados da pesquisa
6.5.3.4 Análise do Slowdown
O slowdown é uma métrica dependente tanto do tempo de reação, quanto do
tempo de execução. Portanto, quanto menor o tempo de reação em relação ao de
execução, menor o slowdown (mais perto de 1) e melhor o desempenho da tarefa.
Na Tabela 13, apresentamos os valores médios do slowdown das tarefas para as
diferentes cargas de trabalho e configurações do RGSA.
Como o slowdown é dependente do tempo de reação e de resposta, não é
necessário mostrar os gráficos para comparação de cada um dos quadros do RGSA.
119
TABELA 13
Slowdown médio
Cargas
Conf.
AA60 AA80 AA100 AB60 AB80 AB100 BA60 BA80 BA100 BB60 BB80 BB100
Conf01 27.123 21.730 18.149 60.317 46.241 5.850 74.191 50.526 11.152 24.701 19.037 4.245
Conf02 8.879 13.195 18.406 78.140 52.216 6.555 76.984 50.260 12.478 5.825 4.673 4.345
Conf03 27.407 22.188 19.416 65.657 42.811 6.041 68.350 53.334 11.908 23.879 18.001 3.431
Conf04 8.859 13.310 18.528 80.741 50.379 7.283 77.331 52.956 12.112 5.888 4.535 4.517
Conf05 1.005 1.004 1.004 1.011 1.005 1.001 1.018 1.027 1.027 1.004 1.006 1.006
Conf06 1.004 1.003 1.004 1.011 1.005 1.000 1.020 1.028 1.035 1.004 1.005 1.007
Conf07 28.832 23.104 18.613 81.044 51.953 5.878 86.215 45.163 12.118 26.072 18.875 3.668
Conf08 9.040 13.432 18.723 82.274 51.291 6.864 80.528 55.494 11.551 6.012 4.975 4.659
Conf09 27.859 23.622 19.579 52.982 41.082 5.593 59.269 38.022 12.406 26.061 19.001 3.711
Conf10 8.977 13.455 18.468 79.216 50.915 6.674 79.994 54.030 12.513 6.400 4.567 4.719
Conf11 1.005 1.005 1.005 1.013 1.005 1.001 1.018 1.029 1.035 1.005 1.007 1.008
Conf12 1.004 1.003 1.004 1.013 1.006 1.001 1.019 1.025 1.024 1.004 1.006 1.008
Fonte: Dados da pesquisa
Baseado nas análises anteriores do tempo de resposta e tempo de reação,
podemos dizer que os esquemas de empacotamento e desfragmentação possuem
desempenho equivalente entre si.
Como o slowdown é calculado pela divisão entre o tempo de resposta pelo
tempo de execução, e o tempo de reação das configurações com nível de
multiprogramação ilimitado é muito baixo, essas configurações tem o valor do
120
slowdown tendendo para o 1. Pois o tempo de execução é quase o mesmo do
tempo de resposta.
Como discutido anteriormente nas métricas de tempo de reação e tempo de
resposta, a política SJF apresenta um desempenho melhor principalmente nas
cargas AA e BB, mas existem casos nos quais a política FCFS apresenta um melhor
desempenho.
6.5.3.5 Análise do Tempo de Simulação
O tempo de simulação é uma métrica importante que reflete o tempo total
gasto pelo sistema para realizar uma determinada atividade. Mas ele está
diretamente relacionado com a utilização do sistema. A utilização é calculada pela
razão entre o tempo de ocupação dos processadores pelo tempo de simulação.
Portanto, as mesmas observações feitas em relação à métrica utilização, podem ser
estendidas para o tempo de simulação. Na Tabela 14, apresentamos os valores
médios do tempo de simulação das cargas de trabalho para as diferentes
configurações do RGSA.
121
TABELA 14
Tempo de simulação médio (segundos)
Cargas
Conf. AA60 AA80 AA100 AB60 AB80 AB100 BA60 BA80 BA100 BB60 BB80 BB100
Conf01 7426 9164 10746 9515 12219 11594 7221 4265 1102 5406 3319 1184
Conf02 6697 8422 10178 7280 9444 11078 5001 3131 1000 4690 2714 1140
Conf03 7274 9231 10709 9809 12740 12630 7372 4648 1071 5366 3235 1230
Conf04 6718 8419 10252 7544 9725 12227 5192 3273 993 4712 2716 1105
Conf05 5906 7380 9160 12758 11861 12397 8962 5103 920 4270 2645 1231
Conf06 6078 7690 9419 13888 12860 12544 11164 6641 992 4350 2702 1210
Conf07 6906 8793 10352 9958 12520 11404 7177 4032 1038 5067 3082 1159
Conf08 6678 8446 10243 7309 9310 11143 4984 3213 988 4611 2666 1110
Conf09 7001 8773 10399 8681 11763 11641 6361 3863 1084 5148 3040 1159
Conf10 6776 8524 10206 7202 9418 11140 5088 3245 1016 4682 2714 1109
Conf11 5887 7378 9090 12540 13753 12437 13554 8928 930 4259 2625 1252
Conf12 6051 7689 9388 13465 13765 12787 13705 9503 995 4340 2729 1190
Fonte: Dados da pesquisa
6.5.3.6 Análise do RGSA
Até o momento, realizamos a comparação das opções dentro de cada quadro
em relação as diferentes métricas. Para analisar o desempenho do RGSA, devemos
compará-lo com cada uma das configurações ou algoritmos tradicionais de
escalonamento de gangues. Como descrito na proposta do RGSA, a carga de
trabalho, quando submetida, é etiquetada com os seguintes parâmetros de entrada:
tempo de execução (alto ou baixo), grau de paralelismo (alto ou baixo), grau de
predominância (60, 80 ou 100) e métrica mais importante (utilização, tempo de
reação, slowdown, tempo de resposta ou tempo de simulação). Assim que
submetida uma determinada carga, a camada CCC avalia os parâmetros de entrada,
reconfigurando o algoritmo para a configuração ideal. Portanto o RGSA é
reconfigurado para a melhor configuração de acordo com os parâmetros indicados
122
na etiqueta de cada carga.
Na Tabela 15, podemos observar que na média geral o RGSA é melhor em
36.61% que as 12 configurações ou algoritmos tradicionais de escalonamento de
gangues individualmente. Note que se escolhêssemos a configuração 5, que foi a
melhor na média, o RGSA ainda seria 11.45% melhor considerando todas as
métricas.
TABELA 15
Melhoria, em porcentagem (%), no desempenho do RGSA em relação às
configurações para uma carga composta das 12 cargas de trabalho
Métricas
Config. Utilização Tempo de
Reação Tempo de Resposta Slowdown Tempo de
Simulação Média
Conf 01 18.8153 99.6937 18.1988 96.6667 19.4711 50.5691
Conf 02 5.5793 99.6545 12.7879 96.3408 5.3772 43.9479
Conf 03 20.2381 99.6986 20.1357 96.6585 21.5047 51.6471
Conf 04 7.1421 99.6695 16.6365 96.4005 8.1059 45.5909
Conf 05 12.2866 4.8307 21.1611 0.0566 18.9160 11.4502
Conf 06 17.0448 11.4411 27.6418 0.1415 25.2068 16.2952
Conf 07 16.0706 99.6884 16.7549 96.9840 17.8183 49.4632
Conf 08 5.1443 99.6561 12.9742 96.4882 5.2786 43.9083
Conf 09 14.6709 99.6726 13.7521 96.3212 15.1375 47.9109
Conf 10 6.0941 99.6576 13.6044 96.4374 5.8391 44.3265
Conf 11 16.6605 14.6595 23.2316 0.2179 27.7065 16.4952
Conf 12 19.0915 11.0755 28.8892 0.0591 29.9556 17.8142
Média 13.2365 69.9498 18.8140 64.3977 16.6931 36.6182
Fonte: Dados da pesquisa
Agora, vamos analisar outro exemplo, onde a carga é composta pelas cargas
AB60 e BA60. De acordo com a Tabela 16, a vantagem geral do RGSA aumenta
123
para 41.53%, e em relação à configuração 5, essa vantagem sobe para 18.83%
considerando todas as métricas. Vamos agora considerar somente a métrica
utilização. A melhoria do RGSA passa de 18.83% para 42.32%, ou seja, ela sobe
23.48%. Podemos notar na Tabela 6.12, que a configuração 5, que seria a melhor
na média, nesse caso, seria bem pior que a configuração 3, que era considerada a
pior na média.
TABELA 16
Melhoria, em porcentagem (%), no desempenho do RGSA em relação às
configurações para uma carga composta das cargas AB60 e BA60
Métricas
Config. Utilização Tempo de
Reação Tempo de Resposta Slowdown Tempo de
Simulação Média
Conf 01 26.7836 99.7605 22.5123 98.4916 27.1878 54.9471
Conf 02 0.8016 99.7739 31.9511 98.6920 0.7671 46.3972
Conf 03 29.0247 99.7647 24.4469 98.4859 29.0702 56.1585
Conf 04 4.2309 99.7809 34.1388 98.7164 4.3209 48.2376
Conf 05 42.3255 4.0597 3.8764 0.0324 43.8949 18.8378
Conf 06 50.3595 5.2884 19.6931 0.0742 51.3580 25.3546
Conf 07 28.2399 99.7709 25.0613 98.7869 28.8798 56.1478
Conf 08 0.7319 99.7739 31.6864 98.7537 0.8703 46.3632
Conf 09 19.0918 99.7198 12.7145 98.1925 18.9861 49.7409
Conf 10 1.0836 99.7729 31.9171 98.7256 0.8443 46.4687
Conf 11 52.1549 0.0000 10.7741 0.0984 53.2991 23.2653
Conf 12 54.4356 0.7533 21.7874 0.1247 55.1504 26.4503
Média 25.7720 67.3516 22.5466 65.7645 26.2191 41.5307
Fonte: Dados da pesquisa
Com esses exemplos, comprovamos que com o uso do RGSA, ou seja, o uso
de reconfiguração nos algoritmos de escalonamento de gangues, podemos alcançar
grandes melhorias sobre os algoritmos tradicionais de escalonamento de gangues,
124
melhorando o desempenho dos aglomerados de computadores e de suas tarefas.
Quando não se sabe a priori a melhor configuração para cada carga, e/ou a
carga não está etiquetada, existirão sobrecargas para a reconfiguração do algoritmo.
Mas esses são problemas da camada CCC, o algoritmo reconfigurável apenas
fornece os mecanismos para que se criem diferentes configurações através da
seleção das opções dos blocos. Portanto esses problemas fogem do nosso escopo.
Mas mesmo se introduzíssemos grandes sobrecargas (mais que 10%), o RGSA
ainda provar-se-ia vantajoso. Portanto, este trabalho abre caminho para estudos
mais profundos sobre o uso de reconfiguração no escalonamento de gangues e
suas principais vantagens e desvantagens.
6.6 Conclusões
Nesta seção, apresentamos a definição, a proposta, o desenvolvimento, a
implementação, a verificação e a análise do desempenho do RGSA por meio de
simulação. Como conclusões gerais sobre os quadros ou partes do RGSA, podemos
destacar:
- Quadro de Esquemas de Empacotamento - Considerando todas as métricas
e cargas de trabalho, na média, ambos esquemas de empacotamento (primeiro e
melhor encaixe) apresentaram desempenho equivalente, como em (FEITELSON;
RUDOLPH, 1995a).
- Quadro de Esquemas de Desfragmentação - Considerando todas as
métricas e cargas de trabalho, na média, ambos esquemas de desfragmentação
(unificação de fatias e escalonamento alternativo) apresentaram desempenho
equivalente.
- Quadro de Níveis de Multiprogramação - Considerando as métricas
utilização e tempo de simulação, o nível de multiprogramação ilimitado apresentou
um desempenho melhor para as cargas de trabalho AA e BB, e o limitado para as
cargas de trabalho AB e BA. Para as métricas tempo de reação e slowdown, o nível
de multiprogramação ilimitado apresentou o melhor desempenho em todos os casos.
Por último, considerando a métrica tempo de resposta, na média, o nível de
multiprogramação limitado foi o melhor.
125
- Quadro de Políticas de Fila - Considerando as métricas utilização e tempo
de simulação, a política SJF foi sempre melhor que a FCFS. Para as métricas tempo
de reação e slowdown, na média, a política SJF apresentou o melhor desempenho,
mas em certos casos, o FCFS foi melhor. Por último, considerando a métrica tempo
de resposta, a política SJF apresentou melhor desempenho para as cargas AA e BB
e a política FCFS para as cargas de trabalho AB e BA.
Na média, o desempenho do RGSA foi em torno de 40% melhor que os
algoritmos tradicionais de escalonamento de gangues para todas as cargas de
trabalho testadas. Um dos resultados mais importantes foi mostrar que dependendo
da métrica selecionada e da carga de trabalho, o melhor algoritmo na média para
todas as situações (Conf5) pode ser pior que o pior algoritmo na média (Conf3). Nas
nossas simulações, o desempenho do RGSA foi 42.32% melhor que o da Conf5
para uma situação específica. Então, o uso de um algoritmo reconfigurável pode
aumentar bastante o desempenho de um aglomerado de computadores.
No nosso caso específico, a maior simulação demorou em torno de 13000
segundos (3.6 horas). Com o uso do RGSA, conseguimos diminuir esse tempo em
40% (1.44 horas). Mas em um sistema real, uma carga de trabalho pode executar
por uma semana. Nesse caso, a redução de 40% poderia reduzir o tempo gasto em
2.8 dias.
Neste capítulo, nós propomos um modelo ou arquitetura de um algoritmo
reconfigurável, que foi aplicado no escalonamento de gangues, mas poderia ser
aplicado em outros problemas. Usando um algoritmo reconfigurável,
desenvolvedores não necessitam criar um algoritmo que funcione bem para todas as
situações. Eles podem concentrar seus esforços em um conjunto ou subconjunto de
algoritmos ou partes de algoritmos, nos quais cada parte seja otimizada para uma
determinada situação.
As principais contribuições deste capítulo são: a definição, a implementação,
a verificação e análise de desempenho do RGSA, comparando-o com cada
algoritmo tradicional de escalonamento de gangues.
Como trabalhos futuros, podemos destacar: proposta e inclusão de novos
quadros e blocos no RGSA; implementação de uma camada CCC adaptável; testes
com maior número de tarefas, cargas diferentes, outros modelos de algoritmos e
padrões de comunicação, diferentes aglomerados e testes em um aglomerado real.
126
7 CONCLUSÕES
Neste último capítulo, discutimos os principais resultados obtidos,
apresentamos as principais contribuições, alguns possíveis trabalhos futuros e a
conclusão geral da pesquisa. Também indicamos um endereço eletrônico, no qual
toda a documentação (artigos, resultados, planilhas, tutoriais e manuais), códigos
fonte e executáveis dos softwares desenvolvidos se encontram disponíveis.
7.1 Discussão dos Resultados
De acordo com as fases e etapas apresentadas e executadas, alcançamos
todas as metas, objetivos principais e intermediários desta pesquisa. Dentre os quais
destacamos:
- Propor, desenvolver, implementar e verificar um algoritmo reconfigurável de
escalonamento paralelo de tarefas (RGSA - Reconfigurable Gang Scheduling
Algorithm).
- Analisar o desempenho do RGSA por meio de simulação.
- Propor, desenvolver, implementar, verificar e validar uma ferramenta de
simulação de escalonamento paralelo de tarefas em aglomerados de computadores
(ClusterSim - Cluster Simulation Tool).
- Propor, desenvolver, implementar e verificar uma biblioteca de simulação
discreta por eventos (JSDESLib - Java Simple Discrete Event Simulation Library).
A JSDESLib é uma biblioteca que se limita a apenas fornecer os mecanismos
básicos de simulação discreta por eventos, tendo como maiores vantagens e
contribuições: a simplicidade e facilidade de uso; e uma implementação paralela e
otimizada. O programador necessita aprender obrigatoriamente apenas o método
simSchedule(event) para desenvolver uma simulação, pois a JSDESLib automatiza
a sincronização das entidades e a distribuição dos eventos. Além da facilidade de
uso, a implementação da JSDESLib é otimizada, suportando paralelismo entre
entidades e reciclagem de eventos. O coletor de lixo do JVM tende a alocar mais
memória para a máquina virtual ao invés de recolher objetos não mais utilizados.
127
Com isso, muitas vezes, a simulação ultrapassa o limite de memória, interrompendo
a simulação. A reciclagem de eventos reutiliza objetos da classe SimEvent, que são
os mais utilizados, sem a necessidade da intervenção do coletor de lixo.
Como contrapeso à simplicidade e facilidade de uso, que são as
características principais da JSDESLib, ela não possui várias funcionalidades
encontradas nos trabalhos relacionados como: animação visual de objetos,
implementação distribuída, simulação hierárquica, etc. Mas é importante ressaltar,
que algumas dessas funcionalidades poderiam ser implementadas sem prejudicar a
facilidade de uso da JSDESLib.
O ClusterSim (Cluster Simulation Tool) é uma ferramenta de simulação
paralela discreta por eventos de desempenho de aglomerados de computadores,
baseada em Java. Ele possui um ambiente gráfico que facilita a modelagem e
criação de aglomerados de computadores e de cargas de trabalho (tarefas paralelas
e usuários), para análise do desempenho deles por meio de simulação. Um
aglomerado de computadores é composto por nodos homogêneos ou heterogêneos,
um algoritmo de escalonamento paralelo e uma rede de interconexão. Uma carga de
trabalho é representada por usuários que submetem tarefas modeladas por meio de
distribuições probabilísticas e descrições da estrutura interna dos processos.
Em relação aos trabalhos relacionados, o ClusterSim apresenta as seguintes
vantagens: ambiente gráfico para modelagem de aglomerados e cargas de trabalho;
um modelo híbrido (distribuições probabilísticas e descrições estruturais) de
representação da carga de trabalho que permite a modelagem de tarefas paralelas
reais, com instruções de repetição, CPU, MPI (comunicação) e E/S; módulo
estatístico e de desempenho que calcula diversas métricas (tempo médio de
resposta das tarefas, utilização média dos nodos etc.). Além dessas vantagens, o
Cluster possui o código fonte livre, possibilitando a extensão de suas classes para a
criação de novos algoritmos de escalonamento paralelo, topologias de rede etc.
O uso de um modelo híbrido de carga de trabalho torna a simulação mais
determinística que um modelo puramente probabilístico. Também elimina um erro
comumente cometido, o uso de parâmetros do modelo de desempenho, como tempo
de execução, no modelo da carga de trabalho, ao invés de utilizar as características
estruturais da carga, como o número de instruções.
A verificação e a validação do ClusterSim, por meio de métodos analíticos e
testes reais, mostrou que o ClusterSim provê mecanismos para repetição e
128
modificação de alguns parâmetros de experimentos sobre um ambiente controlado e
confiável. A validação completa do modelo de simulação de uma ferramenta por
meio de experimentos e/ou modelagem matemática é muito difícil, pois para cada
situação, os resultados teriam que ser re-validados. Então, optamos por validar
apenas os mecanismos básicos de comunicação e processamento do modelo de
simulação, pois são os mais utilizados pelo ClusterSim.
As principais desvantagens do ClusterSim são: modelo de simulação
complexo, que aumenta o tempo de simulação e o consumo de memória de acordo
com o número de tarefas submetidas; poucas implementações de topologias de
rede; não suporta a simulação de arquiteturas em grades; falta de um gerador de
gráficos estatísticos não suporta simulação por meio de traces etc.
Nesta dissertação, nos limitamos a definir o conceito e a arquitetura de um
algoritmo reconfigurável, pois não os encontramos nos trabalhos estudados. Um
algoritmo reconfigurável é composto de blocos construtivos, que permite a mudança
do seu comportamento por meio da configuração da sua forma. A arquitetura de um
algoritmo reconfigurável é composta de três camadas: Camada de Controle de
Configuração (CCC), Camada Reconfigurável (CR) e Camada Básica (CB). A
introdução deste novo conceito permite o aumento da flexibilidade e adaptabilidade
de várias classes de algoritmos existentes, conseqüentemente aumentando o
desempenho dos sistemas nos quais os algoritmos são utilizados.
O Reconfigurable Gang Scheduling Algorithm (RGSA) é resultado da
aplicação do conceito de reconfiguração na classe de algoritmos de escalonamento
paralelo de tarefas, especificamente em escalonamento de gangues. O RGSA é
composto por quatro quadros: Quadro de Esquemas de Empacotamento, Quadro de
Esquemas de Desfragmentação, Quadro de Políticas de Fila e Quadro de Níveis de
Multiprogramação e duas estruturas de dados (Matriz de Ousterhout e Fila de
Espera). Nesta implementação do RGSA, cada quadro possui dois blocos
construtivos.
Na média, o desempenho do RGSA foi em torno de 40% melhor que os
algoritmos tradicionais de escalonamento de gangues para todas as cargas de
trabalho testadas. Um dos resultados mais importantes foi mostrar que dependendo
da métrica selecionada e da carga de trabalho, o melhor algoritmo na média para
todas as situações (Conf5) pode ser pior que o pior algoritmo na média (Conf3). Nos
nossos experimentos, o desempenho do RGSA foi 42.32% melhor que o da Conf5
129
para uma situação específica. Então, o uso de um algoritmo reconfigurável de
escalonamento paralelo de tarefas pode aumentar bastante o desempenho de um
aglomerado de computadores, em decorrência da sua flexibilidade e adaptabilidade.
Como principais desvantagens do RGSA, podemos citar: o número limitado
de blocos por quadro; a camada CCC (controle) não possui mecanismos de auto-
adaptação; a carga de trabalho precisa estar etiquetada com os parâmetros de
entrada etc. Quanto aos testes realizados, podemos destacar as seguintes
limitações: aglomerado de tamanho pequeno; execução de um pequeno número de
tarefas; uso apenas de simulação; as tarefas possuíam o mesmo modelo de
algoritmos paralelo e padrão de comunicação etc.
Por último ressaltamos que com o uso de um algoritmo reconfigurável, os
programadores não têm a necessidade de criar um algoritmo que funcione
idealmente para todas as situações. Eles podem concentrar seus esforços em um
conjunto ou subconjunto de algoritmos ou parte de algoritmos, nos quais cada parte
seja otimizada para uma determinada situação. Essa conclusão mostra uma das
maiores vantagens do uso dos conceitos de computação reconfigurável em
algoritmos.
7.2 Principais Contribuições
As principais contribuições desta dissertação, por ordem cronológica, são:
- Proposta, desenvolvimento e implementação da biblioteca de simulação
JSDESLib.
- Proposta, desenvolvimento e implementação da ferramenta de simulação
ClusterSim.
- Proposta, desenvolvimento e implementação do algoritmo reconfigurável
RGSA.
- Análise de desempenho do algoritmo reconfigurável RGSA.
- Publicação de artigos em congressos e revistas, nacionais e internacionais.
130
7.3 Trabalhos Futuros
Alguns dos possíveis trabalhos futuros são apresentados de acordo com as
principais contribuições desta pesquisa, procurando apresentar soluções para
possíveis lacunas não exploradas ou para o melhoramento de partes pouco
exploradas. Esta pesquisa é bastante ampla e envolve diversas áreas de
computação: computação reconfigurável, engenharia de software, análise de
desempenho, arquitetura de computadores, processamento paralelo e simulação.
A biblioteca JSDESLib, por não ser o enfoque principal da pesquisa, foi pouco
explorada e pode ser melhorada em muitos aspectos, entre os quais destacamos:
implementação distribuída utilizando sockets ou Java RMI; uso de consistência
relaxada na execução dos eventos; simulação hierárquica, permitindo a utilização
de múltiplos níveis ou filas de eventos etc.
Algumas melhorias podem ser realizadas na ferramenta de simulação
ClusterSim, como: simulação em diferentes níveis de complexidade; a
implementação de novas topologias e tecnologias de rede; otimizações no código
para diminuição do tempo de simulação e utilização de memória; inserção de
recursos mais didáticos; a implementação de mecanismos de memória
compartilhada distribuída; simulação de arquiteturas em grades; a implementação
de um gerador de gráficos estatísticos; simulação por meio de traces etc.
O conceito de algoritmo reconfigurável ainda pode ser trabalho em diversos
aspectos: formalização matemática; criação de um método para desenvolvimento de
algoritmos reconfiguráveis; definição do escopo para a aplicação do conceito;
verificação e validação de algoritmos reconfiguráveis; implementação e teste de
diversas classes de algoritmo reconfiguráveis etc.
Com relação ao RGSA, podemos destacar os seguintes trabalhos futuros:
proposta e inclusão de novos quadros e blocos no RGSA; implementação de uma
camada CCC adaptável utilizando algoritmos evolucionários; implementação e
teste em um sistema real; testes com maior número de tarefas, diferentes cargas,
outros modelos de algoritmos e padrões de comunicação etc.
131
7.4 Conclusão Geral
Esta dissertação é parte de uma pesquisa desenvolvida nos últimos 4 anos,
com bastante interesse, empenho e dedicação à pesquisa científica. Durante a
graduação, dois projetos de iniciação científica (MARTINS, 2001; MARTINS; GÓES;
RAMOS, 2002) foram desenvolvidos, envolvendo a área de processamento paralelo
e também computação reconfigurável. Esses projetos foram essenciais para o
ingresso do autor no mestrado, como continuação e aperfeiçoamento dos trabalhos
desenvolvidos e do amadurecimento científico.
Dentro das expectativas, os resultados obtidos foram acima do esperado.
Houve a publicação de 14 artigos durante a pesquisa, divididos em 6 congressos
nacionais e 8 internacionais, em especial a mais recente aceitação e publicação do
artigo “Reconfigurable Gang Scheduling Algorithm” no 10th Workshop on Job
Scheduling Strategies for Parallel Processing (GÓES; MARTINS, 2004a), o mais
importante workshop na área, que gera uma publicação na LNCS da Springer
Verlag. Além da submissão de mais alguns artigos sobre os resultados obtidos e do
desenvolvimento de três ferramentas (Prober, ClusterSim e JSDESLib), algumas
implementações paralelas e a geração de bastante material didático e técnico.
Pessoalmente, todo esse processo de aprendizado, fez com que o autor
amadurecesse bastante e criasse uma base sólida de conhecimento para alcançar
suas novas expectativas e anseios como o ingresso no doutorado e o início da
carreira como docente.
A participação do autor nos trabalhos desenvolvidos no GSDC (Grupo de
Sistemas Digitais e Computacionais) foi de grande importância para o
amadurecimento do autor em relação ao desenvolvimento de trabalhos em equipe
(cooperação, orientação de alunos etc.) e também contribuiu para o fortalecimento
do próprio grupo e de seus componentes.
Como última observação, ressaltamos a importância desta própria dissertação
desenvolvida, que serve como base ou referência para o desenvolvimento de várias
outras pesquisas nas áreas de escalonamento paralelo de tarefas, computação
reconfigurável, processamento paralelo, engenharia de software e simulação de
sistemas computacionais.
132
REFERÊNCIAS
A COLLECTION of Modeling and Simulation Resources on the Internet. 2003. Disponível em: <www.idsia.ch/%7Eandrea/sim/simindex.html > Acesso em: 01 maio 2004. ALMASI, G.S., GOTTLIEB, A. Highly Parallel Computing. 2nd Edition, Benjamin/Cummings: Publishing Company, 1994. ANCONA, D., LAGORIO, G. ZUCCA, E. True Separate Compilation of Java Classes. 4rd International Conference on Principles & Practice Declarative Programming ACM Press, p. 189-200, 2002 BATAT, A.; FEITELSON, D. Gang Scheduling with Memory Considerations. IEEE International Parallel and Distributed Processing Symposium, p. 109-114, 2000. BAXTER, M., ICARUS: A Dynamically Reconfigurable Computer Architecture. Seventh Annual IEEE Symposium on Field-Programmable Custom Computing Machines, p. 278 –279, 1999. BHATIA, D. Reconfigurable Computing: Tenth International Conference on VLSI Design, p. 356-359, 1997. BODHANWALA, H. et al., A General Purpose Discrete Event Simulator, Symposium on Performance Evaluation of Computer and Telecommunication Orlando, USA: Systems, 2001. BRESLAU, L. et al. Advances in Network Simulation. IEEE Computer, v. 33 n. 5, p. 59-67, May 2000. BRUNETON, E., COUPAYE, T., STEFANI, J. B. Recursive and Dynamic Software Composition with Sharing. Seventh International Workshop on Component-Oriented Programming, 2002. BUYYA, R. High Performance Cluster Computing: volume One. Prentice Hall, 1999.
133
BUYYA, R.; MURSHED, M., GridSim: A Toolkit for the Modeling and Simulation of Distributed Resource Management and Scheduling for Grid Computing. The Journal of Concurrency and Computation: Practice and Experience, Wiley Press, USA, 2002. v. 14, Issue 13-15, p. 1175-1220. CAMPOS, L. M. Resource Management Techniques for Multiprogramed Distributed Systems. Master Thesis: University of California, 1999. CANDEA, G.M.; JONEs, M.B., Vassal: Loadable Scheduler Suport for Multi-Policy Scheduling. Washington: Second USENIX Windows NT Symposium, Seattle, 1998. CASANOVA, H. Simgrid: a Toolkit for the Simulation of Aplication Scheduling. Australia, 3rd IEEE/ACM International Symposium on Cluster Computing and the Grid, Brisbane, p. 430-437, 2001. CASAVANT, T., KUHl, J. A Taxonomy of Scheduling in General-Purpose Distributed Computing Systems. New York: IEEE Transactions on Software Engineering, 1988, p.141-154. CHAPIN, S.J. et al. Benchmarks and Standards for the Evaluation of Parallel Job Schedulers. Workshop on Job Scheduling Strategies for Parallel Processing, 1999. p. 67-90. CLARK, B.K., Reconfigurable Software Development. IEEE/AIAA 10th Digital Avionics Systems Conference, 1991. p. 499-503. COMPTON, K. ; HAUCK, S. Reconfigurable Computing: A Survey of Systems and Software. ACM Computing Survey, v. 34, n. 2, p. 171-210, 2002. COMPUTER History Museum. Where compunting hsitory lives 2007. Disponível em: < www.computerhistory.org> Acesso em: 01 maio 2004. DEHON, A. The Density Advantage of Configurable Computing. IEEE Computer, v. 33, n. 4, p. 41-49, 2000. DEHON, A., WAWRZYNEK, J. Reconfigurable Computing: What, Why, and Implications for Design Automation, 36th Design Automation Conference, 1999, p. 610-615.
134
DUCASSE, S., HOFMANN, T., NIERSTRASZ, O. OpenSpaces: An Object-Oriented Framework for Reconfigurable Coordination Spaces. LNCS, v. 1906, Limassol, Cyprus, p. 1-19, 2000. EL-REWINI, H., ALI, H.; LEWIS, T. Task Scheduling in Multiprocessing Systems. IEEE Computer, v. 28, p. 27-37, Dec. 1995. ESCOLA REGIONAL DE ALTO DESEMPENHO; (1.; 2001; GRAMADO, RS).YAMIN, A.C., Escalonamento em Sistemas Paralelos e Distribuídos Anais. Gramado: SBC: 2001. 258p. p. 75-126. FEITELSON, D. G. Packing Schemes for Gang Scheduling. Workshop on Job Scheduling Strategies for Parallel Processing, LNCS, p. 89-110, 1996. FEITELSON, D. G., RUDOLPH, L. Metrics and Benchmarking for Parallel Job Scheduling. Workshop on Job Scheduling Strategies for Parallel Processing. LNCS, p. 1-24, 1997. FEITELSON, D. Metric and Workload Effects on Computer Systems Evaluation. IEEE Computer, 2003, p. 18-25. FEITELSON, D. Metrics for Parallel Job Scheduling and their Convergence. Workshop on Job Scheduling Strategies for Parallel Processing, LNCS (Lecture Notes in Computer Science), p. 188-206, 2001. FEITELSON, D. Workload Modeling for Performance Evaluation, Performance Evaluation of Complex Systems: Techniques and Tools. 2002, p. 114-141. FEITELSON, D., et al. Theory and Practice in Parallel Job Scheduling. 3rd Workshop on Job Scheduling Strategies for Parallel Processing, LNCS, p. 1-34, Berlin, 1997. FEITELSON, D., RUDOLPH, L. Distributed Hierarchical Control for Parallel Processing. IEEE Computer, p. 65-77, 1990. FEITELSON, D., RUDOLPH, L. Evaluation of Design Choices for Gang Scheduling using Distributed Hierarchical Control. Journal of Parallel & Distributed Computing, 1995a. p. 18-34,
135
FEITELSON, D., RUDOLPH, L. Gang Scheduling Performance Benefits for Fine-Grain Synchronization. Journal of Parallel & Distributed Computing, p. 306-318, 1992. FEITELSON, D., RUDOLPH, L. Parallel Job Scheduling: Issues and Aproaches. 1st Workshop on Job Scheduling Strategies for Parallel Processing. Berlin: LNCS, 1995b. FEITELSON, D.; NITZBERG, B. Job characteristics of a production parallel scientific workload on the NASA Ames iPSC/860. Workshop on Job Scheduling Strategies for Parallel Processing, p.337-360, 1993. FEITELSON, D.G. A Survey of Scheduling in Multiprogrammed Parallel Systems. Research Report RC 19790 (87657), IBM T. J. Watson Research Center, Oct. 1994 (Revised version from August 1997).
FRACHTENBERG, E., et al. Flexible CoScheduling: Mitigating Load Imbalance and Improving Utilization of Heterogeneous Resources. 17th International Parallel and Distributed Processing Symposium, 2003.
FRANKE, H., et. al. An Evaluation of Parallel Job Scheduling for ASCI Blue-Pacific. ACM/IEEE Conference on Supercomputing, n. 45, 1999. GAJJALAPURNA, K.M., BHATIA, D. Temporal Partitioning and Scheduling for Reconfigurable Computing. IEEE Symposium on FPGAs for Custom Computing Machines, 1998. p. 329-330. GAL, A., FRÖHLICH, P.H., FRANZ, M. An Efficient Execution Model for Dynamically Reconfigurable Component Software. Seventh International Workshop on Component-Oriented Programming, 2002. GÓES, L. F. W. et al. Análise do Desempenho de uma Implementação Paralela da Rede Neural Perceptron Multicamadas Utilizando Variável Compartilhada. Orlando: Conferencia Iberoamericana en Sistemas, Cibernética e Informática (CISCI 2002), 2002. GÓES, L. F. W., MARTINS, C. A. P. S., ClusterSim: A Java Parallel Discrete Event Simulation Tool, IEEE International Conference on Cluster Computing, 2004. (submitted)
136
GÓES, L. F. W., MARTINS, C. A. P. S., Reconfigurable Gang Scheduling Algorithm. 10th Workshop on Job Scheduling Strategies for Parallel Processing, 2004. (to be published) GÓES, L. F. W., MARTINS, C. A. P. S., RJSSim: A Reconfigurable Job Scheduling Simulator for Parallel Processing Learning. 33rd ASEE/IEEE Frontiers in Education Conference, Colorado, p. F3C3-8, 2003. GÓES, L. F. W., RAMOS, L. E. S., MARTINS, C. A. P. S. , Parallel Image Filtering Using WPVM in a Windows Multicomputer. 2nd International Conference on Computer Science, Software Engineering, Information Technology, e-Business, and Aplications, Foz do Iguaçu, 2002. GÓES, L. F. W., RAMOS, L. E. S., MARTINS, C. A. P. S. Performance Analysis of Parallel Programs using Prober as a Single Aid Tool, 14th IEEE Symposium on Computer Architecture and High Performance Computing (SBAC-PAD), Vitória, p.204-211, 2002. GÓES, L. F. W., RAMOS, L. E. S., MARTINS, C. A. P. S., Implementation of a Parallel Lowpass-Filter Using Message Passing in a Cluster of Workstations, The 6th World Multi-Conference on Systemics, Cybernetics And Informatics (SCI), Orlando, 2002. GÓES, L. F. W., RAMOS, L. E. S., MARTINS, C. A. P. S., Proposta e Implementação de um Ambiente de Desenvolvimento e Prototipação Rápida de Sistemas Computacionais: Paralelos, Dedicados e Reconfiguráveis. 9º Seminário de Iniciação Científica da PUCMG, Belo Horizonte, p. 63, 2001. GRAVEL, J. J. ; KAVANAGH T. F., Computers: The Key to Modern Manufacturing Scheduling. IEEE Transactions on Production Techniques, p. 90-93, 1957. v. 2. HADLICH, T., NEUMANN, P., Modeling Distributed Systems with Reconfigurable Logic. Proceedings of the IEEE International Symposium on Industrial Electronics, (ISIE'97), p. 176-180, 1997. HWANG, K., XU, Z. Scalable Parallel Computing: Technology, Architecture, Programming, Mcgraw-Hill, 1998. JAIN, R. K. The Art of Computer Systems Performance Analysis: Techniques for Experimental Design. Measurement, Simulation and Modeling, John Wiley & Sons, 1991.
137
JANN, J., PATTNAIK, P. ; FRANKE, H. Modeling of Workload in MP’s. Wprkshop on Job Scheduling Strategies for Parallel Processing, LNCS, p. 95-116, 1997. JETTE, M.A., Performance Characteristics of Gang Scheduling in Multiprogrammed Environments. Technical Paper, 1997. KAMIN, S., Dynamically Reconfigurable Software Components, Workshop on New Visions for Software Design and Productivity, 2001. KARATZA, H. D., Gang Scheduling Performance on a Cluster of Non-Dedicated Workstations, 35th IEEE Annual Simulation Symposium, p. 235, 2002. KWOK, Y. ; AHMAD, I., Static Scheduling Algorithms for Allocating Directed Task Graphs to Multiprocessors. ACM Computing Surveys, v. 31, n. 4, p.406-471, Dec./1999. LAW, A.M., KELTON, W.D.,Simulation Modeling and Analysis. McGraw-Hill, 1991. LESLEY, N., FEKETE, A., Reconfigurable Algorithms in View Synchrony. IEEE International Symposium on Network Computing and Aplications, p. 256-267, 2001. LOW, Y.H. et al. Survey of Languages and Runtime Libraries for Parallel Discrete-Event Simulation. Computer Simulation, p.170-186, 1999. MACNAB, R.; HOWELL, F.W., Using Java for Discrete Event Simulation, 12th UK Performance Engineering Workshop, Edinburgh, p.219-228, 1996. MARTINS, C. A. P. S. et al. A New Learning Method of Microprocessor Architecture. Boston: 32nd ASEE/IEEE Frontiers in Education Conference, p. S1F-16, 2002. MARTINS, C. A. P. S. et al. Computação Reconfigurável: Conceitos, Tendências e Aplicações, Jornada de Atualização em Informática, 2002a. MARTINS, C. A. P. S. et al. Método de Aprendizado de Arquitetura de Microprocessadores Baseado em Projetos e Validação Usando Simulação Funcional, Workshop sobre Educação em Computação, 2001.
138
MARTINS, Carlos Augusto Paiva da Silva. PONTIFÍCIA UNIVERSIDADE CATÓLICA DE MINAS GERAIS. Departamento de Ciência da Computação. Proposta e Implementação de um Ambiente de Desenvolvimento e Prototipação Rápida de Sistemas Computacionais: Paralelos, Dedicados e Reconfiguráveis, 2001. xxf. Projeto de pesquisa - Pontifícia Universidade Católica de Minas Gerais, Departamento de Ciência da Computação MARTINS, Carlos Augusto Paiva da Silva; PONTIFÍCIA UNIVERSIDADE CATÓLICA DE MINAS GERAIS. Departamento de Ciência da Computação. Proposta e implementação de um aglomerado de computadores usando redes de comunicação de dados de alto desempenho e disponibilizando uma imagem de sistema único. 2002. 175f. Projeto de pesquisa - Pontifícia Universidade Católica de Minas Gerais, Departamento de Ciência da Computação MILOJICIC, D. et al. Process Migration, ACM Computing Surveys, 2000. MONTANA, D.J., A Reconfigurable Optimizing Scheduler, Proceedings of the Genetic and Evolutionary Computation Conference. p.1159-1166, 2001. NIERSTRASZ, O.; TSICHRITZIS, D., Object-Oriented Software Composition. Prentice Hall, 1995. OUSTERHOUT, J.K., Scheduling Techniques for Concurrent Systems. 3rd International Conference on Distributed Systems, p. 22-30, 1982. PAPADOPOULOS, G. A., ARBAB, F., Dynamic Reconfiguration in Coordination Languages. 8th International Conference on High Performance Computing and Networking, HPCN Europe 2000, v. 1823, Springer, p.197-206, 2000. PARALLEL Workload Archives - 2005. Disponível em: <http://www.cs.huji.ac.il/labs/parallel/workload/> Acesso em: 01 maio 2004. PATTERSON, D. A. ; HENNESSY, J. L., Computer Organization & Design: The Hardware Software Interface, Morgan Kaufmann Publishers, Second Edition, 1998. PAULA, V.C., JUSTO, G.R.B., CUNHA, P.R.F. Specifying and Verifying Reconfigurable Software Architectures. International Symposium on Software Engineering for Parallel and Distributed Systems, p. 21-31, 2000. PENHA, D. O. et al. Analysis of Multi-threading on Different Operating Systems Aplied on Digital Image Processing. 3rd International Conference on Computer
139
Science, Software Engineering, Information Technology, e-Business, and Aplications, Rio de Janeiro, 2003, p. 230-235. PETRINI, F., FENG, W., Buffered Coscheduling: A New Methodology for Multitasking Parallel Jobs on Distributed Systems. IEEE International Parallel and Distributed Processing Symposium, p. 439-444, 2000. POUSA, C. V. et al. A Comparative Performance Analysis of Parallel Algorithm Models in Message-Passing Image Convolution Implementations. 3rd International Conference on Computer Science, Software Engineering, Information Technology, e-Business, and Aplications, Rio de Janeiro, p. 224-229, 2003. PRAKASH, S. ; BAGRODIA, R.L., MPI-SIM: Using Parallel Simulation to Evaluate MPI Programs, Winter Simulation Conference (WSC98), 1998. RAMOS, L. E. S., GÓES, L. F. W., MARTINS, C. A. P. S., Proposta e Implementação Aglomerado de Computadores Usando Redes de Comunicação de Dados de Alto Desempenho e Disponibilizando uma Imagem de Sistema Único, 10º Seminário de Iniciação Científica da PUCMG, Belo Horizonte, 2002. RAMOS, L. E. S., GÓES, L. F. W., MARTINS, C. A. P. S., Teaching And Learning Parallel Processing Through Performance Analysis Using Prober. 32nd Boston: ASEE/IEEE Frontiers in Education Conference, p. S2F13-18, 2002. ROSENBLUM, M. et al. Using the SimOS Machine Simulator to Study Complex Computer Systems. ACM TOMACS Special Issue on Computer Simulation, v. 7, n. 1, p. 78-103, 1997. ROXBY, P. J., PRADA, C. E., CHARLWOOD, S., A Core-based Design Method for Reconfigurable Computing Aplications. IEE Colloquium on Reconfigurable Systems, p. 1-4, 1999. SALZMANN, C., Invariants of Component Reconfiguration. Seventh International Workshop on Component-Oriented Programming, 2002. SEMINÁRIO DE INICIAÇÃO CIENTÍFICA, 10., 2002, BELO HORIZONTE, MG; PONTIFÍCIA UNIVERSIDADE CATÓLICA DE MINAS GERAIS. Resumos. Belo Horizonte: Ed. da PUC-MG, 2002. 155p.
140
SOLSONA, F. et al. CMC: A Coscheduling Model for Non-Dedicated Cluster Computing, International Parallel and Distributed Processing Symposium, LNCS, 2001, p. 76-83. STEWART, D. B. ; KHOSLA, P. K., The Chimera Methodology: Designing Dynamically Reconfigurable and Reusable Real-Time Software Using Port-Based Objects. Journal of Software Engineering and Knowledge Engineering, v.6, n.2, p. 249-277, June 1996. SUBHLOK, J., VENKATARAMAIAH, S., SINGH, A., Characterizing NAS Benchmark Performance on Shared Heterogeneous Networks. IEEE International Parallel and Distributed Processing Symposium, 2002. SULISTIO, A., YEO, C.S. ; BUYYA, R., A Taxonomy of Computer-based Simulation and its Maping to Parallel and Distributed Systems Simulation Tools. International Journal of Software: Practice and Experience, Wiley Press, Wiley Press, 2004. SULISTIO, A., YEO, C.S. ; BUYYA, R., Visual Modeler for Grid Modeling and Simulation Toolkit, Technical Report, Grid Computing and Distributed Systems (GRIDS) Lab, Dept. of Computer Science and Software Engineering, Australia: The University of Melbourne, 2002. SUPERCOMPUTERS TOP 500 - 1991. Disponível em: <www.top500.org > Acesso em: 01 maio 2004. TANENBAUM, A.S., WOODHULL, A.S., Operating Systems. Bookman: 2nd Edition, 2000. WIGLEY, G., KEARNEY, D., The First Real Operating System for Reconfigurable Computers. 6th Australasian Computer Systems Architecture Conference, p. 130-137, 2001. WISEMAN, Y., FEITELSON, D., Paired Gang Scheduling. IEEE Transactions Parallel & Distributed Systems, p. 581-592, 2003. WORKSHOP EM SISTEMAS COMPUTACIONAIS DE ALTO DESEMPENHO, 2., 2001, SÃO PAULO, SP; GÓES, L. F. W., RAMOS, L. E. S., MARTINS, C. A. P. S. Proposta de uma Microarquitetura e um Conjunto de Instruções de um Processador Digital de Sinais.Anais. São Paulo: SBC, 2001. 191p. p.142-145
141
WORKSHOP EM SISTEMAS COMPUTACIONAIS DE ALTO DESEMPENHO: 2.: 2001, PIRENÓPOLIS, GO; RAMOS, L. E. S., GÓES, L. F. W., MARTINS, C. A. P. S., Prober: uma Ferramenta de Análise Funcional e de Desempenho de Programas Paralelos e Configuração de Cluster. SOCIEDADE BRASILEIRA DE COMP. Anais. Pirenópolis: SBC, 2001. 162p. p. 127-134. YAMAMOTO, O. et al. A Reconfigurable Stochastic Model Simulator for Analysis of Parallel Systems. IEEE Symposium on Field-Programmable Custom Computing Machines, p. 291-292, 2000. YAMIN, A.C., Escalonamento em Sistemas Paralelos e Distribuídos, 1ª Escola Regional de Alto Desempenho, Brasil, Gramado, p.75-126, 2001. ZHANG, Y. et al. Sivasubramaniam, A., Improving Parallel Job Scheduling by Combining Gang Scheduling and Backfilling Techniques, IEEE International Parallel and Distributed Processing Symposium, 2000, p.133, ZHOU, B. B., BRENT, R. P., Gang Scheduling with a Queue for Large Jobs. IEEE International Parallel and Distributed Processing Symposium, p. 192-200, 2001. ZHOU, B. et al. An Efficient Resource Allocation Scheme for Gang Scheduling. 1st IEEE Computer Society International Workshop on Cluster Computing, p. 187-194, 1999. ZHOU, J. ; ZHENG, W., A DAG-Based Partitioning-Reconfiguring Scheduling Algorithm in Network of Workstations, 2000.
top related