proposta e desenvolvimento de um algoritmo … · sjf: short job first tgsa: traditional gang...

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


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.


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 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))




Fatia 3 Tarefa 4 Tarefa 4

Matriz de Ousterhout (escolamento alternativo))


Fatia 1 Tarefa 1 Tarefa 1 Tarefa 1 Tarefa 3



Matriz de Ousterhout (unificação de fatias)




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



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.


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


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


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


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


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


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


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


18 RespT Alto Baixo 100 Conf 7





23 RespT Baixo Alto 100 Conf 8



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.


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


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


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


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


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


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


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


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


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


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


Gráfico 11: Tempo de resposta médio em relação aos esquemas de desfragmentação


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


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)


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


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


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


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


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.

proposta e desenvolvimento de um algoritmo … · sjf: short job first tgsa: traditional gang...

Documents