Desenvolvimento de templates para modelagem, simulação e avaliação de desempenho em computadores com arquitetura paralela

CURSO DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO

D

e s e n v o l v im e n t o d e

T

e m p l a t e s p a r a

M

o d e l a g e m

, S

im u l a ç ã o e

A

v a l ia ç ã o d e

D

e s e m p e n h o

e m

C

o m p u t a d o r e s c o m

A

r q u it e t u r a

P

a r a l e l a

Adhemar Maria do Valle Filho

F

lo r ian ó po lis

CURSO.DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO

DESENVOLVIMENTO DE TEMPLATES PARA MODELAGEM,

SIMULAÇÃO E AVALIAÇÃO DE DESEMPENHO

EM COMPUTADORES COM ARQUITETURA PARALELA

por

Adhemar Maria do Valle Filho

D issertação subm etida à U niversidade Federal de Santa Catarina para obtenção do grau de M estre em Ciência da Com putação

Prof. Paulo José de Freitas Filho, Dr.

Orientador

Florianópolis

SIMULAÇÃO E AVALIAÇÃO DE DESEMPENHO

EM COMPUTADORES COM ARQUITETURA PARALELA

Adhemar Maria do Valle Filho

Es t a Dis s e r t a ç ã o Fo i Ju l g a d a Ad e q u a d a Pa r a Ob t e n ç ã o Do Tít u l o De

M

e s t r e e m c iê n c ia d a

C

o m p u t a ç ã o

e s p e c i a l i d a d e a r q u i t e t u r a d e c o m p u t a d o r e s e a p r o v a d a e m s u a f o r m af i n a l

PELO PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA D A COMPUTAÇÃO.

~C*

o

-Prof. Murilo Silva de Camargo, Dr Coordenador do Curso

BANCA EXAMINADORA:

E sta dissertação tornou-se possível a partir do auxílio direto ou indireto de inúm eras pessoas. Cabe aqui o registro especial à figura do m eu orientador que soube m e conduzir sem pre que m e deparava frente a um problem a sem solução abrindo novas perspectivas. Tam bém seu papel foi im portante em term os de recursos físicos, em prestando-m e sua sala e eo'.;ipamento de trabalho.

É im portante ressaltar a atuação da coordenação, professores e secretárias do Curso de Pós-G raduação em Ciência da Com putação através da organização e do fornecim ento de várias disciplinas teóricas para o em basam ento científico, passo fundam ental para a consecução da dissertação.

Ao CNPQ e CAPES, órgãos financiadores de bolsas de pesquisa, agradeço por tornarem viável o presente trabalho e por acreditarem no em penho de professores e alunos.

Aos com panheiros de laboratório e de sala de estudo, agradeço a colaboração tanto nas horas de trabalho quanto na organização do ambiente.

M inha gratidão aos meus pais e irmãs, um agradecim ento especial a m inha esposa que me incentivou e acom panhou-m e nesta caminhada.

Sumário

SUM ÁRIO ...iv

LISTA DE FIGURAS ...vii

LISTA DE TABELAS ... x

LISTA DE ABREVIATURAS...xi

RESUMO ...xiii

ABSTRACT ... ... xiv

1. Introdução... 1

2. Revisão do Estado da A rte...4

2.1 In t r o d u ç ã o... 4

2.2 Pr o c e s s a m e n t o p a r a l e l o...5

2.3 Fe r r a m e n t a s p a r a Av a l i a ç ã o... 8

2.3.1 Aplicação da Sim ulação ... 9

2.3.2 Vantagem e Desvantagens da Sim u la çã o ...10

2.3.3 O Processo de Sim ulação...11

2.3.4 Linguagens de Sim ulação... 12

3. O Multicomputador Nó / / ...16

3.1.1 O M odelo de Arquitetura Baseado em um Barram ento C om um ...16

3.1.2 O M odelo de Arquitetura Baseada em um Sistem a de In terru p çã o ... 18

3 .2 Co m p o n e n t e s d o Mu l t i c o m p u t a d o rNó / / ... 19 3.2.1 Os Nós de Trabalho... 19 3.2.2 O Nó de C ontrole...20 3.2.3 O C ro ssb a r...20 3.2.4 Os Canais de C om unicação... 21 3.2.5 Placas de Interface...22 4. M odelagem ...25 4.1 De f i n i ç ã o...25 4.2 Ti p o s d e Mo d e l o s...26 4.3 Am b i e n t e p a r a Mo d e l a g e m e Si m u l a ç ã o...27

4.3.1 Componentes do Am biente de M odelagem do A R E N A ...29

4 .4 Ex e m p l o d e Mo d e l a g e m n o A RENA 2 . 1 ...31

4.4.1 M odelo to m Linhas de Interrupção ...32

4.4.2 M odelo com barramento de serviço ...35

5. T em plates... 38

5.1 Me t o d o l o g i a p a r a a Co n s t r u ç ã o d e u m Te m p l a t e...39

5.1.1 Descrição do sistem a...39

5.1.2 M ontagem do m o d e lo ...4 0 5.1.3 Divisão do m odelo ... 41 5.1.4 Construção do m ó d u lo ... 41 5.1.5 Validação...42 5.2 Ap l i c a ç ã o d a Me t o d o l o g i a...4 2 6. Ferramenta desenvolvida...48 6.1 Ap r e s e n t a ç ã o da Fe r r a m e n t a Pa r a l e l o I N T ...48 6.1.1 íco n es...49 6.1.2 Construção do m odelo...50 6.1.3 Caixas de d iá lo g o ... 51 6.2 Ap r e s e n t a ç ã o da Fe r r a m e n t a Pa r a l e l o B U S ... 56 1'

6.3 Va l i d a ç ã o d a f e r r a m e n t a... 57

7. C onclusões... 59

8. Bibliografia...62

A N EX O ...65

Figura 2-1: Estrutura geral de um m ulticom putador... 7

Figura 3-1: A rquitetura com barram ento de serviço...17

Figura 3-2: A A rquitetura Baseada em um Sistem a de Interrupção para o M ulticom putador N ó //... 18

Figura 3-3: Estrutura do nó de trabalho...19

Figura 3-4: Estrutura do nó de controle...20

Figura 3-5: D iagram a de blocos básico do cro ssb a r...20

Figura 3-6: D iagram a de blocos dos Canais de C on fig u ração ... 21

Figura 3-7: Diagram a de Blocos da Placa de Interface do nó de trabalho...22

Figura 3-8: D iagram a de Blocos da Placa de Interface do nó de controle...23

Figura 4-1: A m biente de trabalho... 29

Figura 4-2: Ilustração representativa sobre templates e p a in é is... 30

Figura 4-3: M enu de Interação com a simulação do m odelo... ...31

Figura 4-6: M ódulos que com põem o nó de controle...

Figura 4-7: M ódulos que fazem parte do crossbar...

Figura 4-8: V isão geral do modelo que sim ula o N ó// na arquitetura com Linhas de In terru p ção ...

Figura 4-9: Conjunto de m ódulos que representa o barram ento de s e rv iç o ...

F igura 4-10: V isão geral do m odelo que sim ula o N ó// na arquitetura com barram ento de serviço ...

Figura 5-1: Exem plos de Tem plates - SIMAN - Blocks (a), A REN A - Support (b) e C om m on ( c ) ...

Figura 5-2: D ivisão dos m ódulos ressaltando o r.c i c trabalho l ...

Figura 5-3: D efinição dos M ódulos que farão parte do T em plate...

Figura 5-4: Janela O perandos e "P r e v i e w ...

F igura 5-5: Janela L ó g ic a ...

Figura 5-6: Janela Visão do U su á rio ...

Figura 5-7: Janela de C haveam ento...

Figura 5-8: Exem plo de dialog box onde ocorre ch av eam en to ...

Figura 5-9: Janela ícone e sua posição na área de trabalho do A REN A (“work a rea ’’’) ...

Figura 6-1: ícones do Tem plate Paralelo IN T ...

Figura 6-2: M odelo de sim ulação de arquitetura paralela com 8 nós de trab a lh o ...

Figura 6-3: Caixa de diálogo referente ao nó de tra b a lh o ...

O o J J ^ "> JO 34 35 36 38 43 44 44 45 45 46 .46 47 .49 .50 .51

Figura 6-4: C aixa de diálogo para o m ódulo nó de c o n tro le ... 52

Figura 6-5: Caixa de diálogo para o m ódulo cro ssb a r... 52

Figura 6-6: Definição dos N ós de Trabalho e apresentação dos R esultad os...53

Figura 6-7: M atriz de vetores de com unicação...54

Figura 6-8: A nim ação agregada ao m ódulo...55

Figura 6-9: M odelo com animação de arquitetura com linhas de in terru p ção ... 55

F igura 6-10: M ódulo para barram ento de s e rv iç o ... 56

F igura 6-11: Ilustração de anim ação em arquitetura com barram ento de se rv iç o ... 57

Lista de Tabelas

Tabela 2-1: T axonom ia para arquiteturas paralelas [B EL 94]... 5

Tabela 2-2 : Taxonom ia para arquiteturas paralelas (continuação) [B EL 94]... 6

Tabela A N E X O -1: A nálise ao tsm po gasto em com unicações... 66

Tabela ANEXO-2: Gráfico do Tempo de processam ento & Núm ero de nós de trabalho...67

Tabela A N EX O -3: V ariando núm ero de com unicações e núm ero de v ia s ... 68

Lista de Abreviaturas

• A TM (Assynchronous Transfer M ode) - M odo de transm issão assíncrono; • CISC (C om plex instruction Set C om puting) - Conjunto de instruções com plexas; • C O M A (Cache Only M em ory A ccess) - M em ória local transform ada em cache;

• GUI (G raphical User Interface) - Interface voltada ao " j i ário;

• I/O {Input/Output) - Entrada/Saída;

• M IM D (.M ultiple Instruction M ultiple Data) - Instruções m últiplas e dados m últiplos;

• M ISD (.M ultiple Instruction Single Data) - Instruções m últiplas, dados simples;

• N ORM A (j¥ott Rem ote M em ory A ccess) - Acesso a m em ória não remota;

• N U M A (Non Uniform M em ory A ccess) - Acesso a m em ória não uniform e;

• RA M (Random A ccess M em ory) - M em ória de acesso direto;

• RO M (R ead Only M em ory) - M em ória apenas de leitura;

• R ISC (Reduced Instruction Set Com puterisation) - Conjunto de instruções com putacionais de tam anho reduzido;

• SIM D (Single Instruction M ultiple Data) - Instruções simples, dados m últiplos;

V LSIW ( Very Large Scale Integration) - Circuitos Integrados em m uito-larga escala;

SISD (>Single Instruction Single Data) - Instruções sim ples dados simples;

A presenta-se neste trabalho o desenvolvim ento e im plem entação de um a ferram enta para a m odelagem e sim ulação de sistem as com putacionais, cujo objetivo é facilitar e reduzir o tem po associado a esta etapa, em projetos de avaliação de desem penho, com a redução do tem po entre o projeto e sua im plem entação. M ais especificam ente, a ferram enta destina-se a m odelagem de ^iV.emas cue com portam um a arquitetura de processam ento paralelo em configuração com linhas d^ interrupção e barram ento de serviço. Ela reúne um a linguagem de sim ulação, possui um a interface am igável com alta flexibilidade e atende às características específicas daqueles sistem as. Estudos de sistem as com plexos, como os que envolvem o projeto de arquitetura de com putadores, necessitam de ferram entas para sim ulação e análise de desem penho das inúm eras propostas que se apresentam . A ferram enta aqui proposta fornece assistência ao projetista perm itindo a análise do sistem a em todas as etapas de m odelagem e avaliação de perform ance do projeto, desde a coleta de dados até a apresentação e análise dos resultados. E oportuno o desenvolvim ento deste tipo de pesquisa, um a vez que, a grande m aioria das ferram entas existentes no mercado, não conseguem reunir as características que o usuário procura para encam inhar soluções aos inúm eros problem as que surgem ao longo do projeto. O trabalho foi desenvolvido a partir de conhecim entos nas áreas de arquitetura paralela, sim ulação e m odelagem de sistem as juntam ente com o projeto N ó // (leia-se nó paralelo) desenvolvido na U niversidade Federal de Santa Catarina.

Abstract

This w ork presents the developm ent and im plem entation o f a tool for m odeling and sim ulation o f com puter systems. Its m ain purpose is facilitate and abbreviate the tim e devoted to this step, reducing the gap betw een design and im plem entation. Specifically, the tool is suitable to m odel system s that involve parallel processing architecture w ith interrupt requests and bus service. The tool includes a simulation. Language and a GUI (G raphical U ser Interface) w ith high flexibility that is tailored for design those systems. The tool provides a support in every stage o f m odeling and perform ance evaluation, from getting data to the analysis and presentation o f results. This is a convenient research developm ent because o f the m ajority o f the existing tools in the m arket do not provide some characteristics that users are looking for to im prove solutions to their problem s. This w ork has been developed as a part o f the research project called Parallel N ode Project in Federal U niversity o f Santa Catarina. Parallel architecture processing, systems m odeling and sim ulation are the m ain know ledge subjects that contributed to this research.

1. Introdução

Trabalhos que envolvem construções de sistem as com alto grau de com plexidade necessitam de ferram entas que auxiliem a análise para buscar a máxim?. perform ance e ao m esm o tem po perm itam grande flexibilidade em seu uso. Este trabalho apresenta o desenvolvim ento de um a ferram enta destinada à m odelagem e sim ulação de sistem as com estrutura de processam ento paralelo.

O projeto Nó // (leia-se nó paralelo) é um trabalho de pesquisa no qual associa grupos nas áreas de A rquitetura de Com putadores, Sistem as O peracionais e Linguagens de Program ação na U niversidade Federal de Santa Catarina, que busca desenvolver um am biente com pleto para a program ação paralela [COR93], O projeto está em fase adiantada, porém a m áquina real ainda está em fase de construção. Qual arquitetura deve ser adotada, ou qual velocidade deve ter o barram ento, são perguntas que surgem nesta fase de projeto. Para responder estas questões e auxiliar na tom ada de decisões dispõe-se das ferram entas para a m odelagem e simulação. Os produtos existentes não estão dirigidos a fornecer ao usuário um a interface com nom enclaturas do seu dia a dia e não perm item flexibilidade para a criação destas m odelagens e sim ulações em um curto espaço de tempo.

A área de sistem as com putacionais vem adquirindo um a m aior com plexidade a cada nova geração de m áquinas. Para a análise destas novas m áquinas surgem sistem as m atem áticos

avaliação do problem a, decisões de projeto e análise destes sistem as com plexos, o analista encontra com o alternativa vários cam inhos, tais como a m odelagem e sim ulação. Nestas ferram entas o projetista depara-se com as características antagônicas relativas à facilidade & flexibilidade. Com o propósito de construção de um m odelo voltado para a análise de perform ance de sistem as, as dificuldades que um analista encontra são as mais variadas, entre elas estão o desconhecim ento de um a linguagem específica de sim ulação, a falta de flexibilidade ao adotar um a linguagem de propósito específico, o am biente de trabalho diferente do seu dia a dia e o tem po gasto até atingir um produto final para que possa realizar um a análise do m odelo.

O objetivo deste trabalho é a construção de uma ferram enta para a m odelagem de sistem as na área de arquitetura paralela. É uma ferram enta que procura m inim izar as dificuldades encontradas por usuários, dá prioridade em apresentar um am biente “natural” dos usuários potenciais e envolve os conceitos clássicos de m odelagem e sim ulação. Com a utilização de Tem plates ;specíficos gerados num a linguagem de sim ulação, o usuário não necessita de profundos conhecim entos de program ação e os term os utilizados na interface fazem parte do seu am biente de trabalho. A ferram enta apresenta um a interface am igável, que perm ite grande flexibilidade, exibindo ícones com figuras e term os utilizados norm alm ente em processam ento paralelo. O objetivo da utilização desta ferram enta, além dos descritos anteriorm ente, é dim inuir o intervalo que separa o projeto da m odelagem do sistem a.

Para a construção desta ferram enta foi escolhido um am biente de m odelagem , com flexibilidade e com um a interface gráfica voltada ao usuário (GUI - G raphical User Interface), que ao m esm o tempo perm itisse o desenvolvim ento de Tem plates específicos. Para tanto, desenvolveu-se uma m etodologia que segue determ inados passos:

• descrição do funcionam ento do sistema;

• construção de um modelo referente ao sistem a para o qual está voltada a confecção do Tem plate:

• definição da interface para o usuário: • validação.

configuração com linhas de interrupção ou com barram ento de serviço. O utra lim itação im portante é a possibilidade do aparecim ento de novas tecnologias com características não incluídas na ferram enta construída.

Este trabalho está estruturado em 6 capítulos. N o capítulo 2 apresenta-se um a visão geral dos estados da arte na área de arquitetura paralela no âm bito do projeto N ó //, assim como as ferram entas utilizadas para a sua avaliação. No capítulo 3 descreve-se a m áquina N ó // com os elem entos que fazem parte do projeto e no capítulo 4 conceitua-se “M odelagem ” com exem plos utilizados na construção da ferram enta, que é o objeto deste trabalho. No capítulo 5 apresenta-se os conceitos de Tem plate e a m etodologia desenvolvida para a sua construção; no capítulo 6 exam ina-se os dois painéis construídos que fazem parte do Tem plate e apresenta-se as interfaces de com unicação com o usuário, e no capítulo 7 expõe-se as conclusões e sugestões para futuros trabalhos a serem desenvolvidos sobre o tema. No anexo colocou-se a validação com tabelas e com parações.

2. Revisão do Estado da Arte

2.1 Introdução

N este capítulo apresenta-se um a visão geral dos estados aluai1: dao arres nas áreas relacionadas com o trabalho realizado. Ele está dividido da seguinte forma: processam ento paralelo, sim ulação, m odelagem , projeto N ó // e as ferram entas utilizadas para sua avaliação.

A necessidade atual da m axim ização do desem penho das aplicações é devida, principalm ente, à tendência dos sistem as no sentido ascendente de sofisticação e com plexidade [M ON95]. Para solucionar o problem a nas áreas de cálculos, processam ento de sons e de im agens, a com putação necessita de m ecanism os com elevado desem penho e alta confiabilidade, o que significa m áquinas rápidas com grande poder de processam ento [RIC96]. Com a disponibilização no mercado de processadores de baixo custo e da tecnologia de novas arquiteturas, idealizou-se a m áquina paralela.

As m áquinas paralelas foram projetadas de acordo com as necessidades em aplicações específicas. Foram desenvolvidas tecnologias de ponta, em várias configurações, dentro de Centros de Pesquisa em U niversidades e Empresas. Para o acom panham ento e estudo destas novas tecnologias, desenvolveram -se tam bém ferram entas especializadas, m odelos de sim ulação que suportem o paralelism o, bem como técnicas de m odelagem e avaliação de desem penho. A lgum as destas ferram entas surgiram com o Projeto Nó // para auxílio ao estudo e pesquisa.

alteração e validação do projeto. Para a construção de um m odelo de sim ulação, um a das m aiores tarefas é a conversão da descrição do sistem a em um program a para o com putador [LAW 94]. O projetista necessita da escolha de um a linguagem , que pode ser de propósito geral ou de propósito específico para sim ulação. As linguagens e softwares existentes no mercado que podem ser aplicados em com putação paralela não possuem uma interface com term os que sejam am bientados com a área. O tem po aplicado pelo projetista em aprender u m a linguagem pode ser reduzido com a utilização de um a interface com term os-padrão e de fácil m anuseio.

2.2

Processamento paralelo

A rquiteturas paralelas são caracterizadas pela presença de m últiplos processadores que cooperam entre si na execução de um a única aplicação [DUN90], A busca do alto desem penho para atender à crescente dem anda e processam ento m otivou o aparecim ento de vários m odelos de arquiteUF?s paralelas.

D iversas taxonom ias foram propostas para abranger as diferenças de projeto dos com putadores que possuem paralelism o. Gordon Bell, em 1994, atualizou a classificação apresentada por Flynn em 1972, apresentando novas variações e m odelos surgidos até então (Tabela 2-1 e Tabela 2.2).

Tipo de Fluxo de

Instruções

Tipo de fluxo de

dados

Tipo de Processamento

único

único

CISC

RISC

Superescalar e VLSIW RISC

Processadores de sinais digitais

“Multi-threaded"

múltiplos

Vetoriais

SIMD

Tipo de Fluxos de

Instrução

Fluxo de

dados

Tipo de acesso à

memória

Armazenamento

multiprocessador

acesso a memória não uniforme

somente cache (COMA)

(memória

“memory coherent

compartilhada)

nenhum cache

acesso a memória uniforme

"multi-threadecT

supercomputadores e

“mainframes”

Múltiplos

múltiplos barramentos

m ulticomputador

chaveamento distribuído

granularidade fina

homogênea

(passagem ue

o

_{granularidade média não}

homogênea

mensagem)

centralizado

estações

interconectadas na rede

rede distribuída

aglomerados

estações em rede local

estações em

rede

externa

Tabela 2-2 - Taxonomia para arquiteturas paralelas (continuação) [BEL94|

A m áquina que apresenta fluxos de instruções únicos é caracterizada pela execução de um fluxo em cada processador. A brange desde os com putadores CISC até os superescalares, V LSIW RISC, com palavras de instruções bem longas e com putadores “m ulti-threaded" onde m últiplos "threads” processam o m esm o fluxo de instruções. Os processadores vetoriais com dados m últiplos SIM D são os núcleos dos supercom putadores largam ente utilizados em aplicações com uso de ponto flutuante e aplicações com transform ações gráficas.

O m odelo que apresenta fluxos de instruções m últiplos denom inados “M IM D ” é com posto de instruções m últiplas sobre fluxos distintos de dados em seus vários processadores. São divididos em duas classes de acordo com a form a de com unicação entre os processadores: os m ultiprocessadores e os m ulticom putadores.

Os m ultiprocessadores que apresentam m em ória com partilhada dividem -se em duas categorias: acesso à m em ória uniform e (UM A- Uniform M em ory Access) e acesso à m em ória não uniform e (N UM A - Non Uniform M em ory Access). U m a subclasse de N U M A possui cada nó de processam ento com m em ória local transform ada em cache (CO M A - Cache Only M em ory Access). Esta m em ória é caracterizada pelo seu acesso rápido. O utra subclasse, classificada com o “coerência de m em ória”, apresenta m em ória cache pequena, utilizada para acessos a dados presentes na m em ória do outro nó.

Os m ulticom putadores caracterizam -se por apresentar recursos de com unicação por passagem de m ensagem . U m m ulticom putador é constituído por m últiplos nós associados através de um a rede de interconexão. Cada nó é um com putador autônom o e possui um processador, m em ória e pode possuir discos ou periféricos de I/O (Figura 2-1).

Figura 2-1- Estrutura geral de um multicomputador.

Em um m ulticom putador não existe com partilham ento de m em ória, e a interação entre os nós ocorre por meio da troca de m ensagens pela rede de interconexão. Com o não ocorre acesso a dados em m em ória rem ota, este tipo de arquitetura é tam bém cham ado de N O R M A (Non R em ote M em ory Access).

Os m ulticom putadores podem ser agrupados em duas gerações, conform e o esquem a de com unicação “entre os nós” utilizado: “arm azena-e-repassa” ou “circuito chaveado” . Os m u l t i c o m p u t a d o r e s da prim eira geração baseiam -se no esquem a “arm azena-e-repassa” para im plem entar um m ecanism o de chaveam ento, ou roteam ento, de m ensagens por software.

N a segunda geração de m ulticom putadores, é utilizada a técnica de “circuito chaveado” , através de um m ecanism o de chaveam ento de m ensagens por hardware. Em geral, os m ulticom putadores utilizam redes de interconexão estáticas, com o a grelha ou o hipercubo [CA M 95]. A lguns m odelos adotam redes dinâm icas com o o crossbar para estabelecer a com unicação entre os processadores da máquina.

U m exem plo de m ulticom putador da prim eira geração é o Intel iPSC/1 [HW A93], Entre os m ulticom putadores da segunda geração destacam -se o nCU BE/2, o Intel Paragon X P/S e o SuperNodelOOO da Parsys [QUI94],

É im portante observar que sistem as com postos por “ W orkstations”, interconectadas por redes de alta velocidade com o o A TM (.Assynchronous Transfer M ode) podem ser classificados com o com putadores escaláveis e podem apresentar um custo de com unicação da ordem dos m ulticom putadores [MID96].

2.3 Ferramentas para Avaliação

As técnicas de avaliação de desem penho podem ser por m odelagem analítica (teoria das filas), por sim ulação e por coleta de medidas. Para cada caso estudado, um conjunto de critérios de perform ance ou de m edidas deve ser escolhido. U m a m aneira de preparar este conjunto é fazer um a lista dos serviços que o sistem a oferece. Critérios de com o realizar as tarefas corretam ente e tem po gasto para realizá-las, recursos utilizados para realização do serviço, podem ser considerados. M uitos projetistas que desenvolvem m odelos analíticos consolidam seu projeto usando sim ulações e m edições [JAI91].

Para determ inar qual a técnica a ser utilizada, levantaram -se alguns pontos:

• a técnica por m odelagem analítica não deverá envolver sistem as m uito com plexos devido à dificuldade dos cálculos, como, por exem plo, em teoria das filas.

• a técnica por coleta de m edidas necessita da m áquina real ou pelo m enos de um protótipo.

• a técnica por sim ulação utiliza m áquinas com alto poder de processam ento e softw ares adequados.

As técnicas para a m odelagem são usadas para decidir o nível apropriado de detalham ento do m odelo, tais como: definir no início do estudo as m edidas de desem penho para avaliação, delinear todas as inform ações e dados no histórico do m odelo e com parar as m edidas de desem penho com um a avaliação anterior (se existir) [LAW94] [STR94],

Sim ulação é o processo de projetar o m odelo de um sistem a real e conduzir experim entos com ele no intuito de com preender seu com portam ento e avaliar as estratégias para a operação do sistem a. A sim ulação deve abranger a construção do m odelo bem com o a sua experim entação. É um a m etodologia que procura descrever o com portam ento do sistema, construir teorias ou hipóteses que tracem o com portam ento observado e finalm ente usá-lo para fazer previsões futuras, para verificar os efeitos produzidos por trocas no sistem a ou no seu m étodo de operação.

2.3.1 Aplicação da Simulação

A sim uiação é propícia em c^da cslado de pesouisa na utilização e uso de técnicas de pesquisa operacional, devido à sua grande versatilidade, poder e flexibilidade. Quase todos os tipos de sistem as já foram ou podem ser simulados. Pode-se citar alguns exem plos:

=> Sistem as com putacionais: com ponentes de hardw are, sistem as de softw are, redes de com putadores, gerenciam ento e estruturação de dados, processam ento de inform ação.

=> M anufatura: linhas de m ontagem , produção autom atizada, arm azenagem autom atizada, sistem as de controle de inventário, estudos de m anutenção e integridade.

=> N egócios: análises de ações e m ercadorias, política de preços, estratégias de m ercado, estudos para aquisição, análise de fluxo de caixa, previsão.

=> G overno: táticas m ilitares, resgate médico, proteção contra incêndios, serviços policiais, desenhos de estradas e controle de tráfego.

E cologia e am biente: poluição da água e purificação, previsão do tem po, análise de terrem otos e tem pestades, sistem as de energia solar e escoam ento de produção.

2.3.2 Vantagens e Desvantagens da Simulação

As vantagens da sim ulação com eçam pelo fato de que seu conceito é facilm ente com preendido. Isto significa que ao apresentá-lo para um gerente junto com um modelo analítico, ele certam ente irá preferir o modelo simulável.

Pontos favoráveis à simulação:

=> Pode-se explorar novos procedim entos, regras de decisões, estruturas organizacionais, fluxos de inform ações.

=> N ovos projetos de hardw are, layouts físicos, sistem as de transportes e program as de softw are podem ser testados sem com prom eter recursos para aquisição e ou im plem entação.

=> H ipóteses sobre como ou porque certo fenôm eno ocorre, se pode ser testado e se isto é viável ou não.

=> A execução da sim ulação pode ser controlada. M uitas vezes é necessário ru e o sistem a execute várias operações rapidam ente ou lentam ente para observar determ inados detalhes.

=> Pontos de estrangulam ento podem ser constatados no fluxo de inform ações ou de dados.

=> Um estudo de sim ulação consegue fornecer im portantes evidências de com o o sistem a funciona.

D esvantagens:

=> A construção de m odelos requer pessoal especializado e a qualidade da análise depende m uito da qualidade do modelo e do talento do projetista. A sua construção representa uma arte e o talento dos profissionais varia enormemente.

=> Os resultados de uma simulação, às vezes, são difíceis de ser interpretados. Quando colocam -se variáveis randôm icas em um sistem a real. é com plicado determ inar se uma observação é relacionada a uma com binação interna do sistem a ou é efeito da casualidade randômica.

=> A análise por sim ulação pode consum ir m uito tem po e possuir um custo elevado. Uma análise pode não ser viável quando o tempo e os recursos são lim itados. Por isso, para realizar um cálculo rápido, pode ser preferível, às vezes, utilizar m étodos analíticos de modo manual.

2.3.3 O Processo de Simulação

O processo de sim ulação envolve técnicas para resolver problem as e prática em engenharia de software. A lguns pontos im portantes são apresentados, os quais auxiliam a construção de um m odelo de sim ulação e que, após a análise dos resultados, podem ajudar a decisão final referente a m odificações e m elhorias do desem penho do sistem a:

=> D efinir claram ente os objetivos e planejar os recursos, com o por exem plo, com putadores e seus periféricos.

=> D efinição de como sistem a opera.

=> Form ulação conceituai do m odelo, através de diagram a de blocos.

=> Projeto experim ental com m edidas, fatores a serem variados, dados necessários para o m odelo, form ato e quantidade.

=> Preparação para a entrada dos dados.

=> Form ular o m odelo em um a linguagem apropriada de simulação.

=> V alidação e verificação - confirm ar que o m odelo opera da m aneira que o analista previu e que os dados fornecidos representam fielm ente a saída do m odelo real.

=> Projeto experim ental final - projetar um experim ento que irá produzir a inform ação desejada e determ inar quantas vezes o teste deverá rodar especificam ente no m odelo projetado.

=> Executar a sim ulação para gerar os dados desejados e efetuar um a análise mais discrim inativa.

=> Im plem entação e docum entação - colocar os resultados em prática, coletando os resultados e docum entando-os.

2.3.4 Linguagens de Simulação

U m a das m aiores tarefas na construção de um m odelo de sim ulação é a conversão da descrição do sistem a em um program a para o com putador [LAW 94], Para construir um modelo de um sistem a e posteriorm ente sim ulá-lo, necessita-se de um a linguagem de sim ulação. Esta linguagem deve oferecer vantagens com o um am biente flexível e que perm ita a facilidade de utilização para a área em que ela será aplicada.

O desenvolvim ento de linguagens de sim ulação pode ser dividido em vários períodos [NAN84] [NAN93]. Por volta d o : ?.nos 60, ucias as sim ulações eram escritas em um a linguagem de uso geral, muito difundida na ép^ca, o FORTRA N. N os anos seguintes até m eados de 65, apareceram linguagens para uso específico em sim ulação, com o por exem plo GPSS, etc. Até os anos 70, aperfeiçoaram -se estas linguagens com revisões, novas versões e im plem entações. A evolução continuou e nos anos 80 surgem linguagens com binadas para a m odelagem discreta e contínua. Ao m esm o tem po iniciam -se estudos para a m udança de critérios até então aplicados nas linguagens, visando facilitar o desenvolvim ento de m odelos e sua execução. Enquanto alguns autores se preocupavam com m étodos potenciais para fácil program ação [HEI74] [M AT74], outros procuravam dar-lhe um a abordagem m ais formal [ZEI76] [KLE77] [NAN77], A ênfase atual é prover um a interface am igável, com fácil interação entre o usuário e o program a, procurando sim plificar a apresentação de resultados.

A taxonom ia em linguagens de sim ulação pode ser resum ida em três divisões: linguagens de uso geral, linguagens de sim ulação de uso geral e linguagens de sim ulação de propósito específico.

2.3.4.1 Linguagens de uso geral

U m m odelo de sim ulação pode ser escrito em linguagens de propósito geral, com o por exem plo C, BA SIC , FO R TRA N , PA SCA L e C++ [JAC84],

A lgum as vantagens das linguagens de program ação de uso geral: • O usuário, em geral, possui dom ínio da linguagem;

• C e FO R T R A N são encontrados em vários com putadores;

• O custo para aquisição de um a linguagem de uso geral é com um ente m ais baixo; A lgum as desvantagens:

• A lguns usuários podem não dom inar um a linguagem de program ação;

• A program ação de um modelo de sim ulação exige um estudo mais apurado do software, pois será direcionada a um caso específico;

• A docum entação deve ser bem detalhada para perm itir a utilização por outros usuários;

2.3.4.2 Linguagens de simulação de uso geral

Existe tam bém a possibilidade de m odelagem pelo uso de linguagens de sim ulação de propósito geral. Com o exem plo pode-se citar: G PSS/H , SIM A N /C inem a V, SIM SC R IPT II.5. A grande vantagem de um produto voltado à área de sim ulação é que ele fornece um a série de funções necessárias à m odelagem de qualquer tipo de sistem a, com o por exem plo, a geração de núm eros e funções aleatórias. A desvantagem é que para o usuário com preender esta com plexa linguagem , necessita dispender de um tem po que poderia ser utilizado para outros fins.

2.3.4.3 Linguagens de simulação de propósito específico

A ênfase atual em desenvolvim ento de softw ares para sim ulação volta-se para a facilidade de uso por parte do usuário com a criação de am bientes integrados entre um a linguagem poderosa e flexível com um a interface amigável.

São produtos direcionados a objetivos m ais específicos, quais sejam a m odelagem de sistem as de telecom unicações, redes de com putadores, m anufatura, etc. Cita-se a seguir alguns exem plos [LAW 94].:

a) SIM Factory - para a área de m anufatura (pouca flexibilidade);

b) C O N ECT, BO NeS D ESIG N ER e CO M N ET III - pacotes de m odelagem de redes (pouca flexibilidade);

c) A R EN A M P$im (M anufacturing Process Sim ulation) - pacote de sim ulação específico para a área de M anufatura (m aior flexibilidade);

M ais recentem ente, um novo objetivo tem -se im posto: a procura por am bientes que apresentem tanto a facilidade de uso (via interface am igável) quanto um a m aior flexibilidade.

N os exem plos anteriores, os itens a) e b) possuem com o desvantagem a falta de flexibilidade, o que não acontece com o item c). A linguagem de program ação de propósito espt^ifico A R EN A M P$im perm ite o uso de suas características direcionadas à area de m anufatura, porém com acesso a todos os recursos básicos oferecidos pela poderosa linguagem SIM AN e pelos Tem plates padrões do ARENA.

Pode-se citar algum as vantagens de um a linguagem de caráter específico:

• Redução do tem po de program ação e conseqüentem ente do custo do projeto;

• Facilidade de uso para profissionais da área, pois utiliza palavras conhecidas sobre redes de com unicações e com putadores;

• Fornece as características im plícitas de que o modelo necessita.

A lgum as desvantagens são:

• A linguagem de program ação de propósito específico necessita de um estudo mais aprofundado;

• Um softw are de propósito específico não se encontra disponível em qualquer com putador de analistas;

• O softw are de caráter específico apresenta um custo mais elevado em com paração com um softw are de propósito geral;

N este capítulo foram apresentadas algum as noções sobre processam ento paralelo, inchúndo taxonom ias e características de cada tipo, dando ênfase ao m ulticom putador. Foram citadas as técnicas existentes para avaliação de sistem as, ou seja, analítica, de sim ulação e de coleta de dados. Para cada um a delas, apresentou-se as suas vantagens e desvantagens.

3. O Multicomputador Nó II

O M ulticom putador N ó // é o nome dado à m áquina com arquitetura paralela em desenvolvim ento no Curso de Pós G raduação em Ciência da C om putação da U niversidade Federal de Santa Catarina. N este capítulo será feita um a descrição geral da m áquina citando- se as duas configurações básicas. Serão apresentados os com ponentes do m ulticom putador e ao m esm o tem po o seu funcionam ento básico.

3.1 Descrição do Multicomputador Nó

//

O m ulticom putador Nó // é com posto por um conjunto de nós processadores e um nó de controle interligados por um meio físico denom inado crossbar. Cada nó possui um a placa de interface para com unicação com outros nós. As conexões entre os nós são estabelecidas pelo crossbar dinam icam ente, conform e a dem anda do program a paralelo em execução. O nó denom inado nó de controle tem a função de receber as requisições de serviço dos dem ais nós e atendê-las atuando sobre o crossbar.

Foram propostos dois m odelos de arquitetura para o m ulticom putador N ó //: um m odelo baseado em um barram ento com um e outro baseado em um sistem a de interrupção.

3.1.1 O Modelo de Arquitetura Baseado em um Barramento Comum

Foi a prim eira concepção do m ulticom putador Nó //, com um conjunto de nós de trabalho interligado por meio de um com utador de conexões e um barram ento com partilhado. O com utador de conexões é m anipulado durante o funcionam ento norm al da m áquina pelo nó de controle. Este utiliza um barram ento de serviço e um link de configuração para receber

indicações do sistem a e definir dinam icam ente a estrutura da rede com unicação. O m odelo é apresentado na Figura 3-1.

Figura 3-1 : Arquitetura com barramento de serviço

O nó d ;1 controle realiza um a busca seqüencial através do barram ento de serviço para detectar algum pedido efetuado pelos nós de trabalho. E sta busca é feita através do envio de um com ando ao nó inquirido. Se este não sinaliza algum serviço, o nó de controle questiona o próxim o nó de trabalho. Caso o nó questionado necessite de um serviço, ele envia, então, um a requisição ao nó de controle. A pós atender cada pedido, o nó de controle volta ao questionam ento seqüencial aos nós de trabalho.

Se o pedido de serviço retornado pelo nó de trabalho for um pedido de conexão com outro nó, o nó de controle envia ao com utador de conexões a configuração para a conexão pedida. Se o nó solicitado já estiver conectado, o pedido é colocado em um a fila de espera e o nó de controle prossegue com o polling.

Esta arquitetura apresenta um inconveniente na execução do polling pelo nó de controle, pois se um nó de trabalho que foi questionado quiser fazer um pedido de serviço, terá que esperar todos os outros nós da seqüência serem questionados e atendidos, até chegar novam ente a sua vez. Este problem a é agravado quando se aum enta o núm ero de nós.

3.1.2 O Modelo de Arquitetura Baseada em um Sistema de Interrupção

O m odelo descrito a seguir é um a nova arquitetura com o objetivo de m elhorar o m ecanism o apresentado no item anterior. Ele é com posto por linhas de interrupção substituindo o barram ento de serviço. Estas linhas são exclusivas entre os nós de trabalho e o nó de controle (Figura 3-2), representadas por um par de linhas unidirecionais referidas por IN TRtc e IN TRct. A linha IN TRtc é usada pelo nó de trabalho para interrom per o nó de controle, enquanto que a linha IN TRct é utilizada pelo nó de controle para interrom per o nó de trabalho.

Figura 3-2 : A Arquitetura Baseada em um Sistema de Interrupção para o M ulticom putador Nó//

As linhas de interrupção têm a função de indicar a ocorrência de um evento e não podem ser utilizadas para a transferência de dados. Q uando o nó de trabalho necessita enviar um a requisição de serviço ao nó de controle, interrom pe-o através da linha IN TRtc. O nó de controle, conform e a prioridade, estabelece conexão via crossbar com o nó que gerou a interrupção. Estabelece a troca de m ensagens de controle através da requisição de serviço e após a troca a conexão é desfeita. O nó de controle avaliará a requisição e, no m om ento de atendê-la, ativa a linha de interrupção IN TRct do nó de trabalho requisitante, que vai perm itir a realização do serviço requisitado.

As transferências de dados ou de m ensagens de controle somente são efetuadas através da rede de com unicação. O atendim ento a um a requisição não será seqüencial, tipo polling. Isso acarreta a dim inuição no overhead associado à com unicação, pois depende apenas do atendim ento da interrupção e do chaveam ento do crossbar.

3.2 Componentes do Multicomputador Nó //

O m ulticom putador Nó // é subdividido em duas partes: a rede de com unicação e o sistem a de interrupção. N este item serão descritos os com ponentes do M ulticom putador N ó// a seguir citados: nós de trabalho, nó de controle, com utador de conexões ou crossbar, canais de com unicação e as placas de interface.

3.2.1

Os Nós de Trabalho

O M ulticom putador Nó // é constituído de nós com processadores i486, m em ória RAM privativa de 4M b, m em ória ROM com o sistem a operacio.ial m icroccúi^o, 'nterface com a rede de com unicação e interface com o sistem a de interrupção.

C ada nó de trabalho é conectado ao crossbar por canais ou vias de com unicação que form am a rede de com unicação.

A F igura 3-3 apresenta a estrutura do nó de trabalho:

C rossbar

M em ória R O M • ’ Microcódigo

Processador Mem ória R A M

Sistem a de I n t e r r u p ç ã o ^ } ]N JÓ J g T r a b a l h o

Nó de Controle

3.2.2

O Nó de Controle

A rede de comunicação possui um gerenciador que controla o crossbar e os nós de trabalho. Este componente é o nó de controle e sua estrutura é apresentada na Figura 3-4.

Crossbar

,L "

“•f ’ B f

-Interface de configuração do C r o s s b ã P ^ ) Ç ^ Jn t e r f a c e Rede de C o m u n i c a ç ã o ^ ^ ; Memória K< >M C Microcódigo Processador M em ória RAM Sistema de Interrupções

M W 4

Nó de Controle

íWíIb Nós de Trabalho

Figura 3-4 : Estrutura do nó de controle

3.2.3 O Crossbar

O dispositivo utilizado para comutar as conexões é denominado de crossbar. Na Figura 3-5 temos o diagrama de blocos do crossbar. Ele é constituído de um comutador de conexões programável projetado para fornecer um chaveamento completo entre 32 linhas de entrada e 32 linhas de saída. As entradas e saídas são identificadas por um número na faixa de 0 a 31.

O crossbar é programado através de um canal bidirecional serial denominado link de configuração As mensagens de configuração (ConfigLink) consistem de um, dois ou três bytes, e fazem comunicação com o sistema através dos canais de comunicação. O número de canais que interliga o nó de trabalho e o crossbar é implementado de acordo com o hardware, em número de 1 a 4.

3.2.4 Os Canais de Comunicação

Os canais de comunicação utilizados são ligações entre o crossbar e os nós processadores, que no caso são os nós de trabalho e o nó de controle. Os canais formam a rede de comunicação e estabelecem uma comunicação full-duplex com microprocessadores padrão e com outros sub-sistemas, realizando a conversão de um canal serial bidirecional em uma interface paralela de oito bits, e vice-versa.

Figura 3-6: Diagrama de blocos dos Canais de Configuração

Na Figura 3-6 observa-se a interface de Entrada controlada por portas lógicas denominadas de comandos de entrada. Elas controlam o início e o término da comunicação. Da mesma maneira funciona a Interface de Saída. Um byte enviado por um link é reconhecido na entrada do mesmo link, assim cada linha pode transportar dados e informações de controle.

3.2.5 Placas de Interface

As interfaces da rede de comunicação, do sistema de interrupção e a de configuração do crossbar (pertencente apenas ao nó de controle) estão localizadas em uma placa compatível com o barramento PC-AT. A essência das interfaces de rede de comunicação e configuração do crossbar está no link adaptor utilizado, o qual fornece um link serial para transferência de dados em alta velocidade. A seguir serão apresentadas as estruturas das placas de interface para os nós de trabalho e de controle, que servem para implementar a arquitetura do Nó //.

3.2.5.1 Placa de Interface dos Nós de Trabalho

A interface da placa com o barramento PC-AT é responsável pela comunicação entre o microprocessador e as outras interfaces. A interface com a rede de comunicação é utilizada para a comunicação entre os nós de trabalho e também entre o nó de controle e os nós de trabalho. As comunicações se dão através de conexões estabelecidas pelo crossbar. A interface com o sistema de interrupção gera uma interrupção (INTRtc) que é enviada ao nó de controle para caracterizar a solicitação de um pedido, o detect:;- a chegíida de uma interrupção gerada pelo nó de controle (INTRct) (Figura 3-7).

3.2.5.2 Placa de Interface do Nó de Controle

A placa de interface do nó de controle é semelhante à placa dos nós de trabalho, acrescentando a esta uma interface com o canal de configuração do crossbar. Ela é composta de três módulos e uma interface para a placa de barramento do computador.

A interface com a rede de comunicação (Módulo 0) é utilizada para a comunicação entre os nós de trabalho e entre o nó de controle e os nós de trabalho. A interface com o sistema de interrupção (Módulo 1) gera uma interrupção (INTRtc), que é enviada ao nó de controle para caracterizar a solicitação de um pedido, e detecta a chegada de uma interrupção gerada pelo nó de controle (INTRct). Por intermédio da interface denominada de Módulo 2, o nó de controle envia os sinais ConfigLinkln e ConfigLinkOut, fornecendo as informações que configuram o crossbar (Figura 3-8).

Neste capítulo foi detalhada a construção da máquina pertencente ao projeto Nó //. Fcram apresentadas as duas arquiteturas paralelas e suas configurações com barramento de serviço e com linhas de interrupção, juntamente com a descrição do funcionamento de cada uma. Em seguida, os componentes da máquina paralela foram descritos sucintamente. Estes componentes farão parte do modelo que será elaborado para cada uma das arquiteturas. Com o intuito de elaborar o modelo, alguns conceitos sobre modelagem serão mostrados no capítulo seguinte.

4. Modelagem

Neste capítulo apresenta-se inicialmente os conceitua de modelagem e seu uso, com o intuito de simulação, sendo seu ambiente exposto, com suas peculiaridades, objetivando iniciar a construção do modelo que representa a arquitetura paralela. O tópico abordado neste capítulo é parte da metodologia utilizada para a elaboração do Template.

4.1 Definição

Para conceituar modelagem, inicialmente será apresentado uma definição do que é um sistema. Este é identificado quando se isola parte de um ambiente; define-se então um sistema como sendo este mundo fechado no qual se separa os itens que são parte integral dele (que estão dentro do mesmo) e itens que podem afetá-lo externamente. São usados modelos para realizar a comunicação entre ambos. Utiliza-se para esta comunicação elementos, tais como, equações, gráficos e diagramas. O modelo reflete a metáfora ou a linguagem utilizada para falar sobre o sistema [FIS95].

Outra conceituação é aquela que engloba as suposições utilizadas para descrever um sistema ou processo do mundo real e suas abstrações, na tentativa de obter alguma compreensão do seu comportamento e tomá-lo uma relação matemática ou lógica [LAW91].

Por uma modelagem entende-se a representação de um grupo de objetos ou idéias. Historicamente, esta tomou vários formatos, desde a comunicação através de desenhos em cavernas até complexos sistemas de equações matemáticas para o vôo de uma aeronave no espaço. O progresso e a história da ciência e da engenharia estão mais precisamente refletidos na evolução da habilidade humana em desenvolver e usar esses modelos [PEG95].

Utiliza-se modelos para aprender alguma coisa sobre um sistema real que não se pode observar diretamente, por motivos da sua inexistência ou pela dificuldade de manuseio. Um modelo cuidadosamente concebido pode abandonar a sua complexidade e abranger o estritamente necessário ao analista. O mesmo pode ser da forma mais varkda. m?.<? aquele c ue certamente é o mais importante no contexto deste trabalho é o que realiza a simulação.

4.2 Tipos de Modelos

Neste item serão apresentadas as classificações dos modelos de simulação. A taxonomia pode se dar através dos seguintes aspectos: quanto às aplicações, quanto ao seu comportamento em relação ao tempo, quanto à troca de estados dos recursos utilizados e quanto à presença de variáveis randômicas.

No que tange às aplicações, os modelos podem ser:

• modelos de simuladores de imagens, como por exemplo, simuladores de vôo

• simuladores simbólicos, nos quais as propriedades e características de um sistema real são representadas de uma forma matemática ou simbólica.

variáveis randômicas ou imprevisíveis no seu ambiente ou em seus próprios componentes:

• modelos de simulação determinísticos que ignoram as variáveis randômicas;

• modelos estocásticos, que consideram o componente randômico como parte do sistema.

Outra maneira de classificar os modelos de simulação está relacionada com o tempo: • modelos dinâmicos, que descrevem o comportamento do sistema através do tempo; • modelos estáticos, que retratam o comportamento do sistema em um ponto fixo do

tempo.

Para citar mais uma classificação, tem-se a maneira como o modelo representa a troca de estados dentro do sistema:

• modelos discreto», que apresentam trocas de estados em pontos isolados no decorrer do tempo;

• modelos contínuos, onde a troca se dá continuamente ao longo do tempo;

• combinados, que alternam os dois tipos de variações ao longo do tempo, discretas e contínuas.

Os modelos tratados neste trabalho classificam-se como: simbólicos, estocásticos, dinâmicos e discretos. Simbólicos, porque são processados em computadores; estocásticos, pois utilizam a randomização; dinâmicos, porque descrevem o comportamento do sistema através do tempo e discretos, pois alternam estados de ocupação do recurso no decorrer do tempo.

4.3 Ambiente para Modelagem e Simulação

N o âmbito do Laboratório da Pós Graduação em Ciência da Computação utiliza-se o ambiente de modelagem ARENA 2.1, o qual executa a linguagem de simulação SIMAN V.

Esse ambiente possui razoável flexibilidade de uso, permitindo que, num mesmo modelo, se utilize recursos de alto e baixo nível de agregação.

O ambiente ARENA permite a modelagem sem entrar em muitos detalhes a nível da linguagem SIMAN. Esta característica demonstra um alto nível de agregação. Já a linguagem de simulação SIMAN utiliza painéis da própria linguagem, que possuem baixo nível de agregação.

O Arena contém inúmeros recursos para modelagem e simulação, incluindo facilidades como: um ambiente de programação gráfica, recursos de animação, possibilidade de uso da linguagem de simulação SIMAN V e elaboração de relatórios com detalhes dos resultados.

SIMAN é uma poderosa linguageru dc sir^ulação par? delinear sistemas discretos ou contínuos, permitindo também modelar uma combinação entre eles. Sistemas com alteração discreta podem ser representados usando tanto uma orientação voltada à interação de processos ou a eventos escalonados no tempo. Sistemas com alteração contínua são moldados algebricamente ou com equações diferenciais. A combinação destas orientações é utilizada para retratar sistemas ajustados.

A lógica utilizada em SIMAN é segmentada em duas partes, a parte do modelo e a parte do experimento. O modelo descreve os elementos físicos do sistema, tais quais: processadores, linhas de dados, circuitos lógicos, memórias, etc. O experimento é utilizado para especificar sob quais condições a simulação será executada, incluindo elementos como: condições iniciais, disponibilidade dos recursos, tipo de estatísticas a serem registradas e tempo da simulação.

Para apresentar o ambiente de modelagem são necessários alguns conceitos como como templates, painéis e módulos.

4.3.1 Componentes do Ambiente de Modelagem do ARENA

O ambiente de M odelagem é com posto pelos seguintes elementos: área de trabalho, menu de ferram entas e menu de templates. Cada um destes elementos será apresentado e descrito.

Na Figura 4-1 m ostra-se o ambiente de trabalho oferecido pelo ARENA, destacando-se os com ponentes mais im portantes: menu de ferramentas, ícones, painéis, etc.

Figura 4-1- Ambiente de trabalho

Do lado esquerdo tem -se o local onde agrega-se os painéis. Eles fazem parte de um conjunto maior denom inado template. Na ilustração aparece o painel selecionado, que é o Support, e faz parte do tem plate do ambiente ARENA. Os painéis são com postos por módulos, destacando-se na figura o módulo CREA TE e sua caixa de diálogo correspondente.

Figura 4-2- Ilustração representativa sobre templates e painéis

Para esclarecer a diferença entre tem plates e painéis, a Figura 4-2 m ostra um diagram a esquem atizando um Sistem a Com putacional e um Estoque de M ateriais. U m tem plate é como um a divisão principal e um painel seria um a sub-divisão. No exem plo, o “Estoque de M ateriais” é dividido em “Entradas e Saídas”, o que corresponde ne casu do S '^ e m a C om putacional a “Processam ento”, “C om unicação” e “C ontrole” . Dentro de cada sub-divisão ainda existe um a outra separação que corresponde aos módulos. Por exem plo, a entrada dentro do estoque é dividida em “N ota Fiscal” e “C arregador” . Sim ilarm ente, no “Sistem a C om putacional” tem -se o “Processam ento em C ircuitos” e ííB uffers’\

M ódulos são unidades básicas dos painéis e funcionam com o com andos de uma linguagem de program ação como por exem plo FORTRA N. C ada módulo possui sua caixa de diálogo onde o usuário coloca os dados no modelo. A facilidade oferecida por estes blocos é devida ao fato de que eles foram projetados sob a ótica da sim ulação em conjunto com a interface gráfica do ARENA.

Para construir um m odelo, seleciona-se vários m ódulos deste m esm o painel ou pode- se escolher outro painel do m esm o conjunto de templates. Os blocos da linguagem SIM AN tam bém podem ser utilizados na construção dessa modelagem . A flexibilidade é uma característica m arcante neste am biente de programação. A seqüência lógica desses m ódulos conectados em conjunto com os dados fornecidos perm ite a execução do modelo.

Os m odelos são criados graficam ente e executados interativamente, permitindo rodar passo a passo ou de uma forma rápida através de controles existentes no menu de interação (Figura 4-3), o qual se localiza na parte inferior da tela de trabalho. Estas facilidades na execução do program a permitem verificar cada seqüência executada e localizar algum procedim ento incorreto.

► | h | ►>| | h | [ / | m \ ê l i H n l [ õ j y

Figura 4-3- Menu de Interação com a simulação do modelo

O modelo pode ser feito com animação como é apresentado na Figura 4-4 com gráficos, ilustrações que representam recursos ocupados, relógios e contadores. N o momento da execução pode-se selecionar com ou sem animação. E ste recurso permite a verificação do com portam ento do sistema passo a passo e também pode ser utilizado para detectar procedim entos indevidos.

Figura 4-4- Área de trabalho com animação

4.4 Exemplo de Modelagem no ARENA 2.1

Com o exemplo de desenvolvimento de modelagem, apresenta-se dois modelos que simulam a operação da máquina Nó Paralelo e que serão posteriorm ente apresentados ou reconstruídos utilizando a ferram enta do qual este trabalho é objeto.

Os dois modelos constituem -se de elementos básicos, utilizados em uma máquina paralela, cujos com ponentes principais são:

• nós processadores ou nós de trabalho; • nó de controle central;

• com utador de conexões tipo crossbar; • barram ento de serviço.

4.4.1 Modelo com Linhas de Interrupção

O modelo construído utiliza a interface padrão de modelagem do ARENA. Esta interface padrão é orientada a processos que são ativados por entidades. As entidades são objetos que se movem ao longo do sistema, causando mudanças de estado, realizando uma seqüência de operações, com o por exemplo, a alocação de um recurso. Este recurso possui um status que pode livre ou ocupado

N esta modelagem, as entidades representam as mensagens e os recursos representam os processadores. Os recursos serão alocados dinamicamente ao longo do tem po através de entidades que circulam pelo modelo e agregam determinadas características ou atributos para simularem o funcionam ento real do sistema. Tais características, dependendo do sistema a ser modelado, podem ser alteradas a cada simulação.

A modelagem de um nó de trabalho foi construída utilizando-se 19 módulos padrões do ARENA, com o pode ser observada na Figura 4-5.

IO lATive k(sãÍzãV^Delay H Release

[t ssign ^ jà is ig n ]>'

Figura 4-5 - Conjunto de módulos que compõe o nó de trabalho 1

Estes módulos possuem a função básica de gerar as mensagens iniciais e processar parte das variáveis. O retângulo azul, representando o recurso, com põe o nó de trabalho 1. Este modelo foi projetado para quatro nós de trabalho, significando, portanto, que, estes 19 módulos serão repetidos mais quatro vezes a fim de se com por o modelo completo.

Em relação aos m ódulos que com põem o C ontrolador d«n*OKiuu Conexões que é o responsável no N ó// por com andar o com utador de conexões através do canal de configuração, são apresentados na Figura 4-6. Para com por o nó de controle foram utilizados 8 módulos básicos do ARENA.

Figura 4-6- Módulos que compõem o nó de controle

O conjunto de m ódulos apresentado a seguir define o crossbar ou com utador de conexões. Ele representa o meio físico onde se estabelecem as com unicações entre os nós. N a Figura 4-7 estão representados os 22 m ódulos que executam a função do crossbar.

JSeize j^ R e le a s e [ ^ D e la y ^ R e le a s e k

«taCR» g « asr

jC o u n t_ ^ D e la y }^ R e le a s e ^jCount L 5 1 tjSTH

Figura 4-7- M ódulos que fazem parte do crossbar

N a página seguinte apresenta-se a Figura 4-8 com a visão geral do modelo relativo à arquitetura paralela com linhas de interrupção.

N ó de Controle

E 9 H Q n n n 1 1 1 í í i m ü í F ig u ra 4 -8 : V is ão geral do M o d el o qu e si m u la o N ó // na arq uitetu ra co m L in h a s de In te r r u p ç ã o

4.4.2 Modelo com barramento de serviço

Os m ódulos que com põem o barram ento de serviço são semelhantes ao modelo com linhas de interrupção. A diferença no funcionamento dos dois modelos, e portanto refletindo na sua lógica de modelagem , está relacionada com os módulos que tratam do processam ento no nó de controle. N o m odelo com interrupção, a mensagem chega em um a fila existente no nó de controle. O nó de controle, ao perceber que um nó de trabalho deseja efetuar uma com unicação, configura o crossbar e verifica o destino da com unicação, efetuando, a seguir, a conexão desejada. N o caso do barram ento de serviço, as mensagens aguardam nos nós de trabalho, e um dispositivo simulando o p o llin g efetua uma varredura na fila de cada processador. O barram ento de serviço é concebido apenas para troca de mensagens curtas e pré-estabelecidas entre um nó qualquer e o nó de controle. N ão acontecem colisões no acesso ao barram ento de serviço porque é o nó de controle que determ ina com quem será realizada a conexão para verificar o destino da comunicação. O núm ero de iterações tam bém pode ser configurado e representa o número de vezes que o processo deverá ser repetido de acordo com o sistema real.

O conjunto de m ódulos m ostrado a seguir representa as diferenças lógicas de controle que foram apresentadas no parágrafo anterior.

Figura 4-9- Conjunto de módulos que representa o barramento de serviço

N a Figura 4-10 da página seguinte, apresenta-se a visão geral do modelo que contem pla a arquitetura com barram ento de serviço.