FBIO BELOTTI COLOMBO

DANIEL ZOEGA HAYASHIDA

MILTON EIJI KATO

CLUSTER DE PLAYSTATION 3 PARA COMPUTAO CIENTFICA

SO PAULO

2008

DANIEL ZOEGA HAYASHIDA

FBIO BELOTTI COLOMBO

MILTON EIJI KATO

CLUSTER DE PLAYSTATION 3 PARA COMPUTAO CIENTFICA

Projeto de Formatura apresentado

disciplina PCS-2502 Laboratrio de

Projeto de Formatura II, da Escola

Politcnica da Universidade de So

Paulo.

rea de concentrao:

Engenharia de Computao e Sistemas

Digitais

Orientadores:

Profa. Dra. Lria Matsumoto Sato

Prof. Dr. Marcelo Nelson Paz Carreo

SO PAULO

2008

2

DEDICATRIA

Dedicamos este trabalho s nossas famlias, amigos e professores que ajudaram a

concluir o curso e este projeto.

3

Agradecimentos

Agradecemos ao Prof. Marcelo Carreo, Profa. Ins Pereyra e ao Prof. Marco

Alayo por terem acreditado no projeto e comprado os equipamentos necessrios para a

execuo dos trabalhos. Agradecemos tambm Profa. Lria Sato por nos receber e

orientar durante este projeto.

4

The only legitimate use of a computer is to play

games.

(Eugene Jarvis)

5

Resumo

Neste projeto, desenvolvemos um cluster de Playstation 3 que pode ser utilizado para

executar programas em paralelo. O projeto inclui toda configurao necessria para

permitir que os consoles fossem utilizados como computadores normais, a

configurao da comunicao entre os computadores que compunham o cluster e o

desenvolvimento de um software para testar o desempenho do cluster.

O software desenvolvido permite ao usurio realizar simulaes da corroso

anisotrpica do Si em solues de KOH. Esse processo bastante utilizado na

fabricao de sistemas micro eletro mecnicos ou MEMS (Microelectromechanical

systems). O simulador desenvolvido baseado em um autmato celular e a sada

grfica do programa gerada utilizando o algoritmo marching cubes.

Palavras-chave: Simulao. Corroso anisotrpica. Silcio. Cluster. Playstation 3.

6

Abstract

We describe the development of a software for anisotropic wet-etching of Si in KOH

solution utilizing a cellular automata. The software was developed in stages and three

end products were obtained: a simulator that can be run on a single computer, a

simulator that can be run on a cluster and a software that can be run on a PS3 cluster.

The software was developed using MPICH, an implementation of MPI, to allow it to run

on a cluster.

We also describe how the cluster was built and configured to allow the use of the

PlayStation 3 console as a normal computer node of the cluster. This includes the

configurations of the operating system and network as well as the implementation of

MPI used.

Keywords: Simulation. Anisotropic etching. Silicon, Cluster, PlayStation 3.

7

Lista de Ilustraes

Figura 1 Exemplos de uma grade bi-dimensional com clulas triangulares (a), de uma grade

unidimensional (b) e de uma grade tridimensional com clulas cbicas......................................... 19

Figura 2- Conectando bordas para tratar a vizinhana das bordas. ................................................ 22

Figura 3 Toride formada pela ligao das bordas de uma grade bidimensional. ..................... 23

Figura 4 Cantilever antes (a) e depois (b) da corroso anisotrpica do silcio. .......................... 29

Figura 5 Fluxo geral do software de simulao................................................................................ 34

Figura 6 Separao do trabalho entre as diversas unidades de processamento. ...................... 35

Figura 7 Estrutura atmica do cristal de silcio representado pela matriz de 4x4x4 clulas. .... 37

Figura 8 Separao de uma matriz de clulas 3D (a) em diversas fatias longitudinais (b) e

diversas fatias transversais (c). .............................................................................................................. 38

Figura 9 Diviso das clulas entre ns de um cluster. .................................................................... 39

Figura 10 Hierarquia da estrutura de dados na PS3. ...................................................................... 40

Figura 11 Modo de distribuio dos blocos totalmente cclico em 2 dimenses. A figura

mostra qual SPE (1, 2, 3 ou 4) trabalha sobre qual dado. ................................................................. 43

Figura 12 Mdulos de um programa ALF. ........................................................................................ 44

Figura 13 Movimento da varredura dos blocos de uma simulao nos SPEs. Os blocos

opacos so os blocos utilizados para simulao. ............................................................................... 46

Figura 14 Execuo do programa com double-buffering. ............................................................... 46

Figura 15 - Clulas necessrias na determinao do proximo estado da clula central .............. 47

Figura 16 - Fluxograma do programa do simulador no PPE. ............................................................ 49

Figura 17 - Fluxograma do programa do simulador no SPU ............................................................. 51

Figura 18 Troca de borda entre dois ns consecutivos durante a execuo do programa. ..... 53

Figura 19 Planos cristalogrficos do silcio: plano (100) em (a), plano (110) em (b) e plano

(111) em (c). .............................................................................................................................................. 54

Figura 20 A estrutura em vermelho representa os cubos utilizados no algoritmo. ..................... 56

Figura 21 Os 15 casos do algoritmo marching cubes. Os vrtices em amarelo so os que

esto do lado de fora da superfcie. ...................................................................................................... 57

Figura 22 Superfcies com valores decrescentes geradas atravs da execuo do algoritmo

em um mesmo campo escalar. .............................................................................................................. 58

Figura 23 Resultado da aplicao do algoritmo sem o tratamento prvio dos dados ............... 59

Figura 24 Atribuio do raio de um tomo. ....................................................................................... 59

Figura 25 Sada gerada pela simulao visualizada com o uso do software SimMEMS. ......... 62

Figura 26 Resultado de uma simulao utilizando uma mscara com vrias aberturas. ......... 63

Figura 27 Distribuio do trabalho entre trs processos. ............................................................... 64

Figura 28 Variao do tempo de execuo do algoritmo de entrada de com a variao do

nmero de processos. ............................................................................................................................. 65

Figura 29 Variao do tempo de execuo por clula e do tempo de execuo total com o

nmero de ns. ......................................................................................................................................... 66

Figura 30 Distribuio percentual do tempo gasto em cada parte do software de simulao. 67

8

Lista de Tabelas

Tabela 1 Exemplificao da Regra 110 ............................................................................................. 19

Tabela 2 Execuo de um autmato celular utilizando a regra 110. ............................................ 20

9

Sumrio

1. Introduo ........................................................................................................................................ 11

1.1. O Cluster ................................................................................................................................... 11

1.2. O Processador Cell ................................................................................................................ 12

1.3. Por que o PlayStation 3? ...................................................................................................... 13

1.4. Objetivos do Projeto .............................................................................................................. 15

2. Aspectos Conceituais ................................................................................................................... 16

2.1. Sobre o CBEA.......................................................................................................................... 16

2.2. Autmato Celular.................................................................................................................... 18

2.2.1. Viso Geral ........................................................................................................................... 18

2.2.2. Condies de Borda .......................................................................................................... 22

2.3. Message Passing Interface (MPI) ....................................................................................... 24

2.3.1. Funcionalidade .................................................................................................................... 25

2.3.2. Implementaes do MPI ................................................................................................... 26

2.3.2.1. MPICH e MPICH2 ............................................................................................................ 27

2.3.2.2. OpenMPI............................................................................................................................ 27

2.4. MEMS ......................................................................................................................................... 28

3. Especificao do Projeto de Formatura ................................................................................... 30

3.1. O Cluster ................................................................................................................................... 30

3.2. O Software ................................................................................................................................ 31

4. Metodologia ..................................................................................................................................... 32

5. Projeto e Implementao .............................................................................................................. 33

5.1. Estrutura do Software de Simulao ................................................................................ 33

5.2. Estruturas de Dados do Software de Simulao ........................................................... 35

5.3. Diviso dos Dados entre Processos ................................................................................. 36

5.4. Desenvolvimento no Cell ..................................................................................................... 41

5.4.1. Instalao do SDK .............................................................................................................. 41

5.4.2. Modificando o Software para o Cell .............................................................................. 45

5.5. Tratamento das Bordas da Grade ...................................................................................... 52

5.6. As Regras do Autmato ....................................................................................................... 53

5.7. Sada do Software de Simulao ....................................................................................... 55

10

6. Resultados ....................................................................................................................................... 61

7. Consideraes Finais.................................................................................................................... 68

8. Trabalhos Futuros .......................................................................................................................... 69

9. Referncias ...................................................................................................................................... 70

11

1. Introduo

A seguir descreveremos a motivao deste projeto bem como os objetivos principais

deste projeto. Em seguida comentaremos o projeto proposto e a estrutura deste texto.

1.1. O Cluster

Um cluster um grupo de computadores interconectados que trabalham em conjunto.

Em geral os computadores so conectados atravs de redes locais e funcionam como

um nico computador. Clusters so interessantes pois podem fornecer alta

performance ou disponibilidade a preos mais baixos que o de um nico computador

com as mesmas caractersticas.

Em 1994, a Thomas Sterling and Donald Becker desenvolveram na NASA um cluster

chamado Beowulf (MERKEY). Diferentemente dos clusters criados at ento, este

cluster era construdo a partir de computadores pessoais disponveis comercialmente

rodando um sistema operacional aberto, colocados em uma rede local pequena para

realizar processamento paralelo. Todos os componentes so comprados, nenhum

deles feito sob medida. O software utilizado para o desenvolvimento de softwares

tambm era aberto e de fcil aquisio. Devido a essas caractersticas, esse tipo de

cluster ganhou espao mundialmente.

Outra caracterstica marcante deste tipo de cluster o fato de se assemelhar muito

com um nico computador. Existe um n que age como servidor e controla os demais

ns. Toda interface entre o usurio e o sistema feita via o servidor. Em muitos

clusters, os ns cliente no possuem teclados, monitores ou at mesmo um disco

rgido.

12

O nome do cluster vem de um poema antigo ingls, em que o personagem Beowulf

descrito como tendo a fora de trinta homens em sua mo. O conceito do cluster

Beowulf semelhante, pois busca dar o poder de vrios computadores a um usurio

atravs de um nico computador. O cluster que descreveremos neste projeto segue

este modelo.

1.2. O Processador Cell

O desenvolvimento de microprocessadores recentemente sofreu uma grande mudana.

O crescimento do poder computacional vinha se baseando em modificaes do

hardware para melhorar o desempenho do software. O uso de memria cache,

previso de desvios e pipelines e o aumento do clock eram meios de aumentar o

desempenho de um software sem a necessidade de se modificar o cdigo do mesmo.

Devido aos limites alcanados na utilizao dessas tcnicas, a indstria buscou outras

solues para o aumento do desempenho de seus processadores.

Seguindo o exemplo dos supercomputadores, que possuem centenas ou milhares de

processadores, a indstria de microprocessadores lanou uma nova gerao de

processadores multi-core. Esses processadores possuem, em geral, dois ou mais

cores idnticos. Um computador com um processador multi-core de dois ncleos pode,

teoricamente, realizar uma tarefa em metade do tempo que um computador com um

nico core. No entanto, o software que realiza esta tarefa deve ser modificado para que

isso ocorra. Assim, quanto mais ncleos um processador tiver, mais rpido ele ser.

No entanto, criar um processador com muitos ncleos cria alguns novos problemas

para os projetistas do hardware. Apesar da tecnologia permitir colocar cada vez mais

transistores na mesma rea, ainda existem problemas como dissipao de calor e

consumo de energia que limitam a quantidade de transistores no chip. Alm disso, os

processadores atuais possuem uma arquitetura de memria que se utiliza de memria

13

cache dentro do processador. Quando existe mais de um processador utilizando uma

mesma regio de memria, preciso um gerenciamento dessa memria. Esse

gerenciamento significa mais hardware no chip, o que leva a mais calor produzido,

maior consumo de energia e maior rea utilizada.

O processador Cell segue uma arquitetura que busca, ao custo de uma maior

dificuldade para o programador, sanar estes problemas para fornecer um processador

mais econmico e mais rpido. Utilizando uma arquitetura multi-core heterognea,

onde cada ncleo possui sua prpria memria RAM que pode ser acessada

rapidamente, o processador dispensa a necessidade de memria cache para cada

ncleo e, conseqentemente, o hardware de gerenciamento para esses caches.

Removendo outras partes do hardware que so utilizados em quase todos os

processadores atuais, como sofisticados circuitos para previso de desvios, o

processador possui menos transistores que os processadores lanados mesma

poca. No entanto, pode fornecer um poder de processamento superior aos

processadores com maior nmero de transistores.

1.3. Por que o PlayStation 3?

Os jogos 3D modernos requerem muito poder computacional. Em geral as operaes

para renderizar as telas e o nvel de realismo nos modelos grficos requerem que uma

grande quantidade de operaes em ponto flutuante seja realizada em um curto

perodo de tempo. Isso fica evidente ao se analisar o poder de processamento das

placas de vdeo atuais, que esto inclusive sendo estudas para uso em computao

cientfica e ao se verificar o surgimento de hardware dedicado para o clculo de fsica

de jogos. Os consoles no fogem da regra, tendo em geral um grande poder

computacional a um preo abaixo do de mercado, visto que nesse setor o lucro das

14

empresas vem da venda de jogos, e os consoles em si so geralmente vendidos com

prejuzo para as empresas.

No final de 1999 a Sony Computer Entertainment lanou sua console de sexta gerao

o PlayStation 2, movido pelo EmotionEngine, um processador desenvolvido pela

SONY em parceria com a Toshiba. O console se sagrou como o console mais vendido

da histria, ultrapassando a marca de 140 milhes de unidades vendidas(FINANCIAL

TIMES, 2008).

Para a stima gerao de consoles a STI, uma parceria formada pela Sony Computer

Entertainment, Toshiba e IBM, desenvolveu um novo processador, apelidado de Cell.

Este processador radicalmente diferente dos processadores atuais. Seguindo a

arquitetura Cell Broadband Engine Architecture (CBEA), este processador foi otimizado

para o processamento distribudo e aplicaes de mdia. Existem algumas variaes

desse processador, as descries a seguir so vlidas para os processadores Cell

utilizados no PlayStation 3.

A console PlayStation 3 (PS3) no foge dessa regra. Alm de possuir uma placa de

vdeo da nVidia para o processamento grfico, tambm vem com um processador Cell,

cujas caractersticas funcionais j foram descritas. Apesar de ser possvel adquirir da

IBM clusters com processadores Cell, como o BladeCenter QS21, a diferena de

preos entre estes sistemas e um cluster de PS3s considervel. A empresa Fixstars

Solutions vende clusters prontos e j configurados. Um cluster com 8 PS3s, um n

cabea e o switch vendido por cerca de US$17,000.00. Um Bladecenter com 14

blades QS22 vendido por cerca de US$170,000.00 (FIXSTARS, 2008).

Apesar de haver uma diferena de performance, para se estudar o processador Cell e

sua aplicao em um determinado problema um cluster de PS3s uma alternativa bem

mais atraente economicamente. Por isso escolhemos montar um cluster com esses

consoles.

15

1.4. Objetivos do Projeto

Os objetivos deste projeto so:

Montar um cluster heterogneo de consoles PS3 e computadores pessoais

disponveis no mercado para uso em computao cientfica.

Desenvolver um software capaz de rodar nesse cluster para verificar as

vantagens e as desvantagens de se utilizar um cluster e o processador Cell para

a aplicao escolhida.

Como foi descrito acima, existem diversas razes para se estudar a programao em

sistemas paralelos, visto que em breve essa tecnologia se tornar dominante entre os

computadores pessoais. Buscvamos uma aplicao para o cluster que tambm fosse

de interesse prtico, pois um bom desempenho do sistema em uma aplicao sem

funcionalidade prtica alguma no interessante. Escolhemos ento construir um

simulador de corroso anisotrpica de silcio baseado em autmato celular.

Essa escolha foi feita baseada em diversos fatores. Mencionaremos aqui brevemente

dois deles que foram determinantes para escolha. Primeiramente, o Grupo de Novos

Materiais e Dispositivos trabalha ativamente na fabricao e pesquisa de sistemas que

utilizam este tipo de corroso, o que cria interesse prtico no software. Em segundo

lugar, autmatos celulares so facilmente paralelizveis, o que era desejvel dada a

baixa experincia dos integrantes com o assunto.

16

2. Aspectos Conceituais

2.1. Sobre o CBEA

O processador Cell um processador multi-core, mas diferentemente dos modelos

atuais, como os processadores Core 2 Duo da Intel, os ncleos so heterogneos. O

ncleo central baseado na arquitetura Power ISA v2.0.3. Chamado de Power

Processing Element (PPE) este ncleo um processador de 64 bits capaz de rodar

programas de 32 ou 64 bits compilados para a arquitetura Power. , portanto, capaz de

rodar um sistema operacional e controlar o fluxo dos demais ncleos.

Os demais ncleos so chamados de Sinergistic Processing Elements (SPEs). Como o

nome sugere, os ncleos foram desenvolvidos para trabalhar em conjunto com o PPE.

Os SPEs so processadores Single Instruction Multiple Data (SIMD) que foram

otimizados para rodar aplicaes que necessitam de alto poder computacional, no

sendo otimizados para rodar, por exemplo, um sistema operacional. Os processadores

utilizados nas PS3s so fabricados com 8 SPEs mas apenas 7 so habilitados em

hardware para aumentar o rendimento na fabricao. Alm disso, o sistema

operacional da Playstation, que virtualiza o hardware, roda em um dos SPEs. Sobram

assim 6 ncleos para uso no cluster.

A lgica bsica de utilizao do processador Cell utilizar o PPE para gerenciar o

funcionamento dos SPEs. O programador pode escrever um software da mesma

maneira que faria para qualquer outro programa para um PC comum. Ao encontrar

uma parte do cdigo que exige alto poder de processamento, ao invs de deixar o PPE

realizar o processamento, o programador passa a utilizar o PPE para coordenar a

execuo dessa computao nos SPEs. Isso em si j um grande desvio dos mtodos

convencionais de programao.

17

Outra mudana significativa diz respeito ao uso da memria. O PPE possui memria

cache em dois nveis, como os processadores modernos, mas os SPEs no tm

memria cache. Cada SPE possui 256KB de memria RAM local onde devem ser

armazenados as instrues e os dados do programa a ser executado. Um SPE tem

acesso a toda a memria principal mapeada, inclusive as regies mapeadas para

entrada e sada, atravs de operao utilizando Direct Memory Access (DMA). Com

DMA, cada SPE pode acessar a memria principal para escrever ou ler dados sem a

necessidade de interagir com o PPE.

O PPE acessa a memria principal diretamente, como a maioria dos processadores

x86 no mercado. Esse acesso feito atravs de um cache. Quando uma posio de

memria acessada, o processador automaticamente busca um bloco de dados que

contm o dado acessado e o transfere para a memria cache, que mais rpida. Isso

feito pois em geral um acessos subseqentes memria tem alta probabilidade de

estarem no mesmo bloco. Esse fenmeno conhecido como principle of locality. J no

SPE, o programador deve explicitamente dizer ao processador qual parte da memria

deve ser carregada na memria local, programando a unidade de DMA para realizar a

transferncia.

Essa arquitetura tem diversas vantagens. Primeiramente, diminui a latncia da

memria. Um erro no cach (miss) leva a centenas de ciclos de processamento

perdidos devido necessidade de se carregar um bloco inteiro de memria no cache,

ao passo que no Cell se utiliza apenas alguns ciclos para programa o DMA. Isso

tambm explicita a paralelizao da execuo de instrues e a transferncia de dados

e instrues de e para a memria. Um bom programador pode programar as

transferncias de tal maneira que ocorrem enquanto o processamento dos dados que

j esto na memria local realizado. O bom uso dessa arquitetura de trs nveis de

acesso memria pode levar a um desempenho duas ordens de grandeza maior do

processador Cell quando comparado a processadores convencionais(HOFSTEE,

2005).

18

2.2. Autmato Celular

O Autmato Celular um modelo de clculos discretos, composto de uma grade de

clulas e de regras simples de comportamento. O conceito de autmato celulares foi

introduzido pelo matemtico John Von Neumann quando este estudava mquinas auto-

replicantes.

Apesar de ser um modelo bastante simples, possvel obter resultados bastante ricos

e precisos em vrios tipos de simulao, como fenmenos biolgicos, desenvolvimento

de cristais e fenmenos naturais complexos como fluxos turbulentos. A seguir

descreveremos de maneira breve o funcionamento de um autmato celular.

2.2.1. Viso Geral

Um autmato celular possui uma grade regular de clulas. Essas grade pode ser N-

Dimensional. O formato das clulas tambm pode ser variado, permitindo clula ter

diversos nmeros de clulas vizinhas. Abaixo temos alguns exemplos de grades que

podem ser utilizadas por autmatos celulares.

19

Figura 1 Exemplos de uma grade bi-dimensional com clulas triangulares (a), de uma grade unidimensional (b) e de uma grade tridimensional com clulas cbicas.

Cada clula possui um estado discreto. O conjunto de estados possveis das clulas

finito. O tempo tambm discreto. O estado de uma clula no instante t est

diretamente ligado ao estado de um nmero finito de clulas ao seu redor,

denominadas de vizinhana, no instante t-1, isto , todas as clulas mudam de estado

em exatamente o mesmo instante. Apesar de a clula poder estar contida nessa

vizinhana, ela no considerada uma vizinha de si mesma. O prximo estado

definido por um conjunto de regras determinsticas. Tanto o conjunto de regras como a

vizinhana constante, no mudando com o tempo.

O autmato celular no trivial mais simples existente um autmato unidimensional

com uma vizinhana simples e dois estados. Para estes tipos de autmato, existem oito

possveis configuraes para a uma clula e seus dois vizinhos. Existem , portanto, 256

possibilidades distintas para as regras que determinam o prximo estado. Essas 256

regras so identificadas usando a notao Wolfram, criada por Stephen Wolfram. A

notao usar o valor cuja representao binria a regra. A tabela abaixo mostra

como a Regra 110.

Tabela 1 Exemplificao da Regra 110

Estado em t-1 111 110 101 100 011 010 001 000

Estado em t 0 1 1 0 1 1 1 0

20

Esta regra interessante um autmato celular com essa regra equivalente uma

Mquina de Turing Universal. A seguir exemplificaremos o funcionamento de um

autmato celular utilizando essa regra.

Imagine que inicialmente todas as clulas estejam no estado 0, exceto uma. Imagine

tambm que a grade de clulas infinita. Pela regra 110, todas as clulas cujo estado

0 e cujas vizinhas tambm estejam no estado 0 continuaro no estado zero. Assim,

s precisamos nos preocupar com as clulas no estado 1 e em suas vizinhas. A clula

cujo estado 1 entrar no caso 010 e seu prximo estado ser 1. Sua vizinha

imediatamente esquerda entrar no caso 001 e seu prximo estado ser 1. A vizinha

diretamente direita da clula cujo estado inicial era 1 entrar no caso 100, e seu

prximo estado ser 0. A tabela abaixo mostra a evoluo do autmato durante os sete

primeiros passos.

Tabela 2 Execuo de um autmato celular utilizando a regra 110.

t 0 0 0 0 0 0 0 1 0

t + 1 0 0 0 0 0 0 1 1 0

t + 2 0 0 0 0 0 1 1 1 0

t + 3 0 0 0 0 1 1 0 1 0

t + 4 0 0 0 1 1 1 1 1 0

t + 5 0 0 1 1 0 0 0 1 0

t + 6 0 1 1 1 0 1 1 1 0

t + 7 1 1 0 1 1 1 0 1 0

A execuo de um autmato celular bidimensional (plano) pode ser feita imaginando-se

uma folha quadriculada de tamanho infinito, representando a grade de clulas. Cada

quadrado representa uma clula. Assumiremos novamente, por simplicidade, que cada

clula est em um de dois possveis estados. Cada clula possui 8 clulas adjacentes.

Estas 9 clulas (a clula sendo considerada mais suas 8 vizinhas mais prximas)

podem assumir ento 29 = 512 estados diferentes. O comportamento que o autmato

ir assumir pelo decorrer do tempo pode ser determinado atravs de uma tabela de

comportamento que descreve o prximo estado para cada uma dessas 512

21

possibilidades. Ou seja, no prximo passo de tempo (t+1), o estado da clula central

definido dependendo de um dos 512 estados possveis da sua vizinhana.

Da descrio acima, podemos facilmente notar que o estado final das clulas depende

das regras do autmato bem como da configurao inicial das clulas. comum,

principalmente em uma grade infinita, que todas as clulas iniciem em um mesmo

estado, e apenas uma parte delas inicia-se num estado diferente. Algumas vezes, as

clulas podem estar dispostas seguindo um padro peridico. Nesse caso, apenas

uma parte da grade poderia diferir desse padro.

Como um exemplo de autmato celular bidimensional, pode ser levantado o Jogo da

Vida de Conway. O Jogo da Vida segue as seguintes regras:

Nascimento: Se uma clula morta (branca) tem trs clulas vivas (pretas) em

sua vizinhana, ela nasce no prximo passo (se torna preta).

Sobrevivncia: Se uma clula viva (preta) tem duas ou trs clulas vivas na

sua vizinhana, ela sobrevive (continua preta) no prximo passo.

Morte: Em qualquer situao diferente das acima, a clula morre no prximo

passo (se torna branca)

As regras deste jogo so uma analogia com a proliferao de alguns seres vivos, como

as bactrias. Esse simples jogo leva em considerao o fato de que se os indivduos

esto em falta ou em excesso no possvel se manter vivo. Os seres do jogo s se

proliferam na densidade populacional ideal.

Um autmato celular tridimensional opera da mesma maneira que um autmato celular

unidimensional ou bidimensional. A principal diferena a vizinhana. No caso de um

autmato celular tridimensional com vizinhana simples e dois estados, temos 227 =

1342177228 possveis configuraes. Nesse caso, quando se implementa o autmato

em software, bem mais vantajosos descrever as regras como o Jogo da Vida foi

22

descrito acima, atravs de condies que agrupam diversos estados juntos. Isso reduz

a memria necessria para se executar o programa.

2.2.2. Condies de Borda

Para a simulao de um autmato celular, comum se utilizar uma grade de tamanho

finito, visto que a memria um recurso finito. No entanto, ao definirmos um fim para a

grade, encontraremos que as clulas que residem nessas bordas possuem uma

vizinhana diferente das demais. Existem vrias maneiras de se lidar com essas

clulas, falaremos a seguir sobre alguns desses modos a seguir.

Uma soluo simples e bastante engenhosa para esse problema ligar as

extremidades da grade do autmato entre si, de maneira que possvel percorrer as

clulas em qualquer direo sem nunca chegar uma borda. Para exemplificar,

imaginemos um autmato celular unidimensional com uma grade finita. As clulas mais

esquerda e mais direita seriam as bordas, pois no possuem uma vizinhana como

as demais. Fazemos ento com que a vizinha da esquerda da clula mais esquerda

seja borda direita, e que a vizinha da direita da clula mais direita seja a borda

esquerda. Isso equivalente transformar um segmento de linha em um crculo, como

na figura abaixo.

Figura 2- Conectando bordas para tratar a vizinhana das bordas.

23

No caso do autmato bidimensional, uma grade finita equivalente a um espao

retangular de clulas, ao invs de um plano infinito. Neste caso, a soluo seria uma

toride. Na figura abaixo, a linha rosa mostra a juno entre as bordas superior e

inferior enquanto que a linha vermelha mostra a juno das bordas esquerda e direita.

Figura 3 Toride formada pela ligao das bordas de uma grade bidimensional.1

Como podemos perceber pela figura, a representao toma uma dimenso a mais para

se visualizar a forma equivalente, portanto no representaremos o equivalente para

uma grade tridimensional.

No caso do nosso autmato celular, esse tipo de comportamento no desejvel.

Outra maneira de lidar com as bordas, at mais simples que a descrita anteriormente,

considerar as clulas na vizinhana no existente como tendo um valor constante,

definido previamente. No caso do nosso simulador essa soluo bastante intuitiva,

vista que as clulas fora da grade em considerao so o espao vazio, e, portanto,

consideramos seu valor como sendo sempre equivalente ao espao vazio.

1 Figura de http://upload.wikimedia.org/wikipedia/commons/5/54/Torus_cycles.png

24

2.3. Message Passing Interface (MPI)

Todo programa composto de algumas instrues que definem o que o programa faz e

de dados sobre os quais o programa trabalha. Em sistemas paralelos, diversos

processadores executam operaes, que podem ser diferentes para cada processador,

sobre um conjunto de dados, que tambm pode ser diferente para cada processador.

Um problema que surge em sistemas paralelos como realizar a troca de informaes

entre processadores.

Em um ambiente onde todos os processadores tm acesso a um mesmo espao de

memria, essa comunicao, ou troca de informaes, pode ser realizada atravs

dessa memria. Quando o ambiente composto por memria no compartilhada para

cada processador (como em sistemas distribudos), necessrio ter outro meio de

comunicao. Em sistemas conectados por uma rede, a rede o meio de

comunicao. No entanto, ainda preciso definir como essa comunicao, seja via

memria ou via rede, ser realizada.

O MPI (Message Passing Interface) um padro que define uma API para realizar a

troca de mensagens entre processos em uma sistema. Apesar de no ser aprovado por

nenhum rgo de padronizao, a extenso de seu uso tornou o padro reconhecido

mundialmente. O MPI no especifica uma linguagem para as implementaes. Assim,

existem implementaes para diversas linguagens.

Aplicaes que usam MPI so compostas por um ou mais processos que se

comunicam atravs de chamadas de funes pr-definidas de envio e recebimento de

mensagens. Na maioria das implementaes do MPI, criado um conjunto fixo de

processos inicialmente, e estes no precisam necessariamente executar o mesmo

programa. Por isso, o padro MPI algumas vezes referido como MPMD (Multiple

Program Multiple Data).

25

O padro possui duas verses principais. O chamado MPI-1 a verso mais atual da

primeira verso do padro. O chamado MPI-2 a nova verso do padro. Devido s

diferenas entre as implementaes das duas verses e da existncia de diversos

softwares que utilizavam o MPI-1 quando o MPI-2 foi lanado, ambas as verses ainda

so muito utilizadas.

2.3.1. Funcionalidade

A finalidade da interface MPI fornecer funcionalidade de comunicao, sincronizao

e topologia virtual essencial entre um conjunto de processos, de um modo

independente de linguagem. Tipicamente, para otimizao de desempenho, a cada

processador (ou ncleo de processador no caso de processadores multinucleados)

atribudo a apenas um processo. Essa atribuio ocorre em tempo de execuo,

atravs de um agente iniciador do programa MPI, normalmente chamado nas suas

implementaes de mpirun ou mpiexec. Apesar de existir uma padronizao no nome

dos comandos que compilam e executam cdigos com MPI, as diferentes maneiras

como cada implementao lida com a criao dos processos nos hosts que constituem

o cluster leva a algumas diferenas na execuo dos programas. Na maioria das

implementaes, no entanto, o comando para compilar um programa o mesmo:

mpicc.

A biblioteca de funes MPI inclui operaes de envio/recebimento de mensagem

ponto-a-ponto de diversos tipos, referidos mais abaixo; para obter informaes

relacionadas rede (como por exemplo, o nmero de processos sendo executados);

para obter a identidade do processo que executando no respectivo n e os ns

adjacentes acessveis na topologia de rede, entre outras. Quais funes so utilizadas

depende do problema a ser resolvido. No caso do nosso software, utilizamos apenas

algumas funes bsicas, que descreveremos brevemente a seguir.

26

MPI_Init : essa funo deve ser chamada antes de qualquer outra funo da

biblioteca.

MPI_Comm_Size : Essa funo bastante til, pois atravs dela que se

determina quantos ns fazem parte do sistema.

MPI_Comm_Rank : Cada processo recebe um nmero seqencial entre 0 e N,

onde N o nmero total de processos. Essa funo permite saber qual o

nmero do processo que a chamou. Esse valor chamado de rank.

MPI_Send : Essa a funo mais simples para se enviar dados. Atravs dessa

funo pode-se enviar qualquer tipo bsico de dado, como caracteres, inteiros

ou nmeros em ponto flutuante. A quantidade de dados a ser enviada tambm

varivel. O destino dos dados tambm definido na chamada da funo.

MPI_Recv : Essa funo permite receber dados de um determinado n. Existe

tambm a opo de receber informaes de qualquer n. preciso definir o tipo

de dado que ser recebido bem como seu tamanho.

MPI_Finalize : Essa funo fecha os processos MPI.

As descries acima so bastante breves, apenas para dar uma idia do que cada

funo faz. Existem diversos outros parmetros que no foram mencionados. Mas vale

mencionar que as funes acima j permitem fazer muitos programas com MPI. Para

uma explicao mais detalhada das funes e seu uso, existem diversas fontes na

Internet e livros que ensinam a utilizar MPI.

2.3.2. Implementaes do MPI

MPI apenas um padro que define uma API. Para se escrever um programa,

necessrio ter um cdigo fonte ou biblioteca que implemente essa API. Isto , o MPI

descreve as funes que mencionamos acima e o que elas devem e no devem fazer.

Para programar com MPI, precisamos de algo que faa o que o MPI deveria fazer, isso

uma implementao de MPI. Existem diversas implementaes de MPI, a seguir

descreveremos algumas que estudamos quando pesquisamos por uma implementao

So elas: MPICH, MPICH2 e o OpenMPI.

27

2.3.2.1. MPICH e MPICH2

O MPICH a primeira implementao do MPI 1.x, do Argonne National Laboratory.

Muitos fabricantes de supercomputadores no incio da dcada de 90 comercializaram o

MPICH. O Argonne National Laboratory continuou a desenvolver o MPICH por uma

dcada, e atualmente fornece o MPICH2, que uma implementao parcial do padro

MPI-2. Esta verso, diferentemente da primeira, no aceita a troca de mensagens num

ambiente heterogneo.

2.3.2.2. OpenMPI

To cedo quanto o Argonne National Laboratory, o Ohio Supercomputing Center

desenvolveu a implementao aberta LAM/MPI para o padro MPI-1. Os

desenvolvedores ento se juntaram outros grupos que tambm haviam desenvolvido

implementaes do MPI-1 para desenvolverem em conjunto uma implementao para

o padro MPI-2.

O Open MPI representa a juno de trs implementaes MPI bem-conhecidas:

FT-MPI, da University of Tennessee

LA-MPI, do Los Alamos National Laboratory

LAM/MPI, da Indiana University

Alm dos trs acima, houve tambm contribuies da equipe PACX-MPI da University

of Stuttgart. Estes foram os membros fundadores da equipe desenvolvedora do

OpenMPI.

28

2.4. MEMS

Microelectromechanical systems (MEMS) so sistemas de dimenses diminutas que

possuem partes mveis ou de geometria interessante. Os componentes do sistema

variam de tamanho entre 1 e 100 micrometros, e o sistema em si varia de tamanho

entre 20 micrometros a at um milmetro. Devido ao tamanho pequeno, a fsica dos

dispositivos diferente. Apesar das leis serem as mesmas, os efeitos que determinam

o comportamento do sistema so outros. Devido baixa proporo de volume para

rea superficial, efeitos que dependem do volume, como inrcia, so menos

expressivos que efeitos ligados superfcie, como a eletrosttica.

MEMS so utilizados para diversas funes, seja como atuadores ou sensores. Pode-

se construir desde micromotores para movimentao de alta preciso ou sensores para

detectar diversas substncias ou presso. A figura abaixo mostra um cantilever. Essa

estrutura formada atravs da deposio de um filme sobre um substrato de silcio,

mostrado em (a), e pela subseqente remoo do silcio resultando em (b). Cantilevers

podem ser utilizados para movimentao, como os clios de alguns protozorios, ou

para a fabricao de sensores.

29

(a)

(b)

Figura 4 Cantilever antes (a) e depois (b) da corroso anisotrpica do silcio.

No caso da figura acima, a remoo do silcio feita atravs da corroso anisotrpica

do silcio. Este tipo de corroso bastante utilizado na fabricao de MEMS devido

sua simplicidade. Uma maneira de realizar essa corroso mergulhando o dispositivo

na Figura 4 (a) em uma soluo de KOH. Este tipo de corroso conhecido como wet

etch. O filme depositado sobre o silcio chamado de mscara. esta mscara que

define as partes do substrato que sero corrodas ou no.

A corroso anisotrpica do silcio gera alguns resultados bastante complexos,

principalmente quando o tempo de corroso mais longo ou a mscara utilizada para

corroso complexa. Existem trs famlias de planos com ndices de Miller {100}, {110}

e {111} que so bastante comuns. No entanto existem outros planos que surgem

dependendo da soluo utilizada para corroso e da mscara. Devido ao grande

interesse em MEMS e da grande utilizao da corroso anisotrpica em sua

fabricao, diversos simuladores foram desenvolvidos para ajudar a prever o resultado

dessas corroses.

30

3. Especificao do Projeto de Formatura

Os objetivos deste projeto de formatura so: 1) montar e configurar um cluster

heterogneo de PS3s e computadores desktop e 2) desenvolver um software para

rodar nesse cluster. Abaixo descrevemos melhor esses objetivos.

3.1. O Cluster

Como mencionado anteriormente, o uso do processador Cell atravs do uso de

consoles PS3 apresenta alguns problemas, em especial a baixa quantidade de

memria RAM para os padres atuais. Para contornar em parte este problema,

planejamos um cluster heterogneo, onde os ns no so idnticos, podendo ter

arquiteturas ou sistemas operacionais diferentes.

As vantagens desse sistema heterogneo vo alm de superar a limitao de memria.

Tambm permite que o software desenvolvido seja utilizado em outros clusters, no

sendo necessrio um cluster de PS3 para a execuo do programa. Tambm permite

que processadores com arquiteturas diferentes do Cell, que sejam aptos para executar

tarefas para as quais o Cell no foi projetado, sejam utilizados. Esse tipo de arquitetura

utilizado no RoadRunner, o supercomputador construdo pela IBM para o

Departamento de Energia americano. Nesse cluster, operaes padro, como entrada

e sada de dados, so realizados por processadores AMD Opteron. Operaes

computacionalmente intensivas so executadas pelos processadores Cell(IBM, 2008g).

Se tratando de um cluster para processamento paralelo, necessrio realizar a troca

de informaes entre os ns. As consoles PS3s possuem placas de rede (Network

Interface Card - NIC) Gigabit com bom desempenho. Apesar de algumas das

31

funcionalidades das redes Gigabit estarem indisponveis devido ao Hypervisor da PS3,

como as Jumbo Frames de 9000 bytes, optamos por montar uma rede Gigabit para

melhorar o desempenho das trocas de informao entre os ns.

Para tanto usaremos um switch gigabit bsico de oito portas. Como o nmero de ns

ser pequeno, inferior a oito, o desempenho do switch ainda no se torna essencial

para o bom funcionamento do cluster.

3.2. O Software

Para verificar o desempenho do cluster, bem como outros aspectos ligados

programao para o Cell, decidimos desenvolver um software prprio para rodar no

cluster. Este software deveria ser facilmente paralelizvel e ter algum interesse prtico.

Um simulador atomstico de corroso anisotrpica de silcio baseado em autmato

celular satisfaz ambas as necessidades no nosso caso. Vrios trabalhos sobre esse

tipo de corroso j foram desenvolvidos, o que fornece ampla documentao. Alm

disso, por se tratar de uma tecnologia bsica para a fabricao de MEMS, tambm de

interesse prtico. O autmato celular, por sua vez, facilmente paralelizvel. Como

todas as clulas mudam de estado exatamente no mesmo instante e o prximo estado

depende apenas do estado atual, pode-se calcular o prximo estado das clulas de

maneira aleatria. Isso facilita a distribuio do trabalho entre vrios ncleos de um

processador ou vrios ns de um cluster.

O software ser desenvolvido em passos para gerar dois produtos finais. Inicialmente

desenvolveremos uma verso seqencial. Essa verso ser ento modificada para

gerar uma verso que roda no cluster. Essa segunda verso ser ento modificada

para rodar no Cell utilizando todos os ncleos. As duas ltimas verses sero os

produtos finais, possibilitando a simulao em um cluster homogneo ou heterogneo

de PS3s ou desktops.

32

4. Metodologia

A seguir descreveremos a metodologia dos trabalhos desenvolvidos. O cluster foi

montado e configurado seguindo as recomendaes de (BUTTARI, LUSZCZEK,

KURZAK, DONGARRA, & BOSLICA, 2007). Em especial, construiremos um cluster

heterogneo capaz de executar programas compilados utilizando MPICH 1.2.7. Para

iniciar a comunicao entre os ns, utilizaremos Secure Shell (SSH). A conexo deve

ser feita automaticamente, o que ser feito utilizando pares de chaves pblicas /

privadas. Para as PlayStations utilizamos o Fedora 8, uma distribuio do Linux

recomendada pela IBM para a utilizao do Software Development Kit (SDK) do Cell.

O software foi desenvolvido em C, pois uma das linguagens para a qual o SDK

possui um compilador. Novamente, o software utiliza MPICH 1.2.7, tambm em C, para

a comunicao entre os ns. O software foi desenvolvido em vrias fases para permitir

testes e para gerar os resultados mencionados nos objetivos. Para sada do programa,

foi utilizado o algoritmo marching cubes para gerar como sada uma superfcie 3D que

represente bem o slido resultante da simulao.

A programao no Cell foi realizada utilizando um ambiente de desenvolvimento

composto por uma instalao do SDK verso 3.0.0.1.0 do Cell (seguindo as indicaes

padro de instalao do guia de instalao (IBM, 2007a)) em um desktop com

arquitetura x86 com o sistema operacional Linux Fedora 7, incluindo o Full System

Simulator que permite executar programas da arquitetura CBEA. O Full System

Simulator utilizae uma imagem de mquina virtual com a distribuio Fedora do Linux.

Todo os software para desenvolvimento foi fornecido pela IBM.

33

5. Projeto e Implementao

5.1. Estrutura do Software de Simulao

O software de simulao de corroso anisotrpica de silcio foi desenvolvido em trs

partes. Inicialmente uma verso seqencial, que foi posteriormente alterada para rodar

em paralelo no cluster e utilizar as SPEs do processador Cell, foi desenvolvida. Assim,

foi desenvolvido um simulador atomstico baseado em autmato celular seqencial. As

trs partes do simulador so:

Entrada

Simulao

Sada

Na figura abaixo esquematizamos o fluxo do software. A entrada se d por forma de um

arquivo texto que descreve as dimenses da mscara e do substrato, em nmeros de

clulas, bem como o formato da mscara. O formato descrito por uma matriz que

indica sobre quais clulas a mscara est presente. O arquivo de entrada tambm

informa o nmero de iteraes do autmato celular.

O arquivo de sada tambm um arquivo texto. O arquivo est no formato reconhecido

pelo software de CAD SimMEMS. A verso seqencial do software no gera esse

arquivo, mas simplesmente desenha a sada na tela. Para tanto, junto com o simulador

seqencial, uma interface grfica simples tambm foi desenvolvida para permitir a

visualizao dos resultados e a conseqente verificao do software.

34

Figura 5 Fluxo geral do software de simulao.

Cada uma das trs partes foi implementada de maneira modular, atravs de diversas

funes pequenas. Isso permitiu que novos passos fossem adicionados de maneira

simples e fcil quando o cdigo foi modificao do para implementar a verso em

paralelo.

Para o desenvolvimento do simulador em paralelo, adicionamos alguns passos que no

esto presentes na simulao seqencial. Mais especificamente, preciso adicionar

um passo de separao na entrada, um passo de troca de dados entre cada interao

na simulao e a unificao das sadas em uma nica sada no mdulo de gerao da

imagem 3D. Para a verso em paralelo para o Cell, tambm necessrio que se faa a

distribuio do trabalho entre as SPEs aps a separao entre os ns bem como a

unificao de suas sadas antes da unificao das sadas dos ns.

35

Esta separao do trabalho tanto no nvel do MPI, que como dito anteriormente distribui

o trabalho entre ns do cluster, desktops e PS3s, quanto no nvel do Cell dos PS3s que

distribui ainda mais o trabalho a partir da PPE para as SPEs ilustrada na figura

abaixo.

Figura 6 Separao do trabalho entre as diversas unidades de processamento.

5.2. Estruturas de Dados do Software de Simulao

Para rodar a simulao, necessrio representar a matriz de clulas do autmato

celular. A matriz pode ser representada como uma matriz de bytes do C. Apesar dessa

representao ser suficiente para um simulador seqencial ou para um simulador

rodando em um cluster, a estrutura apresenta algumas dificuldades quando se tenta

utilizar o processador Cell.

36

preciso enviar as clulas para a memria local da SPE antes do seu processamento.

Se enviarmos um vetor de dados para o SPE, espacialmente o que enviamos foi uma

coluna de clulas. Isso no suficiente para realizar a simulao, pois preciso ter a

vizinhana da clula para execuo do autmato. Em especial, para simular uma

clula, preciso ter todas as clulas mais prximas e as clulas mais prximas das

clulas mais prximas, formando assim um cubo de 5x5x5 clulas cuja clula central

a clula a ser simulada. necessrio ento percorrer a matriz para obter um pedao

menor da matriz que represente as clulas em uma redondeza tridimensional para a

simulao.

Para evitar a necessidade de realizar essas buscas, e ao mesmo tempo otimizar a

transferncia de dados via DMA para as SPEs, utilizamos uma estrutura bastante

simples para permitir que ao se acessar um vetor de dados, a informao representada

seja tridimensional. Isso feito atravs do uso de duas estruturas. A primeira, e mais

bsica, chamada de bloco bsico. Esta estrutura nada mais que um vetor de

tamanho fixo que representa um espao tridimensional de clulas.

A segunda estrutura chamada de matriz. Essa matriz possui um vetor de tamanho

varivel de blocos bsicos, bem como variveis que armazenam as medidas desse

bloco: altura, largura e comprimento. Assim, quando passamos um pedao desse vetor

ao SPE, o que passamos um bloco bsico, que representa um espao tridimensional.

A Figura 10 mostra um exemplo grfico dessa representao e como ela utilizada no

Cell.

5.3. Diviso dos Dados entre Processos

Em se tratando de um autmato celular de poucos estados, optamos por representar

as clulas atravs de um byte. Para um autmato celular seqencial, podemos

37

representar todas as clulas atravs de uma matriz 3D de bytes. Esta matriz

montada, isto , o substrato preenchido na inicializao, a partir da repetio de um

bloco bsico da estrutura de silcio de tamanho 4 x 4 x 4 clulas que pode ser

observado na figura a seguir. Apesar da estrutura unitria do silcio ser definida com

tamanho 5 x 5 x 5 clulas, utilizamos uma unidade menor pois ao se repetir a estrutura

de 5x5x5 clulas, preciso sobrepor os tomos na borda.

Figura 7 Estrutura atmica do cristal de silcio representado pela matriz de 4x4x4 clulas.

Para o simulador em paralelo, no entanto, precisamos separar a matriz em diversas

partes para permitir que cada n trabalhe sobre uma parte diferente dos dados. Como

j foi dito, a simulao dos autmatos celulares depende do estado atual da clula, dos

vizinhos diretos e dos vizinhos destes (vizinhos dos vizinhos). Desta forma os blocos de

dados no so totalmente independentes, devendo ocorrer uma troca de dados entre

cada passo da simulao para que os tomos nas bordas entre as partes que cada n

sejam atualizadas corretamente.

38

De maneira a simplificar a troca de dados entre os n ns de um cluster, mais fcil

separar a matriz de todas as clulas em n fatias longitudinais (ou transversais). Essa

abordagem simplifica a troca de dados, que se resume a enviar a borda esquerda ao

vizinho da esquerda e a borda da direita ao vizinho da direita.

A figura abaixo exemplifica este processo. O uso de fatias longitudinais diminui o

nmero de vizinhos que precisam receber informaes bem como o nmero de clulas

que precisam ser transmitidas quando comparados a separao em cubos, por

exemplo. No nosso caso, onde estamos simulando a corroso anisotrpica do silcio, a

separao em fatias longitudinais mais interessante, pois os substratos tendem a ser

achatados. Isso significa que a rea de um corte longitudinal menor que a rea de um

corte transversal.

Figura 8 Separao de uma matriz de clulas 3D (a) em diversas fatias longitudinais (b) e diversas fatias transversais (c).

39

A figura abaixo exemplifica como um bloco seria distribudo entre trs ns de um

cluster. Note no esquema que todos os ns recebem um pedao, no somente as

PS3s. Isso ocorre porque o cluster heterogneo e todos os ns participam do

processamento, inclusive o n cabea.

Figura 9 Diviso das clulas entre ns de um cluster.

De forma semelhante, porm mais dinmica, o bloco recebido pelo PPE de uma PS3

dividido novamente. A estratgia utilizada para esta diviso foi de fixar um eixo da

matriz de blocos e associar toda uma fileira a uma SPE. Isto no dividir toda a matriz

num primeiro instante, mas esta estratgia tem a inteno de poder aproveitar dados j

presentes na memria local de um SPE, alm de permitir flexibilidade. possvel

alocar as fileiras dinamicamente, o que permite uma melhor distribuio do trabalho

caso uma regio de blocos seja de rpida simulao. Se os blocos fossem alocados

todos de uma s vez, uma dada SPE poderia ficar sem trabalho enquanto que outra,

40

associada a uma regio com fileiras de blocos mais complexas, ainda tenha o que

processar.

Assim o PPE ainda trabalha no nvel de blocos sem utilizar nenhum acesso a uma

posio de um bloco. Somente na SPE se acessam as posies do bloco, porm de

forma diferente do software seqencial j que o SPE um processador vetorial onde

diversas clulas podem ser simuladas num mesmo momento. A hierarquia da estrutura

de dados e sua diviso pode ser observada na figura abaixo onde se inicia com o bloco

total sendo dividido para trs ns pelo MPI e o resultante dividido pelo PPE para cada

SPE. No ltimo nvel, uma posio de um bloco no conter somente uma clula, mas

sim 16 (8 bits por clula totalizando um vetor de 128 bits que a unidade de trabalho

do processador vetorial).

Figura 10 Hierarquia da estrutura de dados na PS3.

41

5.4. Desenvolvimento no Cell

A seguir descreveremos como foi instalado o SDK e como a programao para o Cell

foi feita.

5.4.1. Instalao do SDK

Para instalao, foram obtidos dois pacotes para instalao: CellSDK-Devel-

Fedora_3.0.0.1.0 e CellSDK-Extras-Fedora_3.0.0.1.0 que so gratuitos e podem ser

baixados do site da IBM. Porm a partir de 23 de outubro de 2008 uma nova verso do

SDK (3.1.0.0.0) substituiu a utilizada. Essa nova verso recomenda ser instalada, entre

outras distribuies, sobre o Fedora 9 (IBM, 2008b).

A instalao do SDK, que necessita conexo com a internet j que so utilizados

muitos repositrios externos, pode ser facilitada se o usurio souber a arquitetura em

qual o SDK ser instalado. Sabendo isso, possvel obter o contedo de um terceiro

pacote de instalao, o CellSDK-Open-Fedora_3.0.0.1.0, a partir do site da Barcelona

Supercomputing Center (BSC) (BSC, 2007) e armazen-los no caminho de busca de

repositrio local ao instalar o SDK. No Fedora 7 este pacote deve se encontrar em

/tmp/sdk/CellSDK-Open-Fedora/(arquitetura)/ onde (arquitetura) de ser CBEA, PPC64,

x86 ou x86_64.

Desta forma no necessrio inicialmente ter acesso a um PS3 que possui a

arquitetura CBEA para realizar a programao. Optou-se por no se desenvolver o

software no PS3, pois a baixa quantidade de memria RAM faz com que a execuo

de um Integrated Development Enviroment (IDE) seja muito lenta. Escolhemos utilizar o

Eclipse IDE 3.2.2 obtido de repositrios prprios do Fedora 7, alm do plug-in CDT 3.1

para programao em C/C++. Isto porque o SDK do Cell fornece um plug-in para que

42

se faa uso das ferramentas de desenvolvimento do SDK a partir do IDE (compiladores

e linkers para PPU e SPU, simulador do Cell, entre outras). Para tanto, preciso

instalar o plug-in cell.ibm.celldt.update que pode ser instalado seguindo as indicaes

presentes no guia de instalao do SDK que pode ser obtido do site CBEA da IBM(IBM,

2007a).

Para estudar o processo de desenvolvimento no IDE, estudamos em primeiro momento

os tutoriais presentes no menu de ajuda do Eclipse associados ao CBEA. Estes so

instalados juntamente com o plug-in do SDK para auxiliar no uso das ferramentas. Para

obter os conhecimentos bsicos iniciais sobre a estrutura do processador Cell (como

bancos de registradores, canais de comunicao tanto para o PPE quanto para as

SPEs), estudamos o tutorial fornecido pela IBM em seu site (IBM, 2007b).

Funes muito utilizadas neste projeto esto descritas nos documentos: (IBM, 2007c) e

(IBM, 2007d), especialmente as bibliotecas spu_mfcio e libspe2. A biblioteca spu_mfcio

utilizada pelas SPEs. Essa biblioteca contm as funes de transferncia de dados

via DMA e o uso do mailbox, entre outros. A biblioteca libspe2 uma biblioteca

dinmica utilizada pelo PPE para realizar as comunicaes com os SPEs. Essa

comunicao realizada atravs dos mailboxes. Os mailboxes podem ser utilizados

para a passagem de mensagem curtas e endereos da memria principal para que as

SPEs possam acess-las realizando transferncias por DMA. A biblioteca tambm

contm funes para carregar diferentes programas nas SPEs e para manter referncia

destes no PPE para seu controle.

Para execuo de um programa compilado para o Cell em um computador sem o

processador Cell, preciso utilizar o Full System Simulator. Informaes de utilizao

do simulador do Cell, tanto para iniciar um programa como para transferir os arquivos

executveis do host para a mquina virtual podem ser encontradas em (IBM, 2007b) e

(IBM, 2007e).

Durante os estudos, encontramos uma biblioteca que auxilia no desenvolvimento de

43

programas que possuem uma carga de dados que pode ser trabalhada

independentemente entre suas partes, ou seja, de forma aleatria. Esta biblioteca a

Accelerated Library Framework (ALF) com documentao que pode ser obtida em

(IBM, 2007f). O Eclipse com o plug-in do SDK do Cell possui uma opo de criao de

projeto tipo ALF que gera automaticamente os cdigos que gerenciam a transferncia

de blocos de trabalho para cada unidade aceleradora, as SPEs. A escolha dos blocos

pode ser fixa ou cclica. O mais prximo ao nosso uso seria a distribuio totalmente

cclica como pode ser vista na figura abaixo que tem a limitao de ser implementada

somente at 2 dimenses. Depois de gerado o cdigo bsico necessrio somente

codificar o algoritmo de trabalho em cima dos blocos e a inicializao destes. A figura a

seguir ilustra os mdulos do ALF, sendo que os que necessitam codificao so

somente o Compute Kernel e Initialization.

(CYCLIC, CYCLIC)

Figura 11 Modo de distribuio dos blocos totalmente cclico em 2 dimenses. A figura mostra qual

SPE (1, 2, 3 ou 4) trabalha sobre qual dado.

44

Figura 12 Mdulos de um programa ALF.

Descartamos o uso do ALF, pois no havia nenhuma estrutura que se alinhasse com as

nossas necessidades e fornecesse um desempenho superior ou igual implementao

manual do nosso software. Devido ao fato do processamento de cada clula de um

autmato depender de uma certa vizinhana, no se pode descartar uma clula aps o

seu processamento, pois a mesma pode ser utilizada ainda no processamento de uma

clula vizinha.

Para a maior parte das aplicaes desenvolvidas para o Cell a simulao dos

programas utilizando o IDE Eclipse foi suficiente. Porm, para aplicaes mais

sofisticadas, especialmente as que utilizam a biblioteca dinmica compartilhada (entre

SPEs e PPE) libmisc, que contm a funo malloc_align, isso no verdade. Um

problema de implementao entre o Eclipse IDE e o simulador faz com que esta

biblioteca no consiga ser carregada corretamente, mesmo que o caminho na varivel

de ambiente LD_LIBRARY_PATH na mquina virtual esteja correto.

45

A funo malloc_align, que aloca memria dinamicamente alinhando esta de acordo

com o parmetro inserido, muito utilizada para alocar memria dinmica de forma a

permitir transferncias via DMA entre PPE e SPEs, j que isto demanda que origem e

destino de reas de memria estejam alinhados em endereos especficos (1, 2, 4 ou 8

para transferncias de menos de 16 bytes e mltiplos de 16 para transferncias

maiores). Alm disso, a otimizao das transferncias de DMA ocorre quando se

enviam quantidades de dados mltiplas de 128 bytes que estejam alinhados em 128.

Deste modo, ainda utilizando o Eclipse para desenvolver, foram elaborados scripts

simples para uma execuo facilitada no simulador iniciado fora do Eclipse, o qual

carrega corretamente a biblioteca libmisc citada acima. No Anexo A se encontra um

processo exemplo utilizando estes scripts.

5.4.2. Modificando o Software para o Cell

Utilizando a estrutura de dados descrita no item 5.3 algumas consideraes sobre

detalhes da implementao sero discutidos a seguir. A primeira considerao

associada ao modo como os blocos recebidos pela PPE, via MPI, so divididos e entre

as SPEs e enviados para as SPEs.

A estratgia de diviso de uma fileira de blocos para cada SPU tem seu ganho ilustrado

na figura abaixo onde a SPE possui um conjunto de 27 blocos (uma matriz 3 x 3 x 3).

Esse bloco preciso para simulao do bloco central, pois diversas clulas possuem

como vizinhos clulas em outros blocos que no o central. Se aps a simulao

escolhssemos um bloco aleatrio para simulao, teramos que enviar novamente 27

blocos para a SPE. No entanto, ao definirmos que cada SPE ir simular uma fileira

inteira, podemos reutilizar alguns blocos que j carregamos na SPU. Na verdade, s

precisamos carregar 9 novos blocos para simular o prximo bloco.

46

Figura 13 Movimento da varredura dos blocos de uma simulao nos SPEs. Os blocos opacos so os

blocos utilizados para simulao.

Outro aspecto que merece ser mencionado que a transferncia desses 9 blocos pode

ser iniciada antes da simulao. Isso permite que a transferncia ocorra paralelamente

ao processamento, para que ao final da simulao do bloco presente seja necessrio

somente um ajuste de ponteiros para iniciar a simulao do prximo bloco com um

tempo de espera mnimo pelos dados. Esta estratgia muito recomendada pelos

manuais de programao do Cell e chamada double-buffering. O double-buffering

utiliza duas reas de memria que trabalham alternadamente, num dado momento uma

est sendo executada enquanto a outra recebe os dados para o prximo bloco e noutro

os papis se alternam. A figura abaixo esquematiza o processo de double-buffering.

Figura 14 Execuo do programa com double-buffering.

47

J dentro dos blocos, observando a figura a seguir, que representa as clulas

necessrias na determinao do prximo estado da clula central (de cor mais forte),

nota-se que uma matriz de 5 x 5 x 5 clulas formada. O modo de organizao desta

para aproveitamento do paralelismo da SPU est descrito a seguir.

Figura 15 - Clulas necessrias na determinao do proximo estado da clula central

Como o SPE um processador vetorial, seu desempenho maior se forem realizadas

operaes com vetores. Para tanto, preciso montar os vetores a partir dos dados

vindos dos blocos bsicos. A maneira como isso feito no software bastante simples.

Imagine que desejamos simular a clula central da figura acima. Agora imagine que

existam outras 15 clulas como a que est na figura acima para as quais tambm

desejamos determinar o prximo estado. Podemos colocar estas 16 clulas em um

vetor. Podemos ento montar outro vetor com as 16 clulas que esto direita das 16

clulas centrais, na mesma ordem. Podemos montar tambm outro vetor com as 16

clulas esquerda da clula central, tambm na mesma ordem, e assim por diante

para todas as 125 clulas possveis de cada bloco de 5 x 5 x 5 clulas.

48

Enquanto as operaes que iremos realizar so idnticas para todas as clulas,

podemos operar com os vetores ao invs de operar com as clulas individuais. Assim,

ao invs de realizarmos uma soma de 26 clulas para determinar o nmero de vizinhos

mais prximos para cada uma das 16 clulas, podemos somar os 26 vetores uma nica

vez e saber o nmero de vizinhos mais prximos de todas as 16 clulas.

Vale mencionar que a operao de montar os vetores um tanto quanto onerosa, o

que torna o reaproveitamento de vetores j montados desejvel. Isso feito simulando

as clulas em uma seqncia tal que vetores j montados possam ser reutilizados.

Na figura a seguir observa-se o fluxograma dos passos principais da execuo da

simulao no PPE que faz somente papel de gerenciador dos dados, distribuindo e

sincronizando as atividades entre as SPEs, sendo que nenhuma simulao em si

ocorre neste. Algumas funes simples foram omitidas como determinao do

endereo do bloco de sada para que a SPE possa retornar o resultado para a memria

principal. O ciclo executa somente um passo da simulao sendo que os resultados da

simulao daquele passo se encontram na rea reservada para os blocos de sada.

Aps o retorno ao programa MPI este deve realizar as trocas das bordas entre os ns e

desta forma realizar a chamada da funo do PPE para executar outro passo da

simulao.

49

Figura 16 - Fluxograma do programa do simulador no PPE.

Na figura subseqente ilustrado o programa que executado na SPE que

construdo de forma pareada com o PPE para que requisies ou endereos das

50

estruturas estejam executando de forma sincronizada, para isso foi dada especial

ateno para utilizar corretamente as funes que bloqueiam a execuo do

processador na espera por uma resposta por um canal de comunicao (como o

mailbox).

Alguns pontos neste fluxograma tambm foram omitidos. Um destes que a

transferncia de blocos ocorre em dois passos. O PPE envia o endereo da matriz de

ponteiros para os blocos a serem transferidos para a SPE. A SPE utiliza este endereo

para transferir primeiro esta matriz. Somente ento, j em posse dos endereos na

memria principal dos blocos, a SPE pode iniciar a transferncia dos blocos da

memria principal para a memria local. Para fins de identificar blocos no existentes

(como so os das bordas) foi definido que ser utilizado o valor NULL ( 0 em C) para o

endereo desses blocos. Assim possvel tratar a busca de acessos de vizinhos sem

desperdiar memria completando estes blocos com valores quaisquer.

51

Figura 17 - Fluxograma do programa do simulador no SPU

52

5.5. Tratamento das Bordas da Grade

Mencionamos anteriormente que quando se roda um autmato onde a matriz de

clulas finita, preciso definir a condio de borda. As regras de transio de estado

do autmato definem o prximo estado de uma clula em geral baseando-se no estado

atual da clula e nos estados das clulas em certa vizinhana. Se a matriz for infinita,

essa vizinhana sempre definida. No entanto isso no verdade para uma matriz

finita.

O nosso tratamento feito de duas maneiras. Primeiramente, as ltimas duas fileiras

de clulas de toda a borda externa da matriz total (as bordas entre os ns no recebem

este tratamento) so tratadas como sendo de material de mascaramento. Cada clula

nessa regio com estado correspondente a existncia de um tomo tem seu estado

mudado para material de mascaramento. Clulas vazias ou com material de

mascaramento no so simuladas, portanto no h necessidade de definir uma

vizinhana diferente para as mesmas. A mscara definida aqui tambm. Onde o

substrato exposto corroso, os tomos so substitudos por clulas vazias ao invs

de por material de mascaramento.

Resta ento tratar as bordas entre os ns durante a simulao em paralelo no cluster.

Isso feito transferindo os dados das bordas entre os ns vizinhos. A ltima camada

de blocos bsicos transferida de um vizinho para outro. Em seguida, aps receber a

camada do vizinho, cada n atualiza o valor das duas camadas extremas com o valor

recebido do seu vizinho. O valor utilizado o das duas camadas antes das duas

camadas finais. Em seguida os ns realizam um processo anlogo, mas o n que

recebia os dados passa a enviar e o que enviava passa a receber. Assim, apesar de

ambos simularem as duas ltimas camadas, os valores obtidos so sempre

sobrescritos. Essa operao realizada ao final de cada passo de simulao. A figura

abaixo exemplifica como essa troca realizada. Finalmente, vale mencionar que

53

qualquer acesso a uma posio no existente, fora da matriz, retorna o estado de

clula vazia.

Figura 18 Troca de borda entre dois ns consecutivos durante a execuo do programa.

5.6. As Regras do Autmato

O autmato utilizado possui regras bastante simples, baseadas em observaes da

corroso anisotrpica do silcio. As regras foram definidas a partir da observao dos

planos cristalogrficos {100}, {110} e {111}. Os planos {100} e {110} tm velocidades de

corroso bastante altas quando comparadas s do plano {111}. Nosso modelo ento

considera que tomos nos planos {111} no so removidos, enquanto que tomos nos

demais planos ({100} e {110}) so removidos. As regras resultantes dessa anlise

esto listadas abaixo. Para estas definies, considere que um vizinho direto um

tomo ao qual o tomo em considerao est ligado quimicamente.

54

1. Se um tomo possui dois ou menos vizinhos diretos, o tomo removido.

2. Se um tomo possui trs vizinhos diretos e estes vizinhos possuam oito ou

menos vizinhos diretos (sem contar o tomo em considerao), o tomo

removido.

3. Em qualquer outro caso, o tomo no removido.

Essas regras, apesar de serem bastante simples, j permitem resultados bastante

interessantes. A regra 1 remove os tomos do plano {100}. A regra 2 remove os

tomos do plano {110} e mantm os tomos do plano {111}. Observando os planos

cristalogrficos na figura a seguir, possvel verificar que o que diferencia os tomos

dos planos {111} e {110} so justamente o nmero de vizinhos dos vizinhos.

(a) (b)

(c)

Figura 19 Planos cristalogrficos do silcio: plano (100) em (a), plano (110) em (b) e plano (111) em (c).

55

Analisando a figura (a), vemos que os tomos na superfcie possuem apenas duas

ligaes feitas. J os tomos da superfcie da figura (b) possuem trs ligaes, mas

duas delas so com tomos que tambm esto na superfcie. Isso reduz o nmero de

vizinhos dos vizinhos. J os tomos da superfcie (c) possuem trs ligaes, e todas

com tomos que no esto na superfcie. A vizinhana utilizada definida tambm pela

estrutura cristalina do silcio. As clulas que podem possuir vizinhos diretos e vizinhos

dos vizinhos formam a vizinhana a ser analisada.

5.7. Sada do Software de Simulao

A sada do programa gerada utilizando o algoritmo Marching Cubes (LORENSEN &

CLINE, 1987). Este algoritmo permite gerar uma malha de polgonos que representa

uma superfcie de valor constante em um campo escalar tridimensional uniforme. O

algoritmo analisa os valores do campo de oito em oito, formando cubos. A anlise gera

um conjunto de tringulos para cada cubo analisado. O conjunto destes tringulos

gerados a superfcie desejada.

Inicialmente devemos definir qual o valor da superfcie par o qual desejamos gerar a

malha. Aps escolhido o valor, passamos a executar o algoritmo. O campo escalar

possui um valor para cada ponto. Analisamos oito pontos que formam os vrtices de

um cubo. Essa escolha sempre feita de maneira que no haja nenhum outro ponto

dentro do cubo que no seja um dos vrtices. Na figura abaixo vemos como feita a

escolha dos vrtices.

56

Figura 20 A estrutura em vermelho representa os cubos utilizados no algoritmo.

Em seguida analisamos quais vrtices esto dentro e quais esto do lado de dentro da

superfcie (valor do vrtice superior ao valor da superfcie) e quais esto do lado de fora

da superfcie (valor do vrtice inferior ao valor da superfcie). Existem 8 vrtices em um

cubo e portanto, 256 possibilidades. Essa configurao pode ento ser armazenada em

um byte. Isso feito igualando o bit correspondente ao vrtice a 1 se o vrtice estiver

dentro da superfcie e a 0 caso contrrio.

Apesar de existirem 256 possibilidades para as configuraes de vrtices dentro e fora

de uma superfcie, existem apenas 15 formas distintas que uma superfcie pode tomar

dentro do cubo quando a mesma aproximada por um conjunto de tringulos. Isso se

deve ao fato de diversos bytes gerarem a mesma forma se as rotaes, espelahmentos

ou inverses dos vrtices dentro e fora da superfcie, junto com a inverso do vetor

normal dos tringulos, apropriadas forem realizadas. Os 15 casos esto exemplificados

na figura abaixo.

57

Figura 21 Os 15 casos do algoritmo marching cubes. Os vrtices em amarelo so os que esto do lado de fora da superfcie

2.

Podemos ento, a partir da configurao representada pelo byte, determinar quais os

tringulos que devem ser gerados. Isso feito em dois passos: inicialmente definimos

os vrtices dos tringulos que sero gerados e em seguida geramos os tringulos com

estes vrtices. Para tanto, indexamos uma tabela pr-calculada (ver Anexo A)

utilizando o byte calculado anteriormente. O valor retornado um inteiro que indica

quais os vrtices que devem ser calculados utilizando quais vrtices do cubo inicial. Em

seguida, utilizamos um segundo vetor que indica a ordem em que os vrtices so

percorridos para gerar os tringulos.

Na figura abaixo temos um exemplo de vrias malhas geradas com o algoritmo. Todas

as malhas foram geradas a partir do mesmo campo escalar, apenas o valor da

superfcie foi modificado. As superfcies possuem valores que diminuem gradualmente,

sendo que o maior valor gera a Figura 9a e o menor valor gera a Figura 9d.

2 Imagem reproduzida de http://upload.wikimedia.org/wikipedia/commons/a/a7/MarchingCubes.svg

58

(a) (b)

(c) (d)

Figura 22 Superfcies com valores decrescentes geradas atravs da execuo do algoritmo em um mesmo campo escalar.

O algoritmo foi considerado porque gera superfcies tridimensionais fechadas, o que

de interesse. O software que foi utilizado como base para este trabalho no permite

gerar tais resultados. No entanto, preciso realizar um pr-tratamento dos dados antes

de se utilizar o algoritmo. Isso ocorre porque, como j foi descrito anteriormente, as

clulas do autmato so inicializadas com a estrutura cristalina do silcio. Se o

algoritmo for usado nesses dados, o resultado ser um octaedro ao redor de cada

tomo. Isso ocorre porque cada tomo ser vrtice de oito cubos, mas em todos esses

cubos os vrtices mais prximos estaro todos fora da superfcie. A figura abaixo

exemplifica esse resultado.

59

Figura 23 Resultado da aplicao do algoritmo sem o tratamento prvio dos dados

Para evitar esse problema, aumentamos o raio dos tomos. Utilizando a mesma matriz

que a simulao, atribumos a todas a posies da matriz o valor 0. Em seguida,

verificamos em quais posies existem tomos. Atribumos ento o valor 3 clula

com o tomo, o valor 2 s clulas mais prximas e o valor 1 s clulas mais prximas

das clulas mais prximas. A figura abaixo mostra uma representao vista de cima

dos valores atribudos. Esse padro se repete de modo simtrico em todo o entorno da

clula com o tomo. Todas as atribuies, com exceto da primeira que zera a matriz,

so cumulativas. Os valores so limitados em 15 pois o valor mximo que pode ser

representado.

1 1 1 1 1

1 2 2 2 1

1 2 3 2 1

1 2 2 2 1

1 1 1 1 1

Figura 24 Atribuio do raio de um tomo.

Com essa atribuio de um raio cumulativo, os tomos mais prximos se unem, e a

superfcie gerada passa ser uma figura tridimensional fechada. No programa, a

superfcie passada pelo valor 0,5. Outra modificao que deve ser feita diz respeito

60

s bordas. necessrio atribuir um valor nulo a todas as clulas que ficam na borda

externa da matriz inteira. Esse tratamento no deve ser aplicado borda compartilhada

entre os ns que realizam o processamento. Isso feito para garantir que a superfcie

gerada est sempre dentro da matriz de simulao, garantindo uma superfcie

tridimensional fechada.

Depois de gerada a malha, o software salva os tringulos em um arquivo texto no

formato reconhecido pelo software SimMEMS (COLOMBO, et al., 2008). O resultado

pode ento ser visualizado na interface grfica do programa simplesmente abrindo o

arquivo gerado.

61

6. Resultados

A seguir descrevemos os resultados obtidos. Esses resultados so ligados ao software

desenvolvido. Na sesso seguinte descreveremos os aspectos tcnicos da utilizao

do processador Cell, do SDK para o Cell disponibilizado pela IBM e do uso de MPI para

o cluster.

Podemos visualizar nas figuras abaixo o resultado de uma corroso utilizando uma

mscara simples. Como j mencionamos, a mscara tratada no autmato como um

estado diferente de certas clulas. O gerar a sada, a mscara pode ser visualizada

atravs dos octaedros que permanecem no topo da estrutura aps a corroso. A

mscara utilizada nesse exemplo simples, sendo apenas uma abertura retangular.

Nas figuras a seguir, foram realizados cinco passos da simulao entre cada imagem.

Nessas figuras, podemos notar o surgimento do plano cristalogrfico {110}, que gera o

under-etch ao ser corrodo, deixando o filme que forma a mscara suspenso. Tambm

fcil notar o plano {100} sendo corrodo em direo base do substrato. Os

resultados observados batem, portanto, com o que esperado na prtica para este tipo

de corroso.

62

Figura 25 Sada gerada pela simulao visualizada com o uso do software SimMEMS.

Outro exemplo que tambm foi simulado utiliza uma mscara com vrias aberturas.

Essa mscara utilizada para construo de micro-pontas. Abaixo podemos observar

o resultado da simulao. A primeira imagem foi produzida aps cinco passos da

simulao. Entre cada imagem tambm foram realizados cinco passos da simulao.

63

(a)

(b)

(c)

(d)

Figura 26 Resultado de uma simulao utilizando uma mscara com vrias aberturas.

64

Na Figura 15a fica fcil visualizar o formato da mscara. Na figura Figura 15b j

possvel notar o surgimento dos planos {111} nas quinas das aberturas, o que era

esperado. Na figura Figura 15c podemos visualizar a estrutura aps o substrato abaixo

da mscara ter sido removido e antes de ocorrer o descolamento das pontas do filme

que serve como mscara. Na Figura 15d j possvel visualizar o descolamento das

pontas.

Todos os resultados aqui mostrados foram obtidos utilizando a verso paralela do

software, implementado com MPI. Especificamente para as imagens acima, utilizamos

a verso MPICH 1.2.5. A simulao foi efetuada com trs processos simultneos. A

primeira estrutura era composta por 32x120x32 clulas. A segunda com 192x96x32

clulas.

Para ilustrar melhor os resultados da simulao, e como o trabalho separado entre os

diversos ns, colorimos de maneira diferente as partes simuladas por cada processo no

cluster. Isso ajuda a visualizar a separao dos dados entre os processos. Neste

exemplo, trs processos recebem partes iguais do substrato inicial para simular. Na

figura seguinte podemos verificar que cada processo tambm recebe um pedao

diferente da mscara.

Figura 27 Distribuio do trabalho entre trs processos.

65

No que tange ao desempenho do software no cluster, fizemos algumas medidas

simples do desempenho. Verificamos o tempo de execuo variando o nmero de

processos sendo executados. Devido a limitaes do software, o nmero de clulas

no constante quando variamos o nmero de processos. Assim importante

considerar o nmero de clulas no constante ao se realizar as comparaes.

Primeiramente, analisamos a entrada do software. Verificamos que com o aumento do

nmero de processos, o tempo de inicializao tambm aumenta. Isso se deve ao fato

da transmisso dos dados da mscara ser realizado de maneira seqencial para cada

processo. Assim, quanto maior o nmero de processos, maior o tempo necessrio para

enviar todas as partes da mscara para os respectivos processos. Os tempos de

execuo esto em segundos.

Figura 28 Variao do tempo de execuo do algoritmo de entrada de com a variao do nmero de processos.

Outro aspecto importante de se considerar o tempo de execuo do processo.

Medimos o tempo de execuo com um, dois e trs processos. A variao pode ser

vista nos grficos abaixo. Note que apesar dos valores totais diminurem, quando

levamos em considerao o nmero de clulas que foram simuladas, ocorre uma perda

no desempenho quando mudamos de dois para trs ns. Os valores de tempo esto

novamente em segundos.

0 0,02 0,04 0,06 0,08 0,1

Processos3

2

1

66

Figura 29 Variao do tempo de execuo por clula e do tempo de execuo total com o nmero de

ns.

Finalmente, interessante visualizar como o tempo total dividido entre as trs partes

do software de simulao: a entrada, a simulao e a sada. No grfico abaixo,

possvel perceber um aumento na porcentagem correspondente entrada e

simulao. Isso explicado pelo fato da entrada demorar mais com o aumento de

processos. J o aumento da porcentagem de tempo gasta com a simulao se deve

necessidade de se realizar a troca de bordas entre os processos, o que no

necessrio com apenas um processo. Tambm interessante mencionar que em todos

os casos a maior porcentagem do tempo gasta com a gerao da superfcie

tridimensional que a sada do software. Isso torna interessante qualquer otimizao

0,00E+00

5,00E-06

1,00E-05

1,50E-05

2,00E-05

2,50E-05

3,00E-05

3,50E-05

4,00E-05

4,50E-05

1 2 3

Tempo Mdio de Simulao por Clula

0

1

2

3

4

5

6

7

8

1 2 3

Tempo Total

67

que possa ser realizada nessa parte do software, pois modificaes na sada iram

gerar o maior impacto no desempenho do software de simulao.

Figura 30 Distribuio percentual do tempo gasto em cada parte do software de simulao.

0% 20% 40% 60% 80% 100%

1

2

3

Tempo Entrada

Tempo Simulao

Tempo Sada

68

7. Consideraes Finais

A possibilidade de ter um contato mais profundo com um paradigma de programao

diferente do tradicional, a programao paralela, es