FÁBIO BELOTTI COLOMBO DANIEL ZOEGA HAYASHIDA MILTON EIJI KATO CLUSTER DE PLAYSTATION 3 PARA COMPUTAÇÃO CIENTÍFICA

Transcrição

1 FÁBIO BELOTTI COLOMBO DANIEL ZOEGA HAYASHIDA MILTON EIJI KATO CLUSTER DE PLAYSTATION 3 PARA COMPUTAÇÃO CIENTÍFICA SÃO PAULO 2008

2 DANIEL ZOEGA HAYASHIDA FÁBIO BELOTTI COLOMBO MILTON EIJI KATO CLUSTER DE PLAYSTATION 3 PARA COMPUTAÇÃO CIENTÍFICA Projeto de Formatura apresentado à disciplina PCS-2502 Laboratório de Projeto de Formatura II, da Escola Politécnica da Universidade de São Paulo. Área de concentração: Engenharia de Computação e Sistemas Digitais Orientadores: Profa. Dra. Líria Matsumoto Sato Prof. Dr. Marcelo Nelson Paéz Carreño SÃO PAULO 2008

3 DEDICATÓRIA Dedicamos este trabalho às nossas famílias, amigos e professores que ajudaram a concluir o curso e este projeto. 2

4 Agradecimentos Agradecemos ao Prof. Marcelo Carreño, à Profa. Inés Pereyra e ao Prof. Marco Alayo por terem acreditado no projeto e comprado os equipamentos necessários para a execução dos trabalhos. Agradecemos também à Profa. Líria Sato por nos receber e orientar durante este projeto. 3

5 The only legitimate use of a computer is to play games. (Eugene Jarvis) 4

6 Resumo Neste projeto, desenvolvemos um cluster de Playstation 3 que pode ser utilizado para executar programas em paralelo. O projeto inclui toda configuração necessária para permitir que os consoles fossem utilizados como computadores normais, a configuração da comunicação entre os computadores que compunham o cluster e o desenvolvimento de um software para testar o desempenho do cluster. O software desenvolvido permite ao usuário realizar simulações da corrosão anisotrópica do Si em soluções de KOH. Esse processo é bastante utilizado na fabricação de sistemas micro eletro mecânicos ou MEMS (Microelectromechanical systems). O simulador desenvolvido é baseado em um autômato celular e a saída gráfica do programa é gerada utilizando o algoritmo marching cubes. Palavras-chave: Simulação. Corrosão anisotrópica. Silício. Cluster. Playstation 3. 5

7 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. 6

8 Lista de Ilustrações Figura 1 Exemplos de uma grade bi-dimensional com células triangulares (a), de uma grade unidimensional (b) e de uma grade tridimensional com células cúbicas Figura 2- Conectando bordas para tratar a vizinhança das bordas Figura 3 Toróide formada pela ligação das bordas de uma grade bidimensional Figura 4 Cantilever antes (a) e depois (b) da corrosão anisotrópica do silício Figura 5 Fluxo geral do software de simulação Figura 6 Separação do trabalho entre as diversas unidades de processamento Figura 7 Estrutura atômica do cristal de silício representado pela matriz de 4x4x4 células Figura 8 Separação de uma matriz de células 3D (a) em diversas fatias longitudinais (b) e diversas fatias transversais (c) Figura 9 Divisão das células entre nós de um cluster Figura 10 Hierarquia da estrutura de dados na PS Figura 11 Modo de distribuição dos blocos totalmente cíclico em 2 dimensões. A figura mostra qual SPE (1, 2, 3 ou 4) trabalha sobre qual dado Figura 12 Módulos de um programa ALF Figura 13 Movimento da varredura dos blocos de uma simulação nos SPEs. Os blocos opacos são os blocos utilizados para simulação Figura 14 Execução do programa com double-buffering Figura 15 - Células necessárias na determinação do proximo estado da célula central Figura 16 - Fluxograma do programa do simulador no PPE Figura 17 - Fluxograma do programa do simulador no SPU Figura 18 Troca de borda entre dois nós consecutivos durante a execução do programa Figura 19 Planos cristalográficos do silício: plano (100) em (a), plano (110) em (b) e plano (111) em (c) Figura 20 A estrutura em vermelho representa os cubos utilizados no algoritmo Figura 21 Os 15 casos do algoritmo marching cubes. Os vértices em amarelo são os que estão do lado de fora da superfície Figura 22 Superfícies com valores decrescentes geradas através da execução do algoritmo em um mesmo campo escalar Figura 23 Resultado da aplicação do algoritmo sem o tratamento prévio dos dados Figura 24 Atribuição do raio de um átomo Figura 25 Saída gerada pela simulação visualizada com o uso do software SimMEMS Figura 26 Resultado de uma simulação utilizando uma máscara com várias aberturas Figura 27 Distribuição do trabalho entre três processos Figura 28 Variação do tempo de execução do algoritmo de entrada de com a variação do número de processos Figura 29 Variação do tempo de execução por célula e do tempo de execução total com o número de nós Figura 30 Distribuição percentual do tempo gasto em cada parte do software de simulação. 67 7

9 Lista de Tabelas Tabela 1 Exemplificação da Regra Tabela 2 Execução de um autômato celular utilizando a regra

10 Sumário 1. Introdução O Cluster O Processador Cell Por que o PlayStation 3? Objetivos do Projeto Aspectos Conceituais Sobre o CBEA Autômato Celular Visão Geral Condições de Borda Message Passing Interface (MPI) Funcionalidade Implementações do MPI MPICH e MPICH OpenMPI MEMS Especificação do Projeto de Formatura O Cluster O Software Metodologia Projeto e Implementação Estrutura do Software de Simulação Estruturas de Dados do Software de Simulação Divisão dos Dados entre Processos Desenvolvimento no Cell Instalação do SDK Modificando o Software para o Cell Tratamento das Bordas da Grade As Regras do Autômato Saída do Software de Simulação

11 6. Resultados Considerações Finais Trabalhos Futuros Referências

12 1. Introdução A seguir descreveremos a motivação deste projeto bem como os objetivos principais deste projeto. Em seguida comentaremos o projeto proposto e a estrutura deste texto O Cluster Um cluster é um grupo de computadores interconectados que trabalham em conjunto. Em geral os computadores são conectados através de redes locais e funcionam como um único computador. Clusters são interessantes pois podem fornecer alta performance ou disponibilidade a preços mais baixos que o de um único computador com as mesmas características. Em 1994, a Thomas Sterling and Donald Becker desenvolveram na NASA um cluster chamado Beowulf (MERKEY). Diferentemente dos clusters criados até então, este cluster era construído a partir de computadores pessoais disponíveis comercialmente rodando um sistema operacional aberto, colocados em uma rede local pequena para realizar processamento paralelo. Todos os componentes são comprados, nenhum deles é feito sob medida. O software utilizado para o desenvolvimento de softwares também era aberto e de fácil aquisição. Devido a essas características, esse tipo de cluster ganhou espaço mundialmente. Outra característica 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 nós. Toda interface entre o usuário e o sistema é feita via o servidor. Em muitos clusters, os nós cliente não possuem teclados, monitores ou até mesmo um disco rígido. 11

13 O nome do cluster vem de um poema antigo inglês, em que o personagem Beowulf é descrito como tendo a força de trinta homens em sua mão. O conceito do cluster Beowulf é semelhante, pois busca dar o poder de vários computadores a um usuário através de um único computador. O cluster que descreveremos neste projeto segue este modelo O Processador Cell O desenvolvimento de microprocessadores recentemente sofreu uma grande mudança. O crescimento do poder computacional vinha se baseando em modificações do hardware para melhorar o desempenho do software. O uso de memória cache, previsão 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 código do mesmo. Devido aos limites alcançados na utilização dessas técnicas, a indústria buscou outras soluções para o aumento do desempenho de seus processadores. Seguindo o exemplo dos supercomputadores, que possuem centenas ou milhares de processadores, a indústria de microprocessadores lançou uma nova geração de processadores multi-core. Esses processadores possuem, em geral, dois ou mais cores idênticos. Um computador com um processador multi-core de dois núcleos 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 núcleos um processador tiver, mais rápido ele será. No entanto, criar um processador com muitos núcleos 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 dissipação de calor e consumo de energia que limitam a quantidade de transistores no chip. Além disso, os processadores atuais possuem uma arquitetura de memória que se utiliza de memória 12

14 cache dentro do processador. Quando existe mais de um processador utilizando uma mesma região de memória, é preciso um gerenciamento dessa memória. 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 econômico e mais rápido. Utilizando uma arquitetura multi-core heterogênea, onde cada núcleo possui sua própria memória RAM que pode ser acessada rapidamente, o processador dispensa a necessidade de memória cache para cada núcleo e, conseqüentemente, o hardware de gerenciamento para esses caches. Removendo outras partes do hardware que são utilizados em quase todos os processadores atuais, como sofisticados circuitos para previsão de desvios, o processador possui menos transistores que os processadores lançados à mesma época. No entanto, pode fornecer um poder de processamento superior aos processadores com maior número de transistores Por que o PlayStation 3? Os jogos 3D modernos requerem muito poder computacional. Em geral as operações para renderizar as telas e o nível de realismo nos modelos gráficos requerem que uma grande quantidade de operações em ponto flutuante seja realizada em um curto período de tempo. Isso fica evidente ao se analisar o poder de processamento das placas de vídeo atuais, que estão inclusive sendo estudas para uso em computação científica e ao se verificar o surgimento de hardware dedicado para o cálculo de física de jogos. Os consoles não fogem da regra, tendo em geral um grande poder computacional a um preço abaixo do de mercado, visto que nesse setor o lucro das 13

15 empresas vem da venda de jogos, e os consoles em si são geralmente vendidos com prejuízo para as empresas. No final de 1999 a Sony Computer Entertainment lançou sua console de sexta geração 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 história, ultrapassando a marca de 140 milhões de unidades vendidas(financial TIMES, 2008). Para a sétima geração 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 distribuído e aplicações de mídia. Existem algumas variações desse processador, as descrições a seguir são válidas para os processadores Cell utilizados no PlayStation 3. A console PlayStation 3 (PS3) não foge dessa regra. Além de possuir uma placa de vídeo da nvidia para o processamento gráfico, também vem com um processador Cell, cujas características funcionais já foram descritas. Apesar de ser possível adquirir da IBM clusters com processadores Cell, como o BladeCenter QS21, a diferença de preços entre estes sistemas e um cluster de PS3s é considerável. A empresa Fixstars Solutions vende clusters prontos e já configurados. Um cluster com 8 PS3s, um nó cabeça e o switch é vendido por cerca de US$17, Um Bladecenter com 14 blades QS22 é vendido por cerca de US$170, (FIXSTARS, 2008). Apesar de haver uma diferença de performance, para se estudar o processador Cell e sua aplicação em um determinado problema um cluster de PS3s é uma alternativa bem mais atraente economicamente. Por isso escolhemos montar um cluster com esses consoles. 14

16 1.4. Objetivos do Projeto Os objetivos deste projeto são: Montar um cluster heterogêneo de consoles PS3 e computadores pessoais disponíveis no mercado para uso em computação científica. 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 aplicação escolhida. Como foi descrito acima, existem diversas razões para se estudar a programação em sistemas paralelos, visto que em breve essa tecnologia se tornará dominante entre os computadores pessoais. Buscávamos uma aplicação para o cluster que também fosse de interesse prático, pois um bom desempenho do sistema em uma aplicação sem funcionalidade prática alguma não é interessante. Escolhemos então construir um simulador de corrosão anisotrópica de silício baseado em autômato 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 fabricação e pesquisa de sistemas que utilizam este tipo de corrosão, o que cria interesse prático no software. Em segundo lugar, autômatos celulares são facilmente paralelizáveis, o que era desejável dada a baixa experiência dos integrantes com o assunto. 15

17 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 núcleos são heterogêneos. O núcleo central é baseado na arquitetura Power ISA v Chamado de Power Processing Element (PPE) este núcleo é 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 núcleos. Os demais núcleos são chamados de Sinergistic Processing Elements (SPEs). Como o nome sugere, os núcleos foram desenvolvidos para trabalhar em conjunto com o PPE. Os SPEs são processadores Single Instruction Multiple Data (SIMD) que foram otimizados para rodar aplicações que necessitam de alto poder computacional, não sendo otimizados para rodar, por exemplo, um sistema operacional. Os processadores utilizados nas PS3s são fabricados com 8 SPEs mas apenas 7 são habilitados em hardware para aumentar o rendimento na fabricação. Além disso, o sistema operacional da Playstation, que virtualiza o hardware, roda em um dos SPEs. Sobram assim 6 núcleos para uso no cluster. A lógica básica de utilização 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 código que exige alto poder de processamento, ao invés de deixar o PPE realizar o processamento, o programador passa a utilizar o PPE para coordenar a execução dessa computação nos SPEs. Isso em si já é um grande desvio dos métodos convencionais de programação. 16

18 Outra mudança significativa diz respeito ao uso da memória. O PPE possui memória cache em dois níveis, como os processadores modernos, mas os SPEs não têm memória cache. Cada SPE possui 256KB de memória RAM local onde devem ser armazenados as instruções e os dados do programa a ser executado. Um SPE tem acesso a toda a memória principal mapeada, inclusive as regiões mapeadas para entrada e saída, através de operação utilizando Direct Memory Access (DMA). Com DMA, cada SPE pode acessar a memória principal para escrever ou ler dados sem a necessidade de interagir com o PPE. O PPE acessa a memória principal diretamente, como a maioria dos processadores x86 no mercado. Esse acesso é feito através de um cache. Quando uma posição de memória é acessada, o processador automaticamente busca um bloco de dados que contém o dado acessado e o transfere para a memória cache, que é mais rápida. Isso é feito pois em geral um acessos subseqüentes à memória tem alta probabilidade de estarem no mesmo bloco. Esse fenômeno é conhecido como principle of locality. Já no SPE, o programador deve explicitamente dizer ao processador qual parte da memória deve ser carregada na memória local, programando a unidade de DMA para realizar a transferência. Essa arquitetura tem diversas vantagens. Primeiramente, diminui a latência da memória. Um erro no cachê (miss) leva a centenas de ciclos de processamento perdidos devido à necessidade de se carregar um bloco inteiro de memória no cache, ao passo que no Cell se utiliza apenas alguns ciclos para programa o DMA. Isso também explicita a paralelização da execução de instruções e a transferência de dados e instruções de e para a memória. Um bom programador pode programar as transferências de tal maneira que ocorrem enquanto o processamento dos dados que já estão na memória local é realizado. O bom uso dessa arquitetura de três níveis de acesso à memória pode levar a um desempenho duas ordens de grandeza maior do processador Cell quando comparado a processadores convencionais(hofstee, 2005). 17

19 2.2. Autômato Celular O Autômato Celular é um modelo de cálculos discretos, composto de uma grade de células e de regras simples de comportamento. O conceito de autômato celulares foi introduzido pelo matemático John Von Neumann quando este estudava máquinas autoreplicantes. Apesar de ser um modelo bastante simples, é possível obter resultados bastante ricos e precisos em vários tipos de simulação, como fenômenos biológicos, desenvolvimento de cristais e fenômenos naturais complexos como fluxos turbulentos. A seguir descreveremos de maneira breve o funcionamento de um autômato celular Visão Geral Um autômato celular possui uma grade regular de células. Essas grade pode ser N- Dimensional. O formato das células também pode ser variado, permitindo à célula ter diversos números de células vizinhas. Abaixo temos alguns exemplos de grades que podem ser utilizadas por autômatos celulares. 18

20 Figura 1 Exemplos de uma grade bi-dimensional com células triangulares (a), de uma grade unidimensional (b) e de uma grade tridimensional com células cúbicas. Cada célula possui um estado discreto. O conjunto de estados possíveis das células é finito. O tempo também é discreto. O estado de uma célula no instante t está diretamente ligado ao estado de um número finito de células ao seu redor, denominadas de vizinhança, no instante t-1, isto é, todas as células mudam de estado em exatamente o mesmo instante. Apesar de a célula poder estar contida nessa vizinhança, ela não é considerada uma vizinha de si mesma. O próximo estado é definido por um conjunto de regras determinísticas. Tanto o conjunto de regras como a vizinhança é constante, não mudando com o tempo. O autômato celular não trivial mais simples existente é um autômato unidimensional com uma vizinhança simples e dois estados. Para estes tipos de autômato, existem oito possíveis configurações para a uma célula e seus dois vizinhos. Existem, portanto, 256 possibilidades distintas para as regras que determinam o próximo estado. Essas 256 regras são identificadas usando a notação Wolfram, criada por Stephen Wolfram. A notação é usar o valor cuja representação binária é a regra. A tabela abaixo mostra como é a Regra 110. Tabela 1 Exemplificação da Regra 110 Estado em t Estado em t

21 Esta regra é interessante um autômato celular com essa regra é equivalente à uma Máquina de Turing Universal. A seguir exemplificaremos o funcionamento de um autômato celular utilizando essa regra. Imagine que inicialmente todas as células estejam no estado 0, exceto uma. Imagine também que a grade de células é infinita. Pela regra 110, todas as células cujo estado é 0 e cujas vizinhas também estejam no estado 0 continuarão no estado zero. Assim, só precisamos nos preocupar com as células no estado 1 e em suas vizinhas. A célula cujo estado é 1 entrará no caso 010 e seu próximo estado será 1. Sua vizinha imediatamente à esquerda entrará no caso 001 e seu próximo estado será 1. A vizinha diretamente à direita da célula cujo estado inicial era 1 entrará no caso 100, e seu próximo estado será 0. A tabela abaixo mostra a evolução do autômato durante os sete primeiros passos. Tabela 2 Execução de um autômato celular utilizando a regra 110. t t t t t t t t A execução de um autômato celular bidimensional (plano) pode ser feita imaginando-se uma folha quadriculada de tamanho infinito, representando a grade de células. Cada quadrado representa uma célula. Assumiremos novamente, por simplicidade, que cada célula está em um de dois possíveis estados. Cada célula possui 8 células adjacentes. Estas 9 células (a célula sendo considerada mais suas 8 vizinhas mais próximas) podem assumir então 2 9 = 512 estados diferentes. O comportamento que o autômato irá assumir pelo decorrer do tempo pode ser determinado através de uma tabela de comportamento que descreve o próximo estado para cada uma dessas

22 possibilidades. Ou seja, no próximo passo de tempo (t+1), o estado da célula central é definido dependendo de um dos 512 estados possíveis da sua vizinhança. Da descrição acima, podemos facilmente notar que o estado final das células depende das regras do autômato bem como da configuração inicial das células. É comum, principalmente em uma grade infinita, que todas as células iniciem em um mesmo estado, e apenas uma parte delas inicia-se num estado diferente. Algumas vezes, as células podem estar dispostas seguindo um padrão periódico. Nesse caso, apenas uma parte da grade poderia diferir desse padrão. Como um exemplo de autômato celular bidimensional, pode ser levantado o Jogo da Vida de Conway. O Jogo da Vida segue as seguintes regras: Nascimento: Se uma célula morta (branca) tem três células vivas (pretas) em sua vizinhança, ela nasce no próximo passo (se torna preta). Sobrevivência: Se uma célula viva (preta) tem duas ou três células vivas na sua vizinhança, ela sobrevive (continua preta) no próximo passo. Morte: Em qualquer situação diferente das acima, a célula morre no próximo passo (se torna branca) As regras deste jogo são uma analogia com a proliferação de alguns seres vivos, como as bactérias. Esse simples jogo leva em consideração o fato de que se os indivíduos estão em falta ou em excesso não é possível se manter vivo. Os seres do jogo só se proliferam na densidade populacional ideal. Um autômato celular tridimensional opera da mesma maneira que um autômato celular unidimensional ou bidimensional. A principal diferença é a vizinhança. No caso de um autômato celular tridimensional com vizinhança simples e dois estados, temos 2 27 = possíveis configurações. Nesse caso, quando se implementa o autômato em software, é bem mais vantajosos descrever as regras como o Jogo da Vida foi 21

23 descrito acima, através de condições que agrupam diversos estados juntos. Isso reduz a memória necessária para se executar o programa Condições de Borda Para a simulação de um autômato celular, é comum se utilizar uma grade de tamanho finito, visto que a memória é um recurso finito. No entanto, ao definirmos um fim para a grade, encontraremos que as células que residem nessas bordas possuem uma vizinhança diferente das demais. Existem várias maneiras de se lidar com essas células, falaremos a seguir sobre alguns desses modos a seguir. Uma solução simples e bastante engenhosa para esse problema é ligar as extremidades da grade do autômato entre si, de maneira que é possível percorrer as células em qualquer direção sem nunca chegar á uma borda. Para exemplificar, imaginemos um autômato celular unidimensional com uma grade finita. As células mais à esquerda e mais à direita seriam as bordas, pois não possuem uma vizinhança como as demais. Fazemos então com que a vizinha da esquerda da célula mais à esquerda seja à borda direita, e que a vizinha da direita da célula mais à direita seja a borda esquerda. Isso é equivalente à transformar um segmento de linha em um círculo, como na figura abaixo. Figura 2- Conectando bordas para tratar a vizinhança das bordas. 22

24 No caso do autômato bidimensional, uma grade finita é equivalente a um espaço retangular de células, ao invés de um plano infinito. Neste caso, a solução seria uma toróide. Na figura abaixo, a linha rosa mostra a junção entre as bordas superior e inferior enquanto que a linha vermelha mostra a junção das bordas esquerda e direita. Figura 3 Toróide formada pela ligação das bordas de uma grade bidimensional. 1 Como podemos perceber pela figura, a representação toma uma dimensão a mais para se visualizar a forma equivalente, portanto não representaremos o equivalente para uma grade tridimensional. No caso do nosso autômato celular, esse tipo de comportamento não é desejável. Outra maneira de lidar com as bordas, até mais simples que a descrita anteriormente, é considerar as células na vizinhança não existente como tendo um valor constante, definido previamente. No caso do nosso simulador essa solução é bastante intuitiva, vista que as células fora da grade em consideração são o espaço vazio, e, portanto, consideramos seu valor como sendo sempre equivalente ao espaço vazio. 1 Figura de 23

25 2.3. Message Passing Interface (MPI) Todo programa é composto de algumas instruções que definem o que o programa faz e de dados sobre os quais o programa trabalha. Em sistemas paralelos, diversos processadores executam operações, que podem ser diferentes para cada processador, sobre um conjunto de dados, que também pode ser diferente para cada processador. Um problema que surge em sistemas paralelos é como realizar a troca de informações entre processadores. Em um ambiente onde todos os processadores têm acesso a um mesmo espaço de memória, essa comunicação, ou troca de informações, pode ser realizada através dessa memória. Quando o ambiente é composto por memória não compartilhada para cada processador (como em sistemas distribuídos), é necessário ter outro meio de comunicação. Em sistemas conectados por uma rede, a rede é o meio de comunicação. No entanto, ainda é preciso definir como essa comunicação, seja via memória ou via rede, será realizada. O MPI (Message Passing Interface) é um padrão que define uma API para realizar a troca de mensagens entre processos em uma sistema. Apesar de não ser aprovado por nenhum órgão de padronização, a extensão de seu uso tornou o padrão reconhecido mundialmente. O MPI não especifica uma linguagem para as implementações. Assim, existem implementações para diversas linguagens. Aplicações que usam MPI são compostas por um ou mais processos que se comunicam através de chamadas de funções pré-definidas de envio e recebimento de mensagens. Na maioria das implementações do MPI, é criado um conjunto fixo de processos inicialmente, e estes não precisam necessariamente executar o mesmo programa. Por isso, o padrão MPI é algumas vezes referido como MPMD (Multiple Program Multiple Data). 24

26 O padrão possui duas versões principais. O chamado MPI-1 é a versão mais atual da primeira versão do padrão. O chamado MPI-2 é a nova versão do padrão. Devido às diferenças entre as implementações das duas versões e da existência de diversos softwares que utilizavam o MPI-1 quando o MPI-2 foi lançado, ambas as versões ainda são muito utilizadas Funcionalidade A finalidade da interface MPI é fornecer funcionalidade de comunicação, sincronização e topologia virtual essencial entre um conjunto de processos, de um modo independente de linguagem. Tipicamente, para otimização de desempenho, a cada processador (ou núcleo de processador no caso de processadores multinucleados) é atribuído a apenas um processo. Essa atribuição ocorre em tempo de execução, através de um agente iniciador do programa MPI, normalmente chamado nas suas implementações de mpirun ou mpiexec. Apesar de existir uma padronização no nome dos comandos que compilam e executam códigos com MPI, as diferentes maneiras como cada implementação lida com a criação dos processos nos hosts que constituem o cluster leva a algumas diferenças na execução dos programas. Na maioria das implementações, no entanto, o comando para compilar um programa é o mesmo: mpicc. A biblioteca de funções MPI inclui operações de envio/recebimento de mensagem ponto-a-ponto de diversos tipos, referidos mais abaixo; para obter informações relacionadas à rede (como por exemplo, o número de processos sendo executados); para obter a identidade do processo que executando no respectivo nó e os nós adjacentes acessíveis na topologia de rede, entre outras. Quais funções são utilizadas depende do problema a ser resolvido. No caso do nosso software, utilizamos apenas algumas funções básicas, que descreveremos brevemente a seguir. 25

27 MPI_Init : essa função deve ser chamada antes de qualquer outra função da biblioteca. MPI_Comm_Size : Essa função é bastante útil, pois é através dela que se determina quantos nós fazem parte do sistema. MPI_Comm_Rank : Cada processo recebe um número seqüencial entre 0 e N, onde N é o número total de processos. Essa função permite saber qual é o número do processo que a chamou. Esse valor é chamado de rank. MPI_Send : Essa é a função mais simples para se enviar dados. Através dessa função pode-se enviar qualquer tipo básico de dado, como caracteres, inteiros ou números em ponto flutuante. A quantidade de dados a ser enviada também é variável. O destino dos dados também é definido na chamada da função. MPI_Recv : Essa função permite receber dados de um determinado nó. Existe também a opção de receber informações de qualquer nó. É preciso definir o tipo de dado que será recebido bem como seu tamanho. MPI_Finalize : Essa função fecha os processos MPI. As descrições acima são bastante breves, apenas para dar uma idéia do que cada função faz. Existem diversos outros parâmetros que não foram mencionados. Mas vale mencionar que as funções acima já permitem fazer muitos programas com MPI. Para uma explicação mais detalhada das funções e seu uso, existem diversas fontes na Internet e livros que ensinam a utilizar MPI Implementações do MPI MPI é apenas um padrão que define uma API. Para se escrever um programa, é necessário ter um código fonte ou biblioteca que implemente essa API. Isto é, o MPI descreve as funções que mencionamos acima e o que elas devem e não devem fazer. Para programar com MPI, precisamos de algo que faça o que o MPI deveria fazer, isso é uma implementação de MPI. Existem diversas implementações de MPI, a seguir descreveremos algumas que estudamos quando pesquisamos por uma implementação São elas: MPICH, MPICH2 e o OpenMPI. 26

28 MPICH e MPICH2 O MPICH é a primeira implementação do MPI 1.x, do Argonne National Laboratory. Muitos fabricantes de supercomputadores no início da década de 90 comercializaram o MPICH. O Argonne National Laboratory continuou a desenvolver o MPICH por uma década, e atualmente fornece o MPICH2, que é uma implementação parcial do padrão MPI-2. Esta versão, diferentemente da primeira, não aceita a troca de mensagens num ambiente heterogêneo OpenMPI Tão cedo quanto o Argonne National Laboratory, o Ohio Supercomputing Center desenvolveu a implementação aberta LAM/MPI para o padrão MPI-1. Os desenvolvedores então se juntaram à outros grupos que também haviam desenvolvido implementações do MPI-1 para desenvolverem em conjunto uma implementação para o padrão MPI-2. O Open MPI representa a junção de três implementações MPI bem-conhecidas: FT-MPI, da University of Tennessee LA-MPI, do Los Alamos National Laboratory LAM/MPI, da Indiana University Além dos três acima, houve também contribuições da equipe PACX-MPI da University of Stuttgart. Estes foram os membros fundadores da equipe desenvolvedora do OpenMPI. 27

29 2.4. MEMS Microelectromechanical systems (MEMS) são sistemas de dimensões diminutas que possuem partes móveis 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 milímetro. Devido ao tamanho pequeno, a física dos dispositivos é diferente. Apesar das leis serem as mesmas, os efeitos que determinam o comportamento do sistema são outros. Devido à baixa proporção de volume para área superficial, efeitos que dependem do volume, como inércia, são menos expressivos que efeitos ligados à superfície, como a eletrostática. MEMS são utilizados para diversas funções, seja como atuadores ou sensores. Podese construir desde micromotores para movimentação de alta precisão ou sensores para detectar diversas substâncias ou pressão. A figura abaixo mostra um cantilever. Essa estrutura é formada através da deposição de um filme sobre um substrato de silício, mostrado em (a), e pela subseqüente remoção do silício resultando em (b). Cantilevers podem ser utilizados para movimentação, como os cílios de alguns protozoários, ou para a fabricação de sensores. 28

30 (a) (b) Figura 4 Cantilever antes (a) e depois (b) da corrosão anisotrópica do silício. No caso da figura acima, a remoção do silício é feita através da corrosão anisotrópica do silício. Este tipo de corrosão é bastante utilizado na fabricação de MEMS devido à sua simplicidade. Uma maneira de realizar essa corrosão é mergulhando o dispositivo na Figura 4 (a) em uma solução de KOH. Este tipo de corrosão é conhecido como wet etch. O filme depositado sobre o silício é chamado de máscara. É esta máscara que define as partes do substrato que serão corroídas ou não. A corrosão anisotrópica do silício gera alguns resultados bastante complexos, principalmente quando o tempo de corrosão é mais longo ou a máscara utilizada para corrosão é complexa. Existem três famílias de planos com índices de Miller {100}, {110} e {111} que são bastante comuns. No entanto existem outros planos que surgem dependendo da solução utilizada para corrosão e da máscara. Devido ao grande interesse em MEMS e da grande utilização da corrosão anisotrópica em sua fabricação, diversos simuladores foram desenvolvidos para ajudar a prever o resultado dessas corrosões. 29

31 3. Especificação do Projeto de Formatura Os objetivos deste projeto de formatura são: 1) montar e configurar um cluster heterogêneo de PS3s e computadores desktop e 2) desenvolver um software para rodar nesse cluster. Abaixo descrevemos melhor esses objetivos O Cluster Como mencionado anteriormente, o uso do processador Cell através do uso de consoles PS3 apresenta alguns problemas, em especial a baixa quantidade de memória RAM para os padrões atuais. Para contornar em parte este problema, planejamos um cluster heterogêneo, onde os nós não são idênticos, podendo ter arquiteturas ou sistemas operacionais diferentes. As vantagens desse sistema heterogêneo vão além de superar a limitação de memória. Também permite que o software desenvolvido seja utilizado em outros clusters, não sendo necessário um cluster de PS3 para a execução do programa. Também permite que processadores com arquiteturas diferentes do Cell, que sejam aptos para executar tarefas para as quais o Cell não foi projetado, sejam utilizados. Esse tipo de arquitetura é utilizado no RoadRunner, o supercomputador construído pela IBM para o Departamento de Energia americano. Nesse cluster, operações padrão, como entrada e saída de dados, são realizados por processadores AMD Opteron. Operações computacionalmente intensivas são executadas pelos processadores Cell(IBM, 2008g). Se tratando de um cluster para processamento paralelo, é necessário realizar a troca de informações entre os nós. As consoles PS3s possuem placas de rede (Network Interface Card - NIC) Gigabit com bom desempenho. Apesar de algumas das 30

32 funcionalidades das redes Gigabit estarem indisponíveis 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 informação entre os nós. Para tanto usaremos um switch gigabit básico de oito portas. Como o número de nós será pequeno, inferior a oito, o desempenho do switch ainda não se torna essencial para o bom funcionamento do cluster O Software Para verificar o desempenho do cluster, bem como outros aspectos ligados à programação para o Cell, decidimos desenvolver um software próprio para rodar no cluster. Este software deveria ser facilmente paralelizável e ter algum interesse prático. Um simulador atomístico de corrosão anisotrópica de silício baseado em autômato celular satisfaz ambas as necessidades no nosso caso. Vários trabalhos sobre esse tipo de corrosão já foram desenvolvidos, o que fornece ampla documentação. Além disso, por se tratar de uma tecnologia básica para a fabricação de MEMS, também é de interesse prático. O autômato celular, por sua vez, é facilmente paralelizável. Como todas as células mudam de estado exatamente no mesmo instante e o próximo estado depende apenas do estado atual, pode-se calcular o próximo estado das células de maneira aleatória. Isso facilita a distribuição do trabalho entre vários núcleos de um processador ou vários nós de um cluster. O software será desenvolvido em passos para gerar dois produtos finais. Inicialmente desenvolveremos uma versão seqüencial. Essa versão será então modificada para gerar uma versão que roda no cluster. Essa segunda versão será então modificada para rodar no Cell utilizando todos os núcleos. As duas últimas versões serão os produtos finais, possibilitando a simulação em um cluster homogêneo ou heterogêneo de PS3s ou desktops. 31

33 4. Metodologia A seguir descreveremos a metodologia dos trabalhos desenvolvidos. O cluster foi montado e configurado seguindo as recomendações de (BUTTARI, LUSZCZEK, KURZAK, DONGARRA, & BOSLICA, 2007). Em especial, construiremos um cluster heterogêneo capaz de executar programas compilados utilizando MPICH Para iniciar a comunicação entre os nós, utilizaremos Secure Shell (SSH). A conexão deve ser feita automaticamente, o que será feito utilizando pares de chaves públicas / privadas. Para as PlayStations utilizamos o Fedora 8, uma distribuição do Linux recomendada pela IBM para a utilização 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, também em C, para a comunicação entre os nós. O software foi desenvolvido em várias fases para permitir testes e para gerar os resultados mencionados nos objetivos. Para saída do programa, foi utilizado o algoritmo marching cubes para gerar como saída uma superfície 3D que represente bem o sólido resultante da simulação. A programação no Cell foi realizada utilizando um ambiente de desenvolvimento composto por uma instalação do SDK versão do Cell (seguindo as indicações padrão de instalação do guia de instalação (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 máquina virtual com a distribuição Fedora do Linux. Todo os software para desenvolvimento foi fornecido pela IBM. 32

34 5. Projeto e Implementação 5.1. Estrutura do Software de Simulação O software de simulação de corrosão anisotrópica de silício foi desenvolvido em três partes. Inicialmente uma versão seqüencial, que foi posteriormente alterada para rodar em paralelo no cluster e utilizar as SPEs do processador Cell, foi desenvolvida. Assim, foi desenvolvido um simulador atomístico baseado em autômato celular seqüencial. As três partes do simulador são: Entrada Simulação Saída Na figura abaixo esquematizamos o fluxo do software. A entrada se dá por forma de um arquivo texto que descreve as dimensões da máscara e do substrato, em números de células, bem como o formato da máscara. O formato é descrito por uma matriz que indica sobre quais células a máscara está presente. O arquivo de entrada também informa o número de iterações do autômato celular. O arquivo de saída também é um arquivo texto. O arquivo está no formato reconhecido pelo software de CAD SimMEMS. A versão seqüencial do software não gera esse arquivo, mas simplesmente desenha a saída na tela. Para tanto, junto com o simulador seqüencial, uma interface gráfica simples também foi desenvolvida para permitir a visualização dos resultados e a conseqüente verificação do software. 33

35 Figura 5 Fluxo geral do software de simulação. Cada uma das três partes foi implementada de maneira modular, através de diversas funções pequenas. Isso permitiu que novos passos fossem adicionados de maneira simples e fácil quando o código foi modificação do para implementar a versão em paralelo. Para o desenvolvimento do simulador em paralelo, adicionamos alguns passos que não estão presentes na simulação seqüencial. Mais especificamente, é preciso adicionar um passo de separação na entrada, um passo de troca de dados entre cada interação na simulação e a unificação das saídas em uma única saída no módulo de geração da imagem 3D. Para a versão em paralelo para o Cell, também é necessário que se faça a distribuição do trabalho entre as SPEs após a separação entre os nós bem como a unificação de suas saídas antes da unificação das saídas dos nós. 34

36 Esta separação do trabalho tanto no nível do MPI, que como dito anteriormente distribui o trabalho entre nós do cluster, desktops e PS3s, quanto no nível do Cell dos PS3s que distribui ainda mais o trabalho a partir da PPE para as SPEs é ilustrada na figura abaixo. Figura 6 Separação do trabalho entre as diversas unidades de processamento Estruturas de Dados do Software de Simulação Para rodar a simulação, é necessário representar a matriz de células do autômato celular. A matriz pode ser representada como uma matriz de bytes do C. Apesar dessa representação ser suficiente para um simulador seqüencial ou para um simulador rodando em um cluster, a estrutura apresenta algumas dificuldades quando se tenta utilizar o processador Cell. 35

37 É preciso enviar as células para a memória local da SPE antes do seu processamento. Se enviarmos um vetor de dados para o SPE, espacialmente o que enviamos foi uma coluna de células. Isso não é suficiente para realizar a simulação, pois é preciso ter a vizinhança da célula para execução do autômato. Em especial, para simular uma célula, é preciso ter todas as células mais próximas e as células mais próximas das células mais próximas, formando assim um cubo de 5x5x5 células cuja célula central é a célula a ser simulada. É necessário então percorrer a matriz para obter um pedaço menor da matriz que represente as células em uma redondeza tridimensional para a simulação. Para evitar a necessidade de realizar essas buscas, e ao mesmo tempo otimizar a transferência de dados via DMA para as SPEs, utilizamos uma estrutura bastante simples para permitir que ao se acessar um vetor de dados, a informação representada seja tridimensional. Isso é feito através do uso de duas estruturas. A primeira, e mais básica, é chamada de bloco básico. Esta estrutura nada mais é que um vetor de tamanho fixo que representa um espaço tridimensional de células. A segunda estrutura é chamada de matriz. Essa matriz possui um vetor de tamanho variável de blocos básicos, bem como variáveis que armazenam as medidas desse bloco: altura, largura e comprimento. Assim, quando passamos um pedaço desse vetor ao SPE, o que passamos é um bloco básico, que representa um espaço tridimensional. A Figura 10 mostra um exemplo gráfico dessa representação e como ela é utilizada no Cell Divisão dos Dados entre Processos Em se tratando de um autômato celular de poucos estados, optamos por representar as células através de um byte. Para um autômato celular seqüencial, podemos 36

38 representar todas as células através de uma matriz 3D de bytes. Esta matriz é montada, isto é, o substrato é preenchido na inicialização, a partir da repetição de um bloco básico da estrutura de silício de tamanho 4 x 4 x 4 células que pode ser observado na figura a seguir. Apesar da estrutura unitária do silício ser definida com tamanho 5 x 5 x 5 células, utilizamos uma unidade menor pois ao se repetir a estrutura de 5x5x5 células, é preciso sobrepor os átomos na borda. Figura 7 Estrutura atômica do cristal de silício representado pela matriz de 4x4x4 células. 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 simulação dos autômatos celulares depende do estado atual da célula, dos vizinhos diretos e dos vizinhos destes (vizinhos dos vizinhos). Desta forma os blocos de dados não são totalmente independentes, devendo ocorrer uma troca de dados entre cada passo da simulação para que os átomos nas bordas entre as partes que cada nó sejam atualizadas corretamente. 37

39 De maneira a simplificar a troca de dados entre os n nós de um cluster, é mais fácil separar a matriz de todas as células 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 número de vizinhos que precisam receber informações bem como o número de células que precisam ser transmitidas quando comparados a separação em cubos, por exemplo. No nosso caso, onde estamos simulando a corrosão anisotrópica do silício, a separação 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 Separação de uma matriz de células 3D (a) em diversas fatias longitudinais (b) e diversas fatias transversais (c). 38

40 A figura abaixo exemplifica como um bloco seria distribuído entre três nós de um cluster. Note no esquema que todos os nós recebem um pedaço, não somente as PS3s. Isso ocorre porque o cluster é heterogêneo e todos os nós participam do processamento, inclusive o nó cabeça. Figura 9 Divisão das células entre nós de um cluster. De forma semelhante, porém mais dinâmica, o bloco recebido pelo PPE de uma PS3 é dividido novamente. A estratégia utilizada para esta divisão foi de fixar um eixo da matriz de blocos e associar toda uma fileira a uma SPE. Isto não dividirá toda a matriz num primeiro instante, mas esta estratégia tem a intenção de poder aproveitar dados já presentes na memória local de um SPE, além de permitir flexibilidade. É possível alocar as fileiras dinamicamente, o que permite uma melhor distribuição do trabalho caso uma região de blocos seja de rápida simulação. Se os blocos fossem alocados todos de uma só vez, uma dada SPE poderia ficar sem trabalho enquanto que outra, 39

41 associada a uma região com fileiras de blocos mais complexas, ainda tenha o que processar. Assim o PPE ainda trabalha no nível de blocos sem utilizar nenhum acesso a uma posição de um bloco. Somente na SPE se acessam as posições do bloco, porém de forma diferente do software seqüencial já que o SPE é um processador vetorial onde diversas células podem ser simuladas num mesmo momento. A hierarquia da estrutura de dados e sua divisão pode ser observada na figura abaixo onde se inicia com o bloco total sendo dividido para três nós pelo MPI e o resultante dividido pelo PPE para cada SPE. No último nível, uma posição de um bloco não conterá somente uma célula, mas sim 16 (8 bits por célula totalizando um vetor de 128 bits que é a unidade de trabalho do processador vetorial). Figura 10 Hierarquia da estrutura de dados na PS3. 40

42 5.4. Desenvolvimento no Cell A seguir descreveremos como foi instalado o SDK e como a programação para o Cell foi feita Instalação do SDK Para instalação, foram obtidos dois pacotes para instalação: CellSDK-Devel- Fedora_ e CellSDK-Extras-Fedora_ que são gratuitos e podem ser baixados do site da IBM. Porém a partir de 23 de outubro de 2008 uma nova versão do SDK ( ) substituiu a utilizada. Essa nova versão recomenda ser instalada, entre outras distribuições, sobre o Fedora 9 (IBM, 2008b). A instalação do SDK, que necessita conexão com a internet já que são utilizados muitos repositórios externos, pode ser facilitada se o usuário souber a arquitetura em qual o SDK será instalado. Sabendo isso, é possível obter o conteúdo de um terceiro pacote de instalação, o CellSDK-Open-Fedora_ , a partir do site da Barcelona Supercomputing Center (BSC) (BSC, 2007) e armazená-los no caminho de busca de repositório 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 não é necessário inicialmente ter acesso a um PS3 que possui a arquitetura CBEA para realizar a programação. Optou-se por não se desenvolver o software no PS3, pois a baixa quantidade de memória RAM faz com que a execução de um Integrated Development Enviroment (IDE) seja muito lenta. Escolhemos utilizar o Eclipse IDE obtido de repositórios próprios do Fedora 7, além do plug-in CDT 3.1 para programação em C/C++. Isto porque o SDK do Cell fornece um plug-in para que 41

43 se faça 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 indicações presentes no guia de instalação 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 são instalados juntamente com o plug-in do SDK para auxiliar no uso das ferramentas. Para obter os conhecimentos básicos iniciais sobre a estrutura do processador Cell (como bancos de registradores, canais de comunicação tanto para o PPE quanto para as SPEs), estudamos o tutorial fornecido pela IBM em seu site (IBM, 2007b). Funções muito utilizadas neste projeto estão descritas nos documentos: (IBM, 2007c) e (IBM, 2007d), especialmente as bibliotecas spu_mfcio e libspe2. A biblioteca spu_mfcio é utilizada pelas SPEs. Essa biblioteca contêm as funções de transferência de dados via DMA e o uso do mailbox, entre outros. A biblioteca libspe2 é uma biblioteca dinâmica utilizada pelo PPE para realizar as comunicações com os SPEs. Essa comunicação é realizada através dos mailboxes. Os mailboxes podem ser utilizados para a passagem de mensagem curtas e endereços da memória principal para que as SPEs possam acessá-las realizando transferências por DMA. A biblioteca também contêm funções para carregar diferentes programas nas SPEs e para manter referência destes no PPE para seu controle. Para execução de um programa compilado para o Cell em um computador sem o processador Cell, é preciso utilizar o Full System Simulator. Informações de utilização do simulador do Cell, tanto para iniciar um programa como para transferir os arquivos executáveis do host para a máquina virtual podem ser encontradas em (IBM, 2007b) e (IBM, 2007e). Durante os estudos, encontramos uma biblioteca que auxilia no desenvolvimento de 42

44 programas que possuem uma carga de dados que pode ser trabalhada independentemente entre suas partes, ou seja, de forma aleatória. Esta biblioteca é a Accelerated Library Framework (ALF) com documentação que pode ser obtida em (IBM, 2007f). O Eclipse com o plug-in do SDK do Cell possui uma opção de criação de projeto tipo ALF que gera automaticamente os códigos que gerenciam a transferência de blocos de trabalho para cada unidade aceleradora, as SPEs. A escolha dos blocos pode ser fixa ou cíclica. O mais próximo ao nosso uso seria a distribuição totalmente cíclica como pode ser vista na figura abaixo que tem a limitação de ser implementada somente até 2 dimensões. Depois de gerado o código básico é necessário somente codificar o algoritmo de trabalho em cima dos blocos e a inicialização destes. A figura a seguir ilustra os módulos do ALF, sendo que os que necessitam codificação são somente o Compute Kernel e Initialization. (CYCLIC, CYCLIC) Figura 11 Modo de distribuição dos blocos totalmente cíclico em 2 dimensões. A figura mostra qual SPE (1, 2, 3 ou 4) trabalha sobre qual dado. 43

45 Figura 12 Módulos de um programa ALF. Descartamos o uso do ALF, pois não havia nenhuma estrutura que se alinhasse com as nossas necessidades e fornecesse um desempenho superior ou igual à implementação manual do nosso software. Devido ao fato do processamento de cada célula de um autômato depender de uma certa vizinhança, não se pode descartar uma célula após o seu processamento, pois a mesma pode ser utilizada ainda no processamento de uma célula vizinha. Para a maior parte das aplicações desenvolvidas para o Cell a simulação dos programas utilizando o IDE Eclipse foi suficiente. Porém, para aplicações mais sofisticadas, especialmente as que utilizam a biblioteca dinâmica compartilhada (entre SPEs e PPE) libmisc, que contém a função malloc_align, isso não é verdade. Um problema de implementação entre o Eclipse IDE e o simulador faz com que esta biblioteca não consiga ser carregada corretamente, mesmo que o caminho na variável de ambiente LD_LIBRARY_PATH na máquina virtual esteja correto. 44

46 A função malloc_align, que aloca memória dinamicamente alinhando esta de acordo com o parâmetro inserido, é muito utilizada para alocar memória dinâmica de forma a permitir transferências via DMA entre PPE e SPEs, já que isto demanda que origem e destino de áreas de memória estejam alinhados em endereços específicos (1, 2, 4 ou 8 para transferências de menos de 16 bytes e múltiplos de 16 para transferências maiores). Além disso, a otimização das transferências de DMA ocorre quando se enviam quantidades de dados múltiplas de 128 bytes que estejam alinhados em 128. Deste modo, ainda utilizando o Eclipse para desenvolver, foram elaborados scripts simples para uma execução 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 Modificando o Software para o Cell Utilizando a estrutura de dados descrita no item 5.3 algumas considerações sobre detalhes da implementação serão discutidos a seguir. A primeira consideração é associada ao modo como os blocos recebidos pela PPE, via MPI, são divididos e entre as SPEs e enviados para as SPEs. A estratégia de divisão 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 simulação do bloco central, pois diversas células possuem como vizinhos células em outros blocos que não o central. Se após a simulação escolhêssemos um bloco aleatório para simulação, teríamos 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 próximo bloco. 45

47 Figura 13 Movimento da varredura dos blocos de uma simulação nos SPEs. Os blocos opacos são os blocos utilizados para simulação. Outro aspecto que merece ser mencionado é que a transferência desses 9 blocos pode ser iniciada antes da simulação. Isso permite que a transferência ocorra paralelamente ao processamento, para que ao final da simulação do bloco presente seja necessário somente um ajuste de ponteiros para iniciar a simulação do próximo bloco com um tempo de espera mínimo pelos dados. Esta estratégia é muito recomendada pelos manuais de programação do Cell e é chamada double-buffering. O double-buffering utiliza duas áreas de memória que trabalham alternadamente, num dado momento uma está sendo executada enquanto a outra recebe os dados para o próximo bloco e noutro os papéis se alternam. A figura abaixo esquematiza o processo de double-buffering. Figura 14 Execução do programa com double-buffering. 46

48 Já dentro dos blocos, observando a figura a seguir, que representa as células necessárias na determinação do próximo estado da célula central (de cor mais forte), nota-se que uma matriz de 5 x 5 x 5 células é formada. O modo de organização desta para aproveitamento do paralelismo da SPU está descrito a seguir. Figura 15 - Células necessárias na determinação do proximo estado da célula central Como o SPE é um processador vetorial, seu desempenho é maior se forem realizadas operações com vetores. Para tanto, é preciso montar os vetores a partir dos dados vindos dos blocos básicos. A maneira como isso é feito no software é bastante simples. Imagine que desejamos simular a célula central da figura acima. Agora imagine que existam outras 15 células como a que está na figura acima para as quais também desejamos determinar o próximo estado. Podemos colocar estas 16 células em um vetor. Podemos então montar outro vetor com as 16 células que estão á direita das 16 células centrais, na mesma ordem. Podemos montar também outro vetor com as 16 células á esquerda da célula central, também na mesma ordem, e assim por diante para todas as 125 células possíveis de cada bloco de 5 x 5 x 5 células. 47

49 Enquanto as operações que iremos realizar são idênticas para todas as células, podemos operar com os vetores ao invés de operar com as células individuais. Assim, ao invés de realizarmos uma soma de 26 células para determinar o número de vizinhos mais próximos para cada uma das 16 células, podemos somar os 26 vetores uma única vez e saber o número de vizinhos mais próximos de todas as 16 células. Vale mencionar que a operação de montar os vetores é um tanto quanto onerosa, o que torna o reaproveitamento de vetores já montados desejável. Isso é feito simulando as células em uma seqüência tal que vetores já montados possam ser reutilizados. Na figura a seguir observa-se o fluxograma dos passos principais da execução da simulação no PPE que faz somente papel de gerenciador dos dados, distribuindo e sincronizando as atividades entre as SPEs, sendo que nenhuma simulação em si ocorre neste. Algumas funções simples foram omitidas como determinação do endereço do bloco de saída para que a SPE possa retornar o resultado para a memória principal. O ciclo executa somente um passo da simulação sendo que os resultados da simulação daquele passo se encontram na área reservada para os blocos de saída. Após o retorno ao programa MPI este deve realizar as trocas das bordas entre os nós e desta forma realizar a chamada da função do PPE para executar outro passo da simulação. 48

50 Figura 16 - Fluxograma do programa do simulador no PPE. Na figura subseqüente é ilustrado o programa que é executado na SPE que é construído de forma pareada com o PPE para que requisições ou endereços das 49

51 estruturas estejam executando de forma sincronizada, para isso foi dada especial atenção para utilizar corretamente as funções que bloqueiam a execução do processador na espera por uma resposta por um canal de comunicação (como o mailbox). Alguns pontos neste fluxograma também foram omitidos. Um destes é que a transferência de blocos ocorre em dois passos. O PPE envia o endereço da matriz de ponteiros para os blocos a serem transferidos para a SPE. A SPE utiliza este endereço para transferir primeiro esta matriz. Somente então, já em posse dos endereços na memória principal dos blocos, a SPE pode iniciar a transferência dos blocos da memória principal para a memória local. Para fins de identificar blocos não existentes (como são os das bordas) foi definido que será utilizado o valor NULL ( 0 em C) para o endereço desses blocos. Assim é possível tratar a busca de acessos de vizinhos sem desperdiçar memória completando estes blocos com valores quaisquer. 50

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

53 5.5. Tratamento das Bordas da Grade Mencionamos anteriormente que quando se roda um autômato onde a matriz de células é finita, é preciso definir a condição de borda. As regras de transição de estado do autômato definem o próximo estado de uma célula em geral baseando-se no estado atual da célula e nos estados das células em certa vizinhança. Se a matriz for infinita, essa vizinhança sempre é definida. No entanto isso não é verdade para uma matriz finita. O nosso tratamento é feito de duas maneiras. Primeiramente, as últimas duas fileiras de células de toda a borda externa da matriz total (as bordas entre os nós não recebem este tratamento) são tratadas como sendo de material de mascaramento. Cada célula nessa região com estado correspondente a existência de um átomo tem seu estado mudado para material de mascaramento. Células vazias ou com material de mascaramento não são simuladas, portanto não há necessidade de definir uma vizinhança diferente para as mesmas. A máscara é definida aqui também. Onde o substrato é exposto à corrosão, os átomos são substituídos por células vazias ao invés de por material de mascaramento. Resta então tratar as bordas entre os nós durante a simulação em paralelo no cluster. Isso é feito transferindo os dados das bordas entre os nós vizinhos. A última camada de blocos básicos é transferida de um vizinho para outro. Em seguida, após 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 nós realizam um processo análogo, 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 são sempre sobrescritos. Essa operação é realizada ao final de cada passo de simulação. A figura abaixo exemplifica como essa troca é realizada. Finalmente, vale mencionar que 52

54 qualquer acesso a uma posição não existente, fora da matriz, retorna o estado de célula vazia. Figura 18 Troca de borda entre dois nós consecutivos durante a execução do programa As Regras do Autômato O autômato utilizado possui regras bastante simples, baseadas em observações da corrosão anisotrópica do silício. As regras foram definidas a partir da observação dos planos cristalográficos {100}, {110} e {111}. Os planos {100} e {110} têm velocidades de corrosão bastante altas quando comparadas às do plano {111}. Nosso modelo então considera que átomos nos planos {111} não são removidos, enquanto que átomos nos demais planos ({100} e {110}) são removidos. As regras resultantes dessa análise estão listadas abaixo. Para estas definições, considere que um vizinho direto é um átomo ao qual o átomo em consideração está ligado quimicamente. 53

55 1. Se um átomo possui dois ou menos vizinhos diretos, o átomo é removido. 2. Se um átomo possui três vizinhos diretos e estes vizinhos possuam oito ou menos vizinhos diretos (sem contar o átomo em consideração), o átomo é removido. 3. Em qualquer outro caso, o átomo não é 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 mantém os átomos do plano {111}. Observando os planos cristalográficos na figura a seguir, é possível verificar que o que diferencia os átomos dos planos {111} e {110} são justamente o número de vizinhos dos vizinhos. (a) (b) (c) Figura 19 Planos cristalográficos do silício: plano (100) em (a), plano (110) em (b) e plano (111) em (c). 54

56 Analisando a figura (a), vemos que os átomos na superfície possuem apenas duas ligações feitas. Já os átomos da superfície da figura (b) possuem três ligações, mas duas delas são com átomos que também estão na superfície. Isso reduz o número de vizinhos dos vizinhos. Já os átomos da superfície (c) possuem três ligações, e todas com átomos que não estão na superfície. A vizinhança utilizada é definida também pela estrutura cristalina do silício. As células que podem possuir vizinhos diretos e vizinhos dos vizinhos formam a vizinhança a ser analisada Saída do Software de Simulação A saída do programa é gerada utilizando o algoritmo Marching Cubes (LORENSEN & CLINE, 1987). Este algoritmo permite gerar uma malha de polígonos que representa uma superfície de valor constante em um campo escalar tridimensional uniforme. O algoritmo analisa os valores do campo de oito em oito, formando cubos. A análise gera um conjunto de triângulos para cada cubo analisado. O conjunto destes triângulos gerados é a superfície desejada. Inicialmente devemos definir qual o valor da superfície par o qual desejamos gerar a malha. Após escolhido o valor, passamos a executar o algoritmo. O campo escalar possui um valor para cada ponto. Analisamos oito pontos que formam os vértices de um cubo. Essa escolha é sempre feita de maneira que não haja nenhum outro ponto dentro do cubo que não seja um dos vértices. Na figura abaixo vemos como é feita a escolha dos vértices. 55

57 Figura 20 A estrutura em vermelho representa os cubos utilizados no algoritmo. Em seguida analisamos quais vértices estão dentro e quais estão do lado de dentro da superfície (valor do vértice superior ao valor da superfície) e quais estão do lado de fora da superfície (valor do vértice inferior ao valor da superfície). Existem 8 vértices em um cubo e portanto, 256 possibilidades. Essa configuração pode então ser armazenada em um byte. Isso é feito igualando o bit correspondente ao vértice a 1 se o vértice estiver dentro da superfície e a 0 caso contrário. Apesar de existirem 256 possibilidades para as configurações de vértices dentro e fora de uma superfície, existem apenas 15 formas distintas que uma superfície pode tomar dentro do cubo quando a mesma é aproximada por um conjunto de triângulos. Isso se deve ao fato de diversos bytes gerarem a mesma forma se as rotações, espelahmentos ou inversões dos vértices dentro e fora da superfície, junto com a inversão do vetor normal dos triângulos, apropriadas forem realizadas. Os 15 casos estão exemplificados na figura abaixo. 56

58 Figura 21 Os 15 casos do algoritmo marching cubes. Os vértices em amarelo são os que estão do lado de fora da superfície 2. Podemos então, a partir da configuração representada pelo byte, determinar quais os triângulos que devem ser gerados. Isso é feito em dois passos: inicialmente definimos os vértices dos triângulos que serão gerados e em seguida geramos os triângulos com estes vértices. Para tanto, indexamos uma tabela pré-calculada (ver Anexo A) utilizando o byte calculado anteriormente. O valor retornado é um inteiro que indica quais os vértices que devem ser calculados utilizando quais vértices do cubo inicial. Em seguida, utilizamos um segundo vetor que indica a ordem em que os vértices são percorridos para gerar os triângulos. Na figura abaixo temos um exemplo de várias malhas geradas com o algoritmo. Todas as malhas foram geradas a partir do mesmo campo escalar, apenas o valor da superfície foi modificado. As superfícies 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 57

59 (a) (b) (c) (d) Figura 22 Superfícies com valores decrescentes geradas através da execução do algoritmo em um mesmo campo escalar. O algoritmo foi considerado porque gera superfícies tridimensionais fechadas, o que é de interesse. O software que foi utilizado como base para este trabalho não 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 células do autômato são inicializadas com a estrutura cristalina do silício. Se o algoritmo for usado nesses dados, o resultado será um octaedro ao redor de cada átomo. Isso ocorre porque cada átomo será vértice de oito cubos, mas em todos esses cubos os vértices mais próximos estarão todos fora da superfície. A figura abaixo exemplifica esse resultado. 58

60 Figura 23 Resultado da aplicação do algoritmo sem o tratamento prévio dos dados Para evitar esse problema, aumentamos o raio dos átomos. Utilizando a mesma matriz que a simulação, atribuímos a todas a posições da matriz o valor 0. Em seguida, verificamos em quais posições existem átomos. Atribuímos então o valor 3 à célula com o átomo, o valor 2 ás células mais próximas e o valor 1 às células mais próximas das células mais próximas. A figura abaixo mostra uma representação vista de cima dos valores atribuídos. Esse padrão se repete de modo simétrico em todo o entorno da célula com o átomo. Todas as atribuições, com exceto da primeira que zera a matriz, são cumulativas. Os valores são limitados em 15 pois é o valor máximo que pode ser representado Figura 24 Atribuição do raio de um átomo. Com essa atribuição de um raio cumulativo, os átomos mais próximos se unem, e a superfície gerada passa ser uma figura tridimensional fechada. No programa, a superfície é passada pelo valor 0,5. Outra modificação que deve ser feita diz respeito 59

61 às bordas. É necessário atribuir um valor nulo a todas as células que ficam na borda externa da matriz inteira. Esse tratamento não deve ser aplicado à borda compartilhada entre os nós que realizam o processamento. Isso é feito para garantir que a superfície gerada está sempre dentro da matriz de simulação, garantindo uma superfície tridimensional fechada. Depois de gerada a malha, o software salva os triângulos em um arquivo texto no formato reconhecido pelo software SimMEMS (COLOMBO, et al., 2008). O resultado pode então ser visualizado na interface gráfica do programa simplesmente abrindo o arquivo gerado. 60

62 6. Resultados A seguir descrevemos os resultados obtidos. Esses resultados são ligados ao software desenvolvido. Na sessão seguinte descreveremos os aspectos técnicos da utilização 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 corrosão utilizando uma máscara simples. Como já mencionamos, a máscara é tratada no autômato como um estado diferente de certas células. O gerar a saída, a máscara pode ser visualizada através dos octaedros que permanecem no topo da estrutura após a corrosão. A máscara utilizada nesse exemplo é simples, sendo apenas uma abertura retangular. Nas figuras a seguir, foram realizados cinco passos da simulação entre cada imagem. Nessas figuras, podemos notar o surgimento do plano cristalográfico {110}, que gera o under-etch ao ser corroído, deixando o filme que forma a máscara suspenso. Também é fácil notar o plano {100} sendo corroído em direção à base do substrato. Os resultados observados batem, portanto, com o que é esperado na prática para este tipo de corrosão. 61

63 Figura 25 Saída gerada pela simulação visualizada com o uso do software SimMEMS. Outro exemplo que também foi simulado utiliza uma máscara com várias aberturas. Essa máscara é utilizada para construção de micro-pontas. Abaixo podemos observar o resultado da simulação. A primeira imagem foi produzida após cinco passos da simulação. Entre cada imagem também foram realizados cinco passos da simulação. 62

64 (a) (b) (c) (d) Figura 26 Resultado de uma simulação utilizando uma máscara com várias aberturas. 63

65 Na Figura 15a fica fácil visualizar o formato da máscara. Na figura Figura 15b já é possível notar o surgimento dos planos {111} nas quinas das aberturas, o que era esperado. Na figura Figura 15c podemos visualizar a estrutura após o substrato abaixo da máscara ter sido removido e antes de ocorrer o descolamento das pontas do filme que serve como máscara. Na Figura 15d já é possível visualizar o descolamento das pontas. Todos os resultados aqui mostrados foram obtidos utilizando a versão paralela do software, implementado com MPI. Especificamente para as imagens acima, utilizamos a versão MPICH A simulação foi efetuada com três processos simultâneos. A primeira estrutura era composta por 32x120x32 células. A segunda com 192x96x32 células. Para ilustrar melhor os resultados da simulação, e como o trabalho é separado entre os diversos nós, colorimos de maneira diferente as partes simuladas por cada processo no cluster. Isso ajuda a visualizar a separação dos dados entre os processos. Neste exemplo, três processos recebem partes iguais do substrato inicial para simular. Na figura seguinte podemos verificar que cada processo também recebe um pedaço diferente da máscara. Figura 27 Distribuição do trabalho entre três processos. 64

66 No que tange ao desempenho do software no cluster, fizemos algumas medidas simples do desempenho. Verificamos o tempo de execução variando o número de processos sendo executados. Devido a limitações do software, o número de células não é constante quando variamos o número de processos. Assim é importante considerar o número de células não é constante ao se realizar as comparações. Primeiramente, analisamos a entrada do software. Verificamos que com o aumento do número de processos, o tempo de inicialização também aumenta. Isso se deve ao fato da transmissão dos dados da máscara ser realizado de maneira seqüencial para cada processo. Assim, quanto maior o número de processos, maior o tempo necessário para enviar todas as partes da máscara para os respectivos processos. Os tempos de execução estão em segundos. Processos ,02 0,04 0,06 0,08 0,1 Figura 28 Variação do tempo de execução do algoritmo de entrada de com a variação do número de processos. Outro aspecto importante de se considerar é o tempo de execução do processo. Medimos o tempo de execução com um, dois e três processos. A variação pode ser vista nos gráficos abaixo. Note que apesar dos valores totais diminuírem, quando levamos em consideração o número de células que foram simuladas, ocorre uma perda no desempenho quando mudamos de dois para três nós. Os valores de tempo estão novamente em segundos. 65

67 4,50E-05 4,00E-05 3,50E-05 3,00E-05 2,50E-05 2,00E-05 1,50E-05 1,00E-05 5,00E-06 0,00E Tempo Médio de Simulação por Célula Tempo Total Figura 29 Variação do tempo de execução por célula e do tempo de execução total com o número de nós. Finalmente, é interessante visualizar como o tempo total é dividido entre as três partes do software de simulação: a entrada, a simulação e a saída. No gráfico abaixo, é possível perceber um aumento na porcentagem correspondente à entrada e à simulação. Isso é explicado pelo fato da entrada demorar mais com o aumento de processos. Já o aumento da porcentagem de tempo gasta com a simulação se deve à necessidade de se realizar a troca de bordas entre os processos, o que não é necessário com apenas um processo. Também é interessante mencionar que em todos os casos a maior porcentagem do tempo é gasta com a geração da superfície tridimensional que é a saída do software. Isso torna interessante qualquer otimização 66

68 que possa ser realizada nessa parte do software, pois modificações na saída iram gerar o maior impacto no desempenho do software de simulação. 3 2 Tempo Entrada Tempo Simulação Tempo Saída 1 0% 20% 40% 60% 80% 100% Figura 30 Distribuição percentual do tempo gasto em cada parte do software de simulação. 67