UM COMPONENTE PARA EXPLORAÇÃO DA CAPACIDADE DE PROCESSAMENTO DE GPUS EM GRADES COMPUTACIONAIS

Texto

(1)UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA PROGRAMA DE PÓS-GRADUAÇÃO EM INFORMÁTICA. UM COMPONENTE PARA EXPLORAÇÃO DA CAPACIDADE DE PROCESSAMENTO DE GPUS EM GRADES COMPUTACIONAIS DISSERTAÇÃO DE MESTRADO. Guilherme Linck. Santa Maria, RS, Brasil 2010.

(2) UM COMPONENTE PARA EXPLORAÇÃO DA CAPACIDADE DE PROCESSAMENTO DE GPUS EM GRADES COMPUTACIONAIS. por. Guilherme Linck. Dissertação apresentada ao Programa de Pós-Graduação em Informática da Universidade Federal de Santa Maria (UFSM, RS), como requisito parcial para a obtenção do grau de Mestre em Computação. Orientador: Prof. Dr. Benhur de Oliveira Stein (UFSM). Dissertação de Mestrado No 11 Santa Maria, RS, Brasil 2010.

(3) Universidade Federal de Santa Maria Centro de Tecnologia Programa de Pós-Graduação em Informática. A Comissão Examinadora, abaixo assinada, aprova a Dissertação de Mestrado. UM COMPONENTE PARA EXPLORAÇÃO DA CAPACIDADE DE PROCESSAMENTO DE GPUS EM GRADES COMPUTACIONAIS elaborada por Guilherme Linck como requisito parcial para obtenção do grau de Mestre em Computação. COMISSÃO EXAMINADORA:. Prof. Dr. Benhur de Oliveira Stein (UFSM) (Presidente/Orientador). Prof. Dr. Nicolas Maillard (UFRGS). Prof. Dr. Cesar Tadeu Pozzer (UFSM). Santa Maria, 24 de Setembro de 2010..

(4) AGRADECIMENTOS. Quero primeiramente de agradecer a Deus, por ter me dado saúde e sabedoria para conduzir este trabalho até o final. Quero agradecer também ao meu orientador, prof. Dr. Benhur Stein, pela paciência e aconselhamentos em determinados momentos, e também por ter acreditado que eu conseguiria terminar este trabalho. Não poderia deixar de agradecer aos integrantes do colegiado do PPGI, por terem aceitado meu pedido de prorrogação, o que tornou possível a conclusão deste trabalho. Também quero agradecer à Coordenação de Aperfeiçoamento de Pessoal de Nível Superior (CAPES), pelas bolsas de estudo recebidas durante o mestrado. Aos familiares e amigos, pela força e pela compreensão da minha ausência em determinadas ocasiões. Agradeço também ao prof. Dr. Cesar Pozzer, por ter cedido algumas horas do seu tempo, inclusive nas férias, para que eu pudesse realizar a avaliação deste trabalho. Por fim, meus mais sinceros agradecimentos a todos os demais que tiveram participação na realização deste trabalho..

(5) “Mas não basta pra ser livre Ser forte, aguerrido e bravo Povo que não tem virtude Acaba por ser escravo” S EGUNDA ESTROFE DO H INO R IO - GRANDENSE.

(6) RESUMO. Dissertação de Mestrado Programa de Pós-Graduação em Informática Universidade Federal de Santa Maria UM COMPONENTE PARA EXPLORAÇÃO DA CAPACIDADE DE PROCESSAMENTO DE GPUS EM GRADES COMPUTACIONAIS Autor: Guilherme Linck Orientador: Prof. Dr. Benhur de Oliveira Stein (UFSM) Local e data da defesa: Santa Maria, 24 de Setembro de 2010. Grades de computadores surgiram na década de 90 com o objetivo de utilizar computadores geograficamente dispersos para computação de alto desempenho. Através destas grades, pode-se chegar ao poder computacional de um supercomputador de uma forma simples, eficiente e barata. Tais benefícios fizeram com que pesquisas em grades de computadores obtivessem destaques no ramo da computação. Recentemente, surgiram no mercado placas adaptadoras gráficas cujo poder computacional supera, e com larga vantagem, mesmo os mais modernos processadores de uso geral. Isso deu origem a pesquisas que resultaram em técnicas de programação relativamente fáceis de aprender e que simplificam a programação de aplicações para estes processadores. Estas técnicas efetivamente introduziram estes processadores no ramo de computação de alto desempenho. A utilização destas técnicas deu origem à programação de propósito geral em unidades de processamento gráfico (General-Purpose computation on Graphical Processor Units-GPGPU). Aplicações de grades são geralmente programadas através de um framework de computação em grade. TUXUR é um destes frameworks e encontra-se em desenvolvimento por mestrandos do Programa de Pós-graduação em Informática da Universidade Federal de Santa Maria. Este trabalho aborda o desenvolvimento de uma funcionalidade prevista no TUXUR. Tal funcionalidade permite que a grade de computadores gerenciada por TUXUR usufrua dos benefícios de aplicações GPGPU, sobretudo no que diz respeito à melhor utilização do hardware dos nós que a compõem. O reflexo imediato desta sinergia é o aumento significativo da capacidade computacional da grade sem o acréscimo de novos computadores. Os resultados encontrados na avaliação evidenciam a importância do uso de GPGPU nas tarefas que se beneficiam desta técnica de programação, mesmo quando executadas em uma grade. Palavras-chave: GPGPU, computação em grade, otimização dos recursos da grade..

(7) ABSTRACT. Master’s Dissertation Programa de Pós-Graduação em Informática Universidade Federal de Santa Maria DEVELOPMENT OF A MODULE TO EXPLORE GPGPU CAPABLE COMPUTERS IN A GRID COMPUTING Author: Guilherme Linck Advisor: Prof. Dr. Benhur de Oliveira Stein (UFSM) Computer grids emerged in the 90’s with the goal of using geographically dispersed computers for high performance computing. Through grids, computational power of a supercomputer can be reached in a simple, efficient and inexpensive way. Such benefits led to highlights in researchs of computer grids. Recently, appeared on market graphics adapter cards whose computational power overcomes, and by a wide margin, even the most modern processors commonly used. This led to researchs that resulted in programming techniques relatively easy to learn and did simplify application programming for these processors. These techniques effectively introduced the processors in the business of high performance computing. The use of these techniques gave rise to General Purpose computing on Graphic Processing Units (GPGPU). Grids applications are generally programmed through a grid computing framework. TUXUR is one of those frameworks and is under development by Master’s Program Graduate at the Federal University of Santa Maria. This dissertation discusses the development of a TUXUR’s foreseen feature. Such feature allows the computer grid managed by TUXUR to enjoy the benefits of GPGPU applications, particularly regarding to the best use of the nodes’s hardware that comprises it. The immediate impact of this synergy is the significant increase in grid computational capacity without adding new computers. The findings of the evaluation highlights the importance of using GPGPU tasks that take advantage of this programming technique, even when performed in a grid.. Keywords: GPGPU, grid computing, grid resources optimization..

(8) LISTA DE FIGURAS. Figura 2.1 – Figura 2.2 – Figura 2.3 – Figura 2.4 – Figura 2.5 – Figura 2.6 –. GFLOP/s: CPUs versus GPUs. Fonte: (NVIDIA, 2009). . . . . . . . . . . . . . . . . . Largura de banda: CPU versus GPU. Fonte: (NVIDIA, 2009). . . . . . . . . . . . . Utilização de transistores: CPU versus GPU. Fonte: (NVIDIA, 2009). . . . . Estrutura interna de um kernel. Fonte: (NVIDIA, 2009). . . . . . . . . . . . . . . . . . Modelo de memória em CUDA. Fonte: (NVIDIA, 2007) . . . . . . . . . . . . . . . . . Modelo de programação simplificado do ATI Stream Computing. Fonte: (AMD, 2009). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figura 2.7 – Poder computacional dos clientes do projeto Folding@home. Fonte: (STANFORD, 2010b). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 24 24 24 28 29 32 34. Figura 3.1 – Arquitetura geral de Tuxur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Figura 4.1 – Presença do módulo na hierarquia de computadores gerenciada por TUXUR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Figura 4.2 – Arquitetura de um trabalhador. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Figura 4.3 – Exemplo de uma possível grade formada pelo lançador. . . . . . . . . . . . . . . 49 Figura 5.1 – Figura 5.2 – Figura 5.3 – Figura 5.4 – Figura 5.5 – Figura 5.6 – Figura 5.7 – Figura 5.8 – Figura 5.9 –. Representação de um Bloco. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Código da Função FDCT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Relação das quantidades de trabalho dos Jobs recebidos no Cenário 1. Tempo de resolução dos Jobs no Cenário 1.. . . . . . . . . . . . . . . . . . . . . . . . . . Capacidades de trabalho dos Trabalhadores no Cenário 1. . . . . . . . . . . . . Tamanho em bytes das respostas dos Jobs do Cenário 1. . . . . . . . . . . . . . . Tamanhos EM bytes dos Jobs do Cenário 1. . . . . . . . . . . . . . . . . . . . . . . . . . Ociosidade dos trabalhadores no Cenário 1. . . . . . . . . . . . . . . . . . . . . . . . . . Porcentagem do tempo total em estado ocioso dos trabalhadores no Cenário 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figura 5.10 – Relação das quantidades de trabalho dos Jobs recebidas no Cenário 2. Figura 5.11 – Tempo de resolução dos Jobs no Cenário 2.. . . . . . . . . . . . . . . . . . . . . . . . . . Figura 5.12 – Capacidades de trabalho dos Trabalhadores no Cenário 2. . . . . . . . . . . . . Figura 5.13 – Tamanhos em bytes dos Jobs do Cenário 2. . . . . . . . . . . . . . . . . . . . . . . . . . . Figura 5.14 – Tamanho em bytes das respostas dos Jobs do Cenário 2. . . . . . . . . . . . . . . Figura 5.15 – Ociosidade dos trabalhadores no Cenário 2. . . . . . . . . . . . . . . . . . . . . . . . . . Figura 5.16 – Porcentagem do tempo total em estado ocioso dos trabalhadores no Cenário 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figura 5.17 – Relação das quantidades de trabalho dos Jobs recebidas no Cenário 3. Figura 5.18 – Tempo de resolução dos Jobs no Cenário 3.. . . . . . . . . . . . . . . . . . . . . . . . . . Figura 5.19 – Capacidades de trabalho dos Trabalhadores no Cenário 3. . . . . . . . . . . . .. 54 54 56 57 58 58 59 59 60 61 62 63 63 63 64 64 65 66 66.

(9) Figura 5.20 – Tamanho em bytes das respostas dos Jobs do Cenário 3. . . . . . . . . . . . . . . Figura 5.21 – Tamanhos em bytes dos Jobs do Cenário 3. . . . . . . . . . . . . . . . . . . . . . . . . . . Figura 5.22 – Ociosidade dos trabalhadores no Cenário 3. . . . . . . . . . . . . . . . . . . . . . . . . . Figura 5.23 – Porcentagem do tempo total em estado ocioso dos trabalhadores no Cenário 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 67 67 68 68.

(10) LISTA DE TABELAS. Tabela 5.1 – Descrição do hardware dos computadores utilizados na avaliação. . . . . 55 Tabela 5.2 – Localização dos trabalhadores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56.

(11) LISTA DE ABREVIATURAS E SIGLAS. ALU. Arithmetic and Logic Unit (Unidade Lógica e Aritmética). AMD. Advanced Micro Devices. BMP. Acrônimo de BitMaP – mapa de bits. BOT. Bag of Tasks (Saco de Tarefas). CEA. Comissão de Energia Atômica. CPU. Central Processing Unit (Unidade Central de Processamento). CUDA. Compute Unified Device Architecture. FDCT. Forward Discrete Cosine Transform (Transformada Discreta do Cosseno Direta). GFLOPS Giga Floating point Operations Per Second (Bilhões de Operações de Ponto Flutuante por Segundo) GPGPU General Purpose computing on Graphics Processing Units (Computação de Propósito Geral em Unidades de Processamento Gráfico) GPU. Graphics Processing Unit (Unidade de Processamento Gráfico). IBM. International Business Machines. JPEG. Joint of Photographic Experts Group (União do Grupo de Especilialistas em Fotografia). LSC. Laboratório de Sistemas de Computação. Mbps. Milhões de bits por segundo. OpenCL Open Computing Language (Linguagem de Computação Aberta) SETI. Search for Extraterrestrial Intelligence (Busca por Inteligência Extraterrestre). TFLOPS Tera Floating point Operations Per Second (Trilhões de Operações de Pontoflutuante por Segundo) UFSM. Universidade Federal de Santa Maria. ULA. Unidade Lógica e Aritmética.

(12) SUMÁRIO. 1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Contexto e Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Objetivos e Contribuição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Organização do Texto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 14 14 15 16. 2 REVISÃO BIBLIOGRÁFICA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Grades Computacionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Principais Conceitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.2 Problemas Envolvidos e Pesquisas Atuais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 GPGPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Computação de Propósito Geral em GPUs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.2 GPGPU: Benefícios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.3 GPGPU: Desafios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Técnicas de Programação para GPGPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 Nvidia CUDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.2 AMD Stream Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.3 OpenCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 Utilização de GPGPU em Grades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.1 Folding@home . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.2 SETI@home . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 17 17 17 19 22 23 23 26 27 27 32 32 33 33 35. 3 FRAMEWORK TUXUR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Objetivos e Contribuição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Tipos de Tarefas Suportadas por Tuxur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Características Importantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 Divisão Dinâmica de Tarefas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.2 Heterogeneidade de Ambiente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Principais Componentes e Suas Funções . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.1 Gerente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.2 Trabalhador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.3 Interface de Comunicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.4 Lançador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.5 Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.6 Interface do Usuário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 36 36 37 37 38 38 39 40 40 41 41 42 42.

(13) 4 MÓDULO GPGPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Relação do módulo com o TUXUR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Componentes Implementados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 Trabalhador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.2 Interface de Comunicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.3 Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Integração deste Módulo ao Tuxur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 43 43 43 44 44 46 47 48. 5 AVALIAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Abordagem do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.1 Função Forward Discrete Cosine Transform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.2 Etapas Transformadas em Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.3 Descrição do Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 Resultados Obtidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.1 Cenário 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.2 Cenário 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.3 Cenário 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 50 50 51 52 52 53 55 56 60 65. 6. CONSIDERAÇÕES FINAIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69. REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 APÊNDICE A FUNÇÕES PRÉ-DEFINIDAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.1 Executadas pelo Gerente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.1.1 job breakJob() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.1.2 byte[] description() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.1.3 void setSubResult() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.1.4 boolean isSolved() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.2 Executas pelos Trabalhadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.2.1 void solve() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.2.2 int workload() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.3 Executadas por Ambos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.3.1 job newJob() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.3.2 byte[] resultDescription() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 80 80 80 80 81 81 81 81 81 82 82 82. APÊNDICE B FUNCIONALIDADES DO GERENTE NO TUXUR . . . . . . . . . . 83 B.1 Divisão e Delegação de Tarefas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 B.2 Recepção e Formação da Resposta Final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 APÊNDICE C VERSÃO IMPLEMENTADA DO TUXUR . . . . . . . . . . . . . . . . . . . C.1 Componentes Implementados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C.1.1 Lançador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C.1.2 Gerente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C.1.3 Trabalhador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C.1.4 Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 86 86 86 87 87 87.

(14) 14. 1 INTRODUÇÃO. 1.1 Contexto e Motivação Aplicações científicas costumam envolver computação intensa sobre um enorme volume de dados. Devido à quantidade de cálculos a serem realizados por estas aplicações, um único computador, mesmo um supercomputador, poderia levar uma grande quantidade de tempo para concluir uma tarefa. Geralmente, o tempo total decorrido pode tornar inviável a sua espera. Uma das alternativas para se melhorar o desempenho na execução destas aplicações está no emprego de grades de computadores. O uso de grades de computadores é uma das formas mais simples e baratas de se alcançar poder computacional de um supercomputador (SINGH et al., 2008). Pesquisas na área de computação de alto desempenho em meados da década de 90 deram origem às grades de computadores (FOSTER, 2001). Estas grades são formadas por diversos computadores, local ou geograficamente distribuídos e interligados em rede (FOSTER; KESSELMAN, 1999). O baixo custo para a execução de programas distribuídos, quando comparado a um supercomputador, associado à escala de paralelização possível de ser alcançada e até então impensável para um supercomputador, fez com que as grades computacionais ganhassem destaque no ramo da computação (CIRNE; SANTOSNETO, 2005). Há poucos anos apareceram no mercado processadores gráficos cujos custos e poder computacional chamaram a atenção da comunidade científica. Isso abriu caminho para utilizá-los não somente para gerar imagens e exibi-las na tela do monitor, mas utilizá-los para computação de propósito geral. Avanços neste sentido deram origem à computação de propósito geral em unidades de processamento gráfico (Graphic Processing Unit GPU), mais conhecida pela sigla GPGPU (General-Purpose computation on Graphical Processor Units) (OWENS et al., 2007)..

(15) 15. A lei de Moore afirma que o poder de processamento dos computadores dobra a cada 2 anos (MOLLICK, 2006). Esta lei não se aplica às GPUs, cujo poder computacional supera esta cifra a cada ano (WU; LIU, 2008; LI et al., 2009). Este descolamento em relação à lei de Moore leva a crer que seu uso seja cada vez mais vantajoso. Os dois principais fabricantes de placas adaptadoras gráficas, Nvidia (NVIDIA, 2010a) e AMD (AMD, 2010a), viram no ramo do GPGPU um valioso nicho de mercado. Embora já fosse possível utilizar uma GPU para computação dos mais diversos tipos de problemas, a programação destas aplicações exigia considerável conhecimento da arquitetura do processador gráfico (WU; LIU, 2008). Estas empresas então criaram técnicas de programação que simplificaram e facilitaram a programação de aplicações GPGPU. A Nvidia criou o CUDA (Compute Unified Device Architecture) (NVIDIA, 2009) e a AMD desenvolveu o Stream Computing (AMD, 2010b). Estes ambientes facilitaram o ingresso dos produtos destas empresas no ramo de computação de alto desempenho. A maioria das novas GPUs produzidas por estas empresas suportam seus respectivos ambientes. Por possuírem supremacia neste mercado, a probabilidade de encontrar uma de suas GPUs instalada em um computador é relativamente alta. Tornar possível a execução de aplicações GPGPU em uma grade de computadores é a principal motivação para o desenvolvimento deste trabalho.. 1.2 Objetivos e Contribuição A aglomeração de recursos dispersos de uma grade computacional com algumas centenas de computadores resulta em uma considerável capacidade computacional. O poder computacional de uma grade pode ser aumentado através da inserção de novos computadores, ou pela atualização (upgrade) de hardware dos existentes. Esta atualização pode incluir a simples substituição da placa adaptadora gráfica. O trabalho aqui apresentado objetiva colocar estes processadores à disposição das aplicações de uma grade computacional. TUXUR, atualmente em desenvolvimento no Laboratório de Sistemas de Computação (LSC) da Universidade Federal de Santa Maria (UFSM), permitiu que esse objetivo fosse alcançado. Assim, computadores que possuam hardware compatível com GPGPU podem receber tarefas especialmente codificadas, fazendo uso destes valiosos recursos que do contrário seriam praticamente ignorados. O uso concomitante da GPU e CPU des-.

(16) 16. tes computadores para a computação de tarefas melhora significativamente a utilização do hardware destes computadores. O desenvolvimento desta funcionalidade, como um módulo do TUXUR, é a contribuição deste trabalho.. 1.3 Organização do Texto A organização desta dissertação respeita a seguinte estrutura de capítulos. No capítulo dois é apresentada a revisão bibliográfica sobre grades de computadores, GPGPU e seu uso em grades. No capítulo três discorremos sobre TUXUR, o framework de computação em grade onde o módulo GPGPU, razão desta dissertação, está inserido. O capítulo quatro aborda o módulo desenvolvido. A avaliação do módulo encontra-se no capítulo cinco. As considerações finais e trabalhos futuros relacionados a este trabalho estão inseridas no capítulo seis..

(17) 17. 2 REVISÃO BIBLIOGRÁFICA. 2.1 Grades Computacionais 2.1.1 Principais Conceitos Grades de computadores surgiram na década de 90, como proposta de uma infraestrutura de computação distribuída que permitisse o compartilhamento de recursos entre projetos de colaboração científica (FOSTER; KESSELMAN, 2003). Inicialmente, grades de computadores foram definidas por FOSTER; KESSELMAN (1999) como sendo uma infraestrutura de software e hardware, que fornece acesso a uma grande quantidade de recursos computacionais de forma segura, consistente, abrangente e barata. Atualmente, FOSTER; KESSELMAN (2003) definem grade como sendo "um sistema que coordena recursos distribuídos utilizando protocolos de propósito geral, padronizados, abertos e interfaces que entregam qualidade de serviço não trivial". OGSA (Open Grid Services Architecture) (FOSTER; KESSELMAN; TUECKE, 2003; FOSTER et al., 2006) é no momento uma das arquiteturas para grades mais influentes no mundo (LU; MA, 2009). Grades de computadores tem sido adotadas nos mais diversos domínios de aplicação. Em (FOSTER; KESSELMAN, 2003) são abordadas doze importantes aplicações, que englobam problemas enfrentados pela indústria, ciência, laboratórios, universidades, grandes corporações, entre outras. Aplicações em grades podem ser agrupadas em cinco grandes classes (FOSTER; KESSELMAN, 1999, 2003). • Distributed Supercomputing: estão inseridas nesta classe as aplicações que necessitam de uma enorme quantidade de recursos computacionais para serem concluídas. Estas aplicações são fortemente acopladas. Muitas vezes os requisitos computacionais não podem ser atendidos por um único supercomputador. Em vista disso,.

(18) 18. recursos de vários supercomputadores podem ser agregados. Atualmente esta classe de aplicação é também conhecida como metacomputação. • High-Throughput Computing: esta classe de aplicações compreende aplicações independentes ou fracamente acopladas. Normalmente suas execuções exploram ciclos não utilizados pelo processador. Aqui, recursos computacionais de diversos computadores são agrupados para se obter alta vazão na conclusão de tarefas. Esta classe leva este nome pois o desempenho das aplicações não se dá pela tradicional métrica de operações de ponto-flutuante realizadas por segundo, mas sim pela velocidade em que computadores devolvem os resultados pretendidos. • On-Damand Computing: aplicações inseridas nesta classe necessitam temporariamente de recursos computacionais que não podem ser obtidos localmente. seja pelo custo ou mesmo por conveniência. Para estas aplicações, o custo envolvido é mais importante do que o desempenho obtido. • Data-Intensive Computing: são aplicações que necessitam armazenar uma enorme quantidade de dados. Geralmente este volume é grande demais para ser armazenado localmente. Grades fornecem um meio de armazenar e acessar estes dados em repositórios geograficamente distribuídos. Normalmente os dados destas aplicações são processados antes de serem efetivamente armazenados, o que as torna computacionalmente intensivas também. É necessária uma boa infraestrutura de comunicação para acesso remoto às bases de dados distribuídas. • Collaborative Computing: são aplicações que tornam possível a interação e compartilhamento de recursos entre pessoas geograficamente distribuídas, normalmente em tempo real. As aplicações contidas nestas classes utilizam a grade para obter os recursos necessários para atingirem seus objetivos. SUCIU; POTOLEA (2008) proporam uma taxonomia para aplicações em grade, com base nas suas características estruturais, dados que utilizam como entrada e gerados como saída. A sintaxe das siglas por eles utilizada é semelhante à utilizada na taxonomia de Flynn. As características das aplicações executadas por uma grade também geram uma classificação para estas grades (KRAUTER; BUYYA; MAHESWARAN, 2001; BALI et al., 2009)..

(19) 19. • Computational Grid: é o tipo de grade que agrega recursos computacionais de um grande número de computadores, com o propósito de oferecer uma gigantesca capacidade computacional para execução de tarefas. As classes de aplicações Distributed e High-Throughput Computing são executadas nestas grades. • Data Grid: são grades que oferecem uma estrutura especializada para acesso e armazenamento distribuído de informações. Aplicações classificadas como DataIntensive Computing fazem uso deste tipo de grade. • Service Grid: basicamente, este é o tipo de grade que oferece serviços que não podem ser fornecidos por um único computador. As classes On-Damand e Collaborative Computing executam nesta classificação de grade. • Equipment Grid: são grades onde os principais recursos são instrumentos que podem ser controlados e acessados remotamente. Os dados coletados por estes instrumentos são processados pela grade que os suportam. 2.1.2 Problemas Envolvidos e Pesquisas Atuais A promessa de alocar uma grande quantidade de recursos para uma aplicação paralela, necessitando de baixo investimento financeiro, despertou o interesse pelas grades de computadores (COSTA; CIRNE; FIREMAN, 2005). No entanto, para um bom aproveitamento dos recursos colocados à disposição, muitos desafios que envolvem a utilização de recursos presentes na grade devem ser superados. De acordo com BUYYA; ABRAMSON; GIDDY (2001), o gerenciamento e o escalonamento dos recursos é uma tarefa complexa, pois: os recursos estão distribuídos geograficamente; são heterogêneos; pertencem a diferentes indivíduos ou organizações com políticas próprias; possuem diferentes modelos de custos e acesso; a disponibilidade e carga dos recursos é dinamicamente variável. Gerenciar e providenciar os recursos que satisfaçam as solicitações dos usuários são os principais objetivos dos sistemas de gerenciamento de recursos(CHEN; LU, 2008). 2.1.2.1 Descoberta de Recursos É fato que não se consegue gerenciar o que não se conhece. Para contornar este problema, grades devem possuir mecanismos de descoberta de recursos. Estes mecanismos são fundamentais para grades de computadores, pois auxiliam no gerenciamento de.

(20) 20. recursos e escalonamento de tarefas (RANJAN et al., 2007). O objetivo básico destes mecanismos é descobrir recursos presentes na grade, que se adequem à descrição dos recursos feita pelos usuários e necessários para a execução de suas tarefas. Diversos trabalhos implementam mecanismos de descoberta de recursos utilizando abordagens centralizadas ou hierárquicas. Estas abordagens tendem a apresentar problemas de escalabilidade e tolerância a falhas na medida em que o tamanho da grade aumenta (TRUNFIO et al., 2007; COKUSLU; HAMEURLAIN; ERCIYES, 2009). Abordagens centralizadas possuem um ponto único de falha e sofrem problemas de sobrecarga no servidor central. Já a hierárquica elimina o problema de sobrecarga, mas a falha em um ponto da hierarquia prejudica o acesso a recursos em níveis inferiores. Em (COKUSLU; HAMEURLAIN; ERCIYES, 2009) pode ser encontrada uma avaliação de mecanismos de descoberta de recursos atuais, baseados em Web Services (WS). Estão presentes abordagens centralizadas e hierárquicas. Com base nos trabalhos avaliados, os autores chegaram à conclusão de que a utilização de WS para esta tarefa só é adequada para grades pequenas e que não apresentam grande dinamicidade no número de nós. Em vista das deficiências das abordagens mencionadas, soluções distribuídas que empregam características de sistemas ponto-a-ponto (Peer-to-Peer - P2P) se mostram promissoras. SCHMIDT; PARASHAR (2003) citam descentralização, auto-organização e tolerância a falhas como características que tornam estes sistemas escaláveis e atrativos para serem utilizados em grades. Trabalhos que utilizam soluções P2P podem ser encontrados em (IAMNITCHI; FOSTER, 2004; SCHMIDT; PARASHAR, 2003; RANJAN et al., 2007; FATTAHI; CHARKARI, 2009; MA; SUN; GUO, 2010). TRUNFIO et al. (2007) apresentam uma interessante fonte de consulta sobre sistemas P2P e discutem outros projetos bem sucedidos que o empregam em serviços de descoberta de recursos. 2.1.2.2 Gerenciamento e Alocação de Recursos Estabelecer acordos entre consumidores de recursos e fornecedores de recursos, onde os fornecedores concordam em fornecer as capacidades necessárias para a execução de tarefas dos consumidores, é o principal propósito de sistemas de gerenciamento de recursos (CZAJKOWSKI; FOSTER; KESSELMAN, 2003). Devido às características das grades de computadores, a alocação de recursos para execução de tarefas é um dos pro-.

(21) 21. blemas mais difíceis e complicados de serem superados (MINGBIAO et al., 2007). BUYYA; ABRAMSON; GIDDY (2000a) propuseram a utilização de modelos econômicos para guiar o gerenciamento de recursos em grades computacionais. Nesta abordagem, os usuários devem pagar pela utilização dos recursos da grade, cujos preços são guiados pela lei da oferta e da demanda. De acordo com os pesquisadores, a precificação dos recursos é uma das melhores formas de controlar e regular o acesso aos recursos. Em grades que empregam modelos econômicos para gerenciar os recursos, existem dois participantes principais: consumidores e fornecedores de recursos (BUYYA; ABRAMSON; GIDDY, 2001). De um modo geral, consumidores objetivam executar suas tarefas com o menor custo possível e no tempo planejado, enquanto os fornecedores objetivam maximizar os lucros e utilização de seus recursos, utilizando o preço como artifício. Desta forma, dentre os fornecedores disponíveis, os consumidores têm a opção de escolher o melhor fornecedor de recursos para execução das suas tarefas. Eles constaram que o Globus Toolkit1 (FOSTER; KESSELMAN, 1997) não possuía serviços que suportassem a negociação dinâmica de recursos. Para contornar essa deficiência eles desenvolveram uma infraestrutura de middleware, que pode ser facilmente combinada a outros middlewares e assim expandir as funcionalidades neles existentes, como o Globus por exemplo. Eles a batizaram de arquitetura de grade para economia computacional (GRid Architecture for Computational Economy - GRACE), a qual foi inicialmente descrita em (BUYYA; ABRAMSON; GIDDY, 2000a) e em (BUYYA; ABRAMSON; GIDDY, 2001) é apresentado um caso de uso desta arquitetura. Basicamente, GRACE oferece recursos que permitem a negociação dinâmica de recursos para suportar a economia computacional. GRACE pode ser então utilizada por sistemas de gerenciamento e escalonamento de recursos em grades de computadores que suportem a negociação dinâmica de recursos. Como exemplo, podemos citar Nimrod/G (BUYYA; ABRAMSON; GIDDY, 2000b; ABRAMSON; GIDDY; KOTLER, 2000), construído utilizando serviços do Globus. Nimrod/G suporta mecanismos de escalonamento baseados em custos e em prazo para término da execução da tarefa (deadline). Entende-se por custos o orçamento financeiro disponível para execução das tarefas. Desde seu lançamento, GRACE tem recebido diversos aprimoramentos. LIU; XU 1. Conjunto de serviços que facilitam a criação de grades computacionais e o desenvolvimento de aplicações para computação em grade..

(22) 22. (2007) constaram que GRACE não possuía um módulo que controlasse a flutuação de preços. A não flutuação dos preços resultaria em menores lucros para os fornecedores de recursos e em uma menor taxa de finalização de tarefas. Eles então implementaram um módulo de flutuação de preços para a GRACE, chamando-o de gerente de precificação flutuante dos recursos (Resources Pricing Fluctuation Manager - RPFM). Este módulo foi em seguida aperfeiçoado e reapresentado em (MA et al., 2009). Foram inseridos mecanismos de gerenciamento de confiança, onde a reputação dos integrantes passou a ser considerada no processo de escalonamento de recursos. Em um ambiente onde os usuários pagam para executar suas tarefas, surge a necessidade de se oferecer uma boa qualidade de serviço (Quality of Service - QoS). Um módulo que dá suporte à QoS garantida por acordo de nível de serviço (Service Level Agreement SLA) foi desenvolvido por WANG et al. (2009) e acrescentado à GRACE. Alguns modelos econômicos que podem ser utilizados na negociação de recursos, bem como estratégias de precificação, são abordados em (BUYYA et al., 2002). Dentre os modelos discutidos, Double Auction é o mais promissor para ambientes de grade segundo os autores. Este modelo é caracterizado por leilões, onde consumidores e fornecedores efetuam lances. Quando lances destes dois participantes são compatíveis, o negócio é fechado. KANT; GROSU (2005) avaliaram três protocolos de alocação de recursos que utilizam Double Auction. Dentre os protocolos avaliados, chegaram a conclusão de que o Continuous Double Auction (CDA) é o melhor para consumidores e produtores, assim como permitiu a maior utilização dos recursos. TAN; GURD (2007) aperfeiçoaram o CDA, apresentando uma variação deste método chamado Stable Continuous Double Auction. As mudanças implementadas levaram a uma melhor eficiência econômica e de escalonamento de recursos. OGSA. 2.2 GPGPU Esta seção aborda inicialmente os avanços das GPUs que acabaram por dar origem à GPGPU. Em seguida, comenta-se sobre os principais ambientes de desenvolvimento que facilitam a programação de aplicações GPGPU e os benefícios em utilizar esta técnica de programação. A parte final deste capítulo faz um breve relato sobre os projetos.

(23) 23. Folding@home e SETI@home, os quais obtiveram significativo sucesso no emprego de GPUs na computação em grade. 2.2.1 Computação de Propósito Geral em GPUs A rápida evolução das GPUs observada nos últimos anos (WU; LIU, 2008), motivada principalmente pelo mercado altamente competitivo e dinâmico de jogos de computadores (SINGH et al., 2008), deu origem a modernas unidades de processamento gráfico. Atualmente, estas unidades (GPUs) são computadores paralelos completamente programáveis e capazes de escalonar milhares de threads (ZHENG et al., 2008). Tais características permitem às GPUs atingir um pico de desempenho cuja magnitude é maior do que a de uma CPU (SINGH et al., 2008). Essas mesmas características despertaram o interesse da comunidade científica para a utilização desses processadores em computação de propósito geral (WU; LIU, 2008), dando origem à GPGPU. A codificação de aplicações não gráficas nas primeiras GPUs era uma árdua tarefa. Para tal, era necessário conhecimento sobre a arquitetura da GPU e a codificação se dava em assembly, fato que só mudou a partir de 2001 quando as GPUs passaram a suportar programação (WU; LIU, 2008). A programação das GPUs permitiu aos desenvolvedores explorarem as suas unidades lógicas e aritméticas (ULA) num campo além do processamento gráfico (OWENS et al., 2007). O desenvolvimento de novas técnicas de programação para GPUs foi fundamental para que isso acontecesse. Na subseção a seguir são abordados alguns benefícios da utilização de GPGPU. 2.2.2 GPGPU: Benefícios GPUs recentes reúnem em um único chip a capacidade de processamento correspondente a dezenas de processadores de propósito geral. O gráfico da figura 2.1 evidencia o progresso em termos de GFLOP/s entre CPUs e GPUs em apenas cinco anos de evolução. A vantagem das GPUs frente às CPUs em termos de GFLOP/s impressiona. O mesmo ocorre quando analisamos a largura da banda de acesso à memória, cujo gráfico pode ser observado na figura 2.2. A razão desta superioridade se deve ao fato de que os processadores gráficos são especializados para a computação intensiva e paralela, concentrando o uso de transistores em unidades de execução. Ao contrário das CPUs tradicionais, onde se concentram em regiões de cache e controle de fluxo (NVIDIA, 2009; OWENS et al., 2007), como pode ser observado na figura 2.3..

(24) 24. Figura 2.1: GFLOP/s: CPUs versus GPUs. Fonte: (NVIDIA, 2009).. Figura 2.2: Largura de banda: CPU versus GPU. Fonte: (NVIDIA, 2009).. Figura 2.3: Utilização de transistores: CPU versus GPU. Fonte: (NVIDIA, 2009). GPUs são especializadas para computação intensiva e altamente paralela, o que é necessário para renderização gráfica (NVIDIA, 2009) e por isso mais transistores são empregados em unidades de computação (OWENS et al., 2007). Já as CPUs foram proje-.

(25) 25. tadas para atingirem um alto desempenho em código sequencial. Esta é a razão pela qual emprega-se mais transistores na unidade de controle de execução das CPUs (NVIDIA, 2009). CPUs também necessitam de bastante memória cache para compensar a latência de acesso à memória, latência esta que é “escondida” através da computação intensa e paralela ao invés do uso de cache nas GPUs (NVIDIA, 2009). Por serem processadores com características SIMD, GPUs também não necessitam de unidades de controle complexas e isso justifica as pequenas regiões em amarelo na figura. Isso é exatamente o contrário do que ocorre nas CPUs, onde métodos de extração de paralelização em nível de instrução são implementados com técnicas de predição de desvios e execução fora de ordem (OWENS et al., 2007). A partir do momento em que as GPUs passaram a suportar programação, abriu-se caminho para o seu emprego em diversas aplicações (SINGH et al., 2008). Owens (2007) afirma que a programação GPGPU não é apenas uma questão de aprender uma nova linguagem de programação, necessita-se compreender o modelo de programação para GPUs. Esse mesmo trabalho afirma que a dificuldade na programação para GPUs, devido a esse modelo diferenciado, não é o bastante para ignorar os seus benefícios. Para que uma aplicação possa usufruir do poder computacional de uma GPU, é necessário que esta possa se adequar ao modelo de computação SIMD (SINGH et al., 2008). Desta forma, aplicações que efetuam as mesmas operações sobre uma grande quantidade de dados podem ser facilmente codificadas utilizando uma das técnicas de programação citadas na seção 2.3. A computação de uma tarefa pela GPU significa que a CPU pode ser utilizada simultaneamente. Assim, rotinas computacionais possíveis de serem computadas em SIMD podem ser executadas na GPU, enquanto as demais têm sua computação realizada pela CPU. DATTA et al. (2008) afirma que vários problemas reais foram solucionados através de GPGPU com um desempenho superior aos últimos processadores com vários núcleos, superando inclusive o processador IBM Cell. Salienta-se que esse desempenho não se deu unicamente em mais operações realizadas por segundo, mas também em operações por segundo por dólar e em operações por watt consumido..

(26) 26. 2.2.3 GPGPU: Desafios Embora as técnicas de programação descritas anteriormente facilitem a codificação de aplicações que executarão nas GPUs, obter explorar com eficiência esses processadores não é uma tarefa fácil. Nem todas as aplicações que desempenham bem em uma CPU repetirão este feito em uma GPU. Um dos requisitos fundamentais para que se obtenha um bom desempenho nestas arquiteturas e a possibilidade da aplicação ser codificadas empregando rotinas SIMD. No entanto, isso ainda não garante que estas aplicações terão um desempenho excepcional. Em CUDA, por exemplo, um dos maiores desafios do programador é conseguir explorar ao máximo a memória de vídeo disponível para as GPUs. Isso é alcançado quando um conjunto de threads conseguem acessar endereços de memória de forma aglutinada (coalesced). Basicamente, threads devem acessar endereços de memória, onde cada endereço esteja localizado em um bank de memória diferente. Os requisitos para que o acesso à memória seja feito de forma aglutinada varia entre as versões do CUDA. Em (NVIDIA, 2009) este problema é abordado com mais detalhes, onde também são apresentadas abordagens para cada versão do CUDA. Para auxiliar o programador a localizar trechos de códigos que afetam o desempenho da aplicação, ferramentas de profiling são bastante úteis. Estas ferramentas fornecem uma série de contadores sobre diversos processos ocorridos durante a execução do programa. Como exemplo podemos citar uma ferramenta brasileira desenvolvida por COUTINHO et al. (2009) e o NVIDIA CUDA Visual Profiler (NVIDIA, 2010b). Um outro desafio relacionado à utilização das GPUs é a confiabilidade dos resultados por elas apresentados. Conforme mencionamos anteriormente, a existência de modernas GPUs é fruto do mercado de jogos de computadores. Em vista disso, o foco do desenvolvimento das GPUs é o mercado de Desktops, onde os requerimentos de segurança são baixos (SHEAFFER; LUEBKE; SKADRON, 2006). GPUs podem apresentar dois tipos de erros: soft e hard. A corrupção transiente de um único bit em um circuito é chamado de soft error. Estes diferem de hard errors pois são aleatórios, temporários e é impossível prever quando irão acontecer (SHEAFFER; LUEBKE; SKADRON, 2006). Gerações atuais de GPUs não oferecem suporte via hardware para verificação desses erros, sejam lógicos ou em células de armazenamento de memória. Consequentemente.

(27) 27. os resultados podem ser silenciosamente corrompidos (DIMITROV; MANTOR; ZHOU, 2009). De acordo com SHEAFFER; LUEBKE; SKADRON (2006), falhas em um único quadro não são tão preocupantes pois podem ser corrigidos no quadro seguinte. No entanto, uma falha em uma aplicação científica ou comercial invalida a computação inteira. Em vista disso, DIMITROV; MANTOR; ZHOU (2009) propuseram algumas estratégias via software para aumentar a confiabilidade de aplicações GPGPU.. 2.3 Técnicas de Programação para GPGPU Facilitar o desenvolvimento de aplicações GPGPU foi fundamental para promover a sua utilização. Esta seção contém uma breve abordagem sobre as três principais técnicas de programação GPGPU. 2.3.1 Nvidia CUDA CUDA é uma arquitetura de computação paralela de propósito geral, lançada em 2006, que alavancou a utilização das GPUs Nvidia na resolução de problemas de forma mais eficiente que nas CPUs (NVIDIA, 2009). A curva de aprendizado para programação através desta arquitetura é suave para programadores familiarizados com a linguagem C. Atente que isso se refere à escrita do código, não na facilidade de se criar aplicações que explorem as GPUs ao máximo. Através de mecanismos de abstração de hardware, CUDA esconde dos programadores os detalhes relacionados à GPU. Basicamente, CUDA oferece ao programador um conjunto de bibliotecas e um compilador C (nvcc) que gera código alvo tanto para o processador principal como para a GPU. Para isso, é necessário explicitar dentro do código-fonte as porções de código que devem executar na GPU, CPU ou em ambas. Esta classificação tornou necessário adicionar algumas extensões à linguagem C padrão. 2.3.1.1 Kernel O processamento no lado da GPU é executado por um núcleo composto por blocos de threads, chamado kernel. A figura 2.4 exibe a estrutura de um kernel. Um bloco é composto por uma ou várias threads. GPUs atuais suportam até 1024 threads por bloco. Cada bloco é escalonado em um dos multiprocessadores das GPUs. Um multiprocessador cria, gerencia e executa de modo concorrente todas as threads de um bloco, com custo.

(28) 28. Figura 2.4: Estrutura interna de um kernel. Fonte: (NVIDIA, 2009). (overhead) zero de escalonamento. Novos blocos são escalonados para os multiprocessadores na medida em que estes terminam a computação dos blocos que receberam. Uma GPU pode possuir vários multiprocessadores, e cada multiprocessador possui oito processadores em seu interior. Os multiprocessadores criam grupos de 32 threads, chamados de warps. Estas threads são escalonadas e executadas nos oito processadores do multiprocessador. O melhor desempenho é obtido quando todas as threads de um warp percorrem o mesmo caminho de execução. Quando threads seguem caminhos diferentes, devido a desvios condicionais, por exemplo. Quando estes ocorrem, serializam-se as threads que seguem um determinado caminho e paralizam-se as outras. Isso se repete até que todas voltem a ter um caminho de execução comum. Fica então evidente que códigos contendo muitos desvios condicionais tendem a apresentar um fraco desempenho nas GPUs. É necessário bastante esforço por parte dos usuários em escrever códigos onde as threads não divirjam em seus fluxos de execução. O usuário não necessita saber quantos multiprocessadores uma GPU possui para ajudálo a definir o número de blocos e threads por bloco. É o sistema quem lida com o escalonamento dos blocos nos multiprocessadores da GPU disponível, completamente transparente para o usuário. Assim, é possível atribuir a cada thread uma pequena quantidade de dados e uma.

(29) 29. função para operar sobre esses dados. O trabalho de um kernel termina quando todas as threads de todos os blocos tiverem sido executadas, só então é permitida a execução de um novo kernel. Enquanto um kernel está sendo executado, a CPU fica ociosa até a sua conclusão. Isto abre espaço para computação heterogênea, ou seja, enquanto a GPU estiver computando, o processador pode ser utilizado para computação de tarefas que não se adequam ao modelo de programação para GPUs. 2.3.1.2 Organização da Memória A figura 2.5 exibe o modelo de memória em CUDA.. Figura 2.5: Modelo de memória em CUDA. Fonte: (NVIDIA, 2007) Como pode ser observado, há seis tipos de memória, os quais são brevemente descritos a seguir. • Registers: São os registradores do processador que podem ser lidos e escritos pelas threads. Cada thread possui um conjunto próprio de registradores. Possuem alta largura de banda e baixa latência. Para um melhor desempenho, encoraja-se que a quantidade de threads por bloco seja um múltiplo de 64. • Shared Memory: Pode ser lida e escrita pelas threads de um mesmo bloco. É o tipo de memória que permite que as threads de um mesmo bloco cooperem na resolução de um problema. Esta memória é dividida em módulos de tamanhos.

(30) 30. iguais, chamados banks. Quando são feitos acessos a endereços que não pertencem a um mesmo bank, a largura de banda obtida é igual ao número de banks acessados multiplicado pela largura de banda de cada um. Nessa situação ela é tão rápida quanto os registradores. • Constant Memory: Quantidade de memória do dispositivo que só permite leitura, sendo otimizada para esta operação. Dados são colocados em uma cache após serem acessados pela primeira vez, o que acelera leituras futuras. Pode ser lida por todas as threads. • Global Memory: Porção de memória acessível por todas as threads de todos os blocos de um kernel. Possui baixa largura de banda e alta latência pois os dados não são colocados em uma cache. • Local Memory: Memória local de uma thread. Possui propriedades semelhantes a Global Memory. • Texture Memory: Memória semelhante a Constant. Operações de leitura nessa memória podem ser mais vantajosas do que se forem realizadas nas memórias Global e Constant. Texture, Global e Constant Memory podem ser lidas e escritas pelo host e perduram até o final da execução da aplicação. O número de blocos que um multiprocessador pode processar por vez depende da quantidade de registradores utilizados por cada thread e de quanta memória do tipo shared cada bloco utiliza. Isso porque os registradores e a memória shared são divididos entre todas as threads dos blocos. Imagine uma situação hipotética onde há duzentos registradores disponíveis e um total de 100KB de memória shared. Considere ainda que os blocos possuam dez threads cada um. As threads necessitam de cinco registradores cada uma e cada bloco ocupa 50KB de memória shared. Neste caso, cada bloco ocupa cinquenta registradores. Se for considerado somente o total de registradores disponíveis, seria possível executar quatro blocos simultaneamente. No entanto, somente dois podem ser executados em paralelo, pois cada bloco ocupa 50KB de memória shared e há apenas 100KB disponíveis..

(31) 31. Em uma situação real, um multiprocessador pode executar até oito blocos em paralelo. Importante ressaltar que caso um bloco necessite mais recursos do que os disponíveis, o lançamento do kernel falhará. 2.3.1.3 Versões do CUDA Nesta seção são abordadas algumas características das versões existentes do CUDA(NVIDIA, 2009). • Versão 1.0 – Máximo de 512 threads por bloco. – 8192 registradores por multiprocessador2 . – 16KB de shared memory para cada multiprocessador. – 64KB de constant memory. – Máximo de 8 blocos ativos por multiprocessador. – Máximo de 768 threads ativas por multiprocessador. – Máximo de 24 warps ativos por multiprocessador. • Versão 1.1 – Características da versão anterior. – Suporte a operações atômicas em dados de 32 bits da global memory. • Versão 1.2 – Características da versão anterior. – Suporte a operações atômicas em dados de 64 bits da constant memory e shared memory. – 16384 registradores por multiprocessador. – Máximo de 1024 threads ativas por multiprocessador. • Versão 1.3 2. Um multiprocessador possui 8 processadores..

(32) 32. – Características da versão anterior. – Máximo de 32 warps ativos por multiprocessador. – Suporte a variáveis de dupla precisão (double). 2.3.2 AMD Stream Computing Assim como o Nvidia CUDA, esta plataforma também possui mecanismos que abstraem os detalhes da GPU para o programador. Os programas em execução nos Stream Cores são denominados Stream Kernels, onde a linguagem de programação Brook+ (AMD, 2009), semelhante à linguagem C, é utilizada para a sua codificação. O modelo de programação do AMD Stream Computing é exibido na figura 2.6. Nesta arquitetura, cada instância de um Stream Kernel sendo executado em um Thread Processor é denominada Thread. Um vetor de Threads compõe o domínio de execução, onde estas são escalonadas para execução pelo Stream Processor em seus Thread Processors. Um novo Stream Kernel só será executado quando todas as Threads do domínio de execução tiverem sua execução terminada.. Figura 2.6: Modelo de programação simplificado do ATI Stream Computing. Fonte: (AMD, 2009).. 2.3.3 OpenCL Linguagem de Computação Aberta (Open Computing Language- OpenCL) foi criada para permitir a programação de aplicações GPGPU, de forma que possam executar nas GPUs de diferentes fabricantes. OpenCL foi o primeiro padrão aberto, livre de royalties, de programação de propósito geral para sistemas heterogêneos (NVIDIA, 2010c)..

(33) 33. A unidade de execução das aplicações codificadas utilizando OpenCL é chamada de kernel. GPUs da Nvidia e da ATI3 suportam a sua execução nas GPUs que fabricam. A utilização deste padrão não está restrito à geração de código para as GPUs, mas para CPUs de vários núcleos também (AMD, 2010c). Esta flexibilidade é obtida na especificação do tipo de kernel criado. Um kernel orientado à paralelização dos dados é melhor executado nas GPUs, enquanto um kernel projetado para paralelização de tarefas se adequa bem às CPUs (AMD, 2010c). Isso dá liberdade ao desenvolvedor para escolher a melhor arquitetura para resolver um determinado problema (HPCWIRE, 2008).. 2.4 Utilização de GPGPU em Grades Grades computacionais formadas por computadores de voluntários4 é uma das formas mais simples, baratas e eficientes de se obter o poder computacional de um supercomputador. Como modernas GPUs estão presentes em praticamente todos os computadores comprados recentemente, tarefas de computação de alto desempenho que envolva GPGPU podem ser executadas praticamente em qualquer computador (SINGH et al., 2008). As tarefas podem ser classificadas de acordo com a sua granularidade. Estas podem ser de grão fino ou grão grosso. Tarefas de grão fino apresentam pouco processamento a cada intervalo de comunicação pela rede, já nas de grão grosso há uma diferença maior entre o tempo gasto computando e as comunicações. SINGH et al. (2008) proporam uma arquitetura de grade computacional híbrida, onde as tarefas de grão grosso são processadas nas GPUs e as de grão fino são executadas nas CPUs dos computadores dos voluntários. As tarefas processadas envolvem comparação de genomas. Dois grandes projetos em computação paralela e distribuída, cuja grade é formada principalmente por computadores de voluntários, viram nas GPUs uma excelente plataforma para execução dos problemas a que se proporam resolver. Esta seção faz uma breve descrição de cada um deles. 2.4.1 Folding@home O poder computacional das GPUs está sendo utilizado pelo maior projeto em computação distribuída do Mundo, o Folding@home (STANFORD, 2010a). Esse projeto, nascido em meados do ano 2000 dentro da Universidade de Stanford, procura descobrir 3 4. Marca controlada pela AMD desde 2006. Usuários que voluntariamente colocam seus computadores à disposição da grade através da Internet..

(34) 34. como as proteínas do corpo humano se formam, a fim de encontrar uma ligação entre as más formações destas proteínas e as doenças por elas causadas (BEBERG et al., 2009). Qualquer pessoa pode ingressar nesse projeto e colocar o seu computador à disposição. Basta acessar o sítio do projeto e descarregar uma aplicação cliente. Há aplicações cliente especialmente desenvolvidas em Nvidia CUDA e ATI Stream Computing disponíveis para download. Quando executados, esses clientes acessam um servidor e o mesmo lhes designa alguma tarefa para computar. O cliente visa não prejudicar o desempenho do computador enquanto alguém estiver operando, só entrando em funcionamento em períodos onde ociosidade é detectada. Nesse sítio também é possível visualizar a superioridade computacional mensurada em Teraflops (TFLOPS) dos poucos clientes GPGPU se comparados à enorme quantidade de clientes CPUs cadastrados e ativos. A figura 2.7 exibe uma tabela5 comparativa desses clientes.. Figura 2.7: Poder computacional dos clientes do projeto Folding@home. Fonte: (STANFORD, 2010b).. Atente para as colunas Native TFLOPS e x86 TFLOPS. A primeira coluna informa quantos TFLOPS possuem os clientes, a segunda adequa esse valor a TFLOPS x86 por motivos explicados em (STANFORD, 2010c). Como exemplo da superioridade computacional das GPUs, observe as linhas Nvidia GPU e Windows. Podemos notar que há 9839 GPUs da Nvidia, cujo poder computacional combinado é de 2471 TFLOPS x86. Por outro lado, temos 313780 CPUs executando clientes no sistema operacional Windows e os mesmos oferecem apenas 298 TFLOPS. 5. Esta tabela é continuamente atualizada e podem haver diferenças em consultas futuras. Versão obtida em 22/2/2010..

(35) 35. 2.4.2 SETI@home ver esse artigo (ANDERSON et al., 2002). A invenção do rádio despertou o interesse científico em captar sinais de vida extra-terreste. O surgimento dos primeiros rádiotelescópios e avanços na tecnologia dos rádios permitiu aos cientistas aperfeiçoar a busca por sinais de rádio de civilização alienígenas. Contudo, não se conhecem os parâmetros desses sinais e a sensibilidade de uma busca exige um significativo poder computacional, conforme descrito em (KORPELA et al., 2001). SETI (Search for Extraterrestrial Intelligence) (BERKLEY, 2010) foi o primeiro projeto de computação distribuída em larga escala a entrar em operação (KORPELA et al., 2001). Tal projeto, lançado em 1999, permitiu que qualquer pessoa proprietária de um computador com conexão à Internet contribuísse para a identificação de ondas de rádio extraterrestres (BANSAL, 2001). Assim como o Folding@home, SETI@home também suporta a execução de tarefas nas GPUs. No sítio do projeto pode ser descarregado um cliente específico para GPUs. Porém, somente GPUs da Nvidia são suportadas até o momento..

(36) 36. 3 FRAMEWORK TUXUR. TUXUR é um framework de computação em grade que está sendo desenvolvido no Laboratório de Sistemas de Computação (LSC), localizado na Universidade Federal de Santa Maria (UFSM). Há uma dissertação em andamento descrevendo-o por completo. O trabalho a que se refere esta dissertação contribui para o seu desenvolvimento, implementando tal funcionalidade prevista em seu projeto. Neste capítulo são abordados primeiramente os objetivos e a contribuição do TUXUR para a área de processamento paralelo e distribuído. Os tipos de tarefas suportados por TUXUR são encontrados a seguir. Dando sequência, são abordadas duas características importantes deste framework. As descrições sobre os principais componentes do TUXUR encerram este capítulo.. 3.1 Objetivos e Contribuição TUXUR foi idealizado para permitir a utilização de recursos disponíveis em uma grade computacional de forma simples, transparente e eficiente. Os pontos chave atacados para lograr êxito nestes objetivos são as tarefas que serão gerenciadas por este framework, e quais nós as executarão. Para isso, as aplicações de computação paralela e distribuída gerenciadas por este framework são automática e dinamicamente divididas em aplicações menores, de acordo com a disponibilidade de recursos e poder computacional dos computadores que compõem a grade. Esta característica de dinamicidade em TUXUR não se restringe unicamente à divisão das tarefas, mas também no gerenciamento do número de computadores que integram a grade de computadores. Isso tem por objetivo permitir a inclusão/remoção de computadores a qualquer momento, seja antes ou durante a computação de alguma tarefa. Para melhorar a eficiência no aproveitamento dos recursos de uma grade computaci-.

(37) 37. onal, é fundamental que a diversidade de hardware existente nestes computadores seja explorada. TUXUR procura explorar a heterogeneidade dos ambientes computacionais que compõem a sua grade de computadores a fim de otimizar a sua utilização. Estas características do TUXUR pretendem contribuir para as pesquisas em frameworks de grades de computadores. Nas subseções seguintes são discutidos os tipos de tarefas suportadas, a importância em dividi-las dinamicamente e porque explorar ambientes heterogêneos para sua execução.. 3.2 Tipos de Tarefas Suportadas por Tuxur Para que TUXUR logre êxito em seus objetivos é necessário definir que tipos de tarefas permitem alcançá-los. Dentre os tipos de tarefas compatíveis com estes objetivos, optou-se por incluir suporte às tarefas do tipo Bag-of-Tasks (saco de tarefas) e maleáveis. Características destes dois tipos de tarefas são brevemente descritas em seguida. Maiores detalhes sobre outros tipos de tarefas podem ser obtidos em FEITELSON; RUDOLPH (1996). As tarefas classificadas como Bag-of-Tasks também podem ser classificadas como tarefas de carga divisível, mesmo que esta divisão não possa ser arbitrária (LIN et al., 2010). As tarefas que se enquadram nesta categoria não necessitam se comunicar enquanto executadas e não dependem uma das outras (COSTA; CIRNE; FIREMAN, 2005). Tarefas maleáveis podem ser consideradas as mais importantes para o TUXUR. Entendese por maleável uma tarefa capaz de originar subtarefas a partir dela. Isso abre a possibilidade de se criar uma subtarefa menor a partir de uma tarefa sabidamente demorada para ser resolvida. Em outras palavras, pode-se personalizar as tarefas para adequarem-se à capacidade computacional do computador escolhido para sua resolução. Foi este tipo de tarefa que motivou o desenvolvimento do TUXUR.. 3.3 Características Importantes Nesta sessão são abordadas duas das características importantes do TUXUR: Divisão Dinâmica de Tarefas e Heterogeneidade de Ambientes. O módulo implementado é beneficiado pela primeira e é fundamental para a segunda. As subsessões a seguir oferecem uma abordagem mais detalhada destas duas características..