Computing Unified Device Architecture (CUDA)

Computing Unified Device Architecture (CUDA)
Programação em GPU (CUDA) Msc. Lucas de Paula Veronese Tiago Alves de Oliveira

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 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

A lei de Moore permitiu aos fabricantes aumentar a frequência dos clocks dos clocks dos processadores em cerca de 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 cooler Back: Pentium 4 (2005) cooler.

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

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

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

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

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

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

Organização de um Código CUDA
Block: 1D, 2D, or 3D group of Threads Grid: 1D or 2D group of Blocks CPU Serial Code Grid 0 . . . GPU Parallel Kernel KernelA<<< nBlk, nThr >>>(args); GPU Parallel Kernel KernelA<<< nBlk, nThr >>>(args); . . . CPU Serial Code CPU Serial Code CPU Serial Code Grid 1 . . . GPU Parallel Kernel KernelB<<< nBlk, nThr >>>(args); GPU Parallel Kernel KernelB<<< nBlk, nThr >>>(args);

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 Host Kernel 1 Kernel 2 Device Grid 1 Block (0, 0) (1, 0) (2, 0) (0, 1) (1, 1) (2, 1) Grid 2 Block (1, 1) Thread (3, 1) (4, 1) (0, 2) (1, 2) (2, 2) (3, 2) (4, 2) (3, 0) (4, 0)

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 CUDA Thread Block Thread Id #: … m Thread Program

Intel Core 2 Extreme QX9650 versus NVIDIA GeForce GTX 280 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 Hardware threads in flight 30,720 ~ 8,000! Memory Bandwidth 12.8 GBps 141.7 GBps ~ 11x To compensate for that Use this

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

Cada GeForce 8800 SM tem 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

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

Cada SM da GeForce 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 7 Bank 6 Bank 5 Bank 4 Bank 3 Bank 2 Bank 1 Bank 0 Thread 15 Thread 7 Thread 6 Thread 5 Thread 4 Thread 3 Thread 2 Thread 1 Thread 0 Bank 15 Bank 7 Bank 6 Bank 5 Bank 4 Bank 3 Bank 2 Bank 1 Bank 0 Thread 15 Thread 7 Thread 6 Thread 5 Thread 4 Thread 3 Thread 2 Thread 1 Thread 0

Linear addressing stride == 2 2-way Bank Conflicts Linear addressing stride == 8 8-way Bank Conflicts Thread 15 Thread 7 Thread 6 Thread 5 Thread 4 Thread 3 Thread 2 Thread 1 Thread 0 Bank 9 Bank 8 Bank 15 Bank 7 Bank 2 Bank 1 Bank 0 x8 Thread 11 Thread 10 Thread 9 Thread 8 Thread 4 Thread 3 Thread 2 Thread 1 Thread 0 Bank 15 Bank 7 Bank 6 Bank 5 Bank 4 Bank 3 Bank 2 Bank 1 Bank 0

Thread Local Memory Block Shared Memory Local Memory: per-Thread Private per Thread Shared Memory: per-Block Shared by Threads of the same Block Inter-Thread communication Global Memory: per-Application Shared by all Threads Inter-Grid communication Grid 0 . . . Global Memory (Global, Constant, and Texture) Grid 1 Sequential Grids in Time

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 é: Chamado somente pelo host

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ções Funções __device__ e__global__ não suportam recursão Funções__device__ e __global__ não podem declarar variáveis estáticas no seu corpo Funçõ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 referenciado Funções __global__ tem que ter o retorno como void Uma chamada a uma função __global__ é assíncrona Os 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__ 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 Internas gridDim 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ções Não é permitido ter o endereço de qualquer uma das variáveis internas Não é permitido atribuir valores para uma variáveis internas

Funões Importantes cudaGetDeviceProperties() Recupera as propriedades do device __syncthreads() Usado para coordenar a comunicação entre as threads do mesmo block atomicAdd() Esta e outras funções atômicas executam operações de leitura, modificação e escrita cuMemAlloc(), 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 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 57

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 Vetor A Vetor B 58

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 Vetor A Vetor B 59

Soma 60

Soma 61

Soma 62

Chamada do Kernel do produto interno
63

Chamada do Kernel do produto interno
64

Makefile para compilação
65

Avaliação de desempenho GPUs x Cluster de CPUs
Paralelização do Solver GMRES. Produto Matriz vetor. Produto interno. Atualização do vetores. 66

Comparação Cluter Multi-Core Vs Gpus
67

Categorização de texto
Foram implementados dois Algoritmos de kNN (k – Nearest Neighbor) PNN (Probabilistic Neural Network) 68

Reconstrução 3D C (s) C+CUDA (s) Speedup 16,8806 0,2942 57,38 69

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 Benchmark Functions 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 70

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 Benchmark Functions Speedup f1 (x) 35.48 f2 (x) 32.80 f3 (x) f4 (x) 31.98 f5 (x) 35.50 f6(x) 34.73 71

Computing Unified Device Architecture (CUDA)

Apresentações semelhantes

Apresentação em tema: "Computing Unified Device Architecture (CUDA)"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback

Login

Autorizar-se através da rede social:

Computing Unified Device Architecture (CUDA)

Apresentações semelhantes

Apresentação em tema: "Computing Unified Device Architecture (CUDA)"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback