UNVERSDADE FEDERAL DE PERNAMBUCO

CENTRO DE NFORMTCA
Trabalho de Graduao
Anlise de algoritmo de modelagem 2D
em problemas de ssmica utilizando GPU
Aluno: Bruno Correia da Silva (bcs2@cin.ufpe.br)
Orientador: Manoel Eusbio de Lima (mel@cin.ufpe.br)
Co-Orientadora: Veronica Teichrieb (vt@cin.ufpe.br)
Recife |2009
Bruno Correia da Silva
2
Bruno Correia da Silva
Anlise de algoritmo de modelagem 2D
em problemas de ssmica utilizando GPU
Orientador: Prof. Dr. Manoel u!"#io de $i%a
Co - Orientadora: Prof&. Dr&. 'eronica (eic)rie#
Recife|2009
Trabalho de graduao
apresentado Secretaria de
Graduao em Engenharia da
Computao da Universidade
Federal de Pernambuco, como
requisito parcial para obteno
do grau de Engenheiro da
Computao.
3
A*radeci%ento!
Agradeo aos meus pais e familiares, Sr. Carlos Correia e Sra Edna Meire, que
mesmo a distncia proveu um suporte indispensvel nesta caminhada.
A um deus, que est presente dentro de mim e de todos que oferece harmonia entre
as pessoas quando esse meu deus aceita o seu deus.
A meu amor, Queliane, que me apoiou e logo vai revisar a ortografia desse teto
tam!"m, eternamente agradecido por sua !ondade, carinho e por estar ao meu
lado#
Aos meus coordenadores, meus agradecimentos pelos feed!ac$s e dicas
etremamente pertinentes, a minha co%orientadora &eronica 'eichrie!, pela
paci(ncia e dedica)o e ao meu orientador Manoel Eus"!io pela confiana em meu
tra!alho.
Agradeo aos meus amigos, que compartilharam os momentos de dificuldade e
contri!u*ram para o sucesso+
,edro -eite por todo o apoio dado nessa reta final me guiando por caminhos
o!scuros# Artur -ira por me propor argumentos para serem superados# a .uilherme
/antas meu monitor especial, Marcelo -ucena meu amigo de conversas aleat0rias,
,epito meu advogado titular, 1amal meu !rother especial, 2elipe Santiago minha
autarquia, meus amigos que me oferecem sempre um momento de alegria e
descontra)o# a todos que encontrei no 3,C4n+ 1o)o ,aulo, 5runo ,essoa, 5iu
1os", Camaroti, 6odrigo ,imentel, 5runo 3olanda, os
&itors,&iviane,Aline,&icente,7ngelo,Manoel Eus"!io,,aulo S"rgio,/erci, Artur, 2a!io,
6afael, ,8etro e 1o)o Cle!er, um futuro engenheiro 5est pela perspectiva do
professor 3elio Magalh)es e minha tam!"m, agradeo a todos esses que fa9em
parte atualmente do meu tra!alho# as pessoas que : passaram por minha vida e
continuam com pinceladas, 1esus, 6afael 6ar, Age Man, 1osias 1unior, -uciano,
6enata .arcia, /ani, 6enata 5e9erra, /iego &ictor, 3udson !rother de enrascadas,
1ama:, Adelmario, Chico ,e9)o, Eduardo, ,aulo S"rgio flamenguista, -eonardo -uis,
4
;le!er, 3ugo,6odolfo, ,edro -ages, -am!erto, ,edro, /ig)o, 6odrigo Surf, ,a!lo
Mago, 1os" 6i!amar, -<cio 2lvio, Marcus, 1ailson e outros que n)o mencionei mas
tem seu local na minha gratid)o# aos meus amigos da C46A=/A, que tanto amo e
tive que me afastar para concluir meu sonho# a todos amigos que fi9 na >ECE,
CE2E'%CE, 2arias 5rito, Ari de S, Evolutivo e no caminhar da vida. Aos meus
professores da vida e de ensino+ Manoel Eus"!io, Marcilia Campos, 3"lio
Magalh)es, &eronica 'heichrie!, Silvio Melo, 1oaquim, Ascendino, 2ontana, Milde,
,aulo Maciel, ,aulo .onalves,S"rgio Cavalcante, Alui9io, 2ernando 2onseca,
,atricia 'edesco, ;tia, Ana Carolina, 6u8, Edson Carvalho,# a todos os funcionrios
do C4n, especialmente a -ucia e 6o!erto.
Aos amigos que : foram levados dessa vida, deio mais uma pincelada de mem0ria
nesse documento# amigos como St(nio e Aleandre.
Ao meu colega vendedor, -uis, que troue o note!oo$ em tempo h!il dos E>A e
me deu oportunidade de terminar esse documento e essa fase da vida.
5
Re!u%o
CORREA, Bruno da Silva. An+li!e de al*orit%o de %odela*e% 2D
e% ,ro#le%a! de !-!%ica utili.ando /P0. Monografia (Graduao em
Engenharia da Computao) Centro de nformtica, Universidade
Federal de Pernambuco, Recife-PE, 2009.
Os jogos para computadores se tornaram programas para medidas de
desempenho. Uma placa me satisfatria, com unidade de memria RAM rpida,
processadores que contm mais de um ncleo de processamento e placas de vdeo
de grande desempenho, revelam recursos necessrios nestes jogos, que mais se
assemelham aos algoritmos de processamento cientfico devido ao alto desempenho
computacional exigido.
Estes jogos requerem demasiadamente processamento grfico para inserir o
usurio em uma experincia nica de realidade virtual e melhor introspeco. Alguns
exemplos destes jogos so: 2arcr8 2, Crisis, Assassin Creed e outros. Cada um, de
uma forma geral, permite que o usurio interaja com todos os componentes de seu
mundo virtual, assemelhando-se a realidade do dia-a-dia. Para se conseguir todas
as aes em tempo real necessrio, no entanto, um grande desempenho de
processamento, principalmente nas placas de processamento de vdeo.
A comunidade cientfica, percebendo o potencial de dispositivos como GPUs
(.raphical ,rocess >nits), devido a sua caracterstica de processamento vetorial
paralelo de alto desempenho, resolveu utiliz-las, por volta do ano 2000, para
clculos cientficos em aplicaes similares, ou que requerem processamento de
imagens, como imagens mdicas, ssmica, geo-processamento, etc.
Percebendo uma nova rea de atuao para as placas de vdeo, as grandes
fabricantes, NVDA e AT, deram o passo inicial para a criao de placas que
6
fossem de propsito gerais. Foi criada assim, uma famlia de componentes
denominada GPGPU, que significa ".eneral ,orpose .raphical ,rocess >nit. As
GPGPU, agora diferentemente das tradicionais GPUs, que eram programadas
atravs de linguagens especiais, passam a utilizar uma linguagem de programao
similar linguagem C, com algumas modificaes. sto permite que um nmero
maior de pessoas consigam escrever seus prprios algoritmos, de maneira fcil,
com um bom desempenho.
O objetivo deste trabalho estudar e utilizar uma arquitetura GPGPU da
NVDA, a fim de estimar desempenho de algoritmos para modelagem 2D em estudo
de ssmica. O resultado deste projeto servir como base tambm para a criao de
um !enchmar$ experimental, que visar comparar seu desempenho com
plataformas baseadas em FPGAs.
Palavra!-c)ave: GPU, NVDA, GPGPU, Potncia, Anlise de desempenho.
7
A#!tract
CORREA, Bruno da Silva. Anal1!i! of al*orit)% for %odelin* in
,ro#le%! of 2D !ei!%ic u!in* /P0 Monograph (Graduation in
computational engineering) Center of Computer science, Federal
University of Pernambuco, Recife-PE, 2009.
The games for computers became programs to measures of performance. A
motherboard satisfactory, with unit of fast RAM, processors containing more than one
core processing and video cards of great performance, show necessary resources in
these games, which is more similar to scientific processing algorithms, due to the
high performance computing required.
These games require too much processing graph to insert the user into a unique
experience of virtual reality and better insight. Some examples of these games are:
FarCry 2, Crisis, Assassin Creed and others. Each, in general, allows the user to
interact with all components of your virtual world, similar to the reality of day-to-day.
To achieve all the actions in real time is necessary, however, a large processing
performance, especially in the processing of video cards.
The scientific community, realizing the potential of devices such as GPUs (Graphical
Process Units), a feature vector parallel processing of high performance, use it
resolved, by the year 2000 for similar applications in scientific calculations, or that
require image processing, such as medical images, seismic, geo-processing, etc.
Realizing a new area of operation for the video cards, large manufacturers, NVDA
and AT, have the first step towards the creation of plaques that were of general
purpose. t was created so a family of components called GPGPU, which means
"General Purpose Graphical Process Unit". The GPGPU, far different from traditional
GPUs, which were programmed using special languages, will use a programming
language similar to C language, with some modifications. This would allow a greater
8
number of people could write their own algorithms, so easy, with a good
performance.
The aim of this study is an architecture and use of GPGPU NVDA in order to
estimate performance of algorithms for modeling in a study of 2D seismic. The result
of this project will also serve as a basis for creating a benchmark test, which aims to
compare their performance with platforms based on FPGAs.
2e1 3ord!: GPU, NVDA, GPGPU, Power, performance Analysis.
9
Su%+rio
$i!ta de 4lu!tra56e!.............................................................................. pg.10
$i!ta de A#reviatura! e Si*la!............................................................. pg.11
CAP4(0$O 7
1.1 ntroduo......................................................................................... pg.12
CAP8(0$O 2
2.1 Histria sobre GPU ......................................................................... pg.14
2.2 Histria e arquitetura NVDA CUDA............................................... pg.15
2.3 Dispositivo de placas de vdeo........................................................ pg.29
CAP8(0$O 9
3.1 Estudo sobre o algoritmo e suas otimizaes................................. pg.32
CAP8(0$O :
4.1 Ambiente de desenvolvimento........................................................ pg.37
4.2 5enchmar$...................................................................................... pg.37
4.3 Metodologia para a anlise do desempenho.................................. pg.42
4.3.1 Clculo do desempenho.............................................................. pg.43
CAP8(0$O ;
5.1 Resultados...................................................................................... pg.46
5.1.1 Resultados da CPU..................................................................... pg.46
5.1.2 Resultados da GPU..................................................................... pg.48
5.2 Comparaes entre as arquiteturas............................................... pg.51
CAP8(0$O <
6.1 Concluses e Trabalhos Futuros.................................................... pg.54
Refer=ncia!.......................................................................................... pg.56
A!!inatura!.......................................................................................... pg.60
A,=ndice! - Apndice-A: Exemplo de sada do benchmark................. pg.61
Ane>o! - Anexo : Bloco de cdigo para calcular o clock na CPU...... pg.62
10
$i!ta de 4lu!tra56e! e /r+fico!
?i*ura 7: Arquitetura da GPU com Cg pg. 15
?i*ura 2: Linguagens suportadas pg. 16
?i*ura 9: Operaes de pontos flutuantes e !and?idth pg. 18
?i*ura :: Quantidade de transistores para processamento de dados pg. 19
?i*ura ;: Pilha de soft?are pg. 20
?i*ura <: Thread Batching pg. 24
?i*ura @: Conjunto de multiprocessadores SMT com memria compartilhada do
/evice pg. 26
?i*ura A: Leitura e Escrita pg. 27
?i*ura 9: A thread pode ter acesso leitura a espao de memria em todos esses
componentes e escrita somente alguns pg. 28
?i*ura 70: Chips de memria GDDR4 pg. 30
?i*ura 77: Maneira como os dados so calculados no eixo X x Z pg. 33
?i*ura 72: Estrutura de computao pg. 33
?i*ura 79: nserir o Pulso Ssmico no meio da matriz pg. 34
?i*ura 2:: Everest e GPU-Z sendo executados para medir desempenho da GPU
com algoritmo fluids da SDK do CUDA pg. 38
?i*ura 9;: Desempenho do overcloc$ da CPU utilizando o algoritmo de modelagem
pg. 40
?i*ura :<: Equao para medio do tempo do processador pg. 41
?i*ura ;@: Medio de temperatura utilizando GPU-Z utilizando o algoritmo da
ssmica pg. 45
?i*ura 7A: Estrutura de computao no CUDA pg. 49
/r+fico 7: Quantidade de ciclos de cloc$ versus tamanho da matriz no CUDA
pg. 51
/r+fico 2: Quantidade de ciclos de cloc$ versus tamanho da matriz no CPU.
pg. 52
/r+fico 9: Quantidade de ciclos de cloc$ versus tamanho da matriz na CPU e CUDA
pg. 52
11
$i!ta de A#reviatura! e Si*la!
A$0 - Unidade Lgica e aritmtica
ABS4 - American National Standards nstitute
C0B$AS - Compute Unified Basic Linear Algebra Subprograms
C0DA - Compute Unified Device Architecture
C0??(- Compute Unified Fast Fourier Transform
C* C for graphics
CP0 - Central Processing Unit
2D - bidimensional
DMA - High Performance Direct memory Access
DRAM - Dynamic Random Access Memory
?P/A - Field Programmable Gate Array
/P0 - Graphic Processor Unit
/P/P0 - General Purpose Graphic Processor Unit
CPC - High Performance Computing
PC4-e - PC Express
S4MD - Single nstructions, Multiple Data Architecture
S4M( - Single nstruction Multiple Thread
SM - Streaming Multiprocessor
SP - Scalar Processor
(DP - Thermal Design Power
9D - Trs dimenses, tridimensional
(D$ Transform & Lighting
-
12
Ca,-tulo 7
7.7 4ntrodu5Eo
@Aith this ne? programming model and the ne? graphics cards,
it is possi!le to o!tain impressive gains in performance ?hen
comparing to conventional processorsB
C
As aplicaes computacionais, de forma geral, tm demandado ,cada vez
mais, processamento de alto desempenho (3igh ,erformance Computing
Applications). Essas necessidades de fato j existem, mas eram processadas em
grandes mainframes, supercomputadores ou grandes clusters de computadores. A
resoluo de problemas de alto desempenho uma rea no mercado mundial
suprida por empresas que utilizam tecnologias como Cell, GPGPU, cluster, entre
outras arquiteturas, com o intuito de vender a melhor soluo, nos mais diversos
domnios de aplicao, como: anlise financeira, minerao de dados,
processamento de imagens, computao cientfica, modelagem computacional, etc.
1

Uma maneira de desafogar essa grande demanda de processamento nos
processadores utilizar um dispositivo que bem comum nas mos dos usurios de
jogos, as placas de vdeos. Elas vm evoluindo e atingindo um alto grau de
eficincia no processamento de dados devido aos requisitos dos jogos que so cada
vez mais complexos. Alm disto, seu custo baixssimo se comparado a sistemas
especialistas dedicados a problemas de alto desempenho. Atualmente, as GPUs
conseguem manter a ordem de teraflops de processamento, que a medida
utilizada para dispositivos de alto desempenho.
25
Por outro lado, j h duas dcadas, est consolidada a utilizao de
dispositivos lgicos programveis como os FPGAs (2ield ,rogramma!le .ate
Arra8s) para soluo de problemas atravs de prototipao. O uso de FPGA se d
quando no vivel o custo para fabricar o chip daquela soluo, ou que o produto
da soluo ir mudar constatemente comprometendo financeiramente o valor final.
13
Agora vem sendo usado para solues de HPC (principalmente pelo baixo consumo
de potncia eltrica o que no acontece na GPU), alm de possibilitarem uma
melhoria bastante significativa de desempenho devido a algumas caractersticas,
como seu paralelismo intrnseco, maior largura de banda no acesso memria e
seu poder de customizao.
7;36
Neste contexto, este trabalho de graduao tem como objetivo identificar
vantagens e desvantagem da GPU visando um algoritmo de alto desempenho em
modelagem 2D em problemas de ssmica.
Este trabalho apresenta otimizaes do algoritmo na arquitetura NVDA
CUDA. Tambm ser realizada uma medio de desempenho. A metodologia criada
poder ser utilizada posteriormente para estudos comparativos com a arquitetura
FPGA ou qualquer outra que venha a ser utilizada para resoluo desse problema.
3
A estrutura da presente monografia segue a seguinte ordem de apresentao:
No capitulo 2 sero abordados a histria sobre a GPU e CUDA, um tpico sobre a
arquitetura CUDA e um explicao sobre algumas tecnologias das placas de vdeo
atualmente. No capitulo 3 ser relatado sobre o Estudo do algoritmo e suas
otimizaes.O capitulo 4 trar a anlise de Desempenho e Potncia do algortimo.
Em seguida ser apresentado as concluses, bem como recomendaes para
projetos futuros, as referncias utilizadas na elaborao da presente monografia, as
assinaturas, apndices e os anexos do trabalho.
14
Ca,-tulo 2
2.7Ci!tFria !o#re /P0
GPU's foram inicialmente desenvolvidas com o propsito de rederizao
grfica. Porm,atualmente tem um potencial enorme na rea de alta performance de
?or$station. A arquitetura das CPU's tm duas ou quatro cores e diferente da
arquitetura das GPUs que apresentam centenas de cores que rodam milhares de
threads.
6
O uso das GPU para programao de propsito geral, chamadas - GPGPU, j
vem sendo feito pela comunidade cientfica h bastante tempo. Havia para essa
programao uma necessidade de epertise sobre o assunto, no havendo
facilidades para o aprendizado da atividade.
Os programadores transformavam o problema em um algoritmo de
computao grfica, modelando-o. O resultado era algum tipo de soluo grfica.
Em seguida, o resultado da compilao era transformado para o mundo do problema
inicial. Ou usavam assem!l8 e programavam diretamente os verte shaders da
placa.
Fazer uma multiplicao Matriz por Matriz apresentava uma complexidade
enorme pela linguagem em assem!l8 que se usava e a falta de conhecimento sobre
as arquitetura das placas de vdeos que no so publicadas pelos fabricantes. As
placas de vdeo, inicialmente, no tinham o foco de programao de algoritmos. E
muitas facilidades e performance que a placa oferecia somente eram acessadas
atravs de comandos de AP que eram oferecidas apenas a jogos. Um exemplo o
T&L que quando foi disponibilizada na quarta gerao no era oferecida para
programao.
38;39
A NVDA criou Cg, uma AP especfica para programao em placas grficas.
Ela ANS C e usa todo potencial do hardware. sso permite que o usurio no
precise programar em assem!l8 ou fazer modelagem de problemas para
15
computao grfica. O programador tem acessvel tanto directx quanto OpenGL.
42
Abaixo, a Figura1 mostra a arquitetura das placas de vdeos e como o Cg
interage em mesmo nvel de hierarquia com o runtime do Directx e OpenGL.
Figura 1: Arquitetura da GPU com Cg
41
.
2.2 Ci!tFria e arGuitetura B'4D4A C0DA
CUDA foi lanado pela NVDA em novembro de 2006. Sua proposta foi criar
uma arquitetura de computao paralela de propsito geral. A justificativa para isso
foi aproveitar a plataforma de computao paralela das placas grficas para resolver
diversos algoritmos computacionais eficientemente. O aplicativo produzido sobre a
16
AP CUDA pode ser um algoritmo em linguagem C, OpenCL, Fortran, C++ e DX11,
no havendo limitaes para o suporte de novas linguagens (Ver Figura1). Ele
tambm pode se comunicar atravs de interface entre outros programas.
37
O CUDA no funciona em todas as GPUs. A arquitetura fornecida a partir da
srie 8 das placas da NVDA, ou modelos posteriores s placas Quadro FX
5600/4600 e Tesla. Veja na Figura 2 uma hierarquia das linguagens suportadas pela
arquitetura CUDA.
Figura 2: Linguagens suportadas
6
.
A arquitetura NVDA CUDA no adequada para resolver para todos os tipos
de problemas. Uma forma de verificar se o nosso problema alcanar alta
performance nessa arquitetura guiar-se pelo trabalho de Asanovic et al, que
apresenta os chamados "13 anes. Cada "ano um mtodo algortmico que
captura um padro de computao e comunicao comum a uma classe de
aplicaes importantes para HPC.
39
Os treze anes sugeridos so: lgebra linear densa, lgebra linear esparsa,
mtodos espectrais, mtodos =%5od8, grids estruturadas, grids no estruturadas,
algoritmos do tipo Quantum Monte Carlo, lgica combinacional, graph traversal,
17
modelos grficos, mquinas de estado finito, programao dinmica e 5ac$trac$ ou
5ranch%and%5ound.
9;13
No ser detalhado sobre o que cada ano representa, cabendo apenas
salientar que o problema atacado nesse trabalho de graduao est inserido no
grupo do primeiro ano: algebra linear densa. Este grupo aborda operaes com
matrizes e vetores e utiliza acesso a memria (matrizes) de maneira tranada.
A arquitetura NVDA CUDA se baseia tanto em componentes de hard?are
como de soft?are. A parte que entendemos por soft?are a executada na CPU,
formada por um algoritmo seqencial escrito comumente na linguagem C ou alguma
outra que suportada por CUDA. A parte do hard?are formada pelo cdigo
compilado por CUDA para ton-lo um $ernel.
8
;ernel so blocos que especificam parte do algoritmo em que se deseja a
paralelizao. Ele tambm pode ser tratado como um cdigo que pode ser utilizado
pela GPU para chamar outros $ernel nela ou em outra GPU.
A GPU contm milhares de threads, CUDA faz a formatao do cdigo de
uma maneira que threads sejam alocadas paralelamente e o usurio usufrua dessa
caracterstica, podendo fazer chamadas de $ernel que sero independentes entre si,
o que permite a GPU rodar vrios algoritmos sem problemas. Uma explicao
detalhada ser feita adiante.
A linguagem utilizada para criar essa paralelizao otimizada est presente na
AP que CUDA fornece. Essa AP formada por bibliotecas importantes, dentre as
quais ressaltamos o CUBLAS e o CUFFT que implementam e otimizam funes da
lgebra linear e transformada de Fourier ,respectivamente.
8;9;10;14
Podemos ver na Figura 3 a diferena de potencial que uma GPU, com seu
paralelismo, possui em relao a um processador (CPU):
18
Figura 3: Operaes de pontos flutuantes e !and?idth
D
.
No primeiro grfico temos informaes sobre pea$ de operaes por ponto
flutuante. A GPU alcana a casa de TFlops/s, e a CPU apresenta um desempenho
baixo mesmo comparado a arquiteturas de GPUs anteriores que no so
compatveis com CUDA.
19
A GPU voltada para computao intensiva, com alta paralelizao, que so
caractersticas do problema de renderizao grfica. Alm disso, sua arquitetura
especializada no processamento deste tipo de dados e no no controle de fluxo.
Podemos visualizar essa diferena quando observamos a Figura 4 a seguir:

Figura 4: Quantidade de transistores para processamento de dados
6
.
A quantidade de transistores utilizados para fazer processamento (ALU)
bem maior na GPU que na CPU. A arquitetura da CPU ainda est dividida em
enormes blocos que contm um componente de controle de fluxo e um de memria
cache. No caso da GPU, o mesmo programa executado em muitos elementos em
paralelo. Dessa maneira, no possui um sofisticado componente de controle de
fluxo, porm, oferece uma grande intensidade de computao aritmtica.
Alm disso, a cache se torna pequena na GPU diminuindo a latncia para
execuo de cada grande bloco de ALU's, diferente da CPU que contm uma cache
enorme, obtendo uma latncia alta para acesso.
Possuindo um unidade de controle, um componente de cache e um conjunto
20
enorme de ALU's, possvel obter a estrutura de vrios grupos de cores. Podemos
assim certificar que a GPU um man8core, apresentando de 32 at 128 cores
dependendo do modelo. Essa subdiviso de cores na GPU chamada de Stream
,rocessing.
Um ponto importante a ser lembrado que, para a execuo na GPU, o
algoritmo paralelizado no pode ter muita dependncia de dados em cada passo de
computao, pois a GPU no faz paralelizao de tarefas e sim de processamento
de dados. Caso essa otimizao no seja feita no algoritmo, a GPU tem seu
desempenho bastante afetado.
11
Com relao hierarquia de compilao para o CUDA, a Figura 5 ilustra a
arquitetura da sua pilha de software.
21
Figura 5: Pilha de soft?are
E
.
Essa pilha de software mostra a hierarquia de execuo de CUDA. A AP de
CUDA fornece suporte a diversas funes matemticas, bibliotecas, suporte ao
runtime e ao driver.
5
O CUDA runtime a camada de alto nvel de programao, enquanto a
camada do driver a camada baixa para manipulao de dados. O CUDA driver
gerencia e otimiza os recursos relacionados diretamente GPU. At onde o autor
conhece, no h notcias divulgadas pela NVDA que mencionem que o uso da
camada alta ou a camada baixa da AP melhore ou piore o desempenho da
aplicao.
11
CUDA baseada em programao paralela, permitindo milhares de threads
executando uma mesma tarefa. Neste caso, a GPU funciona como um co-
processador da CPU, a qual chamamos de "HOST e a GPU de "DEVCE.
22
CUDA usa como base a linguagem C, que permite uma curva rpida de
aprendizado. Nela deve-se criar funes desejadas que CUDA otimize e paralelize
na GPU. Essas funes so chamadas de $ernel. A seguir, observamos um exemplo
de um cdigo simples, em seguida, uma explanao sobre cada aspecto inerente ao
entendimento seqencial desse cdigo ser especificada.
Exemplo 1: cdigo de uma aplicao simples em CUDA
__global__ void matAdd(float A[N][N], float B[N][N],
float C[N][N])
{
int i = threadIdx.x
int ! = threadIdx."
C[i][!] = A[i][!] # B[i][!]
$
int main()
{
%% Kernel invo&ation
dim' dimBlo&((N, N)
matAdd)))*, dimBlo&(+++(A, B, C)$
Nesse cdigo temos uma funo matAdd que apresenta uma tag __global__
antes da definio da funo. Essa tag define ao compilador que esse bloco ser
paralelizado na GPU.
A funo main faz a invocao do mtodo. Ele se localiza no HOST e o
cdigo executado na GPU (DEVCE). Em uma ?or$station podemos encontrar
mais que uma GPU, neste caso elas sero chamadas de DEVCE 0, DEVCE 1, etc.
O $ernel acionado colocando um tag de configurao antes da declarao
dos parmetros,,))) +++-. H trs parmetros possveis na configurao: a
configurao do tamanho das grids (a),a configurao com o tamanho dos blocos(b)
e a quantidade de memria compartilhada que se deseja utilizar no algoritmo(Ns).
23
sso gera uma configurao genrica,)))a,b,N. +++-.
No main, antes da invocao, declaramos um tipo de varivel definida pelo
CUDA chamada, "dim'. A varivel criada dimBlo&( ter trs dimenses e cada
uma dessas dimenses representar a dimenso de um bloco. No exemplo, teremos
um bloco com tamanho N para dimenso x, tamanho N para dimenso y e a
dimenso z que foi omitida tem tamanho 1.
A posio onde se encontra o valor 1 na configurao da chamada da funo
significa o tamanho da grid. Essa definio tambm usado o tipo dim'. Veja a
seguinte declarao:
Exemplo 2: cdigo de uma aplicao simples em CUDA
dim' dimBlo&((*/, */)
dim' dimGrid((N # dimBlo&(.x 0 *) % dimBlo&(.x,
(N # dimBlo&(." 0 *) % dimBlo&(.")
1atAdd)))dimGrid, dimBlo&(+++(A, B, C)
No exemplo 2 o tamanho do grid dado pelo tamanho da matriz, N, mais o
tamanho do bloco na dimenso x, dimBlo&(.x, menos um dividido pela dimenso
do bloco em x. Essa a quantidade de blocos que sero computados pelo grid na
dimenso x. Segue a mesma linha de raciocnio na dimenso y do grid. Vale
novamente ressaltar que a dimenso z foi omitida e seu valor 1.
H uma restrio no tamanho dos blocos. Deve-se verificar a quantidade de
threads que foi declarada em cada dimenso. A regra dimBlo&(.x2
dimBlo&(."2 dimBlo&(.3 (multiplicao das dimenses) precisa ser menor que
o mximo do nmero de threads que pode ser alocada para o bloco.
Na chamada da configurao, )))a,b,N.+++, h um terceiro parmetro,
N.. Esse do tipo .i3e_t e especifica o nmero de !8tes na memria
compartilhada que cada bloco deve alocar dinamicamente. Esse parmetro por
default zero e no precisa ser especificado.
24
O HOST cria invocaes do $ernel de acordo com o parmetro de
configurao. Cada $ernel executado paralelamente e independentemente entre si
na GPU.
A arquitetura CUDA baseada em arra8Fs escalveis de multithread SMs, ou
thread 5atching (ver Figura 6). Ele um !atch de threads que o $ernel executa e
organiza em grids de threads !loc$. Uma thread !loc$ um !atch de threads que
cooperam entre si para compartilhar eficientemente as informaes que sero
processadas. Essa eficincia vai desde o compartilhamento (cpia da DRAM GPU
para a memria compartilhada e vice-versa) dessa informao atravs da memria
compartilhada, at a sincronizao de execuo para o acesso a essa memria.
4
Cada thread identificada atravs de D nica, chamada thread D. H um
nmero limitado de threads por bloco. Porm, um bloco de mesma dimenso e
tamanho pode ser executado por um mesmo $ernel fazendo um grid de blocos,
aumentando ainda mais a quantidade de threads sendo executados em paralelo.
Vale salientar que as threads de blocos diferentes no podem se comunicar.
<
Cada bloco identificado por um !loc$ D, e tem sua D nica em relao ao
grid.
25
Figura 6: Thread Batching
5
.
26
Um multiprocessador um nome formalizado para threads. Ele consiste de
oito cores de processadores escalares, duas unidades de funes especiais
transcendentais, uma unidade de controle de instrues multithread e uma memria
compartilhada on%chip.
8
O multiprocessador cria, gerencia, e executa threads concorrentes com custo
nulo de hardware no mbito de gerenciamento de processos. Para gerenciar
centenas de threads rodando em diferentes programas, o multiprocessador nas
ltimas verses de CUDA emprega o SMT. O multiprocessador mapeia cada thread
a um core de processador escalar, que executa independentemente suas prprias
instrues e tem seu prprio estado de registradores.
Esse multiprocessador SMT cria, gerencia, escalona e executa grupos de 32
threads paralelas chamadas de ?arps. 'hreads individuais que compem o SMT
?arp podem comear sua execuo juntas no mesmo programa, mas esto livres
para ramificarem e executarem de forma autnoma. Contudo, se alguma thread
ultrapassar a dependncia condicional da ramificao, ela ser desabilitada.
@
A arquitetura SMD implementada como um conjunto de mltiplos
processadores que tem a capacidade de, com uma nica instruo, em um mesmo
ciclo de cloc$, processar vrias informaes.
Podemos visualizar as explanaes mencionadas acima na Figura 7 a seguir:
27
Figura 7: Conjunto de multiprocessadores SMT com memria compartilhada do
DEVCE
7
.
Como podemos observar cada multiprocessador possui: um conjunto de
28
registradores de 32-bit, cache paralelo ou memria compartilhada que partilhada
com os outros processos, uma cache constante e outra de textura apenas para
leitura. A memria local e global no "cacheada e pode ser escrita e lida pelos
processos.
Um ponto forte de CUDA que h uma separao na memria DRAM entre o
HOST e o DEVCE. A AP de CUDA fornece uma forma de transmisso de alta
performance para transferir os dados entre esses dispositivos usando 3igh
,erformance (DMA), ou DMA de alta performance.
A leitura (gather) e a escrita (scatter) na DRAM da GPU pode ser feita pelo
algoritmo de forma generalizada, sem se preocupar com a posio acessada na
DRAM. importante salientar que o algoritmo pode apenas acessar variveis
globais, como podemos visualizar na Figura 8:
Figura 8: Leitura e Escrita na DRAW
:
.
Mas para acessar a memria que est na CPU, necessrio usar diretivas,
29
como "cudaMemcpy oriunda da AP de CUDA, para passar da memria DRAM da
CPU para a DRAM da GPU e vice-versa.
A hierarquia de memria de uma GPU pode ser observda na Figura 9
seguinte:
Figura 9: A thread pode ter acesso leitura a espao de memria em todos esses
componentes e escrita somente alguns
4
.
30
Resumindo, as threads podem ler e escrever em registradores e nas
memrias locais. O bloco pode ler e escrever na memria compartilhada. Os grids
podem ler e escrever nas memrias globais, mas apenas ler de constantes e
texturas.
Variveis globais, constantes e texturas so otimizadas para diferentes tipos
de uso da memria. Por exemplo, texturas so frequentemente usadas para
diversos tipos de endereamento, como filtro de informaes.
Variveis globais, constantes e texturas tambm podem ser lida ou escrita
pelo HOST e so persistentes na chamada do $ernel da mesma aplicao que as
contm.
4
2.9 Di!,o!itivo! de ,laca de v-deo
As placas de vdeo no mercado so conectadas aos PCs pelo barramento
PC-e e AGP. As placas PC-e oferecem muita mais banda de transferncia que as
AGP. Ele chega a 4 GB/s em comparao ao AGP de 66 MHz que chega a 533
MB/s. sso permite a utilizao de compartilhamentos de at 2 GB de memria RAM
do HOST sem sofrer grandes perdas nessa ao. A agilidade nas transferncias
reduz a perda de desempenho por utilizar memria compartilhada. sso amplia
perceces para o uso de tecnologias como 'ur!o Cache (NVDA) ou 38per
Memor8 (AT), que simulam memria no DEVCE compartilhando e abstraindo
memria fsica da RAM do HOST.
Arquiteturas que usam o 'ur!o Cache e o 38per Memor8 so arquiteturas de
baixo custo e desempenho, pois esto suscetveis a problemas de disponibilidade e
conflitos de memria pois elas passam a utilizar a memria do HOST como memria
global. Como o componente de memria para a placa de vdeo caro essa
funcionalidade diminui o custo de produo desse tipo de placa.
O uso de um computador que tenha uma placa de vdeo primria on%!oard
(embarcada na placa me) e uma placa de vdeo secundria, uma GPU, bem
31
interessante para se obter o espao mximo do tamanho da memria do DEVCE.
Alguns fabricantes de GPU usam para barateamento da produo a memria
RAM do DEVCE do tipo DDR2 ou DDR3. Contudo , o comum a utilizao da
tecnologia GDDR que permite tempos de latncia muito mais baixos de acesso
nessa memria.
No existe nenhuma diferena fundamental no tipo de memria RAM utilizado
nas placas de vdeo. Elas podem utilizar os mesmos chips de memria DDR, DDR2
ou DDR3 utilizados na memria principal do HOST (memria RAM). A indstria
vende muitas placas de baixo e mdio custo que realmente utilizam esse tipo de
memria de computador, no intuito de reduzir os custos de produo. Mas os
fabricantes de placas 3D de alto desempenho geralmente optam por utilizar
memrias GDDR2, GDDR3 ou GDDR4, tipos de memria otimizadas para placas de
vdeo, que so capazes de operar a freqncias bem elevadas. Nos notebooks o
padro a GDDR2 ou GDDR3 para os modelos mais caros no mercado brasileiro. A
Figura 10 ilustra dois chips de memria GDDR4
Figura 10: Chips de memria GDDR4.
Os padres de desenvolvimento das memrias GDDR so independentes e
no tem nenhuma semelhana com os padres de memrias DDR. Ela apresenta
algumas caractersticas semelhantes em relao as memrias DDR2.
32
As DDR2 e as GDDR realizam quatro transferncias por ciclo de cloc$ e
compartilha de outras caractersticas, como o uso do terminador resistivo interno
16
,
mas oferecem (em relao s memrias DDR2) a vantagem de consumirem menor
quantidade de energia, conseguem dissipar menos calor e tambm ser capaz de
operar em freqncias mais altas.
J as memrias GDDR4 so bastante similares s memrias DDR3 (muito
embora os dois padres no estejam diretamente relacionados). Elas trabalham com
tenso nominal de 1.5V (o que reduz o consumo eltrico), suportam o uso de at 8
bancos de memria e realizam 8 transferncias por ciclo de cloc$, assim como as
memrias DDR3.
Para evitar que o aumento no nmero de transferncias por ciclo resultasse
em um aumento muito grande na latncia da memria, o padro GDDR4 inclui
diversas otimizaes, incluindo o DB (Data Bus nversion) e o Multi%,ream!le, que
permitem reduzir os tempos de espera dos chips.
15
A vantagem das memrias do tipo GDDR4 que a tecnologia tem pode atingir
freqncias efetivas de operao muito mais altas, conseguindo extrair maior
desempenho das clulas de memria.
A placa de vdeo da NVDA GeForce 9800M GS apresenta memria GDDR3.
Possuem uma velocidade de cloc$ de 530MHz, de acesso a memria do DEVCE de
799MHz e uma velocidade de shader de 1325MHz.
35
Ela tem capacidade de 1GB de memria de vdeo, o que permite aumentar a
velocidade de acesso a um grande volume de dados, possibilitando alocaces de
grandes matrizes, por exemplo, dentro da GPU, no necessitando de mtodos como
tur!o cache para conseguir desenvolver essas tarefas.
33
Ca,-tulo 9
9.7 !tudo !o#re o al*orit%o e !ua! oti%i.a56e!
A modelagem desse modelo ssmico foi criada pela Petrobras. Ela props um
algoritmo em linguagem C. O algoritmo composto de quatro matrizes. Trs delas
definem a representao de dados do valor de presso, em trs tempos diferentes
(tempo t, tempo t-1 e tempo t-2), e a quarta a matriz de campo de velocidade
ssmica.
O algoritmo da ssmica consiste de duas estruturas principais: um cloc$ de
inicializao, e uma estrutura de computao. Nessa segunda estrutura onde
ocorrem os clculos que resultam depois na matriz C (tempo t). Na Figura 12
encontramos a descrio da segunda estrutura:
As entradas dos valores iniciais das matrizes so colocadas na estrutura de
inicializao do cloc$. L so inicializados os valores da matriz A e B (fisicamente
representa a matriz no tempo t-1 e t-2). Alm dessas, existe a matriz de velocidade
(VEL) que pode mudar em cada ponto da matriz. Tambm so zerados todos os
elementos da matriz C.
A estrutura maior, onde ocorre o cloc$ de clculo da matrix C, percorrida de
maneira up%do?n, de maneira simultnea e ocorre para todas as outras matrizes.
Mas enquanto a matriz C apenas armazena o valor da convoluo, as matrizes B, A
e VEL sofrem leituras e tem valores multiplicados por fatores.
O nmero de vezes que se percorre a matriz e se faz o clculo da matriz C
depende do tamanho da matriz em x e o valor da velocidade mxima que pode ser
atingida nesse modelo. Segue a Figura 11 mostrando a forma de computar na matriz
up%do?n.
34
Figura 6: Maneira como os dados so calculados no eixo X x Z.
Temos trs cloc$s nessa infra-estrutura de computao. Para a explicao o
primeiro cloc$ se chamar cloc$G, o segundo cloc$C e o terceiro cloc$H. O cloc$1
contm o cloc$C e o cloc$H. Veja Figura 12.
Figura 12: Estrutura de computao.
35
niciado o cloc$G, uma funo de impulso no centro da matriz B(tempo t-1)
ser introduzida. Veja Figura 13. Esse impulso simula um pulso ssmico (ver Figura
13). E esse pulso percebido por todos os elementos adjacentes a esse elemento, e
no resultado final estar espalhado por todos os elementos finais da matriz C.
Figura 73: nserir o Pulso Ssmico no meio da matriz.
Depois de atualizar o valor do pulso, entra-se no cloc$C que esta aninhada em
mais um cloc$. feita uma convoluo entre a matriz B, C e VEL. Com eles se tem
o clculo naquele determinado tempo de cada elemento da matriz C.
Saindo desse cloc$ verificado se as condies para o cloc$G continuam,
caso sim, antes de reinici-lo, passa-se o valor da matriz B para a A e os valores da
matriz C para B. O cloc$ se repete e o clculo do impulso e do cloc$C retomado
novamente. Caso no tenham sido satisfeitas as condies do cloc$G, a matriz C o
resultado final dos clculos e ser gravada em um arquivo.
Nesse primeiro momento de anlise podemos ressaltar o tamanho de dados
que esse algoritmo manipula constantemente no total do seu processamento. Esse
algoritmo por padro tem cada uma das matrizes com tamanho de 1601 x 601. A
necessidade de trazer os dados para perto do processamento vital. A velocidade
de acesso de uma memria local bem maior que o acesso em uma memria
36
global. No caso da CPU trazer os dados mais perto do core utilizando L1 e L2 so
bem mais eficientes o acesso e o reuso de dados.
44
J a GPU traz uma memria GLOBAL dentro do DEVCE. Ela se comunica
com os blocos de memrias no DEVCE, normalmente uma memria GDDR3, e a
velocidade de transferncia entre a memria global para essas outras memrias
dentro do DEVCE bem maior que a velocidade entre o HOST e a memria global
do DEVCE (mesmo usando o 3igh Speed DMA - HSDMA).
4
No CUDA, o HSDMA utilizado para favorecer a opo de alocar a memria
RAM do HOST e com isso o DEVCE, e tem o acesso a ela como se estivesse
usando uma memria dentro do DEVCE, mas essa abstrao degrada o
desempenho do algoritmo que esteja rodando.
Transformando o algoritmo em C usado na arquitetura CPU para o CUDA na
arquitetura GPU, fizemos as seguintes anlises e modificaes:
As matrizes so criadas e inicializadas dentro do DEVCE. No h
nenhum tipo de perda de desempenho para isso. Para essa inicializao chama-se
um $ernel para varrer as matrizes e inicializ-las;
O pulso ssmico pode ser calculado no host sem dela8s. Obtendo a
mesma preciso que o algoritmo em C apresenta. No vai haver problemas ao se
passar esse valor para o DEVCE pois ser inserido no parmetro do $ernel sem
prejuzo do desempenho;
A convoluo foi feita de maneira paralelizada. Um $ernel tem indicado
nos seus parmetros as matrizes, ja totalmente alocadas no DEVCE, e o valor do
pulso ssmico um fator constante usado na convoluo;
O HOST que assume a funo de controle do algoritmo verifica se j
chegou ao fim o algoritmo. Caso sim, ele salva o algoritmo para verificar validao
da sada. Caso no, chamado um $ernel que troca as posies das matrizes. A
troca com B e C troca com B;
Somente no final do algoritmo observado a necessidade de fazer
cpia da matrix C para o HOST para gravao no disco rgido. As matrizes foram
todas criadas e inicializadas no DEVCE, pois h memria suficiente em nossos
casos de testes para isso. Mas se a matrix alcanar grande tamanho, necessrio
37
utilizar recursos da RAM do HOST como memria extra e isso geraria um dela8 que
causaria grande perda de desempenho pelo tempo de acesso a memria;
Foi eliminada uma matriz, a matriz de velocidades ssmicas nos pontos,
pois o seu valor era constante nessa modelagem, podendo ser substitudo na
convoluo pelo valor da constante, o que facilita os clculos, pois ser multiplicado
por uma constante.
Foi usado como modelo para a convoluo o algoritmo MatMul
fornecido como exemplo pela SDK da NVDA. Ele um algoritmo de multiplicao
que chega atingir speed%up de 16x em relao a algoritmo que no usa a memria
compartilhada como recurso na computao.
38
Ca,-tulo :
:.7 A%#iente de de!envolvi%ento
Foram utilizados: Notebook com processador ntel Core 2 Duo P8600
2.4G,Front Side BUS de 1066MHz, memria RAM DDR2 800 de 4GB, placa grfica
NVDA GeForce 9800M GS com memria de vdeo de 1GB DDR3 VRAM. Sistema
operacional Windows Vista Home Premium de 32 bits com SP1, Eclipse com o
MinGW GCC Compiler, Visual Studio 2005.
Nesse notebook foram desenvolvidos e testados os algoritmos em C e CUDA.
:.2 Benc)%arH
As GPUs permitem a modificao de seu cloc$ para melhorar a eficincia,
podendo definir sua velocidade constante. Com essa certeza, esse trabalho no
daria margem para especulao sobre a arquitetura (pois a arquitetura NVDA
CUDA no aberta) e o seu real desempenho. Esse cloc$ pode ser ajustado via
soft?are (assim como o cloc$ da memria), usando utilitrios como o AT Tray Tools,
o RivaTuner ou o ATTool para placas AT. No caso em estudo, pode-se utilizar a
NVDA nTune e o RivaTuner. Esse tipo de funcionalidade utilizada por usurios
que desejam obter o mximo de desempenho de sua placa de vdeo. Mas elas j
vm sendo fabricadas para rodar em seu limite. Em muitas placas, um overcloc$ de
5% j o suficiente para desestabilizar o equipamento e no obter nenhum
resultado no overcloc$.
20;21
Ao executar alguns exemplos do CUDA junto aos programas GPU-Z (medidor
de desempenho especifico para GPU) e Lavalys Everest (medidor de desempenho
generalizado) h indcios que a placa de vdeo mantm seu cloc$ no seu mximo
39
como valor padro. Um dos programas testado foi o fluids, um dos exemplos da
SDK de CUDA. Veja Figura 14 a seguir:
Figura 84: Everest e GPU-Z sendo executados para medir desempenho da GPU com
algoritmo fluids da SDK do CUDA.
Os resultados mostraram que no h necessidade de se fazer overcloo$ para
manter o cloc$ de trabalho padro igual ao definido pelo fabricante. O cloc$ que
definido de fabrica utilizado somente quando h algum programa que utiliza
diretamente a placa de vdeo, em outras situaes o cloc$ baixo para diminuir
potncia utilizada do componente de vdeo e economizar energia. O overcloo$
somente seria necessrio se houvesse desejo desse projeto alcanar melhorias de
desempenho nesses 5% em que o overcloo$ funciona.
17;24;34
A quantidade de memria no problema em questo, por se tratar de matriz de
dados to grande, fator de desempenho do algoritmo. Quanto mais perto do
processamento menor a latncia. Logo, a quantidade de memria no DEVCE
influencia no desempenho do algoritmo e na forma de escolha da arquitetura de
40
resoluo.
A GPU usada para esse !enchmar$ uma GeForce 9800M GS. Ela uma
placa de vdeo para laptops baseado no core G94 com 64 stream processor. Ela
possui uma tcnica chamada 38!rid,o?er que permite, atravs de watchdogs (de
hardware), a escolha entre o uso da placa de vdeo dedicada ou da placa de vdeo
integrada. sso permite que a economia da bateria do notebook seja mxima, assim
como permite que o DEVCE esteja quase em sua totalidade sendo usado pelo
programa em CUDA.
O barramento utilizado para GPU PC-e 16x e tem banda de transmisso
efetiva de 51.1GB/s com largura de banda de 256 bits. Ele apresenta 8
mulprocessadores com 64 ncleos cada. A quantidade mxima que o CUDA pode
alocar de threads de 512 em relao dimenso X x Y x Z. A quantidade de
registradores por bloco 8192. Tem a possibilidade de usar 32 threads em cada
warps.
Ele tem a possibilidade mxima de usar blocos de tamanho mximo de 512x
512x 64. Assim como as grids podem chegar a 65535x 65535x 1. A GeForce 9800M
tem 1024MB de memria GDDR3, 64KB de memria constante, 16KB de memria
compartilhada, tem 256KB de memria Pitch e 16KB de alinhamento de textura.
O processador usado um Peryn-3M ntel Core 2 duo. Este o sucessor do
Core Duo e tem um pipeline mais longo e com 5-20% a mais de velocidade sem
maior consumo de energia. Na arquitetura existe um quarto decodificador, uma
unidade SSE ampliada e uma unidade lgica aritmtica (ALU) adicional. Os Core 2
Duo para notebooks so idnticos aos processadores Core 2 Duo para desktops,
mas os processadores para notebooks trabalham com tenses mais baixas e um
2rontside !us cloc$ mais baixo. O desempenho de notebooks igualmente cloc$ed
20-25% mais baixo que PCs Desktop por causa do 2rontside !us cloc$ mais baixo.
26
O notebook da MS, MS Megabook GT627 Serie 218us, seguindo o padro
de desempenho, deixa que o usurio opte por trabalhar nessas condies de baixo
consumo ou use toda a potncia do barramento que de 1066MHz. Ele tem um
mnimo e mximo de um multiplicador com 400,0MHz, 6x e 9x respectivamente, o
que oferece uma velocidade mxima de 2400MHz e quando o overcloc$ ativado a
velocidade chega a 116% no valor de 2784MHz. Tem cache de L1 com 32KB e L2
41
com 3MB.
27
A seguir temos a Figura 15, que mostra a medio do Everest rodando o
algoritmo de modelagem da ssmica, na arquitetura CPU, com overlock de 16%.
Figura 95: Desempenho do overcloc$ da CPU utilizando o algoritmo de modelagem.
A metodologia escolhida para fazer medio bastante eficiente tratando-se
de algoritmos que no fazem uso da interferncia do usurio e passam a maior parte
do tempo executando no processador. Esse tipo de algoritmo chamado de C,>%
!ound.
31
Ser usado contadores de ciclo de cloc$ para contar a quantidade de ciclos
de cloc$ que necessrio para o algoritmo ser executado. Para isso usaremos
instrues assembly para pegar esses valores para a metodologia da CPU. E para a
o CUDA usaremos a funo cloc$ que retornar o valor desse contador antes e
depois da execuo do $ernel.
A NTEL fornece um paper explicando como calcular e fazer contagem de
ciclos de cloc$ de um algoritmo no PC atravs de instrues de Assembly.
28
Nele
considera-se a preempo que o algoritmo sofre com o sistema operacional. Ser
42
utilizada suas instrues e o algoritmo ir rodar cerca de 200 vezes seguidas para
certificar essa tendncia da quantidade de ciclos para um valor. Usaremos o
Windows Vista no estado idle sem nenhum tipo de processamento rodando em
!ac$ground. sso minimiza o mximo da parte de mudana de contexto que existe
nos sistemas operacionais Windows. O programa em CUDA tambm ter uso do
sistema operacional Windows Vista no estado idle.
O CUDA fornece o mtodo cloc$(). Ele retorna o contador do CUDA. A NVDA
fornece explicao de como obter, usando esse mtodo, a quantidade de ciclos de
cloc$ totais feita pelo algoritmo. Basta apenas que antes e depois da chamada de
um $ernel, se faa uma chamada na funo cloc$. Depois realiza-se uma simples
subtrao entre esses valores. Essa a melhor maneira de medir a quantidade de
ciclos de cloc$.
4
No h a preocupao de preempo no DEVCE, pois ele um mono tarefa.
Tem a caractersticas de SMT que transforma um $ernel (uma instruo no cdigo)
como uma funo atmica.
Esse tipo de metodologia no se adequa a algoritmos que usam de /O ou AP
que faz o processador passar longo tempo em mudana de contexto. A contagem de
cloc$ bem mais preciso que a contagem pelo tempo. Caso se use a contagem de
tempo, o resultado seria na unidade de segundos, e variando o processador mudaria
o resultado do algoritmo. Contar por ciclo de cloc$ limita esse erro e pode gerar
informaes para comparaes. O resultado dessa medio utiliza essa simples
equao para medir o tempo. A quantidade de ciclos totais dividido pela frequncia
do processador ter como resultado o tempo total, veja Figura 16.
Figura 106: Equao para medio do tempo do processador.
43
O contador da CPU nomeado como TSC (Time Stamp Counter). Ele um
registrador de 64 bits e pode ser acessado atravs da instruo RDTSC que foi
introduzida desde o Pentium (P54C). Ela carrega os 32 bits menos significativos no
registrador EDX e os mais significativos no EAX. Ver anexo .
29
Os problemas de se usar esse tipo de instruo seriam: impedir chaveamento
na freqncia do processador (pois o trabalho desenvolvido com um notebook),
subtrair o overhead do uso dessa funo, lidar com o chaveamento de sistema
operacional, detectar e retirar da contagem as faltas na cache e serializar a instruo
RDTSC e a CPUD, pois sem isso ela pode ser executada fora de ordem devido a
arquitetura superescalar, no conseguindo medir o RDTSC do processo correto.
31
:.9 Metodolo*ia ,ara a an+li!e do de!e%,en)o
O algoritmo em C foi desenvolvido pela Petrobrs, esse foi definido como o
algoritmo de referncia. Depois de testes de sada, foram criadas estruturas de
medio de ciclos de cloc$ e tempo de execuo no modelo em C de forma
interativa e incremental. A sada do algoritmo em C fornecido incialmente pela
Petrobrs considerada padro e referncia para o arquivo em CUDA. Os testes
de sada comparar os valores da matriz C que se encontra em um arquivo entre as
duas arquiteturas. Para facilitar essa atividade foi usado o programa WinMerge. Em
poucos passos temos a validao ou negao da igualdade.
32
O algoritmo em CUDA produto desta tese de graduao. Ele foi a partir do
algoritmo em C da Petrobrs para CPU. Depois de testes de sada foi dado incio a
implementao de forma interativa e incremental e das estruturas de medio se
adequando a arquitetura do CUDA.
Para fins de !enchmar$ a gravao da matrix C em um arquivo ser anulada,
pois deseja-se que esse algoritmo seja apenas C,>%!ound, logo, chamar rotinas de
gravao ir deformar a medida dos resultados.
O algoritmo em CUDA foi feito com algumas modificaes do algoritmo C.
44
Para fazer a migrao de arquitetura e adicionar as otimizaes no algoritmo foi
necessrio identificar pontos em que h uma grande possibilidade de ganho de
desempenho com o uso do paralelismo.
dentificar os gargalos do algoritmo e saber us-los de acordo com as
restries e vantagens da arquitetura um processo que necessita de uma profunda
reviso bibliogrfica e promovendo uma interessante lacuna a ser explorada em
trabalhos futuros.
:.9.7 C+lculo do de!e%,en)o
Cada vez que for calculado o valor inicial e final do cloc$, ser recolhido,
respectivamente, o valor do contador de ciclos de cloc$ antes e depois da execuo
do processo principal, eles sero subtrados e o valor ser guardado em um
conjunto.
Depois de uma srie de clculos faz-se a anlise desses valores e escolhe-se
a mediana entre eles. O mtodo mediana ser escolhido devido a caracterstica do
mesmo mostrar uma medida de tendncia central. De modo que o valor escolhido
separa em 50% a populao acima e abaixo dele.
Outros artigos especificam as medidas de desempenho como o consumo de
energia. Kuzman
33
usa um osciloscpio para verificar a potncia que a placa de
vdeo e outros componentes do PC esto usando. Grafikkarten
33
ressalta a
necessidade de fazer medies com temperatura ambiente controlada. Quanto mais
se aumenta a complexidade da arquitetura e o cloc$ (overcloc$) aumenta-se
tambm a potncia de consumo.
Aparece tambm uma caracterstica que o TDP ('hermal /esign ,o?er), a
placa de vdeo, por exemplo, tem seu consumo de energia alterado devido a no
projeo correta de dissipao de calor do gabinete do notebook. Desta forma, o
espao necessrio para dissipao de calor que no atendido acaba fazendo com
que haja um superaquecimento do equipamento ocasionando a dissipao da
45
potncia mais que o desejado. O aumento de temperatura no desejvel para
dispositivos de alto desempenho. Ele pode ser identificado quando a corrente limite
e a voltagem limite do sensor do aparelho ultrapassada.
Nas medies com o programa GPU-Z a temperatura de 49 graus em idlle.
Quando est em uso com algum algoritmo a GPU se mantm a uma temperatura de
66 graus. (ver Figura 17) O que mostra que a MS respeita o seu TDP e consegue
manter uma dissipao de potncia especificada no manual que de no mximo
105 graus.
Foi observado tambm que, nesse trabalho, ficar invivel por meio de
software tentar medir desempenho por potncia, j que a GPU apresentada, 9800M
GS, possui apenas diodo de temperatura, impossibilitando fazer os clculos de
potncia.
Esse problema de TDP vale para todos os dispositivos do computador. Desde
o Athlon 64 a AMD j consegue timos resultados em controlar o consumo em
relao ao Pentium 4.
45
J a plataforma Centrino 2 veio para resolver esse problema
de dissipao de potncia e criar processadores com timo desempenho para
notebooks.
19
46
Figura 117: Medio de temperatura utilizando GPU-Z utilizando o algoritmo da
ssmica.
Como trabalho futuro h possibilidade do uso de um osciloscpio para realizar
a medio em um desktop atravs da voltagem e da corrente eltrica da GPU. Em
trabalhos futuros haver a possibilidade de utilizar sensores da placa me e da GPU
para fazer essa medio.
No ambiente de trabalho, a CPU disponibiliza o medidor de voltagem, mas na
GPU est apenas disponvel o medidor de temperatura (tanto no GPU-Z como
EVEREST).
47
Ca,-tulo ;
;.7 Re!ultado!
Esse captulo se reserva a mostrar dificuldades, desafios e resultados obtidos
nesse trabalho. Nessa seo tambm sero apresentados os resultados da medio
do algoritmo de ssmica usando a arquitetura CPU e GPU. Nele no se utilizou
qualquer tipo de chamada a AP que faa o algoritmo perder sua qualificao de
C,>%!ound.
Foram gerado arquivos a cada benchmark. Um exemplo dele est exposto no
Apndice - A.
;.7.7 Re!ultado! na CP0
O algoritmo fornecido pela Petrobrs necessitou de alteraes em alguns
pontos para facilitar o !enchmar$. No Exemplo 3 pode-se observar o comando para
gerar um !enchmar$. Suas variveis so o tamanho da matriz e a quantidade de
cloc$s.
A quantidade de cloc$s desejados sero a quantidade de amostras de ciclo de
cloc$ medido. Essa amostra ser guardada em um conjunto, que posteriormente
ser usado para outros clculos. Para facilitar a utilizao, basta copiar e alterar o
comando do Exemplo 3 e colocar no main do algoritmo.
Exemplo 3 : Mtodo para facilitar o benchmark.
nome=4.aida*''*5x6775clock*.txt4
&hamadademain(*''*5,6775,588,nome)
48
Pode-se nomear o arquivo com o nome que se desejar no arquivo de sada,
alterando a varivel nome. Em seguida. Basta definir o tamanho da matriz ZxX e a
quantidade de cloc$s que deseja gerar, sabendo que cada cloc$ gera um item para o
conjunto de ciclos de cloc$ para a computao da Matriz C.
No Exemplo 3 temos dois arquivos gerados. O primeiro tem nome:
.aida*''*5x6775clock*.txt, matriz de tamanho 13312x4992 e rodar
duzentas vezes gerando 200 itens no conjunto de ciclos de cloc$ e tambm no
arquivo ter o tempo que cada ciclo de cloc$ necessitou para o algoritmo.
Foi utilizado durante o benchmark o overcloc$ da CPU, que permite que atinja
a velocidade de 2784MHz.
O algoritmo em 176x64 rodou em cloc$ de 800 vezes no tempo mdio de 275
segundos. Sua mediana em relao aos ciclos de cloc$ de 4294967297 ciclos.
Vale ressaltar que muitas vezes o cculo feito de uma maneira to rpida que no
conjunto dos ciclos de cloc$ no se consegue obter a medio de uma boa parte dos
elementos, resultando em zero.
Um segundo teste foi feito com uma matriz de 1456x640 com um cloc$ de
apenas 30 vezes, o algoritmo demora 2867 segundos. A mediana no clculo de
ciclos de cloc$ 223338299444 ciclos.
O terceiro teste foi feito com uma matriz de tamanho 2672x1008 com um
cloc$ de apenas 30 vezes. O algoritmo demora 14947 segundos. No conjunto de
ciclos de cloc$ temos cloc$ de 1047972020468.
Partindo para os resultados com as matrizes com tamanho de valores
13312x4992 e 26624x10000, a primeira matriz demorou em torno de 12 horas e
trinta minutos com apenas um cloc$ e no obteve nenhum resultado (o arquivo de
sada do !enchmar$ estava em branco). Houve algum erro no mostrado pelo
programa, mais tarde descobrimos que o erro se deve a estouro da pilha que faz a
alocao de variveis. Como o sistema operacional estava em ocioso o programa
no gerou nenhum aviso de segmentation fault. Na segunda ocorreu um erro no
inicio do programa, pois o algoritmo fornecido usa alocao dinmica nessas
matrizes e dessa vez nem permitiu rodar o programa. Propem-se para trabalhos
futuros analisar solues otimizadas para alocaes de grandes matrizes em
arquiteturas CPU.
49
;.7.2 Re!ultado! na /P0
No desenvolvimento em GPGPU necessrio se ter um bom conhecimento
em paralelizao de processos. Programar em CUDA requer do programador um
conhecimento da arquitetura e do poder de abstrao da mesma.
12
No CUDA o bloco de $ernel executado por centenas de threads e todas elas
devem encontrar harmonia em relao ao processamento de dados e
compartilhamento de memria (somente no caso de o algoritmo estar utilizando
memria compartilhada). CUDA tem a facilidade de uma boa linha de aprendizado
originado da linguagem C, mas para obter os resultados desejados, colocar a
linguagem no mximo de sua otimizao e deixar o hardware no limite necessrio
um grande esforo.
18
Um programador, mesmo usando uma linguagem muito similar a C, sente
dificuldades para mudar o seu raciocnio para atravs daquela simples instruo ser
capaz de substituir enormes cloc$s de clculos da arquitetura CPU. Para obter os
primeiros passos dessa insero nesse novo paradigma de computao, o site da
NVDA oferece cursos. H tambm links para materiais que so oferecidos em
disciplinas de faculdades como 5er$ele8 e Cam!ridge.
O programa em CUDA foi criado baseado no programa em C na arquitetura
CPU. A mudana do cdigo foi feita de forma incremental. O processo de criao do
algoritmo ocorreu com as seguintes etapas: inicialmente foram criadas as variveis
no DEVCE, depois se criou um $ernel para a inicializao das mesmas, ento
houve a adequao da estrutura da Figura 12 (Estrutura de computao) com as
otimizaes declaradas na seo 3.1, resultando na Figura 18 (Estrutura de
computao no CUDA). Os cloc$s foram transformados em chamadas de $ernel,
usando a paralelizao da GPU para buscar alta performance.
50
Figura 18: Estrutura de computao no CUDA.
A medio dos ciclos de cloc$ na arquitetura CUDA foi feita a partir de
observao da AP
4
da NVDA onde explica o uso da funo cloc$(). Essa funo
retorna um elemento do tipo cloc$It. e esse elemento indica o valor em que est o
contador de cloc$ do DEVCE.
A cada momento em que se chama um $ernel no algoritmo, necessrio
chamar a funo cloc$(), antes e depois da chamada. Assim, com o valor do cloc$
antes e depois de cada $ernel, subtraindo-os, temos a quantidade de ciclos de cloc$
utilizada para rodar aquele $ernel.
Mas no interessa apenas a quantidade de ciclos de cloc$ em cada $ernel,
mas sim o valor global para o algoritmo. Ento, para cada resultado dessa subtrao
adicionado numa varivel global.Essa varivel global representa a quantidade total
de ciclos de cloc$ utilizada pelo GPU para rodar o algoritmo da ssmica.
Houve algumas dificuldades na criao desse programa em CUDA. A
adequao ao novo paradigma de programao foi difcil, principalmente por no
haver nenhum contato com algo similar anteriormente. Problemas de acesso
indevido a memria por erros de paralelizao podem ocorrer.
A compilao apresenta-se um pouco instvel. Mesmo fazendo algumas
restries no $ernel, o resultado permanece o mesmo. Outro problema o mal uso
de parnteses que acaba dificultando o compilador e gerando resultados irreais.
51
At o presente momento no foi realizado a passagem do algoritmo da
convoluo para a arquitetura da GPU. O problema encontrado se d no acesso a
vrias regies do arra8 no mesmo ciclo. Assim, de uma forma paralelizada, pode
ocorrer uma espcie de canibalismo entre as threads, fazendo com que elas se
sobrescrevam no resultado. A soluo desse problema seria um tema a ser
explorado em trabalhos futuros.
Para tentar diminuir a discrepncia no !enchmar$, os elementos acessaro o
mesmo ndice. Fica definido que somente ser acessado um elemento da matriz,
mas a computao da convoluo no ser alterada, veja a Figura 19.
Foi implementado o mesmo modo do Exemplo 3 para facilitar o !enchmar$ no
CUDA. Deve-se colocar o tamanho das matrizes, o nome desejado do arquivo de
sada e a quantidade de cloc$s que deseja fazer para gerar os valores de ciclo de
cloc$.
Tambm feita a contagem de tempo para executar esse algoritmo. Ela
feita antes e depois de cada chamada do mtodo global que faz o clculo da
ssmica.
O algoritmo em 176x64 rodou em um loop de 800 vezes no tempo total de
161 segundos. Sua mediana em relao aos ciclos de cloc$ de 171 ciclos.
Um segundo teste foi feito com uma matriz de 1456x640 com a quantidade de
loop de apenas 30 vezes, o algoritmo demora 1742 segundos. A mediana no clculo
de ciclos de cloc$ foi de 54639 ciclos.
O terceiro teste foi feito com uma matriz de tamanho 2672x1008 com um loop
de apenas 30 vezes. O algoritmo demora 26790 segundos. No conjunto de ciclos de
cloc$ temos 892350.
Partindo novamente para os resultados com as matrizes com tamanho de
valores 13312x4992 e 26624x10000, a pilha de alocao de variveis gera um
problema, pois no consegue alocar dinamicamente vetores com tamanhos dessa
ordem e ela "estourada, no possibilitando a execuo do algoritmo. o algoritmo
original foi preservado ao mximo visto que o CUDA foi utilizado para aperfeioar o
algoritmo que se encontrava na arquitetura CPU. O problema de alocar
dinamicamente arrays com grande tamanhos veio da implementao original.
52
;.2 Co%,ara56e! entre a! arGuitetura!
Analisando os resultados atravs de grficos de linha ;e possvel perceber
que o grfico 1 demonstra um crescimento linear. A quantidade de ciclos de cloc$
cresce tendendo ao infinito numa funo linear (x/2) onde "x a quantidade de
elementos da matriz que se deseja calcular.
Grfico 1: Quantidade de ciclos de cloc$ versus tamanho da matriz no CUDA.
No grfico 2 mostra uma linha de crescimento parbolico no infinito tendendo
a (X^2). Nesse grfico mostra que a da quantidade de ciclos de cloc$ necessria a
execuo do problema de ssmica muito grande. A ordem decimal a partir de
giga.
53
Grfico 2: Quantidade de ciclos de cloc$ versus tamanho da matriz no CPU.
O Grfico 3 apresenta a comparao entre as duas funes.
Grfico 3: Quantidade de ciclos de cloc$ versus tamanho da matriz na CPU e CUDA.
O crescimento linear do grfico do CUDA se deve ao tamanho da memria
compartilhada usada na GPU. Para matrizes pequenas a quantidade de ciclos de
cloc$ chega a ser nfima comparada a CPU.
54
Para ter uma melhora no desempenho no algoritmo de uma maneira fcil
basta procurar um modelo de GPU que tenha um tamanho de memria
compartilhada acima de 16KB, com isso esse grfico do CUDA teria uma queda
drstica na quantidade de ciclos de cloc$ ,apenas em se fazer uma mudana
simples no equipamento. A placa GTX 295 tem, por exemplo, 2044 MB de memria
compartilhada.
A paralelizao do CUDA apesar de ter despendido em mdia o mesmo
tempo de execuo que o algoritmo em CPU, mostra na quantidade de ciclos de
cloc$s que sua complexidade apresenta uma melhora significativa.
Mas, como j havia sido discutido na seo 4.2, esse tempo de execuo total
calculado aparente, a velocidade dos processadores em GPU e CPU esto em
casa decimais diferentes. A GPU tem seu ciclo de trabalho em torno de 500MHz e a
CPU em 2777MHz, em torno de 5,554 vezes mais rpido.
Uma funo linear para soluo desse problema em ssmica bem mais
qualitativa que uma funo exponencial. Esse resultado experimental aumenta as
perspectivas para o uso, em prximos trabalhos, de matrizes de tamanhos maiores,
acrescendo a preciso da modelagem sem requerer a busca de maior infra-estrutura
para isso. Essa metodologia mostra que, com CUDA, se obtm vantagem sobre a
arquitetura CPU.
55
Ca,-tulo <
<.7 Conclu!Eo e (ra#al)o! ?uturo!
Um algoritmo na linguagem C, sendo executado em CPU, ganha
desempenho se houver otimizaes para que se consiga utilizar a GPU para
paralelizar blocos de grande computao. A metodologia criada para comparar as
duas arquiteturas mostra que ao utilizar CUDA se obtm vantagem em relao a
resoluo do problema de ssmica em estudo.
Com a finalidade de programar com o CUDA e tirar o melhor desempenho,
programadores devem escolher a melhor maneira de dividir os dados em blocos
menores. Achar um nmero timo de threads e blocos que mantero a GPU
totalmente utilizada um teste desgastante para o programador.
O algoritmo em CUDA foi feito a partir do algoritmo C. Foram implementadas
algumas modificaes para realizar a migrao de arquitetura e adicionar as
otimizaes no algoritmo. Para tanto, foi necessrio identificar pontos em que h
uma grande possibilidade em ganho de desempenho com o uso do paralelismo.
dentificar os gargalos do algoritmo na arquitetura GPU e saber us-los de
acordo com as restries e vantagens da arquitetura um trabalho que requer
grande demanda de tempo e dedicao,o qual no completamente absorvido e
explorado em apenas um trabalho de concluso de graduao, cabendo a trabalhos
futuros o devido aprofundamento.
Para estudos futuros podem-se incluir modificaes nas variveis do
!enchmar$, tais como: o tamanho do conjunto global de dados que um bloco de
threads pode compartilhar no trabalho, comparao com outras GPU que usam
'ur!o Cache e o nmero de stream processors que podem ser utilizados na GPU.
Em relao a metodologia, pode-se propor o uso de um osciloscpio para
medir em um desktop o desempenho em potncia da GPU e CPU na mesma
?or$station.
56
Uma grande dificuldade da realizao desse projeto foi o tempo despendido
para a aquisio do equipamento. Desde novembro de 2008 so esperados
recursos para compra do equipamento necessrio. Foi imprescindvel a utilizao de
recursos pessoais para a compra do notebook de alto desempenho para
desenvolver e concluir o trabalho de graduao.
H equipamentos no Centro de nformtica da UFPE com GPU disponvel
para o uso do CUDA. Contudo, por questes administrativas, no houve permisso
para o acesso das mquinas. Alm desses impecilhos, houve problemas de
remoo de arquivos de sistema, mquinas quebradas e problemas de ambiente de
configurao do Visual Studio que atrasaram a execuo do projeto.
Somente no dia 5 de junho de 2009, com o recebimento do notebook acima
referido, foi possvel o inicio de fato da execuo desse projeto, restando pouco
tempo para maiores aprofundamentos e concluses.
57
Refer=ncia!
[1] CORPORATON, NVDA. CUDA Computational Finance Geeks3D. Disponvel
em:www.google.com.Acesso em:27/04/ 2009.
[2] CARDOSO, B. L., JARDM, R. A. Computao de alto desempenho utilizando
CUDA. nstituto de Computao - Universidade. Estadual de Campinas SP - BR.
2008.
[3] CORPORATON. NVDA. Disponvel em:http://www.nvidia.com. Acesso
em:27/04/ 2009.
[4] CORPORATON, NVDA. NVDA CUDA Programming Guide 1.0. 2007.
[5] CORPORATON, NVDA. NVDA CUDA Programming Guide 1.1. 2007.
[6] CORPORATON, NVDA. NVDA CUDA Programming Guide 2.0. 2007-2008.
[7] CORPORATON, NVDA. NVDA CUDA Programming Guide 2.1. 2008.
[8] CORPORATON, NVDA. NVDA CUDA Programming Guide 2.2. NVDA, 2008.
[9] CORPORATON, NVDA. NVDA CUBLAS Library. 2008.
[10] CORPORATON, NVDA. NVDA CUFFT Library. 2008.
[11] KAPAS, U. J., RXNER, S., DALLY, W. J., KHALANY, B., AHN, J. H.,
MATTSON, P., OWENS, J. D. Programmable stream processors. Computer 36, 8
(2003), 5462.
[12] LUEBKE, D. CUDA: Scalable Parallel Programming for High Performance
Scientific Computing, NVDA Corporation, EEE explore, 13 abril de 2009.
[13] ASANOVC, K. , BODK, R. , CATANZARO, B. C. , GEBS, J. J. , HUSBANDS,
P. , KEUTZER, K. , PATTERSON, D. A., PLSHKER, W. L., SHALF, J. , WLLAMS, S.
W. , YELCK, K. A. The Landscape of Parallel Computing Research: A View from
58
Berkley, Electrical Engineering and Computer Sciences University of California at
Berkeley, 18 dezembro 2006.
[14] HOUSTON, M. Advanced Programming (GPGPU). Disponvel
em:graphics.stanford.edu/~mhouston/public_talks/cs448-gpgpu.pdf. Acesso
em:27/04/ 2009.
[15] MORMOTO, C. E. Clock da GPU. Disponvel em: http://www.guiado
hardware.net/tutoriais/recursos-placas-3d/pagina3.html. Acesso em: 20/06/2009.
[16] LAMELOT,M. Overclocking Nvidia: GeForce 9600 GT. Disponvel em:
http://www.tomshardware.com/reviews/overcloc$-graphics-card,1916-3.html. Acesso
em: 20/06/2009.
[17] CCOKEMAN. XFX 9600 GT 512MB Review. Disponvel em: http://www.over
cloc$ersclub.com/reviews/xfx_9600_gt/5.htm. Acesso em: 20/06/2009.
[18] GRAY, S. G.-, KA, P. ntro to CUDA and GPU Programming. Disponvel em:
http://www.cis.udel. edu/~cavazos/cisc 879/scribenotes/lecture4Notes.pdf. Acesso
em: 20/06/2009.
[19] LLPANORAMA. Threads and blocks and grids, oh my! Disponvel em:
http://llpan orama.wordpress.com/2008/06/11/threads-and-blocks-and-grids-oh-my/.
Acesso em: 20/06/2009.
[20] CORPORATON, NVDA. NTUNE. Disponvel em: http://www.nvidia
.com/object/ntune_5.05.54.00.html. Acesso em: 20/06/2009.
[21] Riva Tuner v2.24. Disponvel em: http://downloads.guru3d.com/RivaTuner-
v2.09-download-163.html. Acesso em: 20/06/2009.
[22] CHN, M. Athlon 64 for Quiet Power. Disponvel em: http://www.silentp
creview.com/article169-page1.html. Acesso em: 20/06/2009.
[23] MACHRONE ,B. MythMash: Frontside Bus - Bottleneck or Room to Grow?.
Disponvel em: http://www.intelcapabilitiesforum.net/articles/30_mythmash_frontsi
de_bus _- _bottleneck_or_room_to_grow-page_all/. Acesso em: 20/06/2009.
[24] MOHAMED, F. Overclocking your Graphics card. Disponvel em: http://ww w.c
ontrib.andrew.cmu.edu/~fma/overcloc$ing__ graphics_card2.htm. Acesso em:
20/06/2009.
59
[25] SHAH, A. Nvidia Closing in on 2 Teraflops with Graphics Card. Disponvel em:
http://www.pcworld.com/article/156656/nvidia_closing_in_on_2_teraflops_wit
h_graphics_card.html. Acesso em: 20/06/2009.
[26] MORMOTO, C. E. Revista Guia do Hardware,nmero 8,ano 2007. Disponvel
em: www.gdhpress.com.br/bookcast/revista/RevistaGDH_08.pdf. Acesso em:
20/06/2009.
[27] NTEL. ntel Core2 Duo Mobile Processor P8600. Disponvel em:
http://processorfinder.intel.com/details.aspx?sSpec=SLB3S. Acesso em: 20/06/2009.
[28] MS. Disponvel em: http://download2.msi.com/files/downloads/mnu_exe /
01_MS_1651_v1.0_English.zip. Acesso em: 20/06/2009.
[29] NTEL. Using the RDTSC instruction for performance monitoring. Disponvel
em <http://cs.smu.ca/~jamuir/rdtscpm1.pdf>. Acesso em: 08/07/2008. . Acesso em:
20/06/2009.
[30] KSHMOTO, A. GPU e Shaders. Disponvel em: http://www.tupinihon.c
om/tech/pdf/artigo-gpu.pdf. Acesso em: 20/06/2009.
[31] Measurement Techniques. Disponvel em: http://www.spinelli
s.gr/codequality/measurement.pdf. Acesso em: 20/06/2009.
[32] CORREA, J. Desenvolvimento de uma plataforma para projetos de sistemas
dinamicamente reconfigurveis - Extenso do PETSc para Sistemas de Computao
Reconfigurveis. Acesso em: 20/06/2009.
[33] KUZMAN, L., Power consumption of PC. Disponvel em: http://www.ab
chw.com/content/power-consumption-pc. Acesso em: 20/06/2009.
[34] GRAFKKARTEN. Power consumption of current graphics cards.Disponvel
em: http://ht4u.net/reviews/2009/power_consumption_graphics/. Acesso em:
20/06/2009.
[35] CORPORATON, NVDA. NVDA. Disponvel em: http://www.nvi
dia.com/object/product_GeForce_9800m _gs_us.html. Acesso em: 20/06/2009.
60
[36] ROCHA, R. mplementao de Mdulo DSP em FPGA, utilizando o
barramento PC, para solues de alto desempenho. Disponvel em:
http://www.cin.ufp e.br/~tg/2007-2/rcfr.doc. Acesso em: 20/06/2009.
[37] HSU, S. GPU Programming. Disponvel em: www.cmlab.csie.ntu.edu.tw/~v
incent/resource/gpgpu /GPGPU_Programming.pdf. Acesso em: 20/06/2009.
[38] FATAHALAN, K., SUGERMAN ,J.;HANRAHAN, P. Understanding the
Efficiency of GPU Algorithms for Matrix Matrix Multiplication. Disponvel em:
http://grap hics.stanford.edu/papers/gpumatrixmult/. Acesso em: 20/06/2009.
[39] DALLALANA, F. GPU Programming. Disponvel em:
www.lcad.icmc.usp.br/~jbatista/semin/mat/Fred_27_10.ppt. Acesso em: 20/06/2009.
[40] CORPORATON, NVDA. GPU Programming guide GeForce 8 and 9 series.
Disponvel em: http://developer.download.nvidia.com/GPU_Programming_
Guide/GPU_Programming_Guide_G80.pdf. Acesso em: 20/06/2009.
[41] CORPORATON, NVDA. Cg. Disponvel em: http://developer.nvidia
.com/object/cg_faq.html. Acesso em: 20/06/2009.
61
A!!inatura!
___________________________________________________
Manoel Eusbio de Lima
Orientador
___________________________________________________
Paulo Srgio Brando do Nascimento
Avaliador
___________________________________________________
Bruno Correia da Silva
Aluno/Autor
Recife, Junho de 2009
\
62
A,=ndice!
APNDCE A : Exemplo de sada do !enchmar$
A quantidade de ciclo de clock e o tempo so :
53875 e o tempo foi 56.00,
54872 e o tempo foi 56.00,
55111 e o tempo foi 57.00,
55112 e o tempo foi 57.00,
55178 e o tempo foi 57.00,
55186 e o tempo foi 57.00,
55141 e o tempo foi 57.00,
55233 e o tempo foi 56.00,
54942 e o tempo foi 57.00,
54639 e o tempo foi 56.00,
54832 e o tempo foi 58.00,
54887 e o tempo foi 57.00,
55185 e o tempo foi 57.00,
54483 e o tempo foi 56.00,
54571 e o tempo foi 56.00,
54443 e o tempo foi 56.00,
53588 e o tempo foi 55.00,
53633 e o tempo foi 56.00,
53572 e o tempo foi 55.00,
53541 e o tempo foi 55.00,
53545 e o tempo foi 55.00,
53606 e o tempo foi 55.00,
54817 e o tempo foi 57.00,
54893 e o tempo foi 56.00,
54878 e o tempo foi 57.00,
54943 e o tempo foi 56.00,
54596 e o tempo foi 57.00,
53818 e o tempo foi 55.00,
53823 e o tempo foi 55.00,
53856 e o tempo foi 56.00,
53849 e o tempo foi 56.00
.
A mediana : 54639. O tempo total : 1742.
63
Ane>o!
Ane>o 4 : Bloco de cFdi*o ,ara calcular o clocH na CP0
9n.igned get:verhead() {
9n.igned int ba.e, ba.e_extra = 8
9n.igned int &"&le._lo;, &"&le._high
%% <he follo;ing te.t. r9n the ba.i& &"&le &o9nter to find
%% the overhead a..o&iated ;ith ea&h &"&le mea.9rement.
%% It i. r9n m9lti=le time. .im=l" be&a9.e the fir.t &all
%% to C>?I@ normall" ta(e. longer than .9b.eA9ent &all..
%% <"=i&all" after the .e&ond r9n the re.9lt. are
%% &on.i.tent. It i. r9n three time. !9.t to ma(e .9re.
__a.m__ (
4=9.ha4
4&=9id4
4rdt.&4
4mov BBedx, B84
4mov BBeax, B*4
4=o=a4
4=9.ha4
4&=9id4
4rdt.&4
4=o=a4
4=9.ha4
4&=9id4
4rdt.&4
4mov BBedx, B84
4mov BBeax, B*4
4=o=a4
4=9.ha4
4&=9id4
4rdt.&4
4=o=a4
4=9.ha4
4&=9id4
4rdt.&4
4mov BBedx, B84
4mov BBeax, B*4
4=o=a4
C 4=r4 (&"&le._high), 4=r4 (&"&le._lo;)
)
64
__a.m__ (
4=9.ha4
4&=9id4
4rdt.&4
4.9b B8, BBeax4
4mov BBeax, B*4
4=o=aDnDt4
C 4=r4 (ba.e_extra)
C 4r4 (&"&le._lo;)
)
__a.m__ (
4=9.ha4
4&=9id4
4rdt.&4
4mov BBedx, B84
4mov BBeax, B*4
4=o=a4
C 4=r4 (&"&le._high), 4=r4 (&"&le._lo;)
)
__a.m__ (
4=9.ha4
4&=9id4
4rdt.&4
4.9b B8, BBeax4
4mov BBeax, B*4
4=o=aDnDt4
C 4=r4 (ba.e)
C 4r4 (&"&le._lo;)
)
%% End inline a..embl"
%% <he follo;ing =rovide. in.9ran&e for the above &ode,
%% in the in.tan&e the final te.t &a9.e. a mi.. to the
%% in.tr9&tion &a&he.
if (ba.e_extra ) ba.e)
ba.e = ba.e_extra
ret9rn ba.e
$
9n.igned long long getC"&le.(int nnoi_*,int nno!_*) {
9n.igned long &"&le._high* = 8, &"&le._lo;* = 8
9n.igned long &"&le._high8 = 8, &"&le._lo;8 = 8
9n.igned long long tem=_&"&le.* = 8, tem=_&"&le.8 = 8
9n.igned long long ba.e = 8
%% &al&9la o overhead da f9nFGo
ba.e = get:verhead()
65
%%&a=t9rar &i&lo. ini&iai.
a.m(
4&=9id4
4rdt.&4
4mov BBedx, B84
4mov BBeax, B*4
C 4=r4 (&"&le._high8), 4=r4 (&"&le._lo;8)
)
%% f9nFGo a .er &al&9lada o nHmero de &i&lo.
ini&ia_main(nnoi_*,nno!_*)
%%&a=t9rar &i&lo. finai.
a.m(
4&=9id4
4rdt.&4
4mov BBedx, B84
4mov BBeax, B*4
C 4=r4 (&"&le._high*), 4=r4 (&"&le._lo;*)
)
tem=_&"&le.* = ((9n.igned long long)&"&le._high* )) '5) I &"&le._lo;*
tem=_&"&le.8 = ((9n.igned long long)&"&le._high8 )) '5) I &"&le._lo;8
ret9rn (tem=_&"&le.* J tem=_&"&le.8 J ba.e)
$