Computação Paralela Heterogênea Aplicada a Problemas das Ciências e Engenharias

Transcrição

1 Capítulo 2 Computação Paralela Heterogênea Aplicada a Problemas das Ciências e Engenharias Flávia Magalhães Freitas Ferreira (flaviamagfreitas@pucminas.br) Luís Fabrício Wanderley Góes (lfwgoes@pucminas.br) Rose Mary de Souza Batalha (batalha@pucminas.br) Rogério Fernandes Carvalho (rogeriofc@ieee.org) Rosinei Soares de Figueiredo (rosinei.soares@gmail.com) Pontifícia Universidade Católica de Minas Gerais Programa de Pós-Graduação em Engenharia Elétrica Prédio 03 - Sala Av. Dom José Gaspar, Bairro Coração Eucarístico CEP: Belo Horizonte MG Telefone: +55 (31) Resumo Nos últimos anos, a comunidade técnico-científica tem utilizado processadores gráficos programáveis, ou GPUs (Graphics Processing Units) como plataformas de computação de alto desempenho e baixo custo financeiro. Elas são compostas por centenas de unidades de processamento que permitem a execução de grandes quantidades de dados em poucos ciclos. Assim, as GPUs podem apresentar melhor desempenho se comparadas a processadores de propósito geral com múltiplos núcleos (multicores), principalmente quando se executam aplicações onde o paralelismo de dados é abundante. Ao uso de GPUs para computação de propósito geral dá-se o nome de GPGPU (General Purpose Computation on Graphics Processing Unit - GPGPU). A principal motivação para o emprego de GPGPU pela comunidade técnico-científica é a excelente relação custo-benefício proporcionada por essa plataforma de computação paralela, quando comparada com outros sistemas de computação de alto desempenho. O objetivo deste trabalho é introduzir o emprego de GPGPU para o processamento de alto desempenho de aplicações científicas e de engenharia, através do modelo de programação CUDA (Compute Unified Device Architecture). Neste trabalho são explorados dois estudos de caso. O primeiro estudo de caso tem ampla aplicação em várias áreas das ciências e diz respeito à visualização científica de grandes massas de dados. A implementação desenvolvida modela o uso do espaço de vida de uma espécie de primatas em uma região geográfica e comunica o resultado a pesquisadores da área de zoologia utilizandose de imagens volumétricas. O segundo estudo de caso apresenta a resolução de sistemas matriciais lineares através do método Gradiente Conjugado (CG). Esses sistemas lineares apresentados foram obtidos por meio do método dos elementos finitos (FEM) aplicado ao cálculo tridimensional da distribuição do campo elétrico em um oleoduto contendo hidrocarbonetos.

2 1. Introdução Nesta Seção serão abordadas as técnicas de paralelismo utilizadas atualmente, identificando a adequação das mesmas aos diversos tipos de problemas existentes nas ciências e engenharias. Ênfase será dada ao ambiente GPU (Graphics Processing Unit), utilizando o modelo de programação CUDA (Compute Unified Device Architecture). Nos últimos anos, a comunidade técnico-científica tem utilizado processadores gráficos programáveis como plataformas de computação de alto desempenho e baixo custo. A iniciativa de desenvolver algoritmo de propósito geral para essas plataformas é conhecida como Computação de Propósito Geral em Unidade de Processamento Gráfico (General Purpose Computation on Graphics Processing Unit - GPGPU) ou ainda Computação em Unidade de Processamento Gráfico (GPU Computing) [3][4]. A principal motivação para o emprego de GPGPU pela comunidade técnico-científica é a excelente relação custo-benefício proporcionada por essa plataforma de computação paralela quando comparada com outros sistemas de computação de alto desempenho. Outros motivadores para o crescente interesse em GPGPU são: O alto desempenho computacional que pode ser alcançado em certos casos, essencial para algumas aplicações que demandam computação intensiva. A resolução desses problemas geralmente é viável somente quando o sistema de computação (i.e. arquitetura, hardware e software) consegue prover alto desempenho; O contínuo aprimoramento das arquiteturas das GPUs, aumentando ainda mais o potencial computacional a cada nova geração de GPU; A rápida evolução das ferramentas de suporte ao desenvolvimento de GPGPU, como, por exemplo, as linguagens de programação de alto nível, os compiladores, os mecanismos de tratamento de exceções, a padronização de ferramentas etc; O consumo de energia das GPUs, considerado baixo quando comparado com sistemas tradicionais de computação de alto desempenho, como por exemplo, clusters de computadores. O acesso a plataformas de alto desempenho permite aos técnicos e cientistas a oportunidade de exploração das fronteiras do conhecimento de suas áreas por meio da ciência computacional, ou computational science [16], suprindo a lacuna deixada pelas soluções analíticas que, geralmente, se aplicam a um número muito reduzido de problemas reais, e pela experimentação prática com qualidade aceitável, que nem sempre é viável devido a questões tecnológicas e financeiras. Nesse sentido, GPGPU tem conseguido, em alguns casos, atender a essa demanda por desempenho devido ao alto grau de paralelismo espacial das GPUs [7][17]. O paralelismo espacial emprega dois ou mais elementos de processamento (EPs) na execução de instruções em paralelo, ou seja, em um mesmo instante de tempo. Nas GPUs, os EPs são distribuídos espacialmente em um mesmo substrato ou pastilha. A Figura 1 apresenta um substrato com aproximadamente 94 GPUs GT200, que são usadas nas placas gráficas GTX260 da NVIDIA. Essa placa é composta por apenas uma GPU GT200 com 1,4 bilhões de transistores e possui 216 EPs.

3 Figura 1 - Substrato com aproximadamente 94 GPUs GT200 da NIVIDIA (fonte: Devido à natureza paralela das arquiteturas das GPUs [18], GPGPU baseia-se no modelo de computação paralela. Esse modelo é diferente do modelo de computação sequencial que vinha sendo empregado nos processadores de propósito geral, conhecidos como Unidades Centrais de Processamento (Central Processing Units - CPUs). Antes do lançamento da tecnologia Dual-Core [19], a grande maioria das arquiteturas das CPUs era tradicionalmente sequencial, especialmente na classe de computadores desktops. Portanto, esse era o modelo de computação amplamente difundido na academia e na indústria, predominantemente. O paralelismo temporal em nível de instruções (Instruction-Level Parallelism - ILP) [1] vinha sendo explorado há várias gerações de arquiteturas de computadores e era estratégico para garantir ganhos de desempenho satisfatórios. As limitações impostas pelo ILP forçaram as CPUs a seguir o caminho do paralelismo espacial, que já estava sendo trilhado com sucesso pelas GPUs. Essa mudança de paradigma, do modelo de computação sequencial para o modelo de computação paralela, torna o paralelismo explícito ao programador, principalmente quando se deseja alto desempenho computacional. Isso significa que durante o desenvolvimento de um algoritmo ou programa, é preciso levar em consideração aspectos de concorrência, cooperação e comunicação entre as operações que são executadas em paralelo. Tal mudança acarreta em dificuldades adicionais no desenvolvimento de software, principalmente para os programadores que não dominam os conceitos básicos da programação paralela [13]. Até o momento, a engenharia de software não tem dado muita atenção à computação paralela [14]. As linguagens de programação tradicionais possuem limitações quanto ao emprego de construções sintáticas para representar o paralelismo. Além disso, existem vários modelos de computação paralela e alguns algoritmos enquadram-se melhor em um modelo do que em outros. Para manter crescente o aumento de desempenho computacional nessas arquiteturas paralelas, exige-se uma nova abordagem no desenvolvimento de software, de forma a explorar todo o potencial do paralelismo espacial.

4 Entretanto, desenvolver uma aplicação usando GPGPU com maior desempenho computacional tem se mostrado difícil [4], [7]. Isso é particularmente verdadeiro quando os programadores não são especialistas em computação, como é o caso da maioria dos cientistas e engenheiros que usam a programação como uma ferramenta auxiliar na investigação científica de suas áreas do conhecimento. A dificuldade advém de que o programador, levando em consideração o modelo de computação paralela para GPGPU, precisa tomar várias decisões durante o processo de desenvolvimento de software, escolhendo os recursos das plataformas de computação e as estruturas de dados mais adequadas para melhorar o desempenho computacional [8]. Para facilitar o desenvolvimento de aplicações para o modelo GPGPU, a plataforma e o modelo de programação paralela CUDA foram criados através de uma iniciativa da empresa NVIDIA. Como plataforma, CUDA provê uma série de ferramentas que possibilitam aos desenvolvedores criarem aplicações que aproveitem o poder de processamento oferecido pelas GPUs da NVIDIA. Já como modelo de programação, CUDA provê um conjunto de modelos e indicações necessários para criação de programas que utilizam recursos de processamento de GPUs [37]. Além de possibilitar ganhos significativos de desempenho, CUDA ainda tem a vantagem de diminuir a curva de aprendizado de programação paralela. Com CUDA, é possível ao programador enviar código em C, C++ e Fortran diretamente à GPU, com pequenas restrições, sem precisar usar uma linguagem de compilação. Assim, os programas executam as partes sequenciais de suas cargas de trabalho na CPU que geralmente é otimizada para desempenho com um único segmento (thread) ao mesmo tempo em que aceleram o processamento em paralelo através da GPU [38]. A linguagem de programação utilizada nesta pesquisa é a CUDA C, uma extensão da linguagem C, com algumas restrições necessárias à execução em GPUs. Os trechos de códigos escritos em CUDA C são chamados funções kernels. Atualmente, os algoritmos e suas estruturas de dados, ainda, seguem o modelo de computação sequencial conhecido como Fluxo Único de Programa Fluxo Único de Dados (Single Program Single Data - SPSD). Portanto, eles precisam ser analisados e modificados para se adequarem ao modelo de computação paralela adotada em GPGPU com o modelo CUDA. Esse modelo é conhecido como Fluxo de Programa Único Fluxo de Dados Múltiplos (Single Program Multiple Data SPMD) [2]. Entretanto, tais modificações nem sempre são únicas, triviais ou mesmo possíveis. O desenvolvedor precisa analisar o problema e identificar os trechos de algoritmos sequenciais candidatos à paralelização, avaliando se o esforço de programação em GPGPU justificará o empreendimento. Portanto, o benefício do alto desempenho proporcionado por GPGPU nem sempre se aplica. A manipulação dos dados a serem processados também exige atenção especial durante o desenvolvimento de aplicações em GPGPU, pois são introduzidos atrasos no processamento ao se exigir a transferência dos dados do computador, ou Host, para a placa gráfica, ou Device. A Figura 2 apresenta a manipulação de dados em uma plataforma de computação paralela para GPGPU.

5 Plataforma de Computação Paralela Host Device CPU GPU SP SPSP Stream Multiprocessor Leitura/Escrita de dados na memória Host DRAM (Memória Host) Transferência de dados entre Host e Device Leitura/Escrita de dados na memória Global DRAM (Memória Global) HD Leitura/Escrita de dados no disco rígido (memória não volátil) Figura 2: Manipulação de dados em plataforma de computação para GPGPU Mesmo quando os dados já se encontram na memória interna da placa gráfica, chamada memória Global, é preciso levar em consideração o padrão de acesso a esses dados, com o objetivo de minimizar os atrasos decorrentes da latência de acesso a esse tipo de memória. Alternativamente, o desenvolvedor poderá fazer uso de outros tipos de memória que compõem a arquitetura da GPU, com o objetivo de minimizar esses atrasos. Entretanto, outras restrições precisarão ser consideradas. Por exemplo, pode-se utilizar a memória compartilhada (shared memory) como uma espécie de memória cache uma vez que essa memória se encontra dentro da própria GPU (on-chip memory) e a latência de acesso a ela, muitas vezes, é mínima. Porém, a memória compartilhada possui severa restrição de tamanho, geralmente, 16KB, por cada conjunto de threads, chamado Bloco (Threads Block). Além disso, a gerência dessa memória é de responsabilidade do programador. Se a execução de uma rotina paralela não proporcionar um ganho de desempenho computacional significativo, pode ser vantajoso manter a sua versão sequencial, pois o tempo gasto com a transferência dos dados da memória Host para a memória Global pode inviabilizar o uso de GPGPU. Quando a memória Global não comporta todos os dados a serem processados ou os dados mudam constantemente (no caso, por exemplo, de processamento de vídeo), a transferência de dados entre Host e Device torna-se crítica [24]. Tendo em vista esse limitador de desempenho, algumas funcionalidades foram adicionadas às placas gráficas, com o objetivo de esconder a latência de transferência de dados entre Host e Device, tais como, as operações assíncronas de transferência, que permitem transferir uma massa de dados da memória Host para a memória Global enquanto a GPU está processando outros dados. Diante dessas dificuldades enfrentadas pelos programadores, algumas perguntas podem surgir. Entre elas, destaca-se: como saber se uma aplicação desenvolvida utilizando GPGPU, onde se deseja minimizar o tempo de execução e maximizar o desempenho computacional, apresenta desempenho compatível com as características do problema a ser resolvido e com as características da plataforma de computação paralela que utiliza GPU? Todavia, acredita-se que os maiores desafios impostos pela adoção do paralelismo espacial estão na área da educação em Ciência da Computação e áreas correlatas [1], que precisam urgentemente resolver as questões [23] que se apresentam a partir da crescente disponibilidade de arquiteturas paralelas de computadores.

6 O objetivo deste trabalho é introduzir o emprego de GPGPU para o processamento de alto desempenho de aplicações científicas e de engenharia, através do modelo de programação CUDA. Neste trabalho são explorados dois estudos de caso. O primeiro estudo de caso tem ampla aplicação em várias áreas das ciências e diz respeito à visualização científica de grandes massas de dados [9]. A implementação desenvolvida modela o uso do espaço de vida de uma espécie de primatas em uma região geográfica e comunica o resultado a pesquisadores da área de zoologia utilizando-se de imagens volumétricas. O segundo estudo de caso apresenta a resolução de sistemas matriciais lineares através do método Gradiente Conjugado (CG). Esses sistemas lineares apresentados são obtidos por meio do método dos elementos finitos (FEM) aplicado ao cálculo tridimensional da distribuição do campo elétrico em um oleoduto contendo hidrocarbonetos [8] [10] [12].

7 2. Estudo de Caso 1: Visualização Científica de Grandes Massas de Dados em um Problema Relacionado às Ciências Naturais 2.1 Introdução Uma área que tem evoluído bastante e, com isso, ajudado a evolução da Ciência, é a Visualização de Dados e/ou Visualização Científica. Trata-se da arte de gerar imagens que sintetizam uma grande quantidade de dados, a fim de facilitar a compreensão do fenômeno representado, a análise virtual do seu comportamento e a descoberta de conhecimento de forma mais intuitiva [25]. Um dos grandes desafios da Visualização Científica é o alto custo computacional que suas aplicações apresentam. Pela natureza dos dados, geralmente muito complexos e volumosos, as aplicações de visualização acabam por apresentar tempos de resposta elevados e baixa precisão dos resultados [26]. Nesse contexto, o problema geral desta pesquisa apresenta-se na forma do questionamento de como é possível viabilizar a construção e execução de aplicações de Visualização Científica com ganhos significativos de desempenho e qualidade dos resultados. Em resposta ao problema definido, este estudo propôs usar GPUs, programando-as em CUDA, como forma de prover capacidade computacional para as aplicações de visualização, focando-se em melhorias no tempo de resposta e na qualidade dos resultados. A verificação da proposta foi feita utilizando cargas de trabalho provenientes de um estudo de caso. Tal estudo de caso foi definido em uma área externa à computação, na Zoologia dos Vertebrados. Trata-se, portanto, de um projeto interdisciplinar do qual fazem parte os trabalhos de mestrado de [27] e [28]. O objetivo principal do trabalho foi aplicar a Computação Paralela, baseada em GPUs com CUDA, como forma de viabilizar a execução de aplicações de Visualização Científica. Como objetivos específicos, foram estabelecidos os seguintes: Formalizar o estudo de caso; Modelar a aplicação computacional relacionada ao estudo; Estudar as características das arquiteturas de computação utilizadas e a tecnologia CUDA; Construir e experimentar versões da aplicação; Analisar os resultados dos experimentos. 2.2 Visualização Científica A Visualização Científica refere-se ao uso de imagens geradas por computador, que através de elementos geométricos dispostos topologicamente, potencializa o ganho de informação e entendimento sobre conjuntos de dados e suas relações [29]. Tomada como um processo, a Visualização Científica é composta pelos seguintes estágios: o estágio de Aquisição de Dados trata da medição ou geração dos dados científicos, especificamente; o estágio de Melhoria e Transformação é responsável por entregar os dados de forma padronizada e distribuível, aplicando para isto algumas técnicas de transformação, se necessárias; o estágio de Mapeamento de Visualização, também chamado de Filtragem de Dados, tem a responsabilidade de remover ou agrupar dados irrelevantes e mapear os dados relevantes para as representações visuais; o estágio de Renderização é responsável por traduzir em imagens as informações contidas nos dados, já mapeadas em representações específicas pela

8 etapa anterior; por fim, o estágio denominado Imagem tem a função de permitir a manipulação da imagem renderizada para se chegar a uma visualização final [30]. Na Visualização Científica existem subáreas bem definidas. Uma delas é a Visualização Volumétrica, objeto de interesse desta pesquisa. Trata-se do conjunto de técnicas utilizadas para visualização de dados volumétricos, escalares ou não, associados a regiões de volume, para facilitar sua compreensão por meio da visualização do seu interior e da exploração da sua estrutura [25]. 2.3 Trabalhos relacionados Entre os principais trabalhos relacionados a esta pesquisa, citam-se o trabalho de [39] e o trabalho de [27]. Em [39] é feita uma comparação entre arquiteturas baseadas em multicore, arquiteturas baseadas em GPU e arquiteturas baseadas em APU, também chamadas de arquiteturas híbridas, que usam conjuntamente as duas anteriores, aplicando-as em renderização volumétrica. Os resultados mostram que, para o caso verificado, as arquiteturas híbridas apresentam vantagens sobre as demais, pois permitem explorar o melhor de cada uma das arquiteturas componentes, o que reduz a quantidade de comunicação entre cada núcleo de processamento e o tamanho dos dados comunicados, tornando a execução mais rápida. No entanto, a melhor alternativa depende da disponibilidade de arquiteturas paralelas e das características da carga de trabalho, que devem ser avaliados em cada caso. O trabalho de [27] foi selecionado por fazer parte do domínio da aplicação do presente trabalho. Nele é apresentado um estudo sobre o uso da área de vida em três dimensões pelos primatas Calicebus Nigrifons, comumente conhecidos como Guigós. O escopo do projeto abrangeu a coleta presencial de dados sobre o comportamento e localização dos animais em seu habitat natural; a análise estatística das dimensões coletadas e a análise quantitativa da área de vida, que envolve o cálculo da área e volume ocupados e sua apresentação visual. Os resultados mostraram que considerar a terceira dimensão no estudo da área de vida dos animais auxilia na descoberta de novas informações até então desconsideradas. Observou-se também a necessidade da criação e a utilização de métodos de cálculo e apresentação mais refinados, que deem informações mais precisas sobre a utilização do espaço. Sobre tal demanda é que a presente pesquisa explorou a aplicação de GPUs e CUDA. 2.4 Desenvolvimento O desenvolvimento do trabalho deu-se, principalmente, com a definição do estudo de caso, a modelagem e o desenvolvimento da solução, a execução experimental e a análise dos resultados Descrição do estudo de caso O estudo de caso desenvolvido no trabalho relacionou-se com a construção de uma aplicação de Visualização Científica para os pesquisadores em Zoologia dos Vertebrados da PUC Minas. Tal aplicação implementou mecanismos para a modelagem, o cálculo e apresentação do uso do espaço de vida, em três dimensões, pelos primatas estudados. Em conjunto com os cientistas da Zoologia e com base em [40], [41] e [42], foi desenvolvido o modelo matemático para cálculo de área de vida em três dimensões, estendido do modelo Kernel 2D, conforme Equação 1.

9 f! (x) = f!!"#"$ (x1, x2, x3) = 1 n !!!! h1 h2 h3 1 x1 Xi1 h1 1 x2 Xi2 h2!! I I xi Xi1 h1 xi Xi2 h2 1 1 (1) x3 Xi3 h3! I xi Xi3 h3 1 n é a quantidade de pontos amostrais, correspondendo à localização geográfica tridimensional (latitude, longitude e altura em relação ao solo) de algum primata, observada pelo pesquisador de Zoologia em algum tempo contido no intervalo de observação; X é a lista de pontos amostrais; x é a posição corrente (latitude, longitude e altura em relação ao solo) da célula na matriz tridimensional em processamento (matriz que envolve o espaço de vida dos animais); f h (x) é a densidade de ocupação da célula x; h1, h2 e h3 referem-se às distâncias máximas, em cada dimensão, para que um determinado ponto amostral possa contribuir para a estimativa de densidade de utilização (ou ocupação) de uma célula e, finalmente, I(j) é a função indicadora, sendo I = 1 se j é verdadeiro e I = 0 se j é falso. A partir do modelo matemático, elaborou-se o algoritmo para sua a execução sequencial, conforme abaixo. Algoritmo: Cálculo Kernel 3D sequencial 1. Leia e armazene os pontos amostrais em P; 2. Leia e armazene o Fator h em H; 3. Faça a translação dos pontos nos eixos X e Y de forma que os menores valores encontrados em cada um desses eixos, Xmin e Ymin, considerando a margem estabelecida em H, sejam deslocados para a origem do espaço a ser visualizado; 4. Após a translação, identifique o valor máximo de cada uma das dimensões dos pontos amostrais, em metros lineares, e armazene-as em DX, DY, DZ; 5. Crie uma matriz tridimensional G com largura, altura e profundidade igual a DX, DY e DZ, respectivamente, em que cada célula é um cubo de aresta unitária, representando um metro cúbico da região amostrada; 6. Para cada célula da matriz G, calcule o valor da estimativa da densidade de utilização do espaço: 6.1. Inicialize o valor de intensidade K com zero; 6.2. Percorra o conjunto de pontos amostrais P calculando a contribuição de cada um deles para o valor de intensidade de utilização, conforme equação (1), acumulando-a em K; 6.3. Armazene o valor de K na posição corrente da matriz G. 7. Exiba o resultado do cálculo da área de vida; Fim do Algoritmo.

10 Com base no algoritmo sequencial, elaborou-se uma versão paralela, conforme a seguir. Algoritmo: Cálculo Kernel 3D paralelo 1. Leia e armazene os pontos amostrais em P; 2. Leia e armazene o fator h em H; 3. Faça a translação dos pontos nos eixos X e Y de forma que os menores valores encontrados em cada um desses eixos, Xmin e Ymin, considerando a margem estabelecida em H, sejam deslocados para a origem do espaço a ser visualizado; 4. Após a translação, identifique o valor máximo de cada uma das dimensões dos pontos amostrais, em metros lineares, e armazene-as em DX, DY, DZ; 5. Crie uma matriz tridimensional G com largura, altura e profundidade igual a DX, DY e DZ, respectivamente, em que cada célula é um cubo de aresta unitária, representando um metro cúbico da região amostrada; 6. Defina a quantidade de threads T; 7. Defina a quantidade de células Q a serem processadas por cada thread; 8. Transfira os pontos amostrais P para a memória compartilhada da placa gráfica; 9. Aloque um espaço M equivalente ao tamanho da matriz G na memória da placa gráfica; 10. Invoque a execução multithread na GPU da placa gráfica: Para cada thread em execução na placa gráfica: Recupere o identificador Id do thread; Defina, com base em Id e em Q, quais células serão processadas pelo thread; Para cada célula do escopo do thread, calcule o valor da estimativa de utilização: Inicialize o valor de intensidade K com zero; Percorra o conjunto de pontos amostrais P calculando a contribuição de cada um deles para o valor de intensidade de utilização, conforme equação (1), acumulando-a em K; Armazene o valor de K na posição corrente da memória M. 11. Copie o conteúdo da memória M para a matriz G. 12. Exiba o resultado do cálculo da área de vida; Fim do Algoritmo A aplicação construída A aplicação construída pode ser dividida em três blocos básicos: o carregamento dos dados, o cálculo da distribuição de densidade de utilização e a apresentação do resultado do cálculo em forma de imagens e valores quantitativos. A Figura 3 exemplifica o fluxo dos dados e as operações que são executadas sobre eles, na aplicação construída.

11 Figura 3: Fluxo de dados e operações Os dados amostrais, na forma de uma lista de pontos tridimensionais, são importados pela aplicação. A partir desses dados, faz-se o cálculo da densidade de utilização do volume definido por DX, DY e DZ, o que gera uma matriz tridimensional preenchida com esses valores de intensidade (ou densidade) de utilização para cada uma de suas células. Dessa matriz, afere-se o valor de volume com um somatório simples das células ocupadas (as células não ocupadas são, portanto, descartadas) e gera-se a imagem, projetando-se a matriz tridimensional de densidades em um plano: nas imagens geradas por esta aplicação, observa-se apenas uma vista de cima (paralela ao plano xy), em que as células ao longo do eixo z, para um mesmo par (x,y), foram sobrespostas. Pesquisas futuras deverão focar na renderização da imagem volumétrica, o que não foi o foco principal desta pesquisa. As versões experimentais da aplicação foram construídas utilizando-se a plataforma de desenvolvimento Microsoft Visual Studio Foi utilizada a linguagem CUDA C para a codificação dos trechos do programa que executam em GPU e a linguagem C/C++ para os demais componentes do sistema. A aplicação foi construída para o ambiente Windows, utilizando-se o padrão Console Application. Porém, a imagem representativa da distribuição do espaço de vida tridimensional é criada através de chamadas às funções da biblioteca gráfica OpenGL [43] e outras bibliotecas que trabalham em conjunto com esta (a saber, as bibliotecas GLU e GLUT). Para a execução do software nas plataformas selecionadas, fez-se necessária a construção de quatro versões distintas do mesmo. A primeira versão é aquela que faz o cálculo sequencial em CPU; a segunda versão foi desenvolvida para executar o cálculo em paralelo também em CPU, utilizando-se a API OpenMP [48]; a terceira versão foi desenvolvida para execução do cálculo em paralelo utilizando GPU, considerando o compartilhamento desse recurso com o sistema operacional, responsável por gerar a imagem final e, por fim, a quarta versão foi desenvolvida para execução do cálculo em paralelo utilizando GPU, que então foi reservada exclusivamente para a execução dos cálculos, sem interferências advindas das demais tarefas do sistema. A quarta versão foi construída para se verificar o comportamento da aplicação em situação em que toda a capacidade de processamento da GPU fosse dedicada apenas à aplicação propriamente dita (cálculo da distribuição da densidade de ocupação), sem interferência do sistema operacional (em situações, por exemplo, em que um computador possui mais de uma GPU disponível). A justificativa para a criação e experimentação dessa versão é apresentada na seção seguinte, juntamente com outras dificuldades encontradas durante o processo de desenvolvimento. Todas as versões do software geraram o resultado do processamento como esperado, ou seja, uma imagem representativa da distribuição da intensidade de utilização do espaço

12 tridimensional, como exemplificado na Figura 4, bem como as informações sobre o volume desse espaço. Elas apresentaram, porém, tempos de respostas significativamente diferentes para a geração desses resultados. Figura 4: Exemplo de imagem gerada pela aplicação Na Figura 4, as cores representam a intensidade de utilização em cada região de 1m 3 (1 pixel de aresta) projetada sobre o plano xy (as células ao longo da altura eixo z foram sobrespostas). Essas cores foram definidas para facilitar a visualização dos diferentes níveis de utilização. A cor e a transparência de cada pixel foram definidas com base no valor estimado da distribuição de utilização da célula corrente, ou seja, ambos os atributos da imagem, cor e transparência, foram utilizados para comunicar de forma mais eficiente a mesma informação (densidade de ocupação). Para a cor foram definidos três possíveis valores, e para a transparência fez-se uma correspondência direta com o valor estimado da intensidade de ocupação da célula, após a multiplicação por uma constante. As possíveis cores e seus respectivos códigos RGB em OpenGL foram azul [0.0, 0.0, 1.0], verde [0.0, 1.0, 0.0] e vermelho [1.0, 0.0, 0.0]. Na Figura 4, nota-se a existência de diferentes tons de azul, o que é resultado da transparência atribuída a cada elemento, uma vez que a mesma cor é mantida para cada um deles. O verde é mais constante e não sofre tanto o efeito da variação de transparência. Ao centro, a região avermelhada recebe pouca interferência da variação da transparência, mas sofre alguma distorção por estar mergulhada sob uma fina camada de elementos de cor verde, que são computados para a formação da cor resultante Principais dificuldades encontradas No decorrer do desenvolvimento da aplicação algumas dificuldades específicas foram encontradas, entre as quais citam-se a distribuição dos blocos e threads de execução e divisão da carga de trabalho entre cada thread. Como o foco central do trabalho não apresenta tal natureza, não foram feitas análises exaustivas para se encontrar a configuração mais otimizada possível,

13 sendo este um ponto onde cabem novas experiências e proposições de melhoria que visem tornar mais eficiente o uso da capacidade de processamento dos dispositivos. O processamento foi divido de maneira simplória entre as instâncias de execução. Cada thread ficou responsável por processar um vetor de células pertencentes à matriz tridimensional criada para o cálculo da estimativa de intensidade de utilização. Cada um desses vetores de células são formados a partir de um valor fixo para a dimensão x (latitude), um valor fixo para a dimensão eixo y (longitude) e valores variáveis para a dimensão z (altura em relação ao solo), formando pilhas de células na direção do eixo z. Cada uma dessas pilhas de células é processada por um thread diferente. O número de threads e blocos são calculados a partir de parâmetros relacionados ao tamanho da matriz. O número de threads é definido como o máximo valor de x multiplicado pelo máximo valor de y. Já a quantidade de blocos é definida pela quantidade de threads necessárias e pela quantidade máxima de threads por bloco permitida em cada dispositivo. A partir desse modelo de divisão de trabalho, um novo desafio criou outra necessidade específica. Para conjuntos amostrais com muitos pontos, dentre os diversos conjuntos utilizados, a execução feita através desse modelo de divisão ultrapassava o tempo limite estipulado pelo sistema operacional, o que causava a interrupção da execução. Devido a essa dificuldade, fez-se necessária uma readaptação no modelo, de forma que nem todos os blocos de threads fossem enviados para execução de uma só vez. Ao contrário, os blocos passaram a ser enviados parcialmente, evitando o congestionamento do dispositivo. Essa nova configuração permite que as execuções sejam feitas sem extrapolar os limites estabelecidos pelo sistema operacional. No entanto, aumenta consideravelmente a comunicação entre o host e o dispositivo, além de gastar mais tempo com a sincronização do processamento. Resolveu-se (a título de visualizar o quanto essa mudança influencia no desempenho da aplicação) utilizar uma plataforma de experimentação com duas GPUs, sendo uma dedicada ao sistema operacional e outra dedicada exclusivamente à execução da aplicação (cálculo da distribuição da densidade de ocupação). A partir dessa demanda, e juntamente com as demandas iniciais, foram definidas as versões da aplicação e as plataformas a serem experimentadas Experimentos e resultados Para avaliar a viabilidade do uso de GPUs em Visualização Científica, alguns experimentos foram realizados O ambiente experimental de execução do software Foram utilizadas quatro plataformas distintas para execução experimental do software construído. A primeira plataforma possui como componente fundamental o Intel Core i3 [44], uma CPU multicore de dois núcleos físicos e quatro núcleos lógicos, com a tecnologia Hyperthreading [45] da Intel. Nessa plataforma foram executadas as versões sequencial e paralela para CPU. A segunda plataforma tem como principal componente a GPU GT 620 [46], uma GPU com capacidades intermediárias, mas de custo relativamente menor, se comparadas com as GPUs mais avançadas do mercado atualmente. A terceira plataforma é composta pela GPU GTX 560 [47], que apresenta características superiores, como o número de núcleos e frequência de trabalho maiores, além de ser mais eficiente que o modelo anterior. Porém, o seu custo é cerca de 170% maior. Por fim, a quarta plataforma possui duas GPUs como componentes básicos. A primeira delas é a GPU GeForce 7600 GT, de menor capacidade mas cujas especificações não pertencem a este escopo, a qual ficou responsável apenas pelas tarefas

14 do sistema operacional (tais como o movimento de janelas, entre outras tarefas de processamento gráfico geral do computador). A segunda é uma GPU mais avançada (a mesma utilizada na terceira plataforma testada, ou seja, modelo GTX 560), que ficou responsável exclusivamente pela execução dos cálculos da aplicação (distribuição da densidade de ocupação). Esta última plataforma foi necessária para investigar o efeito de se reduzir o número de invocações de execução e comunicação de dados entre o host e o device, condição que seria minimizada com uso de uma GPU dedicada. As quatro plataformas de teste foram escolhidas por apresentarem características diferentes das CPUs ou GPUs nelas contidas, pela necessidade definida de se experimentar ambos os modelos de arquitetura, e também por apresentarem custos diferenciados. As principais características dessas plataformas podem ser visualizadas nas Tabelas 1 e 2 a seguir. Tabela 1: Resumo das características das GPUs utilizadas para o cálculo Características GT 620 GTX 560 Capacidade da memória global (MB) Tipo da memória global GDDR3 GDDR5 Frequência da memória global (MHz) Largura do barramento de acesso à memória global (bits) Taxa máxima de transferência (GB/s) 123,2 128 Número de núcleos Frequência dos núcleos (MHz) Taxa máxima de execução de operações de ponto flutuante (GFLOPS) CUDA Capacidade computacional (versão) Número máximo de threads por bloco Memória compartilhada por bloco (KB) Memória constante (KB) Número de registradores por bloco Ponto flutuante de precisão dupla Sim Sim Tabela 2: Características da CPU Características Intel Core i3 Número de cores 2 Número de threads 4 Frequência de clock (GHz) 2.3 Memória cache disponível (MB) 3 Conjunto de instruções 64- bit Máxima energia térmica de projeto - TDP (W) 35 Tamanho máximo de memória (GB) 16 Memória RAM disponível (GB) 4 Tipos de memória RAM DDR3-1066/1333 Número de canais de memória 2 Largura de banda máxima de memória (GB/s) 21,3

15 2.4.6 Carga de trabalho As cargas de trabalho utilizadas foram construídas tomando-se conjuntos de pontos amostrais tridimensionais, que representam as posições (latitude, altitude e altura em relação ao solo) onde os primatas foram observados, e os algoritmos de processamento desses dados, sendo o principal deles o método de cálculo da distribuição da intensidade de utilização da área de vida. Foram utilizados três conjuntos de dados amostrais, os quais podem ser observados na Tabela 3. O atributo número de pontos refere-se à quantidade de pontos amostrais contidos no conjunto. O atributo tamanho da matriz G gerada refere-se ao tamanho da matriz tridimensional necessária para abranger todos os pontos da amostra, correspondendo ao volume em m 3 do espaço a ser visualizado. Por fim, o atributo número de operações refere-se à quantidade de cálculos de contribuição que serão feitas, utilizando-se a Equação 1, para que a matriz tridimensional G seja totalmente preenchida com valores estimados de densidade de utilização. Conjunto de Dados Tabela 3: Conjuntos de dados utilizados Atributos Nº de pontos Tamanho da matriz G gerada (m 3 ) Conjunto x 468 x 23 Conjunto x 522 x 23 Conjunto x 2245 x 26 Número de Operações Resultados experimentais Para a experimentação, inicialmente fez-se a execução da versão sequencial para CPU na Plataforma 1 (Seq. i3). Em seguida, fez-se a execução da versão paralela para CPU utilizando a mesma plataforma (Par. i3). Na sequência, executou-se a versão paralela para GPU compartilhada nas Plataformas 2 e 3 (Par. GT 620 e Par. GTX 560). Por fim, executou-se a versão paralela para GPU dedicada à aplicação, na Plataforma 4 (Par. GTX 560 Ded.). Cada versão do programa foi executada 10 vezes na plataforma correspondente. Foi coletado, para cada experimento, o tempo gasto para o transporte dos dados para a GPU, bem como para o seu processamento e para o transporte dos dados para a memória principal do host, após o processamento. Tais tempos, referentes às execuções do cálculo de volume para os três conjuntos de dados, nas diferentes plataformas, podem ser observados na Tabela 4 e nas Figuras 5, 6 e 7.

16 Tabela 4: Tempos de reposta das execuções da aplicação Tempo médio de resposta para o Conjunto 1 Seq. i3 Par. i3 Par. GT 620 Par. GTX 560 Par. GTX 560 Ded. Mínimo 10,495 5,714 2,777 2,754 0,530 Médio 10,822 5,910 2,793 2,761 0,546 Máximo 11,419 6,299 2,808 2,778 0,592 Tempo médio de resposta para o Conjunto 2 Seq. i3 Par. i3 Par. GT 620 Par. GTX 560 Par. GTX 560 Ded. Mínimo 144,732 76,267 35,786 34,403 5,024 Médio 145,086 77,418 35,792 34,414 5,041 Máximo 145,407 84,104 35,802 34,439 5,071 Tempo médio de resposta para o Conjunto 3 Seq. i3 Par. i3 Par. GT 620 Par. GTX 560 Par. GTX 560 Ded. Mínimo 5552, , , ,795 92,950 Médio 5556, , , ,647 92,974 Máximo 5560, , , ,584 93,008 Tempo em segundos Seq. i3 Par. i3 Par. GT 620 Par. GTX 560 Par. GTX 560 Ded. Mínimo Médio Máximo Figura 5: Tempos de execução no Conj. 1 Tempo em segundos Seq. i3 Par. i3 Par. GT 620 Par. GTX 560 Par. GTX 560 Ded. Mínimo Médio Máximo Figura 6: Tempos de execução no Conj. 2

17 Tempo em segundos Seq. i3 Par. i3 Par. GT 620 Par. GTX 560 Par. GTX 560 Ded. Mínimo Médio Máximo Figura 7: Tempos de execução no Conj. 3 A Figura 5 apresenta o resumo dos tempos de execução para o conjunto amostral 1. Nesse conjunto, percebem-se reduções no tempo de execução de todas as plataformas em relação à primeira, tanto a que utiliza CPU quanto aquelas que utilizam GPU, no entanto as reduções são mais significativas nas plataformas que utilizam GPU. O uso do paralelismo em CPU gerou uma considerável redução nos tempos de execução para esse conjunto, em torno da metade do tempo gasto pela versão sequencial. Ainda assim, nas plataformas baseadas em GPU é que se notam os ganhos mais consideráveis em relação à versão sequencial em CPU. Dentre as execuções feitas em GPU, nota-se uma redução relativamente pequena dos tempos de resposta daquela feita sobre a GTX 560 sobre a GT 620, no entanto a execução feita utilizando-se uma GPU dedicada apresentou tempos de execução significativamente menores que as demais plataformas. Percebe-se ainda que é bem pequena a variação entre os valores mínimo, médio e máximo de tempo de execução da aplicação em cada plataforma, sobretudo naquelas baseadas em GPU, para as quais os três valores de medição são mais próximos entre si. Essa variação, por ser pequena, faz com que seja alta a probabilidade de que qualquer execução da aplicação sobre determinada plataforma apresente tempos de execução próximos aos valores médios dos resultados experimentais encontrados para cada conjunto. A Figura 6 apresenta o resumo dos tempos de execução para o conjunto amostral 2. Nesse conjunto, assim como na Figura 5, percebe-se a tendência da diminuição dos tempos de execução quando do uso de GPU, sobretudo com a utilização de GPU dedicada. Observa-se ainda uma distribuição bem equacionada dos valores mínimo, médio e máximo do tempo de execução, assim como aqueles apresentados na Figura 5. Isso evidencia o bom comportamento da aplicação em manter seus tempos de execução próximos a um valor médio, sem apresentar grandes desvios de tal valor. A distribuição acompanha uma curva bem similar à distribuição do conjunto amostral 1, com redução do tempo de execução para valores em torno da metade ao se confrontar os tempos de execução sequencial com o paralelo em CPU. Entre as plataformas baseadas em GPU, existe uma redução muito pequena das execuções na GTX 560 em relação às execuções na GT 620, enquanto a GTX 560 dedicada apresenta uma redução bem mais significativa, tanto em relação às plataformas baseadas em CPU quanto em GPU. A Figura 7 apresenta o resumo dos tempos de execução para o conjunto amostral 3. Existe, assim como nas Figuras 5 e 6, a tendência da diminuição dos tempos de execução quando do uso de GPU, principalmente com a utilização de GPU dedicada e, da mesma forma, é notado o bom comportamento da aplicação em manter seus tempos de execução bem próximos à média. Observa-se, nas suas devidas proporções, um comportamento bem semelhante à distribuição dos tempos de execução para o conjunto amostral 1 e 2.

18 A partir dos valores de tempos de execução de cada experimento, fez-se uma análise do ganho de desempenho (speedup) dos programas com código paralelo, em relação à versão sequencial rodando na CPU. Os valores de speedup podem ser visualizados na Tabela 5 e nas Figuras 8, 9 e 10 que seguem. Tabela 5: Ganhos de velocidade (speedup) das execuções da aplicação Speedup em relação Seq. i3 - Conjunto 1 Seq. i3 Par. i3 Par. GT 620 Par. GTX 560 Par. GTX 560 Ded. Mínimo 10,495 1,84 3,78 3,81 19,80 Médio 10,822 1,83 3,87 3,92 19,82 Máximo 11,419 1,81 4,07 4,11 19,29 Speedup em relação Seq. i3 - Conjunto 2 Seq. i3 Par. i3 Par. GT 620 Par. GTX 560 Par. GTX 560 Ded. Mínimo 144,732 1,90 4,04 4,21 28,81 Médio 145,086 1,87 4,05 4,22 28,78 Máximo 145,407 1,73 4,06 4,22 28,67 Speedup em relação Seq. i3 - Conjunto 3 Seq. i3 Par. i3 Par. GT 620 Par. GTX 560 Par. GTX 560 Ded. Mínimo 5552,198 1,87 8,31 8,69 59,73 Médio 5556,266 1,83 8,32 8,66 59,76 Máximo 5560,334 1,80 8,32 8,64 59,78 25,00 Speedup em unidades 20,00 15,00 10,00 5,00 0,00 Par. i3 Par. GT 620 Par. GTX 560 Par. GTX 560 Ded. Mínimo Médio Máximo Figura 8: Speedup das execuções no Conj. 1

19 35,00 Speedup em unidade 30,00 25,00 20,00 15,00 10,00 5,00 0,00 Par. i3 Par. GT 620 Par. GTX 560 Par. GTX 560 Ded. Mínimo Médio Máximo Figura 9: Speedup das execuções no Conj. 2 70,00 Speedup em unidades 60,00 50,00 40,00 30,00 20,00 10,00 0,00 Par. i3 Par. GT 620 Par. GTX 560 Par. GTX 560 Ded. Mínimo Médio Máximo Figura 10: Speedup das execuções no Conj. 3 Com a Figura 8 é possível observar os ganhos de desempenho para a execução da aplicação sobre o conjunto de dados 1. Nele observa-se a tendência do speedup em aumentar, quando da utilização de GPU em relação ao uso de CPU, sendo que a plataforma constituída de uma GPU dedicada é aquela que apresenta o maior ganho. Observa-se também a pequena variação entre os ganhos mínimo, médio e máximo, o que demonstra a estabilidade da aplicação no que se refere ao tempo execução para uma determinada carga de dados. Como se podia esperar, a partir da análise dos tempos de execução, o speedup alcançado com a execução paralela em CPU ficou em torno de 1,83, enquanto que o speedup alcançado com as execuções na GT 620 e na GTX 560 ficaram em torno de 3,87 e 3,92, respectivamente. O ganho mais significativo foi alcançado com a utilização da GTX 560 dedicada, cujo valor ficou em torno de 19,82. A Figura 9 apresenta os ganhos de desempenho para a execução da aplicação sobre o conjunto de dados 2, nas diferentes plataformas de código paralelo. Assim como na Figura 8, é bastante visível a tendência do speedup em aumentar, quando da utilização de GPU em relação ao uso de CPU, sobretudo com a GPU dedicada. No entanto, os ganhos permanecem próximos

20 ao da primeira amostra para execução paralela em CPU, em torno de 1,87, tiveram um pequeno aumento em relação às plataformas baseadas na GT 620 e na GTX 560, com valores em torno de 4,05 e 4,22, respectivamente. Seguindo a tendência da execução anterior, a execução utilizando a GTX 560 dedicada apresentou um ganho relativamente maior, com valor em torno de 28,78. A Figura 10 apresenta, enfim, os ganhos de desempenho obtidos na execução do conjunto 3. Ele apresenta, assim como os anteriores, a tendência do speedup em aumentar, quando da utilização de GPU. O ganho alcançado com uso de CPU paralelo permaneceu próximo aos alcançados com os outros conjuntos amostrais, enquanto aqueles conjuntos alcançados com as demais plataformas obtiveram resultados mais significativos, em torno de 8,32 e 8,66 para as plataformas baseadas na GT 620 e na GTX 560, respectivamente, além de valores em torno de 59,76 para a plataforma baseada na GTX 560 dedicada. Com os resultados obtidos, foram feitas algumas análises acerca dos pontos mais significativos observados nos resultados e tal análise é apresentada na subseção a seguir Análise dos resultados Os resultados mostram, de maneira geral, que as execuções feitas em paralelo apresentam resultados melhores que as execuções sequenciais, o que é comum e natural acontecer. No entanto, percebe-se que tais ganhos de desempenho são bem mais expressivos nas execuções em GPU que naquelas feitas em CPU, o que era esperado em vistas ao grande poder de processamento paralelo disponibilizado neste tipo de componente, fator que justificou sua escolha para a execução da aplicação desenvolvida neste estudo. O speedup máximo alcançado com a execução em CPU foi de 1,90. Por outro lado, obtevese a medida expressiva de 59,78 como speedup máximo para a GPU GTX 560 dedicada. Com a utilização da CPU, os tempos de resposta mantiveram-se praticamente iguais, com variações proporcionalmente insignificantes no tempo de resposta das versões sequencial e paralela, o que pode ser evidenciado com os valores de speedup iguais a um ou bem próximos desse valor. Já com a utilização das GPUs, significativos ganhos de desempenho foram observados, o que vai ao encontro dos objetivos do presente trabalho. Com relação à quantidade de dados em cada amostra utilizada na análise, os resultados da aplicação construída mostraram que, mesmo ao se utilizar uma carga de pontos significativamente maior, os tempos de resposta das execuções em GPU, sobretudo na GTX 560 dedicada, mantiveram-se proporcionalmente pequenos em relação às execuções das cargas menores, quando executadas em CPU (mesmo na execução paralela). Para corroborar a afirmativa anterior, citam-se dois exemplos: (i) o pior tempo de execução na GPU GTX 560 dedicada, para o Conjunto 2, é ainda menor que o tempo de execução da versão mais rápida em CPU, para o Conjunto 1; (ii) o pior tempo de execução na GPU GTX 560 dedicada, para o Conjunto 3, é da ordem de grandeza do tempo de execução da versão mais rápida em CPU para o Conjunto 2, mesmo em face do Conjunto 3 possuir uma quantidade de pontos aproximadamente 3 vezes maior e demandar uma quantidade de cálculos de contribuição cerca de 39 vezes maior que o Conjunto 2. Os casos apresentados são evidenciados na Tabela 6, nas células coloridas de mesma cor.

21 Tabela 6: Conjuntos de dados utilizados Pontos Células Número de cálculos de contribuição Menor tempo em CPU Maior tempo em GPU ded. Conjunto ,495 0,592 Conjunto ,732 5,071 Conjunto ,198 93,008 Os valores apresentados na Tabela 6 evidenciam que o uso de computação paralela com GPUs pode trazer ganhos significativos de desempenho e, ao mesmo tempo, consideráveis ganhos na qualidade dos resultados das aplicações de Visualização Científica, especificamente, pela possibilidade de se considerar, em tempo hábil, amostras de tamanhos maiores. Este estudo de caso definiu como objetivo fundamental aplicar Computação Paralela através de GPUs em aplicações de Visualização Científica, para o qual tomou-se como hipótese que tais aplicações podem ser executadas com tempos de resposta menores e com melhor qualidade de resultados que quando em plataformas baseadas em CPU, mesmo com a utilização de paralelismo. O objetivo foi alcançado satisfatoriamente e, conforme os resultados apresentados, a hipótese foi comprovada. Os resultados mostraram que as GPUs são, para o contexto abordado, uma alternativa viável às CPUs multicore. Conseguiu-se reduzir os tempos de resposta das aplicações em até 59,78 vezes e ainda manter a qualidade necessária dos resultados, com uso de um componente significativamente mais barato e com menor consumo de energia em relação ao uso de soluções clusterizadas, ou baseadas em computadores especialistas, de grande porte. Os objetivos secundários deste estudo de caso também foram alcançados. Com as reduções no tempo de execução das aplicações, obteve-se um software utilizável pelos pesquisadores em Zoologia dos Vertebrados, o que permite a complementação dos objetivos futuros propostos na pesquisa de [27]. Ao considerarem-se os resultados alcançados e o trabalho de [39], pode-se pressupor que os ganhos de desempenho podem ainda ser melhorados, uma vez que cada plataforma paralela possui características específicas, as quais precisam ser consideradas, por contribuírem para o desempenho das aplicações. Além disso, mostrou-se que alternativas que possibilitem menos comunicação entre os nós de processamento são mais prováveis de alcançarem maiores ganhos de desempenho, o que pode ser evidenciado com as melhorias nos resultados alcançados com a última plataforma utilizada, para qual os dados são enviados uma única vez durante a execução e existe uma quantidade menor de invocações. A plataforma CUDA utiliza as GPUs das placas gráficas como componente de processamento geral do computador. Para tanto, é necessário que o programador especifique, com sintaxe específica, os trechos de código que deseja enviar ao dispositivo, bem como fazer o gerenciamento das transferências de memória. CUDA provê as ferramentas necessárias e permite que as capacidades dos dispositivos sejam exploradas de maneira eficiente, porém exige que o desenvolvedor tenha um nível avançado de conhecimento, uma vez que é necessário especificar a forma como o trabalho será dividido entre os núcleos de processamento, os mecanismos de sincronização e transferência de dados, o que aumenta o grau de complexidade do desenvolvimento.

22 2.4.9 Trabalhos futuros As versões construídas da aplicação atenderam aos propósitos definidos neste estudo e possibilitaram demonstrar o potencial do uso de GPUs em Visualização Científica. No entanto, alguns trabalhos são vislumbrados como forma de evoluir a pesquisa. É necessário estudar e aplicar técnicas mais avançadas de computação gráfica para produzir imagens que representam a densidade de utilização do espaço de vida dos primatas de forma mais fluida e interativa, além de adaptar a aplicação para que ela se torne genérica a ponto de que seja possível utilizá-la no estudo da densidade de ocorrência de eventos discretos. Outra possibilidade seria a implementação da aplicação com base em outras plataformas de computação paralela, como OpenCL ou OpenAA, para analisar o comportamento da aplicação em relação ao desempenho, à qualidade dos resultados e à facilidade de desenvolvimento, quando da utilização dessas tecnologias. É importante também, como forma de evoluir a aplicação construída, propor e testar novos algoritmos paralelos que tornem mais eficientes, por exemplo, a divisão de trabalho entre os núcleos de processamento e o uso dos recursos computacionais disponibilizados. Por fim, propõe-se definir e implementar mecanismos de tomada de decisão que tornem a aplicação inteligente para escolher a forma como vai dividir o trabalho a ser realizado. Incluemse nesta escolha a definição do número de threads, da quantidade de blocos de threads e a seleção da porção de trabalho enviada para a GPU de cada vez, bem como a escolha do uso dos diferentes tipos de memória da placa gráfica, entre outros elementos, que podem desencadear uma utilização mais efetiva dos recursos disponíveis.

23 3. Estudo de Caso 2: Cálculo de Campos Elétricos Alguns problemas de cálculo de campos eletromagnéticos foram estudados e um deles, cujo modelo matemático é a Equação de Poisson (2) [49], foi selecionado para o desenvolvimento deste estudo de caso.. ( ε V ) = ρυ (2) Trata-se do cálculo do potencial eletrostático V distribuído em uma seção transversal quadrada de um oleoduto aterrado e parcialmente preenchido com um hidrocarboneto, cuja 3 densidade volumétrica de carga ρ é 10µ C m. A constante dielétrica, ou permissividade υ elétrica relativa ε r desse hidrocarboneto é 2,5. A outra metade do oleoduto está preenchida com ar ( ε r =1,0). Ar Hidrocarboneto ε r =1,0 ε r = 2,5 3 ρ υ = 10µC m Figura 11: Formulação do problema A Figura 11 ilustra o modelo do problema. Para solucioná-lo, emprega-se o Método de Elementos Finitos (FEM) em um domínio cúbico (1m 3 ) e Gradiente Conjugado na resolução do sistema matricial linear resultante. Esta é uma geometria que facilita a verificação dos resultados, entretanto, vale ressaltar que o FEM, geralmente, é adequado para se trabalhar em geometrias irregulares [6]. O programa NetGen [50] foi usado para modelar e discretizar a geometria do problema, utilizando-se o tetraedro como elemento finito. A Figura 12 apresenta uma discretização desse domínio. Ele foi seccionado transversalmente para que a superfície de interface entre os meios esteja visível. Observe que apenas os nós das condições de contorno, incluindo a interface entre os dois meios, estão visíveis. Ar Superfície de Interface Hidrocarboneto Paredes Aterradas Figura 12: Geometria discretizada do problema O problema de cálculo de campo elétrico 3D aqui descrito possui características intrínsecas que são consideradas no desenvolvimento dos programas deste estudo de caso. Estas características serão apresentadas a seguir.

24 3.1 Características do Método de Elementos Finitos O Método de Elementos Finitos é um método numérico que resolve, por aproximação, equações integrais ou diferenciais, como é o caso da Equação (2). Ele é composto por quatro etapas [49]: Discretização do domínio, ou região de solução, em elementos finitos; Aplicação do modelo matemático que descreve o problema a ser resolvido a cada um dos elementos previamente definidos; Montagem da matriz de coeficientes globais considerando a contribuição de cada um dos elementos e a montagem do vetor de termos independentes; Resolução do sistema matricial linear resultante. O sistema linear resultante das fases de aplicação do modelo matemático e da montagem da matriz de coeficientes, incluindo a montagem do vetor de termos independentes, possui a seguinte forma matricial: [ ][ x] [ b] A = (3) Onde [ A ] é a matriz de coeficientes globais; [ x ] é o vetor de incógnitas; [ ] b é o vetor de termos independentes. A matriz [ A ] que compõe a Equação (3) produzida pelo FEM possui as seguintes propriedades: é uma matriz onde todos os elementos que compõem a matriz são números reais; É quadrada, ou seja, o número de linhas é igual ao número de colunas; É não singular, ou seja, existe uma matriz [ A ] tal que[ A][ A] = [ I] = [ A] [ A], onde [ I ] é a matriz identidade e [ A ] 1 é a matriz inversa de [ A ]; É simétrica, [ A ] = [ A] T, onde [ A ] T é a matriz transposta; É definida positiva, [ x] T [ A][ x] > 0 [ x] 0, onde [ x ] é um vetor coluna não nulo e [ x ] T seu respectivo vetor linha; É esparsa, a maioria dos coeficientes de [ A ] são nulos. Do ponto de vista computacional, uma das características mais relevantes da matriz [ A ] é, sem dúvida, a esparsidade. Esta característica influencia os métodos numéricos, tanto na redução da quantidade de memória necessária para armazenar a matriz, quanto na redução do número de instruções executadas. Os métodos de resolução de sistemas lineares podem ser classificados como diretos ou iterativos [49]. Os métodos diretos, tais como Gauss, Gauss-Jordan, Cholesky e Chokesky- Crout, baseiam-se na eliminação de variáveis por meio de operações simples, envolvendo as equações do sistema linear. Esses métodos não conseguem tirar proveito da esparsidade da matriz de coeficientes [5], pois o processo de eliminação de variáveis tende a tornar a matriz de coeficientes densa. Os métodos Jacobi, Gauss-Seidel e Gradiente Conjugado são exemplos de métodos iterativos que fazem aproximações sucessivas do resultado de um sistema linear. A seguir, o método Gradiente Conjugado será apresentado e suas principais características serão brevemente descritas. 3.2 Características do Gradiente Conjugado O método iterativo Gradiente Conjugado foi proposto por [5] e possui as seguintes vantagens computacionais, em relação aos métodos diretos: Baixo consumo de memória, quando a matriz de coeficientes é esparsa; A matriz de coeficientes não é alterada, reduzindo a manipulação de dados; A cada iteração, o método obtém uma aproximação melhor da solução do sistema linear.

25 O Algoritmo Gradiente Conjugado é apresentado na Figura 13; onde: x! é a solução inicial arbitrária (geralmente, utiliza-se o vetor zero); r! é o erro residual em relação à solução inicial escolhida; b é o vetor de termos independentes; e A é a matriz de coeficientes. Cabe observar que a operação de maior custo computacional neste algoritmo é a multiplicação matriz-vetor. x solução inicial arbitrária r b Ax 0 0 P r 0 k 0 repetir r r α k p x r k + 1 k + 1 r β p k 0 k + 1 k + 1 imprimir T k k T k Apk x + α p k 0 k r + α Ap r T k + 1 k + 1 T rk rk k + 1 k k + 1 até r ser desprezível x k r k k k k k + β p k Figura 13: Algoritmo Gradiente Conjugado 3.3 Placas Gráficas Utilizadas e Suas Principais Características Três placas gráficas da NVIDIA foram selecionadas: a GTX260 do fabricante Gainward (Figura 14); a 9600GT do fabricante MSI (Figura 15); e a GT240 do fabricante XFX (Figura 16). Figura 14: GTX260 (fonte: Figura 15: 9600GT (fonte: Figura 16: GT240 (fonte: As principais características das placas gráficas selecionadas são suficientemente diferentes, tornando-as adequadas ao desenvolvimento deste estudo de caso. A Tabela 7 apresenta um comparativo dessas características.

26 Tabela 7: Características de arquitetura das placas gráficas Característica GTX GT GT 240 Capacidade da Memória Global (MiB) Tipo da Memória Global GDDR3 GDDR3 GDDR3 Freqüência da Memória Global (MHz) Largura do Barramento de Acesso a Memória Global (bits) Taxa Máxima de Transferência (GB/s) 123,2 89,6 51,2 Número de Núcleos Freqüência dos Núcleos (MHz) Taxa Máxima de Execução de Operações de ,6 105,6 Ponto Flutuante (GFLOPS) CUDA Compute Capability Número Máximo de Threads por Bloco Memória Compartilhada por Bloco (KiB) Memória Constante (KiB) Número de Registradores por Bloco Ponto Flutuante de precisão Dupla Sim Não Não 3.4 Codificações Desenvolvidas A pesquisa de [11] codificou dois programas para o cálculo do Gradiente Conjugado: um sequencial (SFEM.exe); e outro paralelo (PFEM.exe) para ser executado em clusters de computadores. Esses programas serviram de base para oito novos programas resultantes das codificações desenvolvidas neste estudo. Sete codificações (Cod1 a Cod7), usando CUDA, foram desenvolvidas na geração desses programas com o objetivo de maximizar o desempenho computacional do método Gradiente Conjugado. A relação entre os programas e essas codificações é apresentada na Figura 17. GPUSText SpGPUGlbAld Cod1 Cod6 SFEM [Camargos e outros 2009] PFEM [Camargos e outros 2009] Cod2 SpGPUGlb SpSeq Cod3 Cod7 Cod4 SpGPUSText Cod5 SpGPUMText Cod2 Sp12pCluster SymSpSeq Figura 17: Correlação entre os programas e as codificações desenvolvidas As codificações exploram algumas características do problema e/ou algumas características das arquiteturas das plataformas de computação utilizando-se certas funcionalidades. A Tabela 8 correlaciona codificações e funcionalidades relativas às características. Procurou-se explorar o maior número de variações possíveis com as sete codificações desenvolvidas.

27 Tabela 8: Relação entre codificações e funcionalidades utilizadas nos programas Funcionalidades Aplicadas Cod1 Cod2 Cod3 Cod4 Cod5 Cod6 Cod7 CUDA Threads X X X X X Memória Shared X X X Memória Global X X Acesso Alinhado a X Memória Global Uma associação à X X Memória Texture 2D Quatro associações à X Memória Texture 2D Registradores X X X X X Esparsidade X X X X X X Simetria X Cod1 aplica apenas funcionalidades relacionadas com as características de arquitetura das placas gráficas. Em contrapartida, Cod2 e Cod7 aplicam apenas funcionalidades relacionadas com as características do problema. As demais codificações (Cod3 a Cod6) aplicam funcionalidades relacionadas com características do problema e características de arquitetura das placas gráficas. Conforme já mencionado, a característica mais relevante do problema resolvido por estas codificações é a esparsidade da matriz de coeficientes. Portanto, o emprego da estrutura de dados esparsos, apresentada na Figura 18, possibilitou ganhos expressivos no desempenho das codificações. Os campos elements e cols armazenam os coeficientes e seus índices de coluna da matriz esparsa original. Estes campos são transferidos para a GPU e são armazenados em vetores com dimensão múltipla de 16, garantindo acesso alinhado aos dados. A grande maioria dos coeficientes, cujo valor é zero, é descartada. typedef struct { float *elements; unsigned int *cols; unsigned int numberofelements; unsigned int maxelements; unsigned int maxrows; unsigned int maxcols; bool issymmetric; } SparseMatrix; Figura 18: Estrutura de dados esparsos 3.5 Experimentos realizados As codificações foram baseadas nos programas SFEM e PFEM [11]. Entretanto, as versões para GPU sofreram mudanças significativas, especialmente nas rotinas que codificam o algoritmo Gradiente Conjugado. Todos os programas, inclusive os desenvolvidos por [11], estão organizados em três estágios de processamento, conforme ilustrado na Figura 19. O terceiro estágio, responsável pela resolução do sistema matricial linear montado no estágio anterior, é o alvo das codificações paralelas deste estudo de caso, pois ele é responsável pela maior parte do tempo de processamento dos programas sequenciais. Cada experimento foi realizado 10 vezes para possibilitar o tratamento estatístico dos tempos de execução. Os tempos médios (média

28 aritmética) de execução foram contabilizados para cada um dos estágios de processamento apresentados na Figura 19. 1º Estágio 2º Estágio 3º Estágio Leitura dos Dados Montagem do Sistema Linear (FEM) Gradiente Conjugado (Método Iterativo) Disco Rígido Figura 19: Estágios de processamento dos programas desenvolvidos A Tabela 9 apresenta os experimentos (Exp) realizados. Os experimentos Exp1 e Exp2 (ambos em negrito), inicialmente executados por [11], foram executados novamente para obterse a contabilização dos tempos gastos em cada um dos estágios de processamento. Os dados de entrada são as malhas, MS1 a MS6, da geometria do problema em vários níveis de refinamento que foram geradas utilizando-se o programa Netgen. Tabela 9: Experimentos realizados nesta pesquisa Exp Programa Dados de Entrada Plataforma de Execução 1 SFEM MS1, MS2, MS3, MS4 Quad-Core 2.3GHz, 2GiB RAM 2 PFEM MS1, MS2, MS3, MS4 Cluster 12 Pentium IV 3GHz, 1.25GiB RAM 3 GPUSText MS1, MS2, MS3, MS4 9600GT, GT240, GTX260 (Quad-Core 2.3GHz, 2GiB RAM) 4 SpSeq MS1, MS2, MS3, MS4, MS5, MS6 Quad-Core 2.3GHz, 2GiB RAM 5 Sp12pCluster MS1, MS2, MS3, MS4 Cluster 12 Pentium IV 3GHz, 1.25GiB RAM 6 SymSpSeq MS1, MS2, MS3, MS4, MS5, MS6 Quad-Core 2.3GHz, 2GiB RAM 7 SpGPUGlb MS1, MS2, MS3, MS4, MS5, MS6 9600GT, GT240, GTX260 (Quad-Core 2.3GHz, 2GiB RAM) 8 SpGPUSText MS1, MS2, MS3, MS4 9600GT, GT240, GTX260 (Quad-Core 2.3GHz, 2GiB RAM) 9 SpGPUMText MS1, MS2, MS3, MS4, MS5, MS6 9600GT, GT240, GTX260 (Quad-Core 2.3GHz, 2GiB RAM) 10 SpGPUGlbAld MS1, MS2, MS3, MS4, MS5, MS6 9600GT, GT240, GTX260 (Quad-Core 2.3GHz, 2GiB RAM) A Tabela 10 apresenta os dados das malhas. Cada uma dessas malhas responde proporcionalmente pelo tamanho do sistema matricial que é gerado pela aplicação do FEM.

29 Tabela 10: Dados de entrada utilizados nos experimentos desta pesquisa Nós Fixos Elementos Malhas Nós (Condições de Contorno) (tetraedros) MS MS MS MS MS MS As informações das matrizes de coeficientes desses sistemas lineares são apresentadas na Tabela 11. As malhas MS1 a MS4 são as mesmas utilizadas por [11]. Malhas Tabela 11: Dados das matrizes de coeficientes Dimensão Fator de Coeficientes (n) Condicionamento Não Nulos (nnz) MS , MS , MS , MS , MS , MS , A Tabela 12 apresenta os dados da matriz Thermal2. Esta matriz foi utilizada apenas para análise de tendência do programa que apresentou melhor desempenho computacional durante os experimentos. Essa matriz foi gerada a partir de um problema de termodinâmica proposto pelo grupo de pesquisa Schmid. O sistema linear resultante desse problema está disponível na coleção de matrizes esparsas da Universidade da Florida [51]. Os resultados obtidos a partir desse sistema linear foram aferidos utilizando-se a codificação do Gradiente Conjugado (função PCG) disponível no Matlab R2008b. Tabela 12: Dados da matriz de coeficientes Thermal2 Nome Dimensão (n) Fator de Condicionamento Coeficientes Não Nulos Thermal ,6x A matriz Thermal2, como se pode observar pela Tabela 12, representa o maior sistema linear experimentado. Para tanto, uma versão modificada do programa de melhor desempenho computacional foi desenvolvida alterando-se o 1º estágio de processamento para permitir a leitura da matriz de coeficientes e do vetor [ b ] que compõem esse sistema linear, removendo-se o 2º estágio de processamento, pois esta etapa é desnecessária para processar Thermal2. Também foi desenvolvida uma versão com essas mesmas modificações do programa SpSeq.EXE, para permitir o cálculo de speedup.

30 3.6 Resultados Experimentais Os resultados apresentados utilizam como métricas os tempos de execução e os speedups. Adicionalmente, serão utilizadas duas métricas aplicáveis às GPUs [24], que são: número de operações de ponto flutuante por segundo, ou Giga Float Point Operations Per Second (GFLOPS); e a taxa de transmissão de dados entre a memória global da placa gráfica e a GPU (em GB/s); Resultados dos experimentos Exp1, Exp2 e Exp3 A Tabela 13 apresenta os tempos de execução do programa SFEM (Exp1) em um computador Quad-Core. Esses tempos serão usados como referência de tempo seqüencial para o cálculo de speedup. Tabela 13: Tempos de execução em segundos do programa SFEM Malha / Iterações do CG 1º Estágio 2º Estágio 3º Estágio (CG) Total MS1 / 130 0, , , ,506 MS2 / 184 0, , , ,571 MS3 / 307 0, , , ,264 MS4 / 432 0, , , ,422 A Tabela 14 apresenta os tempos de execução do programa PFEM (Exp2) em um cluster 6 com 12 computadores Pentium IV. A Malha MS4 não convergiu com precisão de 1 10, devido à instabilidade numérica gerada pela utilização da técnica de decomposição de domínio (Domain Decomposition). Tabela 14: Tempos de execução em segundos do programa PFEM Malha / Iterações do CG 1º Estágio 2º Estágio 3º Estágio (CG) Total MS1 / 128 0, , , , MS2 / 166 0, , , , MS3 / 276 0, , , , MS4 / A Tabela 15 apresenta os tempos de execução do programa GPUSText (Exp3), que leva em consideração apenas características da plataforma de computação para GPGPU. O programa GPUSText foi desenvolvido com base no programa SFEM e apenas o Gradiente Conjugado foi paralelizado. A Figura 20 mostra a distribuição do tempo de processamento do programa SFEM ao processar a malha MS4.

31 Tabela 15: Tempos de execução em segundos do programa GPUSText GPU Malha / Iterações do CG 1ºEstágio 2ºEstágio 3ºEstágio (CG) Total 9600GT GTX260 GT240 MS1 / 128 0, , , , MS2 / 165 0, , , , MS3 / 276 0, , , , MS4 / 376 0, , , , MS1 / 128 0, , , , MS2 / 165 0, , , , MS3 / 276 0, , , , MS4 / 376 0, , , , MS1 / 128 0, , , , MS2 / 165 0, , , , MS3 / 276 0, , , , MS4 / 376 0, , , , % 6.661% Tempos de Execução Sequencial Leitura dos Dados Montagem do Sistema Linear Gradiente Conjugado % Figura 20: Perfil de execução de SFEM para a malha MS4 A Figura 21 apresenta os speedups totais obtidos por PFEM e GPUSText executados no cluster e nas GPUs, respectivamente. Figura 21: Speedup dos programas PFEM e GPUSText (ref. SFEM) Como se pode observar, o cluster possui desempenho superior a todas as GPUs, exceto para o caso de MS1 processada pela GTX260. O speedup total teórico possui um comportamento diferente para a malha MS4, em relação às demais malhas. Essa diferença se deve ao impacto da montagem do sistema matricial linear (2º estágio de processamento) no tempo total de execução. Na tentativa de compreender esse comportamento, a Figura 22 apresenta a ordem de grandeza do consumo de memória para cada malha executada no programa SFEM.

32 Figura 22: Consumo de memória (MB) do programa SFEM Percebe-se claramente o consumo excessivo de memória no caso de MS4, impactando negativamente a hierarquia de memória do Quad-Core e, consequentemente, acarretando a degradação do desempenho do sistema. Comparando-se os tempos gastos durante os 1º e 2º estágios dos programas SFEM, PFEM e GPUSText (Tabela 13, Tabela 14 e Tabela 15, respectivamente), percebe-se uma clara vantagem do uso de clusters de computadores associados com a técnica de decomposição de domínio. No caso do cluster de 12 computadores (PFEM), o consumo de memória em cada processador cai para aproximadamente 1 12 do consumo total de SFEM, eliminando, com isso, os efeitos negativos na hierarquia de memória. É importante notar que, no caso do Cluster, os 1º e 2º estágios também são executados em paralelo, o que torna o speedup total teórico apresentado na Figura 21 inadequado. Portanto, teoricamente, poderia se esperar um speedup ainda maior no caso de clusters de computadores. Como os 1º e 2º estágios são praticamente iguais em SFEM e em GPUSText, esperava-se que o desempenho de GPUSText fosse melhor ao processar MS3, comparado com o processamento de MS2. Entretanto, isso não se observou na prática (Figura 21). A explicação está no tamanho da memória Global das placas gráficas (512MiB para 9600GT e GT240; 892MiB para GTX260), que não comportam os sistemas lineares obtidos de MS3 e MS4. Nesses casos, foi necessário transferir, da memória Host para a memória Global, fragmentos da matriz de coeficientes a cada iteração do Gradiente Conjugado, degradando, com isso, o desempenho de GPUSText. A análise de Exp1, Exp2 e Exp3 evidenciou a necessidade de se reduzir a manipulação (transferências, leituras e escritas) dos dados para se obter ganhos expressivos de desempenho em GPGPU. Para tanto, decidiu-se levar em consideração a esparsidade das matrizes de coeficientes Resultados dos experimentos Exp4, Exp5 e Exp6 Todos os outros programas que serão analisados a partir desta seção possuem estrutura de dados otimizada para matrizes esparsas, permitindo a resolução de sistemas matriciais lineares maiores. Portanto, MS5 e MS6 passaram a ser experimentadas, exceto em Sp12pCluster, por demandar uma etapa de pré-processamento mais complexa e não ser o foco desta pesquisa, e em SpGPUSText, por utilizar apenas uma única textura 2D, cuja largura máxima (65536 bytes [24]) não é suficiente para comportar essas malhas. A Tabela apresenta os tempos de execução do programa SpSeq (Exp4), que é essencialmente o mesmo programa SFEM, exceto pela codificação de uma estrutura de dados otimizada para matrizes esparsas.

33 Tabela 16: Tempos de execução em segundos do programa SpSeq Malha / Iterações do CG 1º Estágio 2º Estágio 3º Estágio (CG) Total MS1 / 139 0, , , , MS2 / 184 0, , , , MS3 / 306 0, , , , MS4 / 430 0, , , , MS5 / 340 0, , , , MS6 / 236 0, , , , A Figura 23 mostra, em escala logarítmica, o consumo de memória do programa SpSeq. Figura 23: Consumo de memória (MB) do programa SpSeq 2 A economia de memória, no caso de MS4, é da ordem de 1 10 referente ao consumo de memória de SFEM (Figura 22). Logo, a manipulação de dados é reduzida drasticamente. A codificação de Sp12pCluster permite uma comparação mais justa do desempenho do cluster em relação ao de SpSeq. A malha MS4, assim como em PFEM (Tabela 14), não convergiu com 6 precisão de 1 10 devido à instabilidade numérica. No caso de SymSpSeq, a simetria da matriz de coeficientes foi considerada. Entretanto, conforme mencionado por [28], a simetria não foi explorada pelos programas para GPUs por exigir sincronização excessiva entre threads para evitar acessos concorrentes a uma mesma posição de memória. As Tabelas 17 e 18 apresentam os tempos de execução dos programas Sp12pCluster (Exp5) e SymSpSeq (Exp6). Tabela 17: Tempos de execução em segundos do programa Sp12pCluster Malha / Iterações do CG 1º Estágio 2º Estágio 3º Estágio (CG) Total MS1 / , , , MS2 / 166 0, , , , MS3 / 276 0, , , , MS4 / Tabela 18: Tempos de execução em segundos do programa SymSpSeq Malha / Iterações do CG 1º Estágio 2º Estágio 3º Estágio (CG) Total MS1 / 130 0, , , , MS2 / 183 0, , , , MS3 / 305 0, , , , MS4 / 433 0, , , , MS5 / 340 0, , , , MS6 / 235 0, , , ,544783

34 A Figura 24 apresenta os speedups totais obtidos pelos programas PFEM, Sp12pCluster, SpSeq e SymSpSeq relativos à SFEM. Figura 24: Speedup de PFEM, Sp12pCluster, SpSeq e SymSpSeq (ref. SFEM) Percebe-se o desempenho computacional obtido pela codificação da estrutura de dados esparsos ao se constatar que os tempos de execução obtidos por SpSeq e SymSpSeq, ambos executados em um Quad-Core, são inferiores aos obtidos por PFEM e Sp12pCluster, que foram executados em um Cluster de 12 computadores Pentium IV. Percebe-se, também, que os 1º e 2º estágios são limitadores de desempenho dos programas seqüenciais. O limitador de desempenho dos programas paralelos para cluster é o 3º estágio (Gradiente Conjugado), devido à necessidade de compartilhamento de informações sobre os nós de fronteira entre os subdomínios. Além disso, a estrutura de dados otimizada para matrizes esparsas não contribuiu para uma melhora expressiva no caso de Sp12pCluster, pois quando a decomposição de domínio é feita, os subdomínios possuem menos elementos, tornando a estrutura de dados esparsos menos atrativa Resultados dos experimentos Exp7, Exp8, Exp9 e Exp10 As Tabelas 19 a 21 apresentam os tempos de execução dos programas SpGPUGlb (Exp7), SpGPUSText (Exp8) e SpGPUMText (Exp9), respectivamente.

35 Tabela 19: Tempos de execução em segundos do programa SpGPUGlb GPU Malha / Iterações do CG 1º Estágio 2º Estágio 3º Estágio (CG) Total 9600GT GTX260 GT240 MS1 / 128 0, , , , MS2 / 165 0, , , , MS3 / 276 0, , , , MS4 / 375 0, , , , MS5 / 306 0, , , , MS6 / 221 0, , , , MS1 / 128 0, , , , MS2 / 165 0, , , , MS3 / 276 0, , , , MS4 / 375 0, , , , MS5 / 306 0, , , , MS6 / 221 0, , , , MS1 / 128 0, , , , MS2 / 165 0, , , , MS3 / 276 0, , , , MS4 / 375 0, , , , MS5 / 306 0, , , , MS6 / 221 0, , , , Tabela 20: Tempos de execução em segundos do programa SpGPUSText GPU Malha / Iterações do CG 1ºEstágio 2ºEstágio 3ºEstágio (CG) Total 9600GT GTX260 GT240 MS1 / 128 0, , , , MS2 / 165 0, , , , MS3 / 276 0, , , , MS4 / 376 0, , , , MS1 / 128 0, , , , MS2 / 165 0, , , , MS3 / 276 0, , , , MS4 / 376 0, , , , MS1 / 128 0, , , , MS2 / 165 0, , , , MS3 / 276 0, , , , MS4 / 376 0, , , ,984249

36 Tabela 21: Tempos de execução em segundos do programa SpGPUMText GPU Malha / Iterações do CG 1º Estágio 2º Estágio 3º Estágio (CG) Total 9600GT GTX260 GT240 MS1 / 128 0, , , , MS2 / 165 0, , , , MS3 / 276 0, , , , MS4 / 375 0, , , , MS5 / 306 0, , , , MS6 / 221 0, , , , MS1 / 128 0, , , , MS2 / 165 0, , , , MS3 / 276 0, , , , MS4 / 375 0, , , , MS5 / 306 0, , , , MS6 / 221 0, , , , MS1 / 128 0, , , , MS2 / 165 0, , , , MS3 / 276 0, , , , MS4 / 375 0, , , , MS5 / 306 0, , , , MS6 / 221 0, , , , Por fim, a Tabela 22 apresenta os tempos de execução do programa SpGPUGlbAld (Exp10), que é essencialmente SpGPUGlb, exceto por uma pequena alteração na alocação da matriz de coeficientes, que resulta no acesso alinhado à memória Global da GPU por parte das threads que compõem o programa. Tabela 22: Tempos de execução em segundos do programa SpGPUGlbAld GPU Malha / Iterações do CG 1º Estágio 2º Estágio 3º Estágio (CG) Total 9600GT GTX260 GT240 MS1 / 128 0, , , , MS2 / 165 0, , , , MS3 / 276 0, , , , MS4 / 375 0, , , , MS5 / 306 0, , , , MS6 / 221 0, , , , MS1 / 128 0, , , , MS2 / 165 0, , , , MS3 / 276 0, , , , MS4 / 375 0, , , , MS5 / 306 0, , , , MS6 / 221 0, , , , MS1 / 128 0, , , , MS2 / 165 0, , , , MS3 / 276 0, , , , MS4 / 375 0, , , , MS5 / 306 0, , , , MS6 / 221 0, , , , As diferentes características das plataformas de computação que utilizam GPU foram responsáveis pelas variações obtidas nos tempos de processamento apresentados nessas tabelas, principalmente em relação ao terceiro estágio de processamento (Gradiente Conjugado). Observa-se, também, como uma pequena alteração na alocação da estrutura de dados esparsos (Cod6, Tabela 8), produziu os menores tempos de execução em todas as plataformas de computação experimentadas, devido a uma mudança no padrão de acesso aos dados na memória Global por parte das threads que compõem o Kernel executado nas GPUs.

37 A Figura 25 apresenta os speedups totais obtidos pelos programas esparsos para GPU relativamente a SpSeq. 6 5 Speedup Total MS1 MS2 MS3 MS4 MS5 MS6 Teórico SymSpSeq SpGPUGlb (9600GT) SpGPUGlb (GT240) SpGPUGlb (GTX260) SpGPUSText (9600GT) SpGPUSText (GT240) SpGPUSText (GTX260) SpGPUMText (9600GT) SpGPUMText (GT240) SpGPUMText (GTX260) SpGPUGlbAld (9600GT) SpGPUGlbAld (GT240) SpGPUGlbAld (GTX260) Figura 25: Speedup dos progr. esparsos para GPU e SymSpSeq (ref. SpSeq) O fator limitante previsto pela lei de Amdhal, representado pelo speedup total teórico, se faz notar, pois os 1º e 2º estágios de processamento não são paralelizados nos programas para GPU e o 3º estágio passou a ter menos relevância no tempo total de execução, conforme pode ser visto comparando-se a Figura 20 com a Figura 26. Tempos de Execução Seqüencial Esparso 5.756% % Leitura dos Dados Montagem do Sistema Linear Gradiente Conjugado % Figura 26: Perfil de execução de SpSeq para MS4, que possui incógnitas Observando-se, ainda, a Figura 25, percebe-se que o speedup total não consegue representar o desempenho computacional das placas gráficas. Uma análise descuidada, pode inclusive concluir que o desempenho das GPUs está piorando com o aumento das malhas, mas isso não é verdadeiro. Para evidenciar o desempenho computacional das GPUs, é necessário calcular o speedup do Gradiente Conjugado, em vez do speedup total, removendo da análise o fator limitante de desempenho previsto pela lei de Amdahl. A Figura 27 mostra esses speedups relativos ao programa SpSeq.

38 Speedup CG MS1 MS2 MS3 MS4 MS5 MS6 SpGPUGlbAld (GTX260) SpGPUGlb (GTX260) SpGPUMText (GTX260) SpGPUSText (GTX260) SpGPUGlbAld (9600GT) SpGPUGlb (9600GT) SpGPUMText (9600GT) SpGPUSText (9600GT) SpGPUGlbAld (GT240) SpGPUGlb (GT240) SpGPUMText (GT240) SpGPUSText (GT240) Figura 27: Speedup (CG) dos programas esparsos para GPU (ref.: SpSeq) Analisando a Figura 27, é possível perceber a importância de se considerar as características das arquiteturas das plataformas de computação que utilizam GPU durante o processo de desenvolvimento de programas para GPGPU. Mesmo sabendo que o potencial computacional da GTX260 é superior ao da 9600GT, o desempenho de SpGPUGlbAld processando MS4 na placa 9600GT foi superior ao desempenho de SpGPUSText processando a mesma malha na placa GTX260. As otimizações implementadas em SpGPUGlbAld potencializaram o desempenho da placa 9600GT. Comparando a Figura 27 com a Figura 25, percebe-se o risco de uma conclusão errônea quando se utiliza apenas o speedup como métrica de desempenho durante uma análise. O cálculo do número de operações de ponto flutuante por segundo contribui para o enriquecimento da análise de desempenho. A Figura 28 apresenta o desempenho dos programas para GPU, segundo essa métrica.

39 3 2,5 GFLOPS CG 2 1,5 1 0,5 0 MS1 MS2 MS3 MS4 MS5 MS6 SpGPUGlbAld (GTX260) SpGPUGlb (GTX260) SpGPUMText (GTX260) SpGPUSText (GTX260) SpGPUGlbAld (9600GT) SpGPUGlb (9600GT) SpGPUMText (9600GT) SpGPUSText (9600GT) SpGPUGlbAld (GT240) SpGPUGlb (GT240) SpGPUMText (GT240) SpGPUSText (GT240) Figura 28: GFLOPS (CG) dos programas esparsos para GPU Os valores apresentados na Figura 28 foram calculados com base nas operações executadas durante o Gradiente Conjugado, ou seja, quatro produtos escalares (dot product) e um produto matriz-vetor. Cada produto escalar corresponde a 2 n operações de ponto flutuante, sendo n a dimensão dos vetores, que corresponde ao número de nós livres da malha que deu origem ao sistema linear. O produto matriz-vetor corresponde a 2 nnz operações de ponto flutuante, sendo nnz o número de elementos não nulos (number of non-zeros) da matriz de coeficientes do sistema linear. As informações das matrizes de coeficientes desses sistemas lineares são apresentadas na Tabela 11. As malhas MS1 a MS4 são as mesmas utilizadas por [11]. Tabela 11 apresenta os valores de n e nnz para cada uma das malhas. Portanto, o cálculo de GFLOPS do Gradiente Conjugado é dado pela Equação (4). GFLOPS CG (8 n + 2 nnz) I = T CG (4) Em (4), I é o número de iterações do Gradiente Conjugado e T CG é o tempo de execução do Gradiente Conjugado, considerando os tempos de transferência do sistema linear da memória Host para a memória Global e de transferência do resultado no sentido contrário. Comparando-se os GFLOPS obtidos com o máximo teórico ( TEPF max ) das GPUs, percebese que algo está limitando o desempenho dos programas. Entretanto, esses valores teóricos também não são boas referências quando observados isoladamente. É preciso considerar as limitações decorrentes da taxa de transferência de dados entre a memória Global e os CUDA

40 Cores (Stream Processors - SP). As limitações impostas pelas características do problema que se está resolvendo também devem ser consideradas. Supondo que seja necessário, em média, transferir 4 bytes (são necessários 4 bytes para representar um número de ponto flutuante de precisão simples) por operação de ponto flutuante, percebe-se que TEPF fica limitada a TT 4. max max Em uma aplicação típica, cada operação básica de ponto flutuante exige a transferência de 3 números de ponto flutuante (leitura de2 valores e escrita de 1 resultado), equivalendo a 12 bytes transferidos. Com isso, TEPF max seria limitada a TT max 12 e corresponderia a 10, 27 GFLOPS (GTX 260), 7, 47 GFLOPS (9600 GT) e 4, 27 GFLOPS (GT 240). Portanto, o desempenho das placas gráficas é severamente limitado pela razão FLOP [2]. Bytes transferid os Observa-se que para atingir todo o potencial das placas gráficas é preciso executar o maior número de operações possíveis com cada dado lido/escrito na memória. Em [15] é proposta uma estratégia para diminuir a quantidade de dados transferidos e, consequentemente, aumentar o desempenho computacional de um programa que codifica o método Gradiente Conjugado Pré- Condicionado. Esta estratégia não foi aplicada nesta pesquisa, portanto existe a possibilidade de uma melhora nos resultados aqui apresentados. A Figura 29 apresenta as taxas de transferência obtidas pelos programas para GPU. Como o barramento de acesso à memória é um fator limitador de desempenho, essa métrica também é importante na análise de desempenho GB\s MS1 MS2 MS3 MS4 MS5 MS6 SpGPUGlbAld (GTX260) SpGPUGlb (GTX260) SpGPUMText (GTX260) SpGPUSText (GTX260) SpGPUGlbAld (9600GT) SpGPUGlb (9600GT) SpGPUMText (9600GT) SpGPUSText (9600GT) SpGPUGlbAld (GT240) SpGPUGlb (GT240) SpGPUMText (GT240) SpGPUSText (GT240) Figura 29: Taxa de transferência de dados dos programas esparsos para GPU É importante observar que os dados apresentados nas Figuras 28 e 29 são aproximações teóricas ou analíticas das operações, desconsiderando-se as operações auxiliares presentes nos programas e considerando-se os tempos de transferência de dados entre Host e Device (barramento PCI Express). Se essas operações forem consideradas e os tempos de transferência desconsiderados, as métricas de GFLOPS e taxa de transferência podem ficar inflacionadas. Portanto, para uma análise de desempenho adequada, é preciso considerar todas as métricas aqui apresentadas: tempos de execução; speedups; GFLOPS; e taxa de transferência.

41 A malha MS6 processada na placa gráfica 9600GT pelo programa SpGPUGlbAld produziu um speedup de 10, 80 que foi superior ao speedup de 5, 80 apresentado por [28], mesmo utilizando-se uma placa gráfica de custo inferior nesta pesquisa. A malha MS6 processada na GTX260 pelo programa SpGPUGlbAld produziu o melhor desempenho considerando as três métricas: 20, 99(speedup CG), 2, 56GFLOPS e 13, 32 GB/s. Observa-se que o desempenho das GPUs é crescente à medida em que se aumenta o tamanho do sistema matricial linear a ser resolvido. A diferença de desempenho entre as GPUs também é significativa. Portanto, os experimentos corroboram com a hipótese de que o desempenho aumentará se uma placa gráfica com maior potencial computacional for utilizada ou se um sistema matricial linear maior for processado. Entretanto, o desempenho será severamente afetado quando o sistema matricial linear não couber na memória global da GPU, conforme se observou no programa GPUSText. Além disso, deve-se ter em mente que uma malha muito grande pode inviabilizar o uso do método Gradiente Conjugado, devido ao aumento dos erros de arredondamento durante a resolução do sistema matricial linear, principalmente no caso de sistemas mal condicionados Análise de tendência Para viabilizar uma análise de tendência, o sistema linear Thermal2 (Tabela 12) foi executado pelo programa SpGPUGlbAld (modificado-se o 1º estágio e removendo o 2º estágio de processamento). A Figura 30 apresenta as curvas de tendência do desempenho desse programa executado na placa gráfica GTX260 em relação ao número de coeficientes não nulos (nnz) das matrizes de coeficientes (MS1, MS2, MS3, MS4, MS5, MS6 e Thermal2). Figura 30: Relação coef. não nulos vs. Speedup de SpGPUGlbAld na GTX260 Os resultados obtidos no processamento do Gradiente Conjugado para Thermal2, considerando-se as três métricas, foram 125, 33 (speedup CG), 6, 77 GFLOPS e 40, 67 GB/s. Conforme se pode perceber, houve uma melhoria expressiva nos resultados, se comparados com os resultados para MS6: 20, 99(speedup CG); 2, 56GFLOPS; e 13, 32 GB/s. Os resultados obtidos para Thermal2 e apresentados somente em gráficos por [15] indicam uma proximidade dos GFLOPS produzidos. Entretanto, deve-se considerar que [15] utilizou uma placa gráfica superior (GTX 280) e o método PCG, que favorece a métrica GFLOPS.