Comparação De Aceleradores Amd, Nvidia E Intel Utilizando a Biblioteca Opencl

BRUNO MOKAN MUENCHEN

GPGPU: COMPARAÇÃO DE ACELERADORES AMD, NVIDIA E INTEL UTILIZANDO A BIBLIOTECA OPENCL

Ijuí,

2013

BRUNO MOKAN MUENCHEN

GPGPU: COMPARAÇÃO DE ACELERADORES AMD, NVIDIA E INTEL UTILIZANDO A BIBLIOTECA OPENCL

Trabalho realizado no Componente Curricular de Trabalho de Conclusão de Curso do Curso de Ciência da Computação da Universidade Regional do Noroeste do Estado do Rio Grande do Sul – UNIJUI, como requisito parcial à obtenção do titulo de Bacharel em Ciência da Computação.

Orientador: Edson Luiz Padoin

Ijuí

2013

BRUNO MOKAN MUENCHEN

GPGPU: COMPARAÇÃO DE ACELERADORES AMD, NVIDIA E INTEL UTILIZANDO A BIBLIOTECA OPENCL

Trabalho apresentado ao Componente Curricular de Trabalho de Conclusão de Curso do Curso de Ciência da Computação da Universidade Regional do Noroeste do Estado do Rio Grande do Sul – UNIJUÍ, como requisito parcial à obtenção do titulo de Bacharel em Ciência da Computação.

Aprovação em: ___/___/_____

______

Prof. Edson Luiz Padoin (Orientador) - UNIJUÍ

______

Prof. Rogério Samuel de Moura Martins - UNIJUÍ

Ijuí

2013

AGRADECIMENTOS

Primeiramente, quero agradecer à minha família, em especial à minha mãe, Lurdes, minha avó, Emília, e meu avô, Floriano, que sempre me deram apoio nesta longa caminhada que finda aqui, para o início de uma nova, na qual estou certo de que me ajudarão ainda mais. Também, gostaria de agradecer à minha namorada, Taís, que, assim como os amigos e os demais colegas, caminhou e continua caminhando comigo, agora em uma nova jornada. A todos os meus amigos, pelo companheirismo de todas as horas, em especial aos ex-colegas Wiliam Rambo e Ricardo Lorenzoni, pela ajuda de grande valia na execução deste trabalho e tantos outros durante o decorrer da graduação. Agradeço também aos demais colegas que andaram junto comigo. Aos professores, que participaram de minha formação como um todo, desde as séries iniciais até agora. Obrigado por terem me ensinado a aprender e por terem me auxiliado nas descobertas que fiz até aqui e, ainda, por terem me dado instrução sempre que precisei. Ao meu orientador, pelas orientações de grande valia na elaboração deste trabalho, desde a escolha do tema até a execução. Ao Grupo de Automação Industrial e Controle (GAIC), pela concessão dos equipamentos necessários à mensuração dos dados.

A todos vocês, Muito Obrigado!

“Os que se encantam com a prática sem a ciência são como os timoneiros que entram no navio sem timão nem bússola, nunca tendo certeza do seu destino”. (Leonardo da Vinci)

RESUMO

Este relatório aborda computação massivamente paralela com a utilização de aceleradores e as bibliotecas OpenCL. Atualmente passamos por um grande crescimento da área de computação de alto desempenho, aliado ao fato que os principais computadores do Green500 normalmente fazem uso de aceleradores vindos do mercado de jogos. Hoje existe a necessidade de tornar estes computadores em máquinas que consomem menos energia e que mantenham o mesmo ou até maior poder computacional. Dados estes fatores, esta pesquisa visa obter resultados que comprovem a melhoria da eficiência energética utilizando aceleradores, através de mensurações de desempenho utilizando benchmarks e do consumo energético, utilizando equipamentos específicos a este fim. Palavras-chave: GPGPU; OpenCL; Desempenho de Processadores; CUDA; AMD APP.

ABSTRACT

This report discusses massively parallel computing with the use of accelerators and OpenCL libraries. Currently we went through a major growth area of high performance computing, coupled with the fact that the main Green500 computers usually make use of accelerators coming from the gaming market. Today there is a need to make these computers in machines that consume less power and to keep the same or even greater computational power. Given these factors, this research aims to achieve results that prove the energy efficiency improvement using accelerators, through measurements using benchmarks of performance and energy consumption, using specific equipment for this purpose. Keywords: GPGPU; OpenCL; Performance Processors; CUDA, AMD APP.

LISTA DE FIGURAS

Figura 1 - Diagrama de Blocos - Fermi ...... 22 Figura 2 - Diagrama de Blocos - Kepler ...... 23 Figura 3 - Visão Geral da Arquitetura Graphics Core Next ...... 25 Figura 4 - Plataforma BMI Dranetz PP4300 ...... 40 Figura 5 - GPU NVIDIA utilizada nos testes ...... 42 Figura 6 - GPU AMD utilizada nos testes ...... 43 Figura 7 - Velocidade do Barramento (Host->Device) ...... 50 Figura 8 - Velocidade do Barramento (Device->Host) ...... 50 Figura 9 - Memória do Dispositivo ...... 51 Figura 10 - Desempenho de Pico com Precisão Simples ...... 52 Figura 11 - Desempenho de Pico com Precisão Dupla ...... 52 Figura 12 - Tempo de Compilação do Kernel ...... 53 Figura 13 - Tempo de Atraso na Execução do Kernel ...... 54 Figura 14 - Tempo de Execução do Benchmark FT ...... 54 Figura 15 - Desempenho Atingido Pelos Dispositivos ...... 55 Figura 16 – Consumo Energético dos Dispositivos Executando o FFT ...... 55 Figura 17 - Potência Média Durante a Execução do FFT ...... 56 Figura 18 - Eficiência Energética dos Dispositivos ...... 56 Figura 19 - Tempo de Execução do Algoritmo Leukocyte ...... 57 Figura 20 - Consumo Energético Executando Leukocyte ...... 57 Figura 21 - Potência Média dos Aceleradores Durante Execução do Leukocyte . 58 Figura 22 - Ligando o aparelho...... 70 Figura 23 – Inicialização do Dranetz...... 71 Figura 24 - Selecionando a sondagem de corrente...... 71 Figura 25 - Selecionando o tipo de sonda utilizada (TR2510)...... 72 Figura 26 – Tela principal do aparelho (acessando a tela de configurações)...... 72 Figura 27 - Acessando a opção 5: ADVANCED SETUP OPTIONS...... 73 Figura 28 – Acessando a opção 1: SET INPUT CONFIGURATIONS ...... 73 Figura 29 – Acessando a opção 3: SET SCALE FACTORS...... 73 Figura 30 – Ajuste do fator de escala dos canais...... 74 Figura 31 - Acessando a opção 4: SET SYNC PARAMETERS ...... 74 Figura 32 – Ajustando a frequência da rede elétrica...... 75 Figura 33 - Acessando a opção 5: SET INTERVAL FOR TIMED READINGS. .... 75 Figura 34 - Ajustando o intervalo em 5 segundos de medição dos dados...... 76 Figura 35 - Ligando o aparelho...... 76 Figura 36 - Inicialização do Dranetz...... 77 Figura 37 – Confirmando a utilização de sondagem de corrente...... 77 Figura 38 – Definindo o tipo da sonda utilizada...... 78 Figura 39 – Acessando menu para desabilitar canais desnecessários...... 78 Figura 40 – Canais B, C e D desativados...... 79 Figura 41 – Alterando a visualização da medição de energia...... 79

Figura 42 - Alterando para a próxima visualização da medição de energia...... 80 Figura 43 – Tela utilizada para acompanhar as medições de energia...... 80 Figura 44 – Acessando o menu de configurações...... 81 Figura 45 - Acessando a opção 4: MEMORY FUNCTIONS...... 81 Figura 46 - Acessando a opção 1: MEMORY CARD FUNCTIONS...... 81 Figura 47 - Acessando a opção WRITE CARD para salvar os dados coletados.. 82 Figura 48 - Salvar os dados coletados no cartão...... 82 Figura 49 – Removendo o cartão de memória na frontal direita do aparelho...... 83 Figura 50 - Salvando os dados para o computador ...... 83 Figura 51 - Tela principal do Dran-View...... 84 Figura 52 - Selecionando as informações desejadas...... 85

LISTA DE TABELAS

Tabela 1 - Comparativo entre arquiteturas NVIDIA ...... 21 Tabela 2 - Comparativo de GPUs NVIDIA e AMD ...... 26 Tabela 3 - Terminologia CUDA e Terminologia OpenCL ...... 33 Tabela 4 - Versões de drivers e SDK's ...... 40 Tabela 5 - Especificações da CPU Intel ...... 41 Tabela 6 - Especificações Técnicas GPU NVIDIA ...... 42 Tabela 7 - Especificações Técnicas GPU AMD ...... 43 Tabela 8 - Bus Speed Download (GB/s) ...... 86 Tabela 9 - Bus Speed ReadBack (GB/s) ...... 86 Tabela 10 - Peak FLOPS (SP) (GFLOPS) ...... 87 Tabela 11 - Peak FLOPS (DP) (GFLOPS) ...... 87 Tabela 12 - Device Memory (AMD) ...... 88 Tabela 13 - Device Memory (NVIDIA) ...... 88 Tabela 14 - Device Memory (Intel) ...... 89 Tabela 15 - Kernel Compilation (s) ...... 89 Tabela 16 - Queuing Delay (ms) ...... 90 Tabela 17 - Leukocyte (NVIDIA) ...... 90 Tabela 18 - Leukocyte (AMD) ...... 90 Tabela 19 - Fast Fourrier Transformations (NVIDIA) ...... 91 Tabela 20 - Fast Fourrier Transformations (Intel) ...... 91

SUMÁRIO

1. INTRODUÇÃO ...... 11 1.1. Justificativa ...... 11 1.2. Objetivos ...... 12 1.2.1. Objetivo Geral ...... 12 1.2.2. Objetivos Específicos ...... 13 2. MENSURAÇÃO DO CONSUMO ENERGÉTICO ...... 14 2.1. Tensão ...... 14 2.2. Corrente ...... 14 2.3. Potência ...... 15 2.4. Energia Consumida ...... 17 3. PROCESSADORES E ACELERADORES ...... 18 3.1. Processadores Intel ...... 18 3.2. Aceleradores NVIDIA ...... 19 3.3. Aceleradores AMD ...... 24 4. PROGRAMAÇÃO DE ACELERADORES ...... 28 4.1. Tecnologias ...... 28 4.1.1. OpenCL ...... 28 4.1.2. NVIDIA CUDA ...... 31 4.1.3. AMD APP ...... 33 5. BENCHMARKS ...... 35 5.1. Sintético ...... 36 5.2. Kernel ...... 36 5.3. Algoritmo ...... 37 5.4. Aplicação ...... 37 6. TESTES ...... 39 6.1. Ambiente de Trabalho ...... 39 6.2. Equipamentos para Testes ...... 40 6.2.1. Mensuração do Consumo Energético ...... 40 6.2.2. CPU Intel ...... 41 6.2.3. GPU NVIDIA ...... 42 6.2.4. GPU AMD ...... 43

6.3. Benchmark ...... 44 6.3.1. Scalable HeterOgeneous Computing Benchmark Suite ...... 44 6.3.2. SNU NPB ...... 45 6.3.3. Rodinia Benchmark Suite ...... 47 7. RESULTADOS E DISCUSSÃO ...... 49 7.1. Resultados Benchmark SHOC ...... 49 7.1.1. Velocidade do Barramento ...... 49 7.1.2. Acesso às memórias ...... 51 7.1.3. Desempenho Máximo Atingido ...... 51 7.1.4. Compilação e Atraso na Execução do Kernel ...... 53 7.2. Resultados Benchmark SNU NPB ...... 54 7.3. Resultados Benchmark Rodinia ...... 56 8. CONSIDERAÇÕES FINAIS ...... 59 8.1. Trabalhos Futuros ...... 60 REFERÊNCIAS BIBLIOGRÁFICAS ...... 61 ANEXOS ...... 67

1. INTRODUÇÃO

Nos últimos anos, a discussão a respeito do esgotamento dos recursos naturais como os combustíveis fósseis, aumento da poluição e aumento exponencial de consumo de recursos energéticos tem ganhado cada vez mais foco. No cenário tecnológico, até alguns anos atrás, as indústrias competiam entre si em busca de criar processadores cada vez mais rápidos. Para vencer essa competição elas aumentavam a frequência de trabalho de seus produtos, até que chegaram aos limites que os processadores suportavam sem superaquecer, mas aumentando também o consumo de energia dos mesmos. Esse problema de superaquecimento soluciona-se com o uso de coolers mais robustos e maiores, com a finalidade única de resfriar o processador. Neste ponto as indústrias notaram que o custo de aumentar ainda mais a frequência de clock dos processadores iria se tornar alto demais, visto o grande desperdício de energia térmica nas máquinas. Para solucionar o problema do superaquecimento, as indústrias optaram por reduzir a frequência de seus equipamentos (reduzindo a dissipação de energia térmica) e aumentar a sua capacidade de processamento. Fizeram isso aumentando o número de núcleos presentes dentro de cada processador, podendo, assim, processar um maior número de informações ao mesmo tempo com uma quantidade igual de energia, fazendo um consumo mais eficiente da mesma. Com o passar do tempo, foram surgindo novas tecnologias para processamento e as empresas foram investindo cada vez mais em soluções que pudessem facilmente aliar poder computacional com economia de energia. Atualmente, a grande maioria dos computadores pessoais possui acelerador gráfico, o que certamente foi um grande impulso na criação de sistemas heterogêneos, onde não apenas o processador principal executa as instruções, mas as mesmas podem ser passadas para um processador gráfico executá-las de forma paralela, em um conceito chamado de General Purposes computation on Graphics Processing Unity (GPGPU).

Neste trabalho, pretendemos estudar os ganhos em desempenho e a velocidade de processamento que podem ser proporcionados pela utilização de aceleradores gráficos para o processamento de propósito geral. Pretendemos, também, realizar testes de consumo energético e desempenho tanto utilizando estes aceleradores como sem fazer uso dos mesmos, testando o que a arquitetura x861 tem a oferecer com o uso do padrão OpenCL.

1.1. Justificativa

O grande crescimento na área de computação de alto desempenho faz com que surjam cada vez mais pesquisas por tecnologias capazes de aliar melhor desempenho e menor consumo energético. Duas dessas tecnologias são a CUDA, da NVIDIA, e a APP, da AMD. A grande diferença dessas tecnologias com relação às demais existentes é o fato de que elas permitem a utilização da Unidade de Processamento Gráfico (GPU) no processamento de tarefas que até então cabiam exclusivamente à Unidade Centrar de Processamento (CPU). Além disso, um dos assuntos que mais cresce em todos os sentidos no mundo hoje é a economia de energia e a utilização consciente dos recursos naturais, seja por parte de computadores pessoais como também por parte de supercomputadores aplicados à computação de alto desempenho, como datacenter e computadores de centros de pesquisa. A crescente demanda pela utilização de aceleradores para contribuir com o poder de processamento das máquinas atinge não somente o mercado de alto desempenho, como os supercomputadores utilizados por órgãos governamentais, mas, também, o mercado do consumidor final, tendo como base a adesão de várias empresas da indústria de software a utilizar padrões de programação voltados a arquiteturas heterogêneas, visando acelerar seus softwares e aumentar a produtividade do usuário final. Com preocupação a atender tanto a dispositivos da NVIDIA quanto a

1 Arquitetura x86: Tipo de arquitetura de processadores utilizada principalmente em computadores pessoais. Ver (EDWARDS, 2008)

dispositivos da AMD, além das arquiteturas de 32 e 64 bits que não fazem uso de aceleradores, surgiu o padrão de programação OpenCL, que permite a execução do software em ambos os casos. A escolha das arquiteturas em questão se justifica por estarem entre as mais utilizadas hoje para o desenvolvimento de supercomputadores e por serem líderes do mercado de gráficos para jogos e aplicações que demandem grande quantidade de processamento 3D.

Sete dos 10 primeiros computadores da lista dos mais verdes mudaram nesta última edição da lista Green 500. Entretanto, apesar desta reviravolta significativa, os supercomputadores mais verdes no mundo continuam seguindo uma das duas tendências: (1) agregar muitos processadores de baixo consumo, como o IBM BlueGene/Q e (2) usar aceleradores energeticamente eficiente, tipicamente do mercado de jogos/gráficos, por exemplo a AMD Radeon GPU, NVIDIA Tesla Fermi GPU, Cell, e Intel Knights Corner, para complementar o uso de processadores Intel e AMD.

(GREEN500, 2012)

Portanto, a intenção deste trabalho é buscar o conhecimento acerca dos aceleradores escolhidos para realização dos testes, comparando o seu desempenho, velocidade e consumo, utilizando o padrão de programação OpenCL, que é muito utilizado por vários softwares comerciais que exigem um alto poder de processamento, e procurar aprender mais sobre CUDA e APP, visando trabalhos futuros na área de computação de alto desempenho.

1.2. Objetivos

1.2.1. Objetivo Geral

• Comparar o desempenho, a velocidade e o consumo das GPUs selecionadas e o ganho em relação a CPU usando o padrão OpenCL.

1.2.2. Objetivos Específicos

• Mensurar o consumo de energia dos aceleradores NVIDIA e AMD e do processador Intel;

• Mensurar a diferença de desempenho dos aceleradores e do processador executando os algoritmos dos benchmarks selecionados;

• Computar os dados obtidos das mensurações e avaliar a eficiência energética dos aceleradores e do processador

2. MENSURAÇÃO DO CONSUMO ENERGÉTICO

A mensuração do consumo energético dos equipamentos é o ponto chave da pesquisa, pois através dela, em conjunto com os resultados de desempenho dos benchmarks, foi possível comparar os equipamentos. Para tanto, existem alguns conceitos de eletricidade que devem ser considerados.

2.1. Tensão

A tensão é a pressão elétrica que causa a circulação de corrente. A tensão é também conhecida como força eletromotriz (fem), ou diferença de potencial. Todos estes termos se referem à força que coloca cargas em movimento. A diferença de potencial é o termo que melhor descreve o fenômeno porque uma tensão é uma diferença de energia potencial que existe entre dois pontos. O símbolo da tensão é V(volt).

(FOWLER, 1992)

De acordo com Gussow (1996) “A unidade fundamental de diferença de potencial é o volt (V). O símbolo usado para a diferença de potencial é V, que indica a capacidade de realizar trabalho ao se forçar os elétrons a se deslocarem”.

2.2. Corrente

A corrente elétrica é o resultado do movimento de cargas elétricas. A unidade SI de corrente é o ampère, cujo símbolo é A. os símbolos utilizados são o I para uma corrente constante e i para uma corrente variável no tempo. Se um fluxo constante de 1C de carga passa por um dado ponto em um condutor durante 1 s, a corrente resultante é 1A.

(O'MALLEY, 1993)

O movimento ou o fluxo de elétrons é chamado corrente. Para se produzir corrente, os elétrons devem se deslocar pelo efeito de uma diferença de potencial. A corrente é representada pela letra I. A unidade fundamental com que se mede a corrente é o ampère (A). Um ampère de corrente é definido como o deslocamento de um coulomb através de um ponto qualquer de um condutor durante um intervalo de tempo de um segundo.

(GUSSOW, 1996)

Segundo Fowler (1992) “A abreviatura para ampère é A. Por exemplo, para indicar que a corrente num fio é de 10 ampères, escrevemos I = 10 A”. Onde: I = corrente, A (Ampère) Q = carga, C (Coulomb) T = tempo, s

CORRENTE ALTERNADA

Uma fonte de tensão alternada (Tensão CA) inverte ou alterna periodicamente a sua polaridade. Consequentemente, o sentido da corrente alternada resultante também é invertido periodicamente. Em termos do fluxo convencional, a corrente flui do terminal positivo da fonte de tensão, percorre o circuito e volta para o terminal negativo, mas quando o gerador alterna a sua polaridade, a corrente tem de inverter o seu sentido.

(GUSSOW, 1996)

CORRENTE CONTÍNUA

Corrente contínua se refere ao fluxo de cargas em um único sentido. Uma bateria produz uma corrente contínua em um circuito porque seus terminais sempre possuem a mesma polaridade. Os elétrons se movem do terminal negativo, que os repele, para o terminal positivo, que os atrai, sempre no mesmo sentido de movimento ao longo do circuito.

(HEWITT, 2002)

2.3. Potência

Para Fowler (1992) a potência se refere a quão rapidamente a energia é usada ou convertida noutra forma de energia. Desde que a energia é a capacidade em realizar trabalho, pode-se dizer que a potência está relacionada com a rapidez na realização do trabalho. Segundo Fowler (1992) combina-se estas duas ideias na definição de

potência, que é a taxa de uso da energia ou realização de trabalho. O símbolo de potência é P. De acordo com Fowler (1992) na eletricidade, o joule é usado como unidade base de energia e o segundo como unidade base de tempo. Portanto a unidade de potência é o joule por segundo (J/s). Ele é denominado watt em homenagem ao físico e inventor escocês James Watt. Para Fowler (1992) a unidade base de potência é o watt, que é igual a 1 J/s e cuja abreviatura é W.

Energia (W) ê ( ) = Tempo (t) 푃표푡 푛푐푖푎 푃

A unidade básica de potência é o WATT e é igual a tensão aplicada ao circuito multiplicada pela corrente que flui neste circuito. Isso representa a razão, em qualquer instante, de execução de trabalho pelo movimento de elétrons no circuito. O símbolo P indica potência elétrica. Assim a fórmula de potência é: P=EI. E é a tensão e I é a corrente que flui no resistor ou no circuito cuja potência está sendo medida. A quantidade de potência mudará quando a tensão, a corrente, ou ambos, mudarem

(MARINHA DOS ESTADOS UNIDOS, 1998)

A razão na qual algum corpo absorve ou produz energia é a potência absorvida ou produzida por este corpo. Uma fonte de energia produz ou desenvolve energia, e uma carga absorve energia. A unidade SI da potência é o watt, cujo símbolo é W. O símbolo de potência é P para potências constantes e p para potências variáveis no tempo. Se 1 J de trabalho é absorvido ou liberado numa taxa constante de 1 s, a potência correspondente é 1W.

(O'MALLEY, 1993)

CALCULO DE POTÊNCIA:

A potência é igual à corrente vezes tensão. Expresso como uma fórmula, tem-se: Potência (P) = corrente (I) X tensão (V) Ou P = VI A potência está na sua unidade base quando a tensão é dada em volts e a corrente em ampères.

(FOWLER, 1992)

2.4. Energia Consumida

A energia elétrica consumida ou produzida é o produto da corrente elétrica de entrada ou saída e o tempo durante o qual essa entrada ou saída ocorre:

( ) = ( ) ( )

푊 푗표푢푙푒푠 푃 푊푎푡푡푠 ∗ 푡 푠푒푔푢푛푑표푠 Energia elétrica é aquilo que os consumidores compram das companhias elétricas. Essas companhias não usam o joule como unidade de energia. A unidade utilizada é o quilowatt-hora (KWh), por ser maior e mais conveniente. O KWh não é uma unidade SI. O número de KWh consumidos é igual ao produto da potência absorvida em KW e o tempo durante o qual ocorreu esse consumo:

( ) = ( ) ( )

푊 푞푢푖푙표푤푎푡푡푠 − ℎ표푟푎 푃 푞푢푖푙표푤푎푡푡푠 ∗ 푡 ℎ표푟푎 (O'MALLEY, 1993)

3. PROCESSADORES E ACELERADORES

Para que os testes tivessem uma maior abrangência os mesmos foram executados tanto usando as GPUs como também CPUs. Ressaltaremos, então, algumas características das diferentes arquiteturas utilizadas.

3.1. Processadores Intel

A Intel possui duas principais famílias de processadores, Intel Core e Intel Xeon. A família Core é voltada para o mercado de desktops e notebooks, enquanto a família Xeon é voltada para servidores e computação de alto desempenho.

A visivelmente inteligente família de processadores Intel® Core™ proporciona um desempenho incrível e visual deslumbrante entregues por uma gama de tecnologias Intel ®. Desfrute de imagens brilhantes e uma experiência de computação integrada - independente se você está criando, compartilhando, explorando, ou jogando.

(INTEL, 2012)

Arquitetado para vários processadores dual-core para executar cargas de trabalho intensivas 32-bit e 64-bit, sistemas baseados na série Dual-Core Intel ® Xeon ® 7100 ajudam a resolver os mais difíceis desafios de TI com a escalabilidade, flexibilidade e confiabilidade necessárias para tirar o máximo de qualquer orçamento de TI.

(INTEL, 2012)

Em contrapartida ao fato de as GPUs serem cada vez mais utilizadas em computadores de alto desempenho, a Intel lança o coprocessador Intel Xeon Phi como um acelerador para competir com os aceleradores atuais da NVIDIA e da AMD. O coprocessador Intel Xeon Phi pode acelerar dramaticamente o desempenho de suas aplicações altamente paralelas para ajuda-lo a atingir os limites da inovação e das descobertas científicas – sem necessitar que seus desenvolvedores reinventem a roda.

(INTEL, 2012)

Specifcações chave: • 60 cores/1.053 GHz/240 threads • Até 1 terafops desempenho precisão dupla • 8 GB de memória e 320 Gb/s de largura de banda • Padrão PCIe x16* • Sistema operacional Linux *, endereçável por IP • Suportado pelos produtos de desenvolvimento de software mais recentes da Intel • Engine de vetor de 512-bit • 32 Kb L1 I/D cache, 512 KB de cache L2 (por núcleo) • 8 Gb de memória GDDR5 (até 320 Gb/s) • 225W TDP • PCIe X16 (requer host IA) • Host OS: Red Hat Enterprise Linux 6.x, SuSE Linux 12 +

(INTEL, 2012)

Alguns dos centros de computação de alto desempenho de maior sucesso atualmente já estão usando o coprecessador Intel Xeon Phi para atingir capacidades de computação massivamente paralelas.

• O Texas Advanced Computer Center lançará em breve um supercomputador de 20 PETAFLOPS que irá incluir milhares de coprocessadores Intel Xeon Phi

• O projeto DEEP está usando a família E5 do processador Xeon e coprocessadores Intel Xeon Phi como fundação para "uma plataforma computacional habilitada para exascale"

• A Intel construiu um pequeno protótipo de cluster utilizando coprocessadores Xeon Phi que atingiram o ranking de 150º maior supercomputador no mundo

(INTEL, 2012)

3.2. Aceleradores NVIDIA

A NVIDIA possui várias séries de arquiteturas de GPUs com as quais desenvolve seus aceleradores. As principais hoje são a Fermi e a Kepler.

Fermi é a primeira arquitetura de computação a oferecer um nível tão elevado de precisão dupla de ponto flutuante e um único chip com uma hierarquia de memória flexível e com proteção a erros e suporte para linguagens como C + + e FORTRAN. Como tal, Fermi é a primeira arquitetura de computação completa do mundo.

(GLASKOWSKY, 2009)

A próxima geração da arquitetura CUDA da NVIDIA, codinome Fermi, acrescenta novos e poderosos recursos para computação de propósito geral. Os processadores Fermi vão continuar assumindo as cargas de trabalho de gráficos em PCs e consoles de video-game, mas estão dando um grande passo para se tornar um parceiro das CPUs. GPUs não devem mais ser um recurso subutilizado.

(HALFHILL, 2009)

A arquitetura Fermi é a sucessora da arquitetura Tesla e predecessora da nova arquitetura Kepler, recentemente lançada pela NVIDIA.

A arquitetura Tesla, introduzida em novembro de 2006 na GPU GeForce 8800, unifica os processadores de vértice e pixel e estende-se a eles, permitindo elevado desempenho em aplicações de computação paralela escrita na linguagem C usando o Compute Unified Device Architecture (CUDA2-4), um modelo de programação paralela e toolkit. A Tesla unificou arquiteturas de gráficos e computacional, está disponível em uma escalável familia da série GeForce 8 e Quadro, para laptops, desktops, estações de trabalho e servidores. Ela também oferece a arquitetura de processamento para plataformas computacionais Tesla introduzida em 2007 para computação de alto desempenho.

(LINDHOLM, NICKOLLS, et al., 2008)

A arquitetura Kepler da NVIDIA foi construída sobre o fundamento estabelecido pela primeira vez em 2010, com as GPUs da arquitetura Fermi. A arquitetura Fermi introduziu um pipeline de geometria inteiramente novo paralelo otimizado para mosaico e mapeamento de deslocamento. Isso tornou possível para jogos como Battlefield 3, Batman: Arkham City, e Crysis 2 para usar personagens ricamente detalhados e ambientes, mantendo o alto desempenho. Kepler continua a oferecer o melhor desempenho de tessellation e combina isso com novas funcionalidades especificamente concebidas para proporcionar uma mais rápida, mais suave, mais rica experiência de jogo.

(NVIDIA, 2012)

A primeira GPU baseada na nova arquitetura Kepler, de codinome “GK104”, não é apenas nossa GPU de maior desempenho hoje, ela é também a mais eficiente em termos de consumo de energia. A GK104 é fabricada num processo otimizado de 28nm, e cada unidade interna foi desenhada para o melhor desempenho/watt possível. O primeiro produto a ser introduzido baseado na GK104 é a GeForce GTX680.

(NVIDIA, 2012)

Na Tabela 1, podemos observar um comparativo entre ambas as arquiteturas de GPUs da NVIDIA.

Tabela 1 - Comparativo entre arquiteturas NVIDIA

GPU GT200 (Tesla) GF110 (Fermi) GK104 (Kepler) Transistores 1.4 bilhões 3.0 bilhões 3.54 bilhões CUDA Cores 240 512 1536 Clock do Núcleo Gráfico 648MHz 772MHz 1006MHz Clock do Shader 1476MHz 1544MHz n/a GFLOPs 1063 1581 3090 Unidades de Textura 80 64 128 Taxa preenchimento de Texel 51.8 Gigatexels/sec 49.4 Gigatexels/sec 128.8 Gigatexels/sec Clock de Memória 2484 MHz 4008 MHz 6008MHz Largura de Banda de Memória 159 GB/sec 192.4 GB/sec 192.26 GB/sec Nº Máx. Displays Ativos 2 2 4 TDP 183W 244W 195W Fonte: NVIDIA (2012)

Quando desenhando nossa arquitetura Fermi da geração anterior, engenheiros da NVIDIA deram foco em aumentar dramaticamente a performance em comparação com a geração Tesla (GT200), com ênfase especial em geometria, tesselation, e performance computacional para DirectX11. O pensamento da gestão de consumo de energia foi uma consideração importante durante o desenvolvimento da Fermi, atingir níveis inéditos de desempenho DX11 foi o objetivo principal. Para a Kepler nos tivemos uma abordagem diferente. Enquanto mantendo nossa performance lider em graficos continuou sendo o objetivo mais importante, o tema principal de condução do projeto Kepler foi aumentar drasticamente o desempenho por watt. Os engenheiros da NVIDIA aplicaram tudo que foi aprendido da Fermi para melhor otimizar a Kepler para operação altamente eficiente, em adição a melhorar significativamente o desempenho.

(NVIDIA, 2012)

O GPC (Graphics Processing Cluster) é o bloco de hardware de alto nível dominante na GF100. Ele traz duas inovações chave – um Raster Engine escalável para triangulos, rasterização e Z-cull, e um PolyMorph Engine, para atributos de vertex e tessellation. A Raster Engine fica dentro do GPC, enquanto a PolymorphEngine fica no SM. Como o nome indica, o GPC encapsula todas as unudades de processamento gráfico. Ele representa uma combinação balanceada de recursos de processamento de pixel de vertex, geometria, raster, textura e pixel. Com exceção das funções do ROP, um GPC pode ser pensado como uma GPU em si, e a GF100 tem quatro GPCs! Em GPUs anteriores da NVIDIA, Unidades de Textura e SMs eram agrupados em blocos de hardware chamados Texture Processing Clusters (TPCs). Na GF100, cada SM tem quatro unidades de textura dedicadas, eliminando a necessidade de TPCs.

(NVIDIA, 2010)

Na Figura 2 e Figura 1 podemos observar a diferença no diagrama de blocos das arquiteturas Fermi e Kepler. Enquanto a arquitetura Fermi tem seis GPCs, a Kepler tem apenas quatro. Além disso, o número de controladores de memória também diminuiu de seis para quatro e cada Raster Engine tem apenas duas Polymorph Engine. A arquitetura Kepler também conta com conexão PCI Express 3.0.

Figura 1 - Diagrama de Blocos - Fermi

Fonte: NVIDIA (2010)

Figura 2 - Diagrama de Blocos - Kepler

Fonte: NVIDIA (2012)

Primeiramente, usuários construíam supercomputadores adicionando múltiplas GPUs aos PCs e estações de trabalho, e conjuntos montados de nós de computação GPU. Em 2007, em resposta a demanda de sistemas computacionais com GPU, NVIDIA introduziu a placas gráficas Tesla C870, D870 e S870, e sistemas de computação deskside e rack contendo um, dois e quatro GPUs T8. A GPU T8 foi baseada na GPU GeForce 8800, configurada para computação paralela. A segunda geração de sistemas computacionais, Tesla C1060 e Tesla S1070, introduzida em 2008, usava a GPU T10. A T10 continha 240 núcleos de processamento, um TERAFLOP/s máximo de desempenho de ponto flutuante de precisão simples, ponto flutuante

de precisão dupla IEEE 754-2008, e 4GB de memória DRAM. Hoje existem systemas Tesla S1070 com milhares de GPUs largamente em sistemas de computação de alta performance em produção e pesquisa.

(NICKOLLS e DALLY, 2010)

3.3. Aceleradores AMD

Os aceleradores da AMD dividem-se principalmente entre as arquiteturas Terascale 2 e Graphics Cores Next (GCN)

As GPUs da serie Radeaon 5000, também conhecidas como Evergreen, foram disponibiliadas no fim de 2009. Estas GPUs utilizam a arquitetura Terascale 2, que foi produzida para suportar DirectX 11. A AMD Radeon 5870 e parte dessa familia de GPUs. Ta serie Radeon 6000, conhecida como Northern Islands, não tras muitas modificações na arquitetura da serie 5000, mas simplesmente inclui suporte para múltiplas saídas gráficas.

(LEE, 2012)

A série 7000, conhecida como Southern Islands, representa uma grande mudança em relação as arquiteturas anteriores da AMD. As unidades de computação tradicionalmente baseadas em gráficos foi substituída pela arquitetura de propósito mais geral Graphics Cores Next (GCN). Uma das maiores mudanças dessa arquitetura é a eliminação do Very Long Instruction Word (VLIW). Isso permite aplicações de propósito geral obterem uma utilização maior da GPU.

(LEE, 2012)

Figura 3 - Visão Geral da Arquitetura Graphics Core Next

Fonte: LEE (2012)

A GPU AMD Radeon E6760 e baseada na arquitetura TeraScale 2. A arquitetura MIMD consiste de seis motores SIMD, com cada SIMD consistindo de 16 stream cores (SCs), compartilhamento de dados local (LDS) de 32KB e cache L1 de 16KB. Cada SC consiste de cinco elementos de processamento (PEs) organizados em uma unidade de execução VLIW de 5 caminhos atingindo ate cinco FP32-bit MACs por ciclo de clock. Os 32KB LDS permitem baixa latência no compartilhamento de dados, sincronização e comunicação dos 16 SCs dos SIMD. 64KB de compartilhamento global de dados (GDS) é compartilhado pelos seis SIMDs e acessível pela CPU através do barramento PCI Express. Os 128KB de cache L2 coalesce leitura e escrita de memoria para otimizar o acesso da GPU a memória de 1GB GDDR5. Usando o barramento PCI Express, o host carrega o processador de comando e o processador de envio ultra-threaded distribuí os segmentos de processamento aos SIMDs e SCs. Com um total de 480 Pes, a Radeon E6750 atinge ate 576GFLOPs SP (pico a 600MHz de clock) com um TDP de cerca de 35W

(MANDL e BORDOLOI, 2011)

As GPUs AMD atuais tem um grande número de ALUs, unidades de busca de textura e um grande arquivo de registro. As velocidades listadas na Tabela I foram obtidas de informações listadas no Catalyst Control Center. Houveram três gerações de GPUs AMD que suportaram o StreamSDK, a RV670, RV770 e RV870. Essas GPUs são oferecidas em muitas placas diferentes. A RV670 não suporta OpenCL. Para o objetivo deste artigo a RV670 foi testada usando uma placa de vídeo 3870, a RV770 foi testada usando uma 4870 e a RV870 foi testada usando uma 5870.

Tabela I: Recursos de Hardware da GPU

(LI, 2010)

Na Tabela 2 podemos observar um comparativo entre GPUs NVIDIA e AMD.

Tabela 2 - Comparativo de GPUs NVIDIA e AMD

NVIDIA NVIDIA Tesla AMD Radeon AMD Radeon

GTX280 2075 HD 5870 HD 7970 AMD Nome NVIDIA Low NVIDIA High AMD High Low/Discrete Unidades de 30 14 20 32 Computação Processadores 240 448 1600 2048 Stream Frequencia da 1296MHz 1147 MHz 850 MHz 925 MHz GPU Tam Max. Grupo 512 1024 256 256 de Trabalho Memória 1GB 6GB 512MB 3GB Tipo Barramento GDDR3 GDDR5 GDDR5 GDDR5 Memória Tipo de Cache Nenhum Leitura/Escrita Nenhum Leitura/Escrita Tamanho de 0 128 0 64 Linha do Cache Tamanho do 0 229736 0 16384 Cache

Fonte: LEE (2012)

A GPU AMD Radeon HD5870 fornece 2.72 TFLOPS/s de poder computacional com precisão simples, com no máximo 188 watts de potência (14.47 GFLOPS/W). Comparativamente, a segunda geração dos processadores Intel I7 975 (CPU Quad-Core) fornece 14 GFLOPS/s, equanto consomo 130 watts de potência (0.11 GFLOPS/W). Execução especulativa agressiva seria muito mais eficiente de energia

em GPUs comparado com CPUs. Por último, mas não menos importante, os aprimoramentos de software e hardware têm sido feitos para melhorar a precisão de ponto flutuante em uma GPU. A AMD recentemente adicionou instruções de operação Fused Multi- Architecture na serie HD 500 da linha Radeon, e melhorou a velocidade e precisão de muitas computações envolvendo accumulação de produtos.

. AMD recently has added Fused Multiply-Accumulate operation instructions to the Radeon line in the HD 5000 series, and improved the speed as well as accuracy of many computations involving the accumulation of products. GPUs estão constantemente se movendo em direção da IEEE 754-2008.

(SUN e KAELI, 2011)

4. PROGRAMAÇÃO DE ACELERADORES

Nesta seção falaremos sobre OpenCL, CUDA e AMD APP, as principais tecnologias disponíveis atualmente para programação com GPGPU, suas características e aplicações.

4.1. Tecnologias

A GPGPU está ganhando cada vez mais força em computação de alto desempenho, sendo que as arquiteturas heterogêneas que utilizam GPUs para processamento de dados massivamente paralelos já são uma das principais opções na construção de supercomputadores.

GPU computing é o uso de uma GPU (unidade de processamento gráfico), juntamente com uma CPU para acelerar aplicações de uso geral científicas e de engenharia. Pioneira há cinco anos pela NVIDIA, a computação GPU tornou-se rapidamente um padrão da indústria, apreciado por milhões de usuários no mundo todo e adotada por praticamente todos os fornecedores de computação.

(NVIDIA, 2012)

GPGPU significa computação de propósito geral em unidades de processamento gráfico, também conhecida como computação GPU. Unidades de Processamento Gráfico (GPUs) são processadores com muitos núcleos de alto desempenho capazes de executar muita computação e transferência de dados. Uma vez projetado especialmente para computação gráfica e difíceis de programar, GPUs de hoje são processadores paralelos de uso geral com suporte para interfaces de programação e linguagens padrão da indústria, como programação em C. Quem portar suas aplicações para GPUs muitas vezes vão alcançar acelerações de ordens de magnitude vs. implementações otimizadas de CPU.

(GPGPU.ORG, 2012)

4.1.1. OpenCL

O OpenCL foi desenvolvido com a finalidade de se tornar um padrão em computação paralela heterogênea. Segundo a NVIDIA (2012), “OpenCL é

uma marca comercial da Apple Inc., usada sob licença pela Khronos”.

OpeCL disponibiliza uma linguagem comum, interfaces de programação e abstrações de hardware possibilitando programadores acelerar aplicações com paralelismo de dados e paralelismo de tarefas em um ambiente de computação heterogêneo consistindo de CPU e qualquer “dispositivo” OpenCL. Dispositivos OpenCL podem ou não compartilhar a memória com a CPU, e tipicamente tem um conjunto de instruções de máquina diferente., para que as interfaces OpenCL assumam heterogeneidade entre o host e qualquer dispositivo acoplado. As interfaces de programação chave provides pelo OpenCL incluem funçõe para enumeração de dispositivos disponíveis (CPUs, GPUs e Aceleradores de vários tipos), gerenciando “contextos” que contém os dispositivos a serem utilizados, gerenciando alocações de memória, desempenhando transferências de dados da memória global para a do dispositivo compilando funções de programas e “kernels” OpenCL para serem executados nos dispositivos alvo, verificando o progresso da execução e checando erros.

(STONE, GOHARA e SHI, 2010)

OpenCL ™ é o primeiro padrão aberto livre de royalties para multi-plataforma, a programação paralela de processadores modernos encontrados em computadores pessoais, servidores e dispositivos portáteis / incorporado. OpenCL (Open Computing Language) melhora muito a velocidade e capacidade de resposta para um amplo espectro de aplicações em categorias do mercado de inúmeros jogos e entretenimento para software científico e médico.

(KHRONOS GROUP, 2012)

Atualmente, ambos AMD e NVIDIA oferecem suporte a OpenCL em suas GPUs, sendo que esse suporte é mais amplamente oferecido pela AMD. Programas escritos em OpenCL também podem ser executados em arquiteturas x86, sendo que a AMD e a Intel fornecem suporte à mesma.

OpenCL™ (Open Computing Language) é uma API de baixo nível para computação heterogênea que roda em CUDA-powered GPUs. Usando a API do OpenCL, os desenvolvedores podem executar kernels escritos usando um subconjunto limitado da linguagem de programação C em uma GPU.

(NVIDIA, 2012)

OpenCL™ é o primeiro padrão de programação verdadeiramente aberto e livre de royalties para uso geral em sistemas heterogêneos. OpenCL ™ permite que os programadores evitem a necessidade de investir no código fonte e facilmente desenvolvam tanto para CPUs multi-core quanto para GPUs mais recentes, como os da AMD.

(AMD, 2012)

OpenCL é um padrão aberto para um modelo de programação unificado oferecendo suporte tanto da CPU como do processador gráfico. Ele é projetado para ser usado com aplicações altamente paralelas e para aplicações de visão computacional, incluindo vídeo, mídia e conteúdo 3D.

(INTEL, 2012)

• API Cross-plataform de computação paralela e linguagem C-like para dispositivos de computação heterogêneos; • Código é portátil através de dispositivos-alvo diferentes: o Garantia de estar correto; o Desempenho de um kernel dado não é garantida através de dispositivos alvo diferentes; • Implementações OpenCL já existem para GPUs AMD e NVIDIA, CPUs x86; • Em princípio, OpenCL poderia também ser executado em DSPs, Cell e talvez FPGAs;

(HWU e STONE, 2010)

Programas OpenCL são divididos em duas partes: uma que excuta no dispositivo (GPU) e outra que executa no host (CPU). O device program é a parte do código que usa GPU para execução paralela. Programadores tem que escrever funções especiais chamadas kernel que usam a Linguagem de Programação OpenCL (uma extensão da linguagem de programação C). Estes kernels são escalonados para serem executados na GPU. O programa do host oferece uma API para que o programador possa gerenciar a execução dos kernels no dispositivo. O programa do host pode ser programado em C ou C++ e ele controla o ambiente OpenCL

(OANCEA, ANDREI e DRAGOESCU, 2012)

Ambos AMD e NVIDIA disponibilizaram implementações OpenCL para suas respectivas GPUs. ]estes dispositivos necessitam de um grande número de work-items e work-groups OpenGL para saturar completamente o hardware e esconder a latência. GPUs NVIDIA usam uma arquitetura de processador escalar para os PEs indivuduais vistos pelo OpenCL, proporcionado-os a trabalharem com uma alta eficiência na maior parte dos tipos de dados OpenCL. GPUs AMD usam uma arquitetura vetorial, e tipicamente obtém melhor performance de forma que os work-items OpenCL podem trabalhar em tipos vetoriais de quarto elementos, como o float4. Em muitos casos, um kernel OpenCL vetorizado pode ser construido para executar bem em CPUs x86, e em GPUs AMD e NVIDIA, embora o código do kernel resultante pode ser menos legível do que o equivalente escalar. Diferenças na arquitetura de baixo nível das GPUs incluindo qual memória vai para o cache o quais os padroes de acesso a memória criam conflitos de bancos que afetam o melhor desempenho do kernel. Differences in low level GPU architecture including variations on what memory is cached and what

memory access patterns create bank conflicts affect kernel optimality. Literatura sobre OpenCL fornecida pelo fabricante normalmente contém diretrizes de otimização de baixo nível.

(STONE, GOHARA e SHI, 2010)

4.1.2. NVIDIA CUDA

A CUDA é uma arquitetura desenvolvida pela NVIDIA, que consiste da utilização de placas gráficas específicas, que suportem essa tecnologia, para desempenharem o papel que deveria ser da CPU. Ou seja, a execução das tarefas não seria feita no processador, e sim na GPU. Conforme a NVIDIA (2012), “CUDA é uma plataforma de computação paralela e modelo de programação que aumenta drasticamente o desempenho computacional pelo aproveitamento do poder da GPU”.

Desenvolvedores de empresas como a Adobe, ANSYS, Autodesk, MathWorks e Wolfram Research estão acordando este gigante adormecido - a GPU - a fazer de computação propósito geral científica e de engenharia em uma variedade de plataformas. Usando linguagens de alto nível, aplicações aceleradas por GPU executam a parte seqüencial de sua carga de trabalho da CPU - o que é otimizado para single-threaded performance - acelerando o processamento paralelo na GPU. Isso é chamado de "computação GPU". Computação GPU é possível porque GPUs de hoje fazem muito mais do que renderizar gráficos: Isso soa como um teraflop de desempenho de ponto flutuante e tarefas flexiveis de aplicativos projetados para qualquer coisa de finanças até medicina. CUDA é amplamente utilizado através de milhares de aplicativos e há publicações de trabalhos de pesquisa e apoiado por uma base instalada de mais de 375 milhões GPUs CUDA em notebooks, estações de trabalho, clusters de computação e supercomputadores.

(NVIDIA, 2012)

CUDA vem com um ambiente de software que permite aos desenvolvedores usar C como uma linguagem de programação de alto nível. Outras línguas, interfaces de programação de aplicativos, ou directivas abordagens são suportadas, tais como FORTRAN, DirectCompute OpenACC.

(NVIDIA, 2007)

O advento dos processadores multicore e GPUs manycore significa que os chips de processamento principais agora são sistemas

paralelos. Além disso, seu paralelismo continua em escala com a lei de Moore. O desafio é desenvolver um software aplicativo que escale transparentement seu paralelismo para alavancar o aumento do número de núcleos do processador, assim como aplicativos gráficos em 3D transparentemente escalam seu paralelismo com vários núcleos GPUs com grande variação do número de núcleos. O modelo de programação paralela CUDA é projetado para superar este desafio, mantendo uma baixa curva de aprendizado para os programadores familiarizados com linguagens de programação padrão, como C. Na sua essência são três principais abstrações - uma hierarquia de grupos de discussão, memórias compartilhadas, e sincronização de barreira - que são simplesmente expostos ao programador como um conjunto mínimo de extensões de linguagem. Estas abstrações fornecer refinado paralelismo de dados e paralelismo fio, aninhada dentro de granulação grossa paralelismo de dados e paralelismo de tarefas. Eles guiam o programador a particionar o problema em sub-problemas grosseiros que podem ser resolvidos de forma independente em paralelo por blocos de tópicos, e cada sub- problema em partes mais finas que podem ser resolvidos de forma cooperativa em paralelo por todos os segmentos dentro do bloco.

(NVIDIA, 2007)

CUDA pode ser vista como um conjunto de extensões da linguagem de programação C/C++ que distingue entre funções altamente multithread (doravante kernels) e funções do host de thread única. Kernel são expressos como programas SIMD e explicitamente gerenciam a hierarquia de memória da GPU. Kernels são gerenciados por uma série de chamadas de API definitas pelo runtime do CUDA que alocam memoria na GPU, copiam dados entre o host e a GPU, executam kernels, etc. O compilador CUDA compila os kernels para PTX (e possivelmente algumas representações nativas), que são empacotados em uma estrutura binaria contendo entradas separadas para cada destino da ISA. O binário é armazenado como um array estático no código nativo C/C++ que será executado no host. A partir do CUDA 2.2, a representação textual do PTX e no formato Unicode na estrutura binaria. O código fonte resultante e completamente C++, que então é passado para um compilador nativo como o GCC. O binário gerado contém referencias para funções da API CUDA, e deve ser linkado à implementação do runtime do CUDA para ser executado.

(KERR, DIOAMONS e YALAMANCHILI, 2009)

Hierarquia de Thread. O PTX define um modelo de máquina virtual que explicitamente expressa instruções simples de dados de múltiplos streams (SIMD) e instruções múltiplas em múltiplos streams de dados como estilo de paralelismo na aplicação. O nível mais baixo da hierarquia de thread implementa o modelo SIMD de computação onde threads SIMD são agrupadas em Arrays de Threads Cooperativas (CTAs). Cada CTA executa em um único processador que é referenciado como multiprocessador. Threads em um CTA podem se comunicar via memoria compartilhada e sincronizar via barreiras. CTAs distintos podem executar em MPs distintos representando o modelo MIMD de execução. O modelo de execução impede quaisquer restrições de ordem entre CTAs.. No nível mais alto, um kernel é composto de um conjunto de CTAS que podem ser executados

concorrentemente e em uma ordem não específica. Como não há suporte de hardware para sincronismo entre CTAs na mesma invocação do kernel, a comunicação deve ser orquestrada pelo software atraves da memória global.

(KERR, DIOAMONS e YALAMANCHILI, 2009)

Na Tabela 3 está sumarizada a diferença e equivalência de termos CUDA e OpenCL.

Tabela 3 - Terminologia CUDA e Terminologia OpenCL

CUDA OpenCL Thread Work-item Thread block Work-group

Fonte: OANCEA, ANDREI e DRAGOESCU (2012)

4.1.3. AMD APP

A tecnologia AMD APP, também conhecida como ATI Stream é uma tecnologia concorrente à tecnologia CUDA da NVIDIA. Segundo OANCEA, ANDREI e DRAGOESCU (2012), “o modelo de programação APP assemelha-se ao paradigma CUDA. Ele suporta os modelos de programação de paralelismo de dados e paralelismo de tarefas”.

A tecnologia ATI Stream é um conjunto de hardware e tecnologias avançadas de software que permitem processadores gráficos AMD (GPU), trabalhar em conjunto com o processador central do sistema (CPU), para acelerar muitas aplicações além dos gráficos apenas. Isso permite plataformas mais equilibradas capazes de executar tarefas de computação exigentes mais rápido do que nunca.

(AMD, 2013)

A tecnologia AMD APP é um conjunto de hardware e tecnologias avançadas de software que permitem à Graphics Processing Unity (GPU), trabalhar em conjunto com núcleos x86 do sistema (CPU), para acelerar muitas aplicações além dos gráficos apenas. Isso permite plataformas mais equilibradas capazes de executar tarefas de computação exigentes mais rápido do que nunca, e coloca os desenvolvedores de software no caminho para otimizar as Accelerated processing Units (APU AMD).

(AMD, 2012)

A AMD APP Software Development Kit (SDK) é uma plataforma completa de desenvolvimento criado pela AMD para permitir que você rapidamente e facilmente desenvolver aplicações aceleradas por tecnologia AMD APP. O SDK fornece amostras, documentação e outros materiais para você começar rapidamente alavancar computação acelerada com OpenCL™, Bolt, ou C ++ AMP na sua C / C + +, ou Aparapi para sua aplicação Java.

(AMD, 2012)

Segundo AMD (2012), “A AMD está focada no OpenCL, a fim de permitir que desenvolvedores utilizem, de forma mais simples, o potencial da computação heterogênea”. Ainda segundo AMD (2013), “AMD App Acceleration é um conjunto de tecnologias disponível nas series de GPU Radeon 6000 e superiores e é desenhada para melhorar qualidade de vídeo e performance de aplicativos”.

A AMD aposta que o OpenCL tende a se estabelecer como a principal ferramenta para os desenvolvedores, o que se reflete em sua estratégia de criar soluções compatíveis com essa tecnologia. O objetivo principal é permitir que as aplicações desenvolvidas em OpenCL consigam tiram o máximo proveito da capacidade de processamento das CPUs e GPUs da fabricante.

(AMD, 2012)

5. BENCHMARKS

Benchmarks são algoritmos que forçam o uso de determinado recurso computacional, ou do sistema como um todo, executando determinadas tarefas com a finalidade de avaliar a sua capacidade, desempenho e/ou tempo de execução. São essenciais na pesquisa, pois se pretende avaliar o quanto de tarefas podem ser realizadas com determinada quantidade de energia.

Benchmarks são programas utilizados para avaliar sistematicamente algum aspecto do desempenho de um computador, com o objetivo de encontrar gargalos no sistema, ou para comparar o desempenho de duas ou mais máquinas diferentes. Quando utilizado para comparar o desempenho de máquinas, a métrica de desempenho mais confiável é o tempo de execução total para executar o benchmark.

(LILJA, 2000)

Programas de benchmark são usados para medir e prever a performance de um sistema e revelar seu comportamento bem como revelar seus pontos fortes e fracos. Ainda, definimos uma suíte de benchmark como um grupo de programas de benchmark juntamente com um conjunto de regras para governar condições e procedimentos de teste, incluindo a plataforma do ambiente, entrada e saída de dados e medidas de performance.

(OBAIDAT e BOUDRIGA, 2010)

Um benchmark é um programa de teste de performance que visa adquirir características de processamento e movimentação de dados de um grupo de aplicações. Programas de benchmark são usados para medir e prever a performance de um sistema e revelar seu comportamento bem como revelar seus pontos fortes e fracos. Ainda, definimos uma suíte de benchmark como um grupo de programas de benchmark juntamente com um conjunto de regras para governar condições e procedimentos de teste, incluindo a plataforma do ambiente, entrada e saída de dados e medidas de performance.

(OBAIDAT e BOUDRIGA, 2010)

Conforme IDA (2000) Apud Berry, Cybenko e Larson (1991) dependendo da codificação do programa, os benchmarks podem ser divididos em vários tipos, dentre os principais estão:

5.1. Sintético

Um Benchmark sintético é um programa artificial no qual o conjunto de operações que ele executa é selecionado para simular uma determinada classe de aplicações. O objetivo é que sendo o conjunto de instruções, o mesmo, das aplicações reais, o desempenho obtido na execução será um bom parâmetro para a avaliação do desempenho da aplicação real.

(RAMOS, 2008)

Benchmarks sintéticos são pequenos programas artificiais que contem uma mistura de afirmações selecionadas de modo que eles representem um grande conjunto de aplicações reais. Benchmarks sintéticos normalmente não executam operações significativas em um grande conjunto de dados. Eles assumem o risco de que algumas partes dos programas podem ser removidas por um compilador de otimização

(RAUBER e RÜNGER, 2010)

São aqueles cujo código não faz nenhuma computação útil, não representa nenhuma aplicação real; somente exercita alguns componentes básicos do computador. Geralmente, tentam determinar uma frequência média de instruções típicas, comumente utilizadas, e recriá-las em um programa. Os mais conhecidos são o Whetstone e o Dhrystone.

(IDA, 2000)

A maioria dos aplicativos projetados atualmente não só utilizam o processamento, mas também necessita de uma grande quantidade de operações de input / output com a ajuda de dispositivos externos. Assim, estes se tornaram uma parte integrante da carga de trabalho, que precisa ser considerada para a avaliação do desempenho do sistema no mundo real.

(OBAIDAT e BOUDRIGA, 2010)

5.2. Kernel

São baseados no fato de que a maior parte da computação de um programa é concentrada em uma pequena parte de seu código. Esta pequena parte, chamada de núcleo (kernel), é extraída do programa e usada como benchmark. Deve ser ressaltado que eles não servem para avaliar completamente o desempenho de uma máquina. São bastante interessantes por sua simplicidade e pequeno tamanho. Um bom exemplo para este tipo de programa é o Livermore Loops.

(IDA, 2000)

Conforme Thomas (2010) benchmarks kernel são partes pequenas mas relevantes de aplicações reais que normalmente capturam uma grande parcela do tempo de execução de aplicações reais. Comparado a programas reais, benchmarks kernel têm a vantagem de que são muito mais curtos e fáceis de analisar

(RAUBER e RÜNGER, 2010)

Benchmarks de kernel não consideram os dispositivos de entrada e saída, caracterizando o desempenho dos sistemas apenas com base na performance do processador. A grande desvantagem de utilizar estes tipos de benchmark é que eles não fazem uso de dispositivos de I/O para o cálculo do desempenho do sistema, assim, o desempenho do kernel não irá visualizar o desempenho do sistema como um todo.

(OBAIDAT e BOUDRIGA, 2010)

5.3. Algoritmo

São algoritmos bem definidos, geralmente implementações de métodos conhecidos em computação numérica, como por exemplo os métodos de resolução de equações lineares (álgebra linear) que fazem parte do benchmark Linpack.

(IDA, 2000)

5.4. Aplicação

Segundo IDA (2000), “benchmarks de aplicação são programas completos, que resolvem problemas científicos bem definidos. Um exemplo é o SPEC”.

Benchmarks do tipo aplicação são utilizados principalmente para avaliar o desempenho dos sistemas, que são usadas para uma determinada aplicação, tais como reserva de linha aérea, serviços bancários, classificação, previsão do tempo, e assim por diante. Para essas aplicações, benchmarks são definidos como um grupo coletivo de funções, que fazem uso de todos os recursos do sistema.

(OBAIDAT e BOUDRIGA, 2010)

Benchmarks de aplicativos reais incluem vários programas inteiros que refletem uma carga de trabalho de um usuário padrão. Tais coleções são frequentemente chamadas de suítes de referência. Eles têm a vantagem de que todos os aspectos dos programas selecionados são capturados. Os resultados de desempenho produzidos são significativos para os usuários para os quais o pacote de benchmark representa as cargas de trabalho típico.

(RAUBER e RÜNGER, 2010)

6. TESTES

Para realização dos testes foi necessário a utilização de equipamentos para medição de energia, os quais coletaram os dados necessários para que pudéssemos obter os resultados. Os testes com os benchmarks SNU NPB e Rodínia tiveram os dados de consumo coletados, enquanto que o benchmark SHOC foi utilizado para que fosse possível obter dados como velocidade de comunicação com a memória RAM, velocidade do barramento de comunicação e desempenho máximo em FLOPS. Após a execução dos testes os dados foram coletados do Dranetz1 e tratados de forma apropriada. Os testes se deram no mesmo ambiente, ou seja, foi utilizado o mesmo computador, com o mesmo sistema operacional para testar cada tecnologia, além da utilização dos mesmos algoritmos.

6.1. Ambiente de Trabalho

Em todos os testes realizados foi utilizado o mesmo computador, consistindo de uma máquina equipada com processador Intel Core i3, modelo 2120, com clock de 3.30Ghz e 3MB de Cache L2, memória de 4Gb DDR III. O Sistema operacional utilizado foi o Ubuntu Linux 12.04, kernel 3.2.0-29-generic. Foram criadas três partições no disco rígido SATA II, que se diferenciavam apenas pelo Setup Development Kit (SDK) instalado, um responsável pela GPU GeForce GT520 (NVIDIA), outro pela Radeon HD 6450 (AMD), e outro pela CPU. Os algoritmos foram compilados utilizando os compiladores GNU Compiler Collection (GCC), na versão 4.6.3. Os benchmarks não necessitaram de nenhuma configuração diferenciada da distribuição, sendo necessário apenas as instalação do pacote mpich2 para que fosse possível a execução do SHOC. Os SDK’s e drivers utilizados para as diferentes tecnologias foram os mais recentes e as versões dos mesmos podem ser observadas na Tabela 4.

1 Equipamento utilizado para coletar dados referentes ao consumo. Ver seção 6.2.1.

Tabela 4 - Versões de drivers e SDK's

NVIDIA AMD Intel Drivers 304.51 Catalyst 12.8 - SDK/Toolkit CUDA Toolkit 4.2 AMD APP SDK 2.7 Intel SDK 1.5 Headers OpenCL 1.1 1.1 1.1

6.2. Equipamentos para Testes

Descreveremos aqui os equipamentos que foram utilizados para viabilizar a medição do consumo energético durante os testes, bem como, quais equipamentos foram testados a fim de obter os resultados para comparação dos mesmos. O acelerador Xeon Phi, da Intel, não foi utilizado porque, segundo a INTEL (2012) “Nós atingimos um teraFLOP de pico de precisão dupla com um único chip”, o que faz com que este acelerador tenha um desempenho muito superior aos aceleradores e ao processador escolhidos para os testes, que são aceleradores básicos.

6.2.1. Mensuração do Consumo Energético

Para medições de consumo das plataformas foi utilizado o equipamento Dranetz PP-4300, que é muito eficiente na medição de dados como tensão e corrente alternada. Após as medições, os dados foram coletados através do DranView, que é um software específico para extração dos dados da memória do Dranetz.

Figura 4 - Plataforma BMI Dranetz PP4300

Os dados foram então exportados para o formato Comma Separated Values (CSV) e, em seguida, importados para uma planilha, onde se identificou os momentos de início e fim da execução, para então tratar os dados e gerar a informação necessária para a obtenção dos resultados desejados.

6.2.2. CPU Intel

A CPU da Intel que foi utilizada foi o Intel Core-i3 2120, com núcleo Arrandale. Assim como as GPUs utilizadas, esta CPU também é um dispositivo de entrada de mercado, não tendo tanto poder computacional quanto suas versões mais completas. Arrandale é o codinome de um processador de dois núcleos móvel usado na série 5 de chipsets intel baseados na plataforma de codinome Calpella. Arrandale é composto de um núcleo processador de 32nm e 45nm gráficos e controlador de memória integrado num pacote multi-chip. Arrandale é parte da família de processadores Westmere de 32nm, baseado na microarquitetura Intel codinome Nehalem e direcionada para a produção no 4T'09, com disponibilidade no 1T'10.

(INTEL, 2012)

A Tabela 5 nos mostra as especificações técnicas da CPU utilizada nos testes de desempenho.

Tabela 5 - Especificações da CPU Intel

Especificação Intel Core-i3 Frequência de clock 3.3GHz Número de Núcleos 2 Número de Threads 4 Processo de Fabricação 32nm Intel Smart Cache 3MB Conjunto de instruções 64-bit TDP1 65W

1 O TDP (Thermal Design Power) junto com a temperatura de junção máxima,define o ponto de design recomendado da Intel para a capacidade da solução. Ver (INTEL, 2004).

6.2.3. GPU NVIDIA

O acelerador da NVIDIA que foi utilizado é uma GPU GeForce GT520, construída com arquitetura Fermi. Na Tabela 6 podemos verificar as especificações técnicas da GPU utilizada para realização dos testes.

Tabela 6 - Especificações Técnicas GPU NVIDIA

Marca - EVGA - NVIDIA GeForce GT 520. - Núcleos CUDA: 48. - Frequência da GPU: 810MHz. Processador gráfico - Processo de fabricação: 40nm. - Unidades de Textura / ROPs: 8 / 4. - Temperatura da GPU: 102ºC (máx.). - Frequência dos processadores: 1,62GHz. - Padrão: DDR3. - Interface: 64bits. Memória - Capacidade: 1GB. - Frequência: 1GHz. Interface - PCI Express 16x (v2.0). - DirectX v11. - HDMI v1.4a. - Shader v5.0. Tecnologias suportadas - OpenCL v1.0. - OpenGL v4.2. - DirectCompute v5.0. - NVIDIA CUDA / PhysX. TDP - Máximo: ± 29W.

Figura 5 - GPU NVIDIA utilizada nos testes

6.2.4. GPU AMD

Na Tabela 7 podemos verificar as especificações técnicas da GPU da AMD utilizada para realização dos testes.

Tabela 7 - Especificações Técnicas GPU AMD

Marca - SAPPHIRE - AMD Radeon HD - Frequência: 625MHz. Processador gráfico - Processadores Stream: 160. - Processo de fabricação: 40nm. - Unidades de Textura / ROPs: 8 / 4. - Padrão: DDR3. - Interface: 64bits. Memória - Capacidade: 1GB. - Frequência: 1,334GHz. Interface - PCI Express 16x (v2.1). - DirectX v11. - HDMI v1.4a. - Shader v5.0. - OpenGL v4.1. Tecnologias suportadas - OpenCL v1.1. - DirectCompute v11. - AMD App / Avivo HD (UVD 3) / HD3D / PowerPlay. TDP - Máximo: ± 20W.

Figura 6 - GPU AMD utilizada nos testes

6.3. Benchmark

Apenas o algoritmo FT, da suíte NPB, e o algoritmo Leukocyte, da suíte Rodinia, foram utilizados para mensuração do consumo energético e do tempo de execução. Os algoritmos da suíte SHOC foram utilizados apenas para mensurar o desempenho dos dispositivos, pois executam em sequência e de forma muito rápida, o que dificultaria a distinção do consumo energético de cada uma de suas etapas, podendo causar inconsistência. Para cada algoritmo executado foi calculada uma média referente a dez execuções do mesmo, para que os dados obtidos não ficassem suscetíveis à intervenção de alguma tarefa que o sistema pudesse estar executando no momento. Desta forma, ampliamos a confiabilidade dos resultados obtidos. Ambos os algoritmos foram compilados apenas uma vez para cada dispositivo a ser utilizado. Ou seja, as suítes de benchmark foram compiladas três vezes durante os testes, para que fosse certificado que cada compilação utilizasse as bibliotecas corretas fornecidas pelo fabricante do dispositivo em questão. Os benchmarks utilizados nos testes foram o Scalable HetorOgeneous Computing Benchmark Suite (SHOC), versão 1.1.4, o SNU NPB, versão 1.0.2, e o Rodinia Benchmark Suite, versão 2.1. A escolha do SHOC se dá pela gama de opções de testes oferecidas pelo mesmo, sendo utilizado para testar capacidades do dispositivo como largura de banda de memória e do barramento. O NPB será utilizado para testes de desempenho e consumo dos dispositivos.

6.3.1. Scalable HeterOgeneous Computing Benchmark Suite

O Scalable Heterogeneous Computing Benchmark Suite (SHOC) é uma coleção de programas de benchmark para testar o desempenho e estabilidade de sistemas utilizando dispositivos de computação com arquiteturas não-tradicionais de coputação de propósito geral e o software usado para programá-los. Seu foco inicial é em sistemas que contenham unidades de processamento gráfico (GPUs) e processadores multi-core, e sobre o padrão de programação OpenCL. Ele pode ser usado em conjuntos, bem como hospedeiros individuais.

(GPGPU.ORG, 2010)

O SHOC é dividido em diversos subprogramas que testam diferentes aspectos do sistema. Os que foram utilizados mensuram a largura de banda do barramento de conexão do dispositivo, largura de banda de memória do dispositivo, velocidade de compilação do kernel, pico máximo em MFLOPS1, e a demora em inicializar o kernel no dispositivo, ambos descritos a seguir:

• Velocidade do barramento: Mede a largura de banda do barramento de interligação entre o processador hospedeiro e o dispositivo OpenCL (tipicamente o barramento PCIe) fazendo por várias vezes a transferência de dados de vários tamanhos para e a partir do dispositivo.

• Largura de banda da memória do dispositivo: mede a largura de banda para todos os espaços de endereço da memória do dispositivo, incluindo global, local, constante, e as memórias de imagem. O espaço de memória global é testado usando acessos coalescentes quanto não-coalescentes à memória. Em todos os casos, cada segmento gera 16 pedidos de memória independentes.

• Compilação do Kernel: Kenels OpenCL são compilados em tempo de execução, e este benchmark mede com média a velocidade e despesas gerais para compilação kernels de diferentes complexidades.

• Pico em MFLOPS: Medida da quantidade de operações de ponto flutuante (precisão simples ou dupla) por segundo, utilizando uma carga de trabalho sintética simpático projetado para para exercitar completamente as unidades funcionais do dispositivo. Taxas de execução são computadas para diferentes combinações de operações aritméticas, como 1) adições apenas, 2) apenas multiplicação, 3) um número igual de multiplicações e adições, 4) um mix composto de multiplicações e adições em uma proporção de 2 para 1.

• Atraso de enfileiramento: Mede a sobrecarga de lançamento de um kernel no sistema de filas do OpenCL.

(DANALIS, ROTH, et al., 2010)

6.3.2. SNU NPB

O SNU NPB é nada mais que uma adaptação dos algoritmos do NAS

1 MFLOPS – Milhões de Operações de Ponto Flutuante por Segundo.

Parallel Benchmarks, desenvolvidos pela NASA utilizando a linguagem Fortran, portados para OpenCL, OpenMP e C.

O NAS Parallel Benchmarks (NPB) é um pequeno conjunto de programas destinados a ajudar a avaliar o desempenho dos supercomputadores paralelos. Os pontos de referência são derivados da dinâmica de fluidos computacional (CFD) e aplicações consistem em cinco núcleos e três pseudo-aplicações, na especificação original "lápis e papel" (NPB 1). O pacote de benchmark foi estendido para incluir novos padrões de malha adaptativa desestruturada, I/O paralelo, aplicações multi-zona e grades computacionais. Tamanhos de problema do NPB são predefinidos e indicado como classes diferentes. Implementações de referência do NPB estão disponíveis em modelos de programação mais usadas como MPI e OpenMP (NPB 2 e NPB 3).

(NASA, 2012)

A adaptação que será utilizada foi desenvolvida pelo Center for Manycore Programming (CMP) da Seoul National University (SNU) - Korea. Segundo a SNU (2011) “SNU NPB Suite é um conjunto de benchmarks paralelos NAS (NPB) implementados em C, OpenMP C e OpenCL. Atual SNU NPB Suite consiste de quatro diferentes implementações”. Essa suíte de benchmarks foi escolhida porque, segundo Saphir, Woo e Yarrow (1996) “Enquanto a suíte NPB foi desenhada para comparar diferentes tipos de computadores, ela pode ser usada também para mostrar pequenas diferenças em um único tipo de computador”. A suíte possui diversos algoritmos diferentes, porém, foi utilizado apenas o algoritmo FT, que é a implementação do algoritmo Fast Fourier Transform (FFT), que calcula de forma eficiente a Transformada Discreta de Fourrier (DFT).

A transformada de Fourier vem em três variedades: a boa e velha transformada de Fourier, a série de Fourier e transformada de Fourier discreta. Mas é a transformada de Fourier discreta, ou DFT, que representa o renascimento de Fourier. Em 1965, os cientistas da computação James Cooley e John Tukey descreveram um algoritmo chamado de transformação rápida de Fourier, o que tornou muito mais fácil de calcular DFTs em um computador. De repente, a DFT se tornou uma maneira prática para processar sinais digitais.

(HARDESTY, 2009)

A DFT faz matematicamente o que o ouvido humano faz fisicamente: decompor um sinal em suas frequências componentes. Ao

contrário do sinal analógico de, digamos, um aparelho de som, o sinal digital a partir de um leitor de MP3 é apenas uma série de números, cada um representando um ponto em um rabisco. Colete pontos suficientes, e você produzir um fac-símile razoável de um sinal contínuo: com qualidade de CD de gravação digital de áudio, por exemplo, recolhe 44.100 amostras por segundo. Se extrair um número de valores consecutivos de um sinal digital, - 8, ou 128, ou 1000 - o DFT representa como a soma ponderada de um número equivalente de frequências. ("Ponderada" apenas significa que algumas das frequências contam mais do que outros em relação ao total).

(HARDESTY, 2009)

6.3.3. Rodinia Benchmark Suite

As cargas de trabalho do Rodínia são selecionados e projetado para plataformas de computação heterogênea, incluindo ambos os CPUs e dispositivos, como GPUs e FPGAs [10]. Rodínia abrange não só as aplicações de domínios emergentes tais como bioinformática, mineração de dados e processamento de imagem, mas também inclui as implementações de algoritmos clássicos importantes, como decomposição LU e travessia de gráfico. A taxonomia Dwarf de Berkeley[1] foi inicialmente utilizada como uma diretriz para escolher aplicações para o Rodínia, a fim de evitar a perda de importantes padrões paralelos.

(CHE, SHEAFFER, et al., 2009)

O algoritmo desta suíte que foi escolhido para ser utilizado foi o Leukocyte, que detecta e rastreia glóbulos brancos microscópicos em vasos sanguíneos. A velocidade dos leucócitos fornece informações importantes sobre o processo de inflamação, o que ajuda pesquisadores no desenvolvimento de medicamentos anti-inflamatórios. Este algoritmo foi escolhido principalmente por fazer uso apenas de cálculos de ponto flutuante com precisão simples.

Na aplicação, as células são detectadas no primeiro fotograma e então rastreado através de quadros subsequentes. A detecção é feita através do cálculo para cada pixel no quadro inverso a pontuação do Coeficiente Máximo da Gradiente de Variação (GICOV) em uma série de elipses possíveis. A pontuação GICOV para uma elipse é a magnitude do gradiente médio ao longo da elipse, dividido pelo desvio padrão da magnitude do gradiente. A matriz de pontuação GICOV é então dilatado para simplificar o processo de encontrar máximos locais. Para cada um máximo local, um algoritmo de contorno ativo é utilizada para determinar com mais precisão a forma da célula.

(UNIVERSITY OF VIRGINIA, 2009)

O rastreamento é conseguido através de computação, em primeiro lugar, na área em torno de cada célula, uma matriz do Movimento do Fluxo do Vetor Gradiente (MGVF). O MGVF é um campo gradiente enviesada na direcção do fluxo de sangue, e é calculado usando um procedimento iterativo solução Jacobiana. Depois de calcular o MGVF, um contorno activo é utilizado, uma vez mais para refinar a forma e determinar a localização de cada nova célula.

(UNIVERSITY OF VIRGINIA, 2009)

7. RESULTADOS E DISCUSSÃO

Este capítulo está organizado da seguinte forma. Na primeira seção avaliaremos os dados obtidos pela execução do benchmark SHOC. Na segunda seção, serão avaliados os dados do benchmark SNU NPB. Por fim, na terceira seção avaliaremos os dados do benchmark Rodinia.

7.1. Resultados Benchmark SHOC

Os resultados do benchmark SHOC serão avaliados por parte. Primeiramente avaliaremos os dados referentes à velocidade do barramento de conexão. Em seguida, avaliaremos a velocidade de acesso às memórias. Avaliaremos, então, o desempenho máximo atingido e, por último, a compilação e atraso de execução dos kernels.

7.1.1. Velocidade do Barramento

Inicialmente foi avaliado o desempenho do barramento de conexão do dispositivo. Podemos avaliar na Figura 8 a velocidade máxima atingida na hora de transferir os dados da memória RAM para o dispositivo. Observamos que a CPU apresentou uma velocidade 62% superior à GPU NVIDIA quando transferindo os dados da memória RAM para o dispositivo. Em relação à GPU AMD a vantagem da Intel foi ainda maior, atingindo a marca de 76%.

Figura 7 - Velocidade do Barramento (Host->Device)

12,0000 10,8179

10,0000

8,0000 6,6457 6,1267 6,0000 GB/s

4,0000

2,0000

0,0000 GPU NVIDIA GPU AMD CPU Intel

O resultado obtido era esperado, assim como era esperado uma taxa de transferência maior quando se transfere os dados de volta à memória RAM.

Na Figura 9 observamos que no sentido inverso, ou seja, transferindo os dados do acelerador para a memória, a diferença foi ainda maior, de 64%, entre a CPU Intel e a GPU AMD, que neste ponto foi melhor em relação à GPU NVIDIA, que foi 65% inferior à CPU.

Figura 8 - Velocidade do Barramento (Device->Host)

12,0000 11,0038

10,0000

8,0000 6,6453 6,6979

6,0000 GB/s

4,0000

2,0000

0,0000 GPU NVIDIA GPU AMD CPU Intel

Em relação às GPUs, quando comparamos uma à outra, pode-se avaliar que a GPU NVIDIA teve um desempenho 8% maior quando transferindo dados da memória ao acelerador e cerca de 1% inferior no sentido inverso.

7.1.2. Acesso às memórias

Avaliamos um desempenho superior da AMD quando da leitura e da escrita da memória global (RAM), como pode ser visto Figura 10.

Figura 9 - Memória do Dispositivo

80,0000 72,8590 70,0000 62,6605 60,0000 50,0000

40,0000 GB/s 30,0000 22,1876 19,1588 16,8669 20,0000 9,4596 8,4674 10,0000 0,0000 Leitura Leitura Escrita Escrita Leitura Local Escrita Local Leitura de Global Global Aleat. Global Global Aleat. Textura GPU AMD GPU NVIDIA CPU Intel

Quando a leitura e escrita se dá de forma aleatória na memória global o ganho da CPU em relação às GPUs é consideravelmente grande. No teste de leitura local, as taxas de memória sobem muito em relação à leitura global, sendo que nesse aspecto a NVIDIA tem um ganho maior.

7.1.3. Desempenho Máximo Atingido

Outro importante teste dos dispositivos é seu pico de desempenho em GFLOPS. Podemos avaliar na Figura 11 os resultados dos testes do pico máximo de desempenho atingido pelos dispositivos para operações com precisão simples de ponto flutuante.

Figura 10 - Desempenho de Pico com Precisão Simples

200,0000 187,2388 180,0000 160,0000 151,6093 140,0000

120,0000 100,0000

GFLOPS 80,0000 60,0000 51,8942 40,0000 20,0000 0,0000 GPU NVIDIA GPU AMD CPU Intel

Observamos que as GPUs tiveram um desempenho muito acima da CPU. Essa margem chegou a ter uma diferença de 260% se compararmos a GPU AMD com a CPU Intel. No comparativo entre GPUs, a AMD teve uma vantagem de 23%. Mesmo com a grande diferença entre as plataformas quando falamos em precisão simples, quando mudamos o teste para precisão dupla a vantagem se inverte totalmente. A Figura 12 mostra que a CPU teve um pico cerca de 300% superior à GPU NVIDIA. Porém, o fator mais significativo foi a total ausência de suporte por parte da GPU AMD.

Figura 11 - Desempenho de Pico com Precisão Dupla

60,0000 51,9107 50,0000

40,0000

30,0000 GFLOPS 20,0000 12,9508 10,0000 Não Suportado 0,0000 GPU NVIDIA GPU AMD CPU Intel

7.1.4. Compilação e Atraso na Execução do Kernel

Outro dado que chamou a atenção foi o tempo de compilação do Kernel OpenCL durante a execução do algoritmo. A compilação utilizando os SDKs da Intel e AMD não compilam automaticamente os Kernels OpenCL. No caso da AMD, o SDK oferece suporte tanto às CPUs quanto às GPUs AMD, e também às CPUs Intel. A diferença entre o tempo de compilação foi de cerca de 80% mais rápido na CPU Intel. A Figura 13 mostra os resultados dos testes, que indicam que quando o benchmark foi compilado usando o SDK NVIDIA os Kernels foram automaticamente compilados. Como o SDK NVIDIA é utilizado apenas para as GPU’s NVIDIA, não há a necessidade de compilar o kernel em tempo de execução, como nos demais SDK’s, pois o acelerador a ser usado já é conhecido. A compilação utilizando os SDKs da Intel e AMD não compilam automaticamente os Kernels OpenCL. No caso da AMD, o SDK oferece suporte tanto às CPUs quanto às GPUs AMD, e também às CPUs Intel. A diferença entre o tempo de compilação foi de cerca de 80% mais rápido na CPU Intel.

Figura 12 - Tempo de Compilação do Kernel

0,0700 0,0591 0,0600

0,0500

0,0400

0,0300 segundos 0,0200 0,0126 0,0100 0,0001 0,0000 GPU NVIDIA GPU AMD CPU Intel

O último fator avaliado com o uso do SHOC foi o tempo necessário entre transferir o kernel para o dispositivo até o momento em que sua execução inicia. Avaliando os dados da Figura 14 mais uma vez a GPU NVIDIA esteve à frente das demais, demorando cerca de 93% menos tempo para transferir. A

compilação pelo SDK Intel foi aproximadamente 53% menos demorada.

Figura 13 - Tempo de Atraso na Execução do Kernel

0,1000 0,08816 0,0900 0,0800

0,0700 0,0600 0,0500 0,0415 0,0400

milissegundos 0,0300 0,0200 0,0100 0,0055 0,0000 GPU NVIDIA GPU AMD CPU Intel

7.2. Resultados Benchmark SNU NPB

Durante a execução do SNU NPB foram coletados os dados referentes ao consumo energético dos dispositivos. O acelerador da AMD não foi capaz de executar este teste, já que o mesmo utiliza ponto flutuante com dupla precisão, que não é suportado por este acelerador, de acordo com os resultados do SHOC. Na Figura 14, observamos que a execução foi mais demorada na GPU do que na CPU. Isso era esperado conforme os resultados do benchmark SHOC, que mostraram inferioridade no pico de desempenho com dupla precisão da GPU, sendo 270% mais lento. Figura 14 - Tempo de Execução do Benchmark FT

25,0000

19,5091 20,0000

15,0000

segundos 10,0000 5,4312 5,0000

0,0000 GPU NVIDIA CPU Intel

Conforme pode ser observado na Figura 15 mais uma vez a CPU Intel foi superior, tendo atingido um nível 370% maior que a GPU. O baixo nível de desempenho atingido, se comparados com os resultados da Figura 12, se explica pelo fato de que o benchmark anterior serve para determinar o pico máximo, enquanto o SNU NPB determina quanto foi atingido executando determinada tarefa.

Figura 15 - Desempenho Atingido Pelos Dispositivos

2500,0000

1991,1750 2000,0000

1500,0000

MFLOPS 1000,0000

421,6270 500,0000

0,0000 GPU NVIDIA CPU Intel

Da mesma forma que teve menos poder computacional a GPU também consumiu mais energia para executar o algoritmo. A Figura 16 nos mostra que foi necessário 645% mais energia para a conclusão da execução.

Figura 16 – Consumo Energético dos Dispositivos Executando o FFT

0,3500 0,3065 0,3000 0,2500

0,2000

Wh 0,1500 0,1000 0,0411 0,0500 0,0000 GPU NVIDIA CPU Intel

Da mesma forma que o consumo do acelerador foi superior ao consumo do processador, houve um aumento de 107% na potência média do

acelerador em relação ao processador, como pode ser observado na Figura 17.

Figura 17 - Potência Média Durante a Execução do FFT

60,0000 56,5582

50,0000

40,0000

30,0000 27,2426 Watt 20,0000

10,0000

0,0000 GPU NVIDIA CPU Intel

Com os dados obtidos dos testes anteriores podemos traçar um gráfico da eficiência energética dos aceleradores. Na Figura 18 observamos que a CPU Intel foi cerca de 3400% mais eficiente que a GPU quando executamos os testes com dupla precisão de ponto flutuante.

Figura 18 - Eficiência Energética dos Dispositivos

300 262,5063193 250

200

150

MFLOPS/Watt 100

50 7,453950439 0 GPU NVIDIA CPU Intel

7.3. Resultados Benchmark Rodinia

A execução do Rodinia não nos retorna uma mensuração do total de

operações executadas durante o teste, apenas nos diz quanto tempo foi necessário para executar o benchmark. Na Figura 19 podemos observar a diferença de tempo entre as execuções nos dispositivos AMD e NVIDIA, sendo que a NVIDIA demorou 66% menos tempo durante a execução.

Figura 19 - Tempo de Execução do Algoritmo Leukocyte

30,0000 28,300868

25,0000

20,0000

15,0000 12,5769 segundos 10,0000

5,0000

0,0000 GPU NVIDIA GPU AMD

Quando analisamos os dados do consumo energético deste algoritmo, na Figura 20, reparamos que, mesmo tendo levado mais de o dobro do tempo para terminar a execução o consumo do dispositivo AMD foi apenas 5% maior. Podemos justificar essa pequena diferença analisando o TDP especificado pelo fabricante de cada dispositivo, que é 9W inferior no dispositivo AMD.

Figura 20 - Consumo Energético Executando Leukocyte

0,24 0,2389 0,238 0,236 0,234 0,232

0,23 Wh 0,228 0,2271 0,226 0,224 0,222 0,22 GPU NVIDIA GPU AMD

Ainda, a potência média durante a execução do Leukocyte foi 113% superior no acelerador NVIDIA, como pode ser observado na Figura 21. Mesmo necessitando de mais potência, o fato de precisar de menos de a metade do tempo para executar o algoritmo fez com que o consumo energético, demonstrado na figura anterior, tivesse uma diferença favorável à NVIDIA.

Figura 21 - Potência Média dos Aceleradores Durante Execução do Leukocyte

70,0000 65,0047 60,0000 50,0000

40,0000 30,3892 Watt 30,0000 20,0000 10,0000 0,0000 GPU NVIDIA GPU AMD

8. CONSIDERAÇÕES FINAIS

Com a justificativa de averiguar o ganho em eficiência com a utilização de GPUs para executar tarefas da CPU foi realizada a pesquisa na qual foram testadas duas GPUs e uma CPU. Para tanto, foi realizado um estudo aprofundado das tecnologias disponíveis no mercado, bem como dos dispositivos e arquiteturas escolhidos para os testes e dos benchmarks que foram executados. Em um primeiro teste, observamos o aumento significativo do consumo de energia mesmo sem executar nenhum algoritmo, apenas adicionando os aceleradores na máquina. Quando a máquina estava com os aceleradores instalados seu consumo dobrou. Os resultados obtidos com o benchmark SHOC nos mostram que as GPUs tem sim um ganho muito alto em relação às CPUs quanto ao desempenho. GPUs conseguem atingir um pico de desempenho muito mais elevado com números reais de precisão simples. Porém, observamos nos testes que esse pico cai muito quando precisamos utilizar números reais de precisão dupla, que, no caso do acelerador da AMD, nem ao menos é suportado. Resultado que já era esperado e confirmou-se foi a largura de banda do barramento de conexão do dispositivo. A velocidade é muito maior em CPUs, que são desenvolvidos para terem velocidade muito superior de comunicação. O processador mostrou-se mais rápido no acesso aleatório à memória global, porém mais lento acessando dados de forma sequencial ou da memória local. Outros testes que foram executados são referentes ao kernel OpenCL. O tempo gasto na compilação do kernel foi muito elevado no acelerador AMD, e relação ao processador e ao acelerador NVIDI, no qual o mesmo foi quase nulo. Outro fator importante sobre o kernel é o tempo de atraso na execução, que também mostrou o acelerador AMD ser o mais lento e o NVIDIA o mais rápido. Devido ao fato de não encontrarmos um benchmark capaz de testar ambos aceleradores e processador utilizando números reais de precisão simples, não pudemos constatar se há ou não uma melhora na eficiência quando a necessidade é de números com precisão simples. Por outro lado, com a

utilização do FFT da suíte Rodinia, pudemos constatar que não há vantagem em utilizar estes aceleradores quando precisamos de precisão dupla, pois os mesmos se mostraram muito menos eficientes que o processador. Por fim, pudemos comparar os dois aceleradores utilizando o Leukocyte, da suíte SNU NPB, que nos mostrou que o acelerador NVIDIA foi muito mais rápido na solução do problema, porém, consumiu praticamente a mesma quantidade de energia que o acelerador AMD. Portanto, esta pesquisa nos demonstrou o quão ineficientes são os aceleradores para cálculos com números reais de precisão dupla e, também, a diferença de consumo em se utilizar ou não estes aceleradores. Por outro lado, os testes também mostraram uma discrepante diferença no pico máximo em FLOPS quando não é necessário números com precisão dupla, o que muda completamente o panorama da utilização dos aceleradores. Dessa forma, é possível afirmar que há um ganho muito grande de desempenho com a utilização de aceleradores na realização de cálculos com números reais de precisão simples, mesmo que não possamos afirmar com certeza, devido a não possuirmos benchmarks apropriados, se a utilização dos mesmos é energeticamente mais eficiente.

8.1. Trabalhos Futuros

Como pôde ser observado nos resultados, os dispositivos AMD testados não ofereceram suporte a números reais com precisão dupla. Com base nisso, pretendemos realizar testes em dispositivos com poder computacional maior, podendo assim fazermos uma comparativo mais abrangente das plataformas. Além disso, há intenção de utilizar a nova arquitetura Kepler da NVIDIA e GPU’s da série FirePro, da AMD. Também se pretende realizar um comparativo entre a utilização de CUDA e OpenCL utilizando GPU’s NVIDIA, visando um comparativo entre os dois modelos de programação para GPGPU. Por fim, o desenvolvimento de um algoritmo em OpenCL capaz de rodar tanto em CPUs quanto em GPUs, e que utilize precisão simples, pode dar um ponto de vista mais claro quanto as diferenças entre estas arquiteturas.

REFERÊNCIAS BIBLIOGRÁFICAS

AMD. AMD Accelerated Parallel Processing (APP) SDK (formerly ATI Stream). AMD Accelerated Parallel Processing (APP) SDK (formerly ATI Stream), 2012. Disponivel em: . Acesso em: 25 Setembro 2012.

AMD. AMD FirePro™ 3D Professional Graphics. AMD FirePro™ Professional Graphics, 2012. Disponivel em: . Acesso em: 14 Jan 2013.

AMD. AMD oferece aos desenvolvedores versões atualizadas da APP SDK e Catalyst. AMC, 2012. Disponivel em: . Acesso em: 14 Jan 2013.

AMD. For Consumers. AMD, 2013. Disponivel em: . Acesso em: 16 Jan 2013.

AMD. Tecnologia ATI Stream. AMD, 2013. Disponivel em: . Acesso em: 14 Jan 2013.

CHE, S. et al. A Characterization of the Rodinia Benchmark Suite. The University of Virginia. Virginia, p. 2. 2009.

DANALIS, A. et al. The Scalable HeterOgeneous Computing (SHOC). Oak Ridge National Laboratory, 2010. Disponivel em: . Acesso em: 3 Outubro 2012.

EDWARDS, B. Birth of a Standard: The Intel 8086 Microprocessor. PCWorld, 2008. Disponivel em: . Acesso em: 27 Setembro 2012.

FOWLER, R. J. Eletricidade: princípios e aplicações. 2ª. ed. São Paulo: Makron Books, 1992.

FREE SOFTWARE FOUNDATION. Option Summary - Using the GNU Compiler Collection (GCC). GCC, the GNU Compiler Collection, 2010. Disponivel em: . Acesso em: 28 Setembro 2012.

GLASKOWSKY, P. N. NVIDIA’s Fermi: The First Complete. Fermi Architecture for High-Performance Computing | NVIDIA, 2009. Disponivel em:

%27s_Fermi-The_First_Complete_GPU_Architecture.pdf>. Acesso em: 27 Novembro 2012.

GMU. What is CFD? Computational Fluid Dynamics, 2009. Disponivel em: . Acesso em: 5 Outubro 2012.

GPGPU.ORG. Scalable HeterOgeneous Computing (SHOC) Benchmark Suite. General Purposes Computation on Graphics Hardware, 2010. Disponivel em: . Acesso em: 3 Outubro 2012.

GPGPU.ORG. About GPGPU.org. GPGPU.org, 2012. Disponivel em: . Acesso em: 25 Setembro 2012.

GREEN500. The Green500 List. The Green500 List, 2012. Disponivel em: . Acesso em: 26 Maio 2012.

GUSSOW, M. Eletricidade Básica. 2ª. ed. São Paulo: Makron Books, 1996.

HALFHILL, T. R. Looking Beyond Graphics. Fermi Architecture for High- Performance Computing | NVIDIA, 2009. Disponivel em: . Acesso em: 27 Novembro 2012.

HARDESTY, L. Explained: The Discrete Fourier Transform. Massachussets Institute of Technology, 2009. Disponivel em: . Acesso em: 26 Setembro 2012.

HERNANDEZ, M. F. G. Eliminação de Gauss e Decomposição LU. Decomposição LU - Unicamp, 2012. Disponivel em: . Acesso em: 26 Setembro 2012.

HEWITT, P. G. Física Conceitual. 9ª. ed. Porto Alegre: Bookman, 2002.

HWU, W.-M.; STONE, J. The OpenCL Programming Model. Illinois UPCRC Summer School. Illinois. 2010.

IDA, C. O. Benchmarks, 2000. Disponivel em: . Acesso em: 14 Jan 2013.

INTEL. Enhanced Intel® SpeedStep® Technology for the Intel® Pentium® M Processor, 2004. Disponivel em: . Acesso em: 27 Novembro 2012.

INTEL. Intel.con. Dual-Core Intel® Xeon® Processor 7000 Sequence-based Platforms, 2012. Disponivel em: . Acesso em: 28 Novembro 2012.

INTEL. Intel® Core™ Processor Family. Intel.com, 2012. Disponivel em: . Acesso em: 28 Novembro 2012.

INTEL. Intel® SDK for OpenCL* Applications 2012. Intel® Developer Zone, 2012. Disponivel em: . Acesso em: 25 Setembro 2012.

INTEL. Intel® Xeon Phi™ Coprocessor 5110P. Intel Corporation, 2012. Disponivel em: . Acesso em: 14 Jan 2013.

INTEL. Intel® Xeon Phi™ Coprocessor: Parallel Processing. The Intel® Xeon Phi™ Coprocessor: Parallel Processing, Unparalleled Discovery, 2012. Disponivel em: . Acesso em: 27 Novembro 2012.

INTEL. Products (Formerly Arrandale). ARK | Your source for information on Intel products, 2012. Disponivel em: . Acesso em: 27 Novembro 2012.

INTEL. The Intel® Xeon Phi™ Coprocessor 5110P. Intel® Xeon Phi™ Coprocessor: Parallel Processing, 2012. Disponivel em: . Acesso em: 14 Jan 2013.

KARAS, P. GPU Acceleration of Image Processing Algorithms. Masaryk University. Brno, p. 42. 2010.

KERR, A.; DIOAMONS, G.; YALAMANCHILI, S. A Characterization and Analysis of PTX Kernels. School of Electrical and Computer Engineering - Georgia Institute of Technology. Atlanta, Georgia, p. 10. 2009.

KHRONOS GROUP. OpenCL - The open standard for parallel programming of heterogeneous systems. Khronos Group, 2012. Disponivel em: . Acesso em: 25 Setembro 2012.

LEE, K. S. Characterization and Explitation of GPU Memory Systems. Virginya Politechnic Institute and State University. Blacksburg, Virginia, p. 85. 2012.

LI, R. T. X. A Micro-benchmark Suite for AMD GPUs. University of Delaware. Delaware, p. 10. 2010.

LILJA, D. J. Measuring Computer Performance: A practitioner's guide. Cambridge (UK): Cambridge University Press, 2000.

LINDHOLM, E. et al. NVIDIA Tesla: A Unified Graphis And Computing Architecture. SCHOOL OF COMPUTER SCIENCE, Carnegie Mellon, 2008. Disponivel em: . Acesso em: 27 Novembro 2012.

MANDL, P.; BORDOLOI, U. General-purpose Graphics Processing Units Deliver New Capabilities to the Embedded Market. amd.com, 2011. Disponivel em: . Acesso em: 16 Jan 2013.

MARINHA DOS ESTADOS UNIDOS. Curso de Eletricidade Básica. 1ª. ed. Rio de Janeiro: Hemus, 1998.

NASA. Nas Parallel Benchmarks. NAS Advanced Supercomputing Division, 2012. Disponivel em: . Acesso em: 26 Setembro 2012.

NICKOLLS, J.; DALLY, W. J. THE GPU COMPUTING ERA. IEEE MICRO, Santa Clara, Califórnia, Março - Abril 2010. 56-69.

NVIDIA. CUDA C Programming Guide. Developer Zone, 2007. Disponivel em: . Acesso em: 14 Jan 2013.

NVIDIA. NVIDIA GF100. NVIDIA, 2010. Disponivel em: . Acesso em: 16 Jan 2013.

NVIDIA. NVIDIA GeForce GTX 680. The fastest, most efficient GPU ever built., 2012. Disponivel em: . Acesso em: 27 Novembro 2012.

NVIDIA. OpenCL | Nvidia Developer Zone. Nvidia Developer Zone, 2012. Disponivel em: . Acesso em: 25 Setembro 2012.

NVIDIA. Parallel Programming and Computing Platform | CUDA | NVIDIA. Welcome to NVIDIA - World Leader in Visual Computing Technologies, 2012. Disponivel em: . Acesso em: 27 Novembro 2012.

NVIDIA. What Is CUDA. Nvidia Developer Zone, 2012. Disponivel em: . Acesso em: 30 Maio 2012.

NVIDIA. What is GPU Computing? | High-Performance Computing. NVIDIA, 2012. Disponivel em: . Acesso em: 25 Setembro 2012.

OANCEA, B.; ANDREI, T.; DRAGOESCU, R. M. GPGPU Computing. Challenges of the Knowledge Society. IT, Bucharest, 11-12 Mai 2012. 2070.

OBAIDAT, M. S.; BOUDRIGA, N. A. Fundamentals of performance evaluation of computer and telecomunications systems. Nova Jersey (US): John Wiley & Sons, 2010.

O'MALLEY, J. Análise de Circuitos. 2ª. ed. São Paulo: Makron Books, 1993.

RAMOS, N. Avaliação e comparação de desempenho de computadores: metodologia e estudo de caso. Universidade Federal de Pernambuco. Recife, p. 60. 2008.

RAUBER, T.; RÜNGER, G. Parallel programming for multicore and cluster systems. 1ª. ed. New York: Springer, 2010.

SAPHIR, W.; WOO, A.; YARROW, M. The NAS Parallel Benchmarks 2.1 Results. Nas Parallel Benchmarks, 1996. Disponivel em: . Acesso em: 27 Setembro 2012.

SEOUL NATIONAL UNIVERSITY. SNU NPB Suite. Center for Manycore Programming, 2011. Disponivel em: . Acesso em: 26 Setembro 2012.

STONE, J. E.; GOHARA, D.; SHI, G. OpenCL: A Parallel Programming Standard for Heterogeneous Computing Systems. US National Library of Medicine, 2010. Disponivel em: . Acesso em: 16 Jan 2013.

SUN, E.; KAELI, D. Aggressive Value Prediction on a GPU. 23rd International Symposium on Computer Architecture and High Performance Computing , Boston - MA, 26 - 29 Out 2011. 9 - 16.

TSUKAMOTO, S. K. Arquitetura dos supercomputadores – TOP500. Universidade de São Paulo. São Paulo, p. 16. 2010.

UNIVERSITY OF VIRGINIA. Leukocyte. Leukocyte - Rodinia, 2009. Disponivel em: . Acesso em: 22 Novembro 2012.

ZUBELLI, J. P. Decomposição LU. IMPA, 2010. Disponivel em: . Acesso em: 26 Setembro 2012.

ANEXOS

ANEXO A – Instalação e Configuração do OpenCL

Abaixo descreveremos os passos seguidos para instalação e configuração das bibliotecas OpenCL no Ubuntu, conforme visto em .

Cabeçalhos (Headers)

Os headers apenas necessitam ser baixados do site do distribuidor, conforme os códigos descritos abaixo:

cd /usr/include sudo mkdir CL cd CL sudo wget http://www.khronos.org/registry/cl/api/1.1/cl_d3d10.h \ http://www.khronos.org/registry/cl/api/1.1/cl_ext.h \ http://www.khronos.org/registry/cl/api/1.1/cl_gl_ext.h \ http://www.khronos.org/registry/cl/api/1.1/cl_gl.h \ http://www.khronos.org/registry/cl/api/1.1/cl.h \ http://www.khronos.org/registry/cl/api/1.1/cl_platform.h \ http://www.khronos.org/registry/cl/api/1.1/opencl.h \ http://www.khronos.org/registry/cl/api/1.1/cl.hpp

Bibliotecas

Para configuração das bibliotecas primeiro deve ser instalado o SDK/Driver que contém as mesmas, após deve-se configurar o sistema, conforme especificado a seguir:

Intel: sudo cp /usr/lib/libOpenCL.so /usr/lib/OpenCL/vendors/intel/ sudo echo "/usr/lib/OpenCL/vendors/intel" > /etc/ld.so.conf.d/opencl- vendor-intel.conf sudo ldconfig

AMD: sudo mkdir -p /usr/lib/OpenCL/vendors/amd/ sudo cp lib/x86/* /usr/lib/OpenCL/vendors/amd/ sudo echo "/usr/lib/OpenCL/vendors/amd" > /etc/ld.so.conf.d/opencl- vendor-amd.conf sudo ldconfig

NVIDIA: Para configuração da NVIDIA o caminho é um pouco mais complicado, visto que pode ser necessário manter as bibliotecas no local original para que não pare de funcionar a CUDA. Faz-se o seguinte:

sudo echo "/usr/local/cuda/lib" >> /etc/ld.so.conf.d/opencl-vendor- nvidia.conf sudo ldconfig

LibOpenCL.so

Configuração da biblioteca do OpenCL:

Intel: sudo ln -s /usr/lib/OpenCL/vendors/intel/libOpenCL.so /usr/lib/libOpenCL.so.1.1

AMD: sudo ln -s /usr/lib/OpenCL/vendors/amd/libOpenCL.so /usr/lib/libOpenCL.so.1.1

NVIDIA: sudo ln -s /usr/local/cuda/lib/libOpenCL.so /usr/lib/libOpenCL.so.1.0

O próximo passo deve ser feito para todos, visto que vincula a biblioteca 1.1 para funcionar também como a 1.0, visto que são compatíveis:

sudo ln -s /usr/lib/libOpenCL.so.1.1 /usr/lib/libOpenCL.so.1 sudo ln -s /usr/lib/libOpenCL.so.1 /usr/lib/libOpenCL.so sudo ln -s /usr/lib/libOpenCL.so.1.1 /usr/lib/libOpenCL.so.1.0

Feitos estes procedimentos basta agora instalar os drivers de cliente, se já não foi feito anteriormente.

Anexo B Configuração Dranetz Power Platform 4300

Abaixo apresentamos três manuais sobre o aparelho utilizado nas medições de energia, sendo os manuais referentes à configuração inicial, configuração para a medição de energia e procedimentos para salvar os dados em cartão de memória, transferência dos arquivos para o computador e operações com o software Dran View. O manual será composto pelo passo à passo formado por imagens, com observações caso necessário.

Configuração inicial

A configuração do equipamento Dranetz Power Platform 4300 foi realizada conforme o manual de usuário disponível em . Figura 22 - Ligando o aparelho.

Fonte: Laboratório do DCEEng.

Figura 23 – Inicialização do Dranetz.

Fonte: Laboratório do DCEEng.

Após inicializar, o aparelho questiona se desejamos selecionar sondagem de corrente? Basta pressionar o botão correspondente a opção YES.

Figura 24 - Selecionando a sondagem de corrente.

Fonte: Laboratório do DCEEng.

Na tela seguinte, devemos selecionar o tipo de sonda utilizada (TR2510), em nosso caso, utilizamos apenas o canal A ignorando os demais canais. Neste caso já está correto o modelo da sonda, basta pressionar EXIT.

Figura 25 - Selecionando o tipo de sonda utilizada (TR2510).

Fonte: Laboratório do DCEEng.

Na tela principal do aparelho, pressionamos o botão SETUP para acessar as configurações necessárias antes das medições.

Figura 26 – Tela principal do aparelho (acessando a tela de configurações).

Fonte: Laboratório do DCEEng.

A sequência de imagens abaixo ilustra os passos para a configuração da escala de fatores.

Figura 27 - Acessando a opção 5: ADVANCED SETUP OPTIONS.

Fonte: Laboratório do DCEEng.

Figura 28 – Acessando a opção 1: SET INPUT CONFIGURATIONS

Fonte: Laboratório do DCEEng.

Figura 29 – Acessando a opção 3: SET SCALE FACTORS.

Fonte: Laboratório do DCEEng.

Ajustamos cada canal para (utilizando as opções “NEXT CHAN” e

“ENTER SCALE” e pressionando o teclado numérico para a entrada dos números) que fique conforme a imagem abaixo, lembrando que utilizaremos apenas o canal A para realizar as medições.

Figura 30 – Ajuste do fator de escala dos canais.

Fonte: Laboratório do DCEEng.

Após pressionamos duas vezes o botão EXIT para retornar ao menu principal das configurações. No menu principal de configurações, apresentamos os passos para configurar a frequência de operação para 60Hz.

Figura 31 - Acessando a opção 4: SET SYNC PARAMETERS

Fonte: Laboratório do DCEEng.

A opção “SYNC MODE” deverá ficar como “External” e a opção “NOMINAL FREQUENCY” deverá ficar com o valor “60.0” conforme figura abaixo.

Figura 32 – Ajustando a frequência da rede elétrica.

Fonte: Laboratório do DCEEng.

Após pressionamos duas vezes o botão EXIT para retornar ao menu principal das configurações. O último ajuste necessário está no intervalo em segundos de cada medição, sendo demonstrado na sequencia de figuras abaixo.

Figura 33 - Acessando a opção 5: SET INTERVAL FOR TIMED READINGS.

Fonte: Laboratório do DCEEng.

Figura 34 - Ajustando o intervalo em 5 segundos de medição dos dados.

Fonte: Laboratório do DCEEng.

Após pressionamos EXIT três vezes e voltamos a tela principal do Dranetz, concluindo assim a configuração inicial do mesmo.

Realizando as medições de energia

A sequência de figuras abaixo ilustra o passo a passo realizado no aparelho em cada medição de energia, salientando que a cada medição, o aparelho era desligado para a remoção do cartão de memória para coleta dos dados.

Figura 35 - Ligando o aparelho.

Fonte: Laboratório do DCEEng.

Figura 36 - Inicialização do Dranetz.

Fonte: Laboratório do DCEEng.

Após inicializar, o aparelho questiona se desejamos selecionar sondagem de corrente? Basta pressionar o botão correspondente a opção YES.

Figura 37 – Confirmando a utilização de sondagem de corrente.

Fonte: Laboratório do DCEEng.

Figura 38 – Definindo o tipo da sonda utilizada.

Fonte: Laboratório do DCEEng.

Agora vamos desativar os canais (B, C e D) que não iremos utilizar pressionando o botão SELECT CHANNEL.

Figura 39 – Acessando menu para desabilitar canais desnecessários.

Fonte: Laboratório do DCEEng.

Para desativar um canal, basta apertar o botão “NEXT CHANEL” para trocar de canal (A, B, C ou D) e após pressionar os botões “VOLTS ON/OFF” e “AMPS ON/OFF” para desativar as medições nos canais desejados (B, C e D) Ao finalizar de desativar a medição nos canais B, C e D o resultado deverá ser conforme a imagem na sequencia. Após, basta pressionar o botão EXIT e retornar a tela principal.

Figura 40 – Canais B, C e D desativados.

Fonte: Laboratório do DCEEng.

Para acompanhar melhor a medição de energia, na tela principal pressionamos o botão “METER MODE”.

Figura 41 – Alterando a visualização da medição de energia.

Fonte: Laboratório do DCEEng.

Após pressionamos NEXT METER para a exibição da medição desejada.

Figura 42 - Alterando para a próxima visualização da medição de energia.

Fonte: Laboratório do DCEEng.

Exibição da tela de medição desejada. Para sair da tela, basta pressionar EXIT.

Figura 43 – Tela utilizada para acompanhar as medições de energia.

Fonte: Laboratório do DCEEng.

Salvando os dados e exportando para arquivo TXT

Com o equipamento já ligado e em funcionamento, na tela principal, basta acessar a opção SETUP para acessar as funções do cartão de memória.

Figura 44 – Acessando o menu de configurações.

Fonte: Laboratório do DCEEng.

Figura 45 - Acessando a opção 4: MEMORY FUNCTIONS.

Fonte: Laboratório do DCEEng.

Figura 46 - Acessando a opção 1: MEMORY CARD FUNCTIONS.

Fonte: Laboratório do DCEEng.

Figura 47 - Acessando a opção WRITE CARD para salvar os dados coletados.

Fonte: Laboratório do DCEEng.

Para salvar os dados no cartão, basta pressionar as opções WRITE EVENTS, WRITE SETUPS e WRITE BOTH.

Figura 48 - Salvar os dados coletados no cartão.

Fonte: Laboratório do DCEEng.

Após salvar os dados, basta desligar o aparelho para remover o cartão de memória.

Figura 49 – Removendo o cartão de memória na frontal direita do aparelho.

Fonte: Laboratório do DCEEng.

Figura 50 - Salvando os dados para o computador

Fonte: Laboratório do DCEEng.

São 3 arquivos (HCI.EVT, HCI.SET, HCI.MDB) que o Dranetz gera, os quais salvamos no computador, sendo utilizado apenas o arquivo HCI.EVT devido ao fato de ser armazenado neste arquivo os últimos 20 minutos de medição, onde a cada medição de 10 minutos, salvava-se os dados no computador, não sendo necessários os demais arquivos. Para visualizar os dados gerados, utilizamos o software Dran-View 6.0 Entrerprise (trial). A versão do programa utilizada foi a “Enterprise” que está disponível para download em .

Figura 51 - Tela principal do Dran-View.

Fonte: print do software em execução.

Para efetuarmos a exportação dos arquivos, precisamos habilitar uma barra de ferramentas (Adittional Tools), habilitamos esta barra ao clicar com o botão direito do mouse sobre alguma das barras já existentes, selecionando a opção Additional Tools ( ), a qual disponibiliza o botão properties ( ). Após, basta abrir os arquivos salvos, clicar no botão “properties” acima citado e selecionar o que desejamos exportar, conforme pode ser visualizado na imagem abaixo.

Figura 52 - Selecionando as informações desejadas.

Fonte: print do software em execução.

Na sequencia, basta ir ao menu “FILE” opção “Save AS” e salvar o arquivo no local desejado com o formato TXT. Após o arquivo TXT salvo, efetuamos a importação do mesmo com o Microsoft Excel, convertendo o mesmo em tabela e realizando os cálculos necessários.

ANEXO C – Tabelas de Resultados de Testes

Tabela 8 - Bus Speed Download (GB/s)

GPU NVIDIA GPU AMD CPU Intel 6,6460 6,2295 10,4954 6,6459 6,2254 11,1333 6,6459 6,2358 11,0989 6,6460 6,0651 10,6862 6,6460 5,9139 11,2605 6,6460 6,1792 10,0262 6,6460 6,0616 10,1543 6,6459 6,2196 11,0219 6,6436 6,1779 11,3183 6,6460 5,9585 10,9840 6,6457 6,1267 10,8179

Tabela 9 - Bus Speed ReadBack (GB/s)

GPU NVIDIA GPU AMD CPU Intel 6,6450 6,7316 11,0794 6,6453 6,7359 9,8684 6,6454 6,6698 11,7086 6,6454 6,6905 10,4257 6,6452 6,6945 10,9711 6,6453 6,7144 12,0194 6,6453 6,7097 10,6183 6,6453 6,6675 10,9464 6,6451 6,6688 12,0670 6,6454 6,6959 10,3341 6,6453 6,6979 11,0038

Tabela 10 - Peak FLOPS (SP) (GFLOPS)

GPU NVIDIA GPU AMD CPU Intel 151,5270 187,2730 51,0947 151,5280 187,3290 49,5782 151,5280 187,2230 52,8964 151,7990 187,1500 52,8982 151,5290 187,3810 52,8835 151,8010 187,1500 51,6860 151,5260 187,2810 51,0778 151,7970 187,2370 52,8652 151,5270 187,1780 51,0936 151,5310 187,1860 52,8681 151,6093 187,2388 51,8942

Tabela 11 - Peak FLOPS (DP) (GFLOPS)

GPU NVIDIA GPU AMD CPU Intel 12,9508 Não Suportado 50,7741 12,9508 Não Suportado 50,8315 12,9508 Não Suportado 52,7497 12,9508 Não Suportado 52,7624 12,9508 Não Suportado 52,7635 12,9508 Não Suportado 52,7587 12,9509 Não Suportado 50,7905 12,9508 Não Suportado 52,7908 12,9508 Não Suportado 50,8408 12,9508 Não Suportado 52,0446 12,9508 Não Suportado 51,9107

Tabela 12 - Device Memory (AMD)

Global Global Global Read Global Write Local Local Texture Read Strided Write Strided Read Write Read 9,4514 3,0428 8,4556 0,6167 43,8498 69,4563 16,2375 9,4420 3,0710 8,4505 0,6110 43,7000 69,5249 15,6180 9,4610 3,0936 8,4515 0,6103 43,8315 69,2179 15,2335 9,4609 2,9848 8,4642 0,6112 43,8347 69,2994 15,5644 9,4692 3,0248 8,5008 0,6099 43,7123 69,2585 15,7104 9,4566 3,0383 8,4695 0,6091 43,8731 69,3786 15,6945 9,4376 3,1083 8,5041 0,6110 43,8666 69,4608 15,8240 9,4562 3,0507 8,4620 0,6171 43,7125 69,5046 16,1168 9,4573 3,0164 8,4591 0,6132 43,8681 69,7400 15,6047 9,5042 3,0767 8,4563 0,6110 43,8662 69,4014 15,8300 9,4596 3,0507 8,4674 0,6121 43,8115 69,4242 15,7434

Tabela 13 - Device Memory (NVIDIA)

Global Global Global Global Read Write Write Local Local Texture Read Strided Strided Strided Read Write Read 6,7289 1,5051 6,4227 0,3897 62,6634 72,8622 21,0456 6,7407 1,5097 6,4200 0,3891 62,6364 72,8411 22,5210 6,7386 1,5057 6,4255 0,3895 62,6627 72,8656 22,2307 6,7432 1,5063 6,4262 0,3892 62,6645 72,8642 22,4131 6,7360 1,5168 6,4188 0,3942 62,6739 72,8642 21,9919 6,7296 1,5029 6,4363 0,3890 62,6619 72,8639 22,4285 6,7377 1,5014 6,4269 0,3893 62,6637 72,8625 22,3825 6,7387 1,5055 6,4246 0,3891 62,6578 72,8404 22,5055 6,7350 1,5208 6,4302 0,3905 62,6558 72,8611 22,0511 6,7395 1,5016 6,4207 0,3906 62,6650 72,8649 22,3063 6,7368 1,5076 6,4252 0,3900 62,6605 72,8590 22,1876

Tabela 14 - Device Memory (Intel)

Global Global Global Read Global Write Local Local Texture Read Strided Write Strided Read Write Read 1,4527 19,1333 0,2854 16,8345 18,7305 24,6817 2,9412 1,4603 19,2729 0,2704 16,8778 18,7606 24,7020 2,9340 1,4499 19,1358 0,2754 16,8660 18,7609 24,7035 2,8114 1,4586 19,1583 0,2725 16,8791 18,7568 24,7042 2,9169 1,4582 19,1538 0,2768 16,8504 18,7629 24,7035 2,9497 1,4499 19,1702 0,2682 16,8920 18,7647 24,7022 2,9457 1,4577 19,1352 0,2706 16,8631 18,7638 24,7040 2,8085 1,4578 19,1505 0,2743 16,8686 18,7615 24,7017 2,7859 1,4544 19,1405 0,2758 16,9100 18,7594 24,7035 2,8190 1,4553 19,1378 0,2755 16,8273 18,7612 24,7064 2,7810 1,4555 19,1588 0,2745 16,8669 18,7582 24,7013 2,8693

Tabela 15 - Kernel Compilation (s)

GPU NVIDIA GPU AMD CPU Intel 0,0001 0,0588 0,0129 0,0001 0,0590 0,0129 0,0001 0,0591 0,0125 0,0001 0,0590 0,0123 0,0001 0,0598 0,0123 0,0001 0,0592 0,0124 0,0001 0,0591 0,0129 0,0001 0,0590 0,0123 0,0001 0,0590 0,0125 0,0001 0,0590 0,0130 0,0001 0,0591 0,0126

Tabela 16 - Queuing Delay (ms)

GPU NVIDIA GPU AMD CPU Intel 0,0039 0,0893 0,0415 0,0057 0,0888 0,0392 0,0058 0,0889 0,0416 0,0057 0,0746 0,0419 0,0058 0,0928 0,0414 0,0053 0,0892 0,0415 0,0057 0,0927 0,0417 0,0055 0,0893 0,0422 0,0056 0,0859 0,0419 0,0058 0,0901 0,0417 0,0055 0,08816 0,0415

Tabela 17 - Leukocyte (NVIDIA)

TEMPO DE EXECUÇÃO (s) CONSUMO (W) 12,5747 0,2350 12,5787 0,2310 12,5757 0,2230 12,5787 0,2490 12,5784 0,2350 12,5774 0,2420 12,5801 0,2350 12,5815 0,2490 12,5709 0,1400 12,5733 0,2320 12,5769 0,2271

Tabela 18 - Leukocyte (AMD)

TEMPO DE EXECUÇÃO (s) CONSUMO (W) 29,1348 0,2640 28,1885 0,2050 28,2122 0,2700 28,1641 0,2770 28,2722 0,2550 28,2091 0,2470 28,1777 0,2550 28,1911 0,2510 28,2461 0,1640 28,2129 0,2010 28,300868 0,2389

Tabela 19 - Fast Fourrier Transformations (NVIDIA)

TEMPO DE EXECUÇÃO (s) MFLOPS CONSUMO (W) 19,4830 422,1400 0,3020 19,5090 421,5800 0,3630 19,5090 421,5200 0,2820 19,5200 421,5800 0,3430 19,5280 421,4300 0,3430 19,5030 421,6200 0,3430 19,5110 421,6200 0,2420 19,5000 421,7100 0,2220 19,5160 421,5000 0,3430 19,5120 421,5700 0,2820 19,5091 421,6270 0,3065 MFLOPS/WATT 1375,618271

Tabela 20 - Fast Fourrier Transformations (Intel)

TEMPO DE EXECUÇÃO (s) MFLOPS CONSUMO (W) 5,3850 2010,1000 0,0390 5,4210 1995,4500 0,0470 5,4340 1986,6200 0,0380 5,4450 1981,5500 0,0460 5,4140 1994,1700 0,0470 5,4480 1977,8400 0,0450 5,4510 1991,8400 0,0480 5,4270 1993,0900 0,0400 5,4500 1989,6600 0,0340 5,4370 1991,4300 0,0270 5,4312 1991,1750 0,0411 MFLOPS/WATT 48447,08029