computing unified device architecture (cuda) programação em gpu (cuda) msc. lucas de paula...

Computing Unified Device Architecture (CUDA)

Programação em GPU (CUDA)

Msc. Lucas de Paula VeroneseTiago Alves de Oliveira

[email protected]@lcad.inf.ufes.br

Introdução

• A Compute Unified Device Architecture (CUDA) é um novo modelo de programação paralela que permite a programar GPUs de alto desempenho para propósito geral através de uma pequena extensão da linguagem de programação C

Introdução

O GK104 possui 1536 cores

Introdução

• A arquitetura Single Instruction Multiple Thread (SIMT) do CUDA GPUs permite a implementação de código multithreads escalável de propósito geral

Introdução

• A arquitetura Single Instruction Multiple Thread (SIMT) do CUDA GPUs permite a implementação de código multithreads escalável de propósito geral

Computação serial de y ax + y, y e x vetores e a escalar void saxpy_serial (int n, float a, float *x, float *y) { for (int i = 0; i < n; i++) y[i] = a * x[i] + y[i]; } // Invoca o kernel serial SAXPY saxpy_serial (n, 2.0, x, y); Computação paralela de y ax + y em C + CUDA __global__ void saxpy_paralelo (int n, float a, float *x, float *y) { int thread_id = blockIdx.x * blockDim.x + threadIdx.x; int thread_increment = blockDim.x * gridDim.x; int i; for (i = thread_id; i < n; i += thread_increment) y[i] = a * x[i] + y[i]; } // Invoca o kernel paraelo SAXPY com 4 blocos de 4 threads saxpy_paralelo <<<4, 4>>> (n, 2.0, x, y);

Introdução• De onde vem tanta performance?

– Mais transistores são dedicados ao processamento de dados, em vez de cache de dados e exploração de ILP.

• A indústria de jogos de computador oferece economias em escala.

Introdução• Mais de 100 milhões de CUDA GPUs já foram vendidas.

• Isso a torna a mais bem sucedida plataforma de alto desempenho de computação paralela na história da computação e, talvez, uma das tecnologias de computação mais inovadoras da década.

• Muitos dos programas relevantes foram portados para C+CUDA e executam em ordens de magnitude mais rápido em CUDA GPUs do que em CPUs.

Introdução

Linha do Tempo das Linguagens para GPGPU

Introdução

• Nós vamos:• Discutir as forças científicas,

tecnológicas e de mercado que levaram ao surgimento do CUDA

• Examinar a arquitetura de GPUs CUDA

• Mostrar como programar e executar paralelo C + CUDA código

Forças que levaram ao surgimento do CUDA• Os avanços científicos e inovações em hardware e

software permitiram aumento exponencial do desempenho de sistemas de computadores ao longo dos últimos 40 anos

Forças que levaram ao surgimento do CUDA• A lei de Moore permitiu aos

fabricantes aumentar a frequência dos clocks dos clocks dos processadores em cerca de 1.000 vezes nos últimos 25 anos

• Mas a capacidade de dissipar o calor gerado por estes processadores atingiram limites físicos

• Aumento significativo na freqüência de clock é agora impossível sem grandes esforços no resfriamento de Circuito Integrado

• Este problema é conhecido como the Power Wall e impediu o aumento do desempenho dos sistemas de processador único.

Front: Pentium Overdrive (1993) completed with its coolerBack: Pentium 4 (2005) cooler.

Forças que levaram ao surgimento do CUDA• Durante décadas, o desempenho da hierarquia de

memória cresceu menos do que a performance dos processadores

• Hoje em dia, a latência de acesso à memória é centenas de vezes maior do que o tempo de ciclo de processadores

Forças que levaram ao surgimento do CUDA• Com mais processadores em um único Circuito Integrado,

a necessidade de largura de banda de memória está crescendo

• Mas o número de pinos de Circuito Integrado é limitada ...

• Esta latência + problema da largura de banda é conhecida como the Memory Wall

The Athlon 64 FX-70, launched in 2006, has two processing cores that can run only one thread at a time, while the UltraSPARC T1, launched in 2005, has 8 cores that can run 4 threads simultaneously each (32 threads in total). The Athlon 64 FX-70 has 1207 pins, while the UltraSPARC T1, 1933 pins

Forças que levaram ao surgimento do CUDA

• Arquiteturas de processadores capazes de executar múltiplas instruções em paralelo, fora de ordem e especulativo também contribuiu significativamente para o aumento do desempenho dos transformadores

• No entanto, empregando mais transistores na implementação dos processadores não resultou em uma maior exploração de ILP

• Este problema é conhecido como the ILP Wall


• David Patterson resumiu:• A Power Wall + The Memory Wall + ILP the Wall = a

Brick Wall for serial performance• Todos os pontos de evidências para a manutenção da

validade da Lei de Moore (pelo menos para os próximos 13 anos, de acordo com ITRS06)

• No entanto, sem um progresso visível na superação dos obstáculos, a alternativa que resta para a indústria foi a implementação de um número crescente de processadores em um único Circuito Integrado


• A indústria de computadores mudou o seu curso em 2005, quando a Intel, seguindo o exemplo da IBM (POWER4) e Sun (Niagara), anunciou que iria desenvolver sistemas multi-core x86

• Processadores multi-core aproveitam o número de transistores disponíveis para explorar o paralelismo de grãos grosseiros

• Sistemas com múltiplos processadores estão entre nós desde os anos 1960, mas os mecanismos eficientes para aproveitar o paralelismo de grão grosso e fino de aplicações, até recentemente, não existia

• Neste contexto aparece CUDA

Forças que levaram ao surgimento do CUDA• Impulsionado pela demanda na indústria de jogos, o

desempenho GPUs aumentou fortemente• Além disso, o maior número de transistores disponíveis

permitiu os avanços em arquitetura GPUs, que levam a Tesla, que suporta CUDA


• De onde o nome “Compute Unified Device Architecture (CUDA)” vem?• Gráficos tradicionais consistem em fases

programáveis separadas:• Processadores de vértices, que executam

programas de sombreamento de vértices• E processadores de fragmentos de pixels, que

executam programas de sombreamento de pixel• CUDA GPUs unificam os processadores de vértice e

pixel e estendê-los, permitindo que aplicações de alto desempenho de computação paralela escritas no + C CUDA

Forças que levaram ao surgimento do CUDA• A GPU realiza a síntese

de imagem em três etapas• Processa vértices dos

triângulos, posições da tela do computador e atributos como cor e orientação da superfície

• Experimente cada triângulo para identificar os pixels totalmente e parcialmente coberto, chamados fragmentos

• Processa os fragmentos por meio de amostragem de textura, cálculo de cor, visibilidade, e mistura

• GPUs anterior -> hardware específico para cada um

GeForce 6800 block diagram

Forças que levaram ao surgimento do CUDA• Processadores de fragmento de

pixel tradicionalmente tem desvantagem com processadores de vértices

• No entanto, cargas de trabalho não são bem equilibrados, levando a ineficiência

• Unificação permite o balanceamento de carga dinâmica de cargas de trabalho variáveis entre vertex e pixel-processamento e permite a fácil introdução de novas capacidades por software

• A generalidade necessária de um processador unificado permitiu a adição do novo GPU com capacidade de computação paralela

GeForce 6800 block diagram


• GP-GPU computação de próposito geral modelados como problemas assim como renderização de gráficos.• Transforme dados em imagens ("mapas de

textura")• Tranforme algoritmos em síntese de imagens

("passos de renderização")• C+CUDA verdadeira programaççao paralela

• Hardware: arquitetura de dados totalmente paralela e geral

• Software: C com extensões mínimas, mas poderosas

Arquitetura Tesla

• 192 Single Precision CUDA Cores

• 64 Unidades Double Precision

• 32 SFU Special Function Units

• 32 Load/Store Units

• 16 unidades de textura

Arquitetura Tesla

• 4 escalonadores de Warp

• 8 unidades de despacho

• 65536 Registradores de 32 bits

Arquitetura Kepler

• Warp são Grupos de 32 threads de um mesmo Bloco.

• Cada Warp executa a mesma instrução com dados diferentes

• Na Kepler se não houver dependência de dado entre instruções um mesmo Warp pode ser executado ao mesmo tempo que o outro com instruções diferentes

Arquitetura Kepler

• Cache de Instrução

• A Cache L1 e shared memory estão espacimente alocada no mesmo nivel– Estas duas memórias podem

ter seus tamanhos configurados código

– Ambas compartilham um espaço de 64KB

• 48KB de uma Cache somente de leitura

Arquitetura Kepler

CPU Serial Code

Grid 0

. . .

. . .

GPU Parallel Kernel

KernelA<<< nBlk, nThr >>>(args);

Grid 1CPU Serial Code

GPU Parallel Kernel

KernelB<<< nBlk, nThr >>>(args);

Organização de um Código CUDA

. . .

Grid: 1D or 2D group of Blocks

Block: 1D, 2D, or 3D group of Threads

GPU Parallel Kernel

KernelA<<< nBlk, nThr >>>(args);

GPU Parallel Kernel

KernelB<<< nBlk, nThr >>>(args);

CPU Serial CodeCPU Serial Code

Organização de um Código CUDAHost

Kernel 1

Kernel 2

Device

Grid 1

Block(0, 0)

Block(1, 0)

Block(2, 0)

Block(0, 1)

Block(1, 1)

Block(2, 1)

Grid 2

Block (1, 1)

Thread(0, 1)

Thread(1, 1)

Thread(2, 1)

Thread(3, 1)

Thread(4, 1)

Thread(0, 2)

Thread(1, 2)

Thread(2, 2)

Thread(3, 2)

Thread(4, 2)

Thread(0, 0)

Thread(1, 0)

Thread(2, 0)

Thread(3, 0)

Thread(4, 0)

• Um Kernel é executado como um Grid de Blocks

• Um Block é um grupo de Threads que podem cooperar com cada outra por:• Compartilhamento de

dados de forma eficiente por meio da baixa latência de memória compartilhada

• Sincronizar sua execução para hazard-free sem acessos de memória compartilhada

• Duas Threads de dois diferentes não podem cooperar diretamente


CUDA Thread Block

Thread Id #:0 1 2 3 … m

Thread Program

• O programador declara Blocks:• de 1, 2, or 3

dimensões• Contendo 1 to 512

Threads no toal• All Threads in a Block

execute the same Thread Program

• Each threads have a Thread Id within a Block

• Threads share data and synchronize while doing their share of the work

• The Thread Program uses the Thread Id to select work and to address shared data


Intel Core 2 Extreme QX9650 NVIDIA GeForce GTX 280

Peak Gflop/s 96 Gflop/s 933 Gflop/s ~ 10x

Transistors 820 million 1.4 billion ~ 2x

Processor clock 3 GHz 1.296 GHz ~ 1/2

Cores 4 240 ~ 60x

Cache / Shared Memory 6 MB x 2 (12MB) 16 KB x 30 (0,48MB) ~ 1/25

Threads executed per clock 4 240 ~ 60x

Hardware threads in flight 4 30,720 ~ 8,000!

Memory Bandwidth 12.8 GBps 141.7 GBps ~ 11x

• Intel Core 2 Extreme QX9650 versus NVIDIA GeForce GTX 280

Use this

To compensate

for that

Organização de um Código CUDA• Memory Hierarchy

(hardware)• Registers: dedicado

HW – único ciclo• Shared Memory:

dedicado HW – único ciclo

• Constant Cache: dedicado HW – único ciclo

• Texture Cache: dedicado HW – único ciclo

• Device Memory – DRAM, 100s de ciclos

Organização de um Código CUDA• Cada GeForce 8800 SM tem

8192 registradores de 32-bit• Esta é uma decisão de

implementação, não é uma parte do CUDA

• Registradores são dinamicamente particionados entre todas as Threads atríbuido para o SM

• Uma vez atribuído a uma Thread, o registo não é acessível por outras threads

• Ou seja, Threads no mesmo bloco só acessam registradores atribuído a si mesmo


• Register variables

Computação serial de y ax + y, y e x vetores e a escalar void saxpy_serial (int n, float a, float *x, float *y) { for (int i = 0; i < n; i++) y[i] = a * x[i] + y[i]; } // Invoca o kernel serial SAXPY saxpy_serial (n, 2.0, x, y); Computação paralela de y ax + y em C + CUDA __global__ void saxpy_paralelo (int n, float a, float *x, float *y) { int thread_id = blockIdx.x * blockDim.x + threadIdx.x; int thread_increment = blockDim.x * gridDim.x; int i; for (i = thread_id; i < n; i += thread_increment) y[i] = a * x[i] + y[i]; } // Invoca o kernel paraelo SAXPY com 4 blocos de 4 threads saxpy_paralelo <<<4, 4>>> (n, 2.0, x, y);


• O número de registros restringe aplicações• Por exemplo, se cada Block tem 16X16 Threads e cada

Thread usa 10 registers, quantos Blocks podem executar em cada SM?• Cada Block requer 10*16*16 = 2560 registers• 8192 > 2560 * 3, mas 8192 < 2560 * 4• Assim, três Blocks podem rodar em um SM, tanto

quanto em um registers ocupado• Que tal se cada Thread aumentasse o uso de registos por

um?• Cada Block exige agora 11 * 16 * 16 = 2816 registros• 8192 <2816 * 3• Agora, apenas dois Blocks podem ser executado em

um SM

Organização de um Código CUDA• Cada SM da GeForce 8800

tem 16 KB de Memória Compartilhada

• Divididos em 16 bancos de 32bit words

• CUDA usa Memória Compartilhada como armazenamento compartilhado para todas as Threads em um Block

• Controle de leitura e escrita• Cada banco tem uma largura

de banda de 32 bits por ciclo de clock

• Sucessivas words de 32 bits são atribuídos aos bancos sucessivos

• Vários acessos simultâneos a um banco resultado num bank conflict

• Acessos conflitantes são serializados


• Linear addressing stride == 1– No Bank Conflicts

• Random 1:1 Permutation – No Bank Conflicts

Bank 15

Bank 7Bank 6Bank 5Bank 4Bank 3Bank 2Bank 1Bank 0

Thread 15

Thread 7Thread 6Thread 5Thread 4Thread 3Thread 2Thread 1Thread 0

Bank 15


Thread 15



• Linear addressing stride == 2– 2-way Bank Conflicts

• Linear addressing stride == 8– 8-way Bank Conflicts

Thread 11Thread 10Thread 9Thread 8

Thread 4Thread 3Thread 2Thread 1Thread 0

Bank 15


Thread 15


Bank 9Bank 8

Bank 15

Bank 7

Bank 2Bank 1Bank 0x8

x8


Grid 0

. . .

Global Memory (Global, Constant,

and Texture). . .

Grid 1

SequentialGridsin Time

Thread

Local Memory

Block

SharedMemory

Local Memory: per-ThreadPrivate per Thread

Shared Memory: per-BlockShared by Threads of the same Block

Inter-Thread communication

Global Memory: per-ApplicationShared by all Threads

Inter-Grid communication


Tipos de Qualificadores de Função__device__•O qualificador__device__ declara uma função que é:

• Executado no device• Chamado somente pelo device

__global__•O qualificador __global__ declara uma fonção que começa no kernel. Esta função é:

• Executado no device• Chamado somente pelo host

Organização de um Código CUDA• Qualificadores do

tipo de função são adicionados antes das funções

• A função __global__ são sempre chamadas com uma configuração

• A função __device__ são chamadas pelas funções pelo __global__

Parallel Programming in C+CUDA

RestriçõesFunções __device__ e__global__ não suportam recursãoFunções__device__ e __global__ não podem declarar variáveis estáticas no seu corpoFunções __device__ e __global__ não podem ter um número variável de Funções __device__ não pode ter o seu endereço referenciadoFunções __global__ tem que ter o retorno como voidUma chamada a uma função __global__ é assíncronaOs parâmetros da função __global__ são passados através de memória compartilhada com o dispositivo e estão limitados a 256 bytes


Tipo de Qualificadores de Variáveis__device__

• Declara uma variável que reside no device• Reside no espaço de memória global• Tem o tempo de vida de uma aplicação• É acessível a partir de todas as Threads dentro da grid de

um host


__constant__ • Declara uma variável que:

• Reside no espação de memória constante• Tem o tempo de vida da aplicação• É acessível por todas as threads do grid e do host

__shared__ • Declara uma variável que:

• Reside no espaço de memória do Block• Tem o tempo de vida do Block• É acessível somente por todas as threads de um Block


Variáveis InternasgridDim

Esta variável contém as dimensões do grid

blockIdx

Esta variável contém o indíce do block dentro do grid


blockDim

Esta variável contém as dimensões de um block

threadIdx

Esta variável contém o indíce da thread dentro do block

warpSize

Esta variável contém o tamanho do warp em threads


RestriçõesNão é permitido ter o endereço de qualquer uma

das variáveis internasNão é permitido atribuir valores para uma

variáveis internas

Parallel Programming in C+CUDAFunões ImportantescudaGetDeviceProperties()Recupera as propriedades do device__syncthreads()Usado para coordenar a comunicação entre as threads

do mesmo blockatomicAdd()Esta e outras funções atômicas executam operações de

leitura, modificação e escritacuMemAlloc(), cuMemFree(), cuMemcpy()Esta e outras funões de memória permitem alocar,

liberar e copiar memórias para/do device

Comparação entre os SMs da FERMI e a da Kepler

Produto Interno em CUDAProduto Interno em CUDA

• Suponha que o vetor A e B tenha 32 posições

• Para computar o produto interno é criado:– Grid de 4 blocks– Cada block contêm

4 threads




4 threads

Vetor A

Vetor B


Vetor A

Vetor B



4 threads

SomaSoma

Chamada do Kernel do produto interno Chamada do Kernel do produto interno

Makefile para compilaçãoMakefile para compilação

Avaliação de desempenho GPUs x Cluster de CPUsAvaliação de desempenho GPUs x Cluster de CPUs

• Paralelização do Solver GMRES.– Produto Matriz vetor.– Produto interno.– Atualização do vetores.

Comparação Cluter Multi-Core Vs GpusComparação Cluter Multi-Core Vs Gpus

Categorização de textoCategorização de texto

• Foram implementados dois Algoritmos de – kNN (k – Nearest Neighbor)– PNN (Probabilistic Neural Network)

0

10

20

30

40

50

60

70

80

0 691 1382 2073 2764 3455 4146 4837 5528 6219 6910 7601

Numero de Documentos

Sp

eed

-up

PNN

kNN-CUBLAS

kNN

Reconstrução 3DReconstrução 3D

C (s) C+CUDA (s) Speedup

16,8806 0,2942 57,38

Differential Evolution (DE)Differential Evolution (DE)

• Tempo de Computação para os Benchmarks de Otimização com 100 dimensões, 100 partículas e 10,000 iterações

BenchmarkFunctions

Speedup

f1 (x) 15.05

f2 (x) 13.15

f3 (x) 9.91

f4 (x) 14.96

f5 (x) 18.07

f6(x) 19.04

Differential Evolution (DE)Differential Evolution (DE)

• Tempo de Computação para os Benchmarks de Otimização com 100 dimensões, 1000 partículas e 100,000 iterações

BenchmarkFunctions

Speedup

f1 (x) 35.48

f2 (x) 32.80

f3 (x) 32.80

f4 (x) 31.98

f5 (x) 35.50

f6(x) 34.73

computing unified device architecture (cuda) programação em gpu (cuda) msc. lucas de paula...

Documents