Implementazione di linguaggi 2. CUDA, query su GPU. Dott Stefano Ghio. Dott Michele Bozzano.

Transcript

1 Implementazione di linguaggi 2 CUDA, query su GPU Dott Michele Bozzano michele.bozzano@gmail.com Dott Stefano Ghio otacorp@gmail.com

2 GPGPU General purpose processing on the GPU Come dice il nome (Graphics Processing Unit) è il microprocessore di una scheda video ed è stato inizialmente ideato per assolvere compiti specifici di computer grafica. Esso si è evoluto diventando estremamente flessibile e potente, tanto che ci si è chiesti se esistesse la possibilità di sfruttarlo per computazioni general-purpose.

3 Potenzialità del GPGPU La potenza e la flessibilità delle GPU le rende una interessante piataforma per computazioni general purpose. L obbiettivo è quello di mettere a disposizione dei programmatori le potenzialità inutilizzate delle GPU per poterle sfruttare come un co-processore ad alta velocità. Esempi di applicazioni Physical modeling Computational engineering Matrix algebra Convolution Sorting Database operations

4 CPU vs GPU Le GPU stanno diventando sempre più veloci: La crescita annuale di CPU e GPU è determinata dalla seguente legge: CPUs: 1.4 GPUs: 1.7 (pixels) to 2.3 (vertices)

5 GPU vs CPU: NVIDIA 280 vs Intel i multi-processors in a TPC = Thread Processing Cluster (24 cores)

6 GPU vs CPU Peak Performance Trends Le prestazioni massime delle GPU sono cresciute rapidamente L'hardware ha tenuto il passo della legge di Moore

7 CPU vs GPU La maggioranza delle operazioni eseguite su GPU è estremamente ripetiva e le condizioni per cui delle parti di codice vengono eseguite o meno sono molto rare. A grandi linee, infatti, possiamo dire che nelle CPU standard la maggior parte dei transistor è spesa per gestire il controllo (con le cache e la logica di salto), mentre nel caso delle GPU i core sono molto più semplici e veloci e quasi tutta l'area è spesa per implementarli.

8 Problematiche La progettazione delle GPU è guidata dal mercato dei videogiochi e da ciò ne risulta uno stile di programmazione inusuale, con simbolismi legati alla computer grafica e un ambiente di programmazione molto ristretto. Il perfezionamento di linguaggi di programmazione orientati alle GPU, quale CUDA, sta tentando di porre rimedio a questa difficolta di utilizzo.

9 CUDA Compute Unified Device Architecture modello architetturale Application Programming Interface (API) per sfruttare tale architettura una serie di estensioni (C for CUDA) al linguaggio C per descrivere un'applicazione parallela in grado di girare sulle GPU che adottano quel modello La API di CUDA è molto più facile da comprendere rispetto alle API grafiche.

10 CUDA Un'applicazione CUDA è composta da parti seriali, normalmente eseguite dalla CPU di sistema, o host, e da parti parallele, denominate kernel, che vengono invece eseguite dalla GPU, o meglio ancora nei termini usati da NVIDIA, dal device.

11 CUDA Programming Model La GPU è vista come una periferica di elaborazione che: È un coprocessore (slave) della CPU (host) Ha una propria memoria DRAM (device memory) Un kernel è una funzione richiamabile dalla CPU. Un thread è una istanza di un kernel. GPU manda in esecuzione molti threads in parallelo.

12 CUDA Programming Model Host (CPU) Device (GPU) Kernel PCIe Threads (instances of the kernel) Device Memory

13 Thread Batching: Grids and Blocks Un kernel è definito come una grid (griglia), e può a sua volta essere decomposto in blocchi, che vengono assegnati, sequenzialmente, ai vari multiprocessori, e rappresentano un parallelismo a grana grossa. All'interno dei blocchi, c'è l'unità di computazione fondamentale, il thread, ad una granularità di parallelismo molto fine. Un thread può appartenere ad un solo blocco, ed è identificato da un indice univoco per tutto il Host Kernel 1 Kernel 2 Block (1, 1) Threa d (0, 0) Threa d (0, 1) Threa d (0, 2) Device Threa d (1, 0) Threa d (1, 1) Threa d (1, 2) Grid 1 Block (0, 0) Block (0, 1) Grid 2 Threa d (2, 0) Threa d (2, 1) Threa d (2, 2) Block (1, 0) Block (1, 1) Threa d (3, 0) Threa d (3, 1) Threa d (3, 2) Threa d (4, 0) Threa d (4, 1) Threa d (4, 2) Block (2, 0) Block (2, 1)

14 Thread Batching: Grids and Blocks I kernel (le griglie) sono eseguite sequenzialmente tra loro. I blocchi e i thread, invece, sono eseguiti logicamente in parallelo. Il numero di thread fisici in esecuzione in parallelo dipende dalla loro organizzazione in blocchi e dalle loro richieste in termini di risorse rispetto alle risorse disponibili nel device. I blocchi sono pensati per garantire la scalabilità: supponendo di avere un'architettura con solo 2 multiprocessori e un'altra con 4, e un'applicazione decomposta in 8 blocchi, essa potrà essere eseguita su entrambe, ovviamente con tempi (e livelli di parallelismo) diversi. Nel caso si renda successivamente disponibile un'architettura con 8 multiprocessori, l'applicazione automaticamente si adatterà ad essa e potenzialmente scalerà ancora con le prestazioni.

15 Thread Batching: Grids and Blocks

16 Thread Batching: Grids and Blocks La caratteristica fondamentale di CUDA, che rende il modello di programmazione sostanzialmente differente da altri modelli paralleli, normalmente usati dalle CPU, è che per essere efficiente richiede migliaia di thread. Ciò è reso possibile dalla struttura tipica delle architetture grafiche, che impiegano thread molto leggeri e permettono di creare e cambiare i contesti di esecuzione in maniera molto rapida ed efficiente (nessun ciclo di clock).

17 Classi di applicazioni Si comprende abbastanza facilmente che il modello di CUDA si adatta a specifiche classi di applicazione. In particolare, le caratteristiche principali di queste applicazioni sono: presenza di molte operazioni matematiche (grande intensità aritmetica) elevato grado di parallelismo (le stesse operazioni vengono ripetute per una grande quantità di dati) elavata richiesta di banda di memoria condizioni di controllo molto limitate minima dipendenza tra data elements

18 Memory Hierarchy CPU and GPU Memory Hierarchy

19 CPU Memory Hierarchy In qualsiasi punto del programma è possibile Allocare/liberare la memoria locale e quella globale Accedere in maniera random alla memoria Registers Read/write Memory (RAM) Read/write Disk (HD) Read/write

20 GPU Memory Hierarchy Le modalità di accesso alla memoria sono più restrittive È possibile allocare/liberare la memoria solamente prima della computazione L'accesso alla memoria è limitato durante la computazione Registers Read/write Caches and video memory Read/write Memory (RAM) No access Disk access No access

21 CUDA Device Memory Allocation La GPU (o device) può accedere alla sua memoria privata, o global memory. L'host ha la possibilità di spostare i dati in questa memoria tramite le primitive. Ciascun multiprocessore può poi accedere alla propria shared memory, che invece non può in alcun modo essere gestita dall'host. I dati allocati in shared memory hanno una visibilità limitata al singolo blocco di thread CUDA. Host (Device) Grid Block (0, 0) Shared Memory Registers Thread (0, 0) Local Memor y Global Memory Register s Thread (1, 0) Local Memor y Block (1, 0) Shared Memory Register s Thread (0, 0) Local Memor y Register s Thread (1, 0) Local Memor y Constant Memory Texture Memory

22 CUDA Device Memory Allocation Read-write per-thread registers Read-write per-thread local memory Read-write per-block shared memory Read-write per-grid global memory Read-only per-grid constant memory Read-only per-grid texture memory (Device) Grid Block (0, 0) Shared Memory Registers Thread (0, 0) Local Memor y Register s Thread (1, 0) Local Memor y Block (1, 0) Shared Memory Register s Thread (0, 0) Local Memor y Register s Thread (1, 0) Local Memor y Host Global Memory Constant Memory Texture Memory

23 CUDA Device Memory Allocation cudamalloc Alloca gli oggetti nella Device Global Memory Richiede due parametri: L indirizzo di un puntatore all oggetto che si desidera allocare La dimensione dell oggetto da allocare cudafree Libera aree di memoria usate dalla Global Memory Bisogna specificare il puntatore all area di Host (Device) Grid Block (0, 0) Shared Memory Registers Thread (0, 0) Local Memor y Global Memory Constant Memory Texture Memory Register s Thread (1, 0) Local Memor y Block (1, 0) Local Memor y Shared Memory Register s Thread (0, 0) Register s Thread (1, 0) Local Memor y

24 CUDA Device Memory Allocation cudamemcpy() (Device) Grid esegue le operazioni di copia Block (0, 0) Block (1, 0) Richiede quattro parametri Un puntatore ad un area di memoria sorgente Shared Memory Registers Register s Shared Memory Register s Register s Un puntatore ad area di memoria destinazione Thread (0, 0) Thread (1, 0) Thread (0, 0) Thread (1, 0) Il numero di bytes da copiare La direzione dell operazione: Host to Device Device to Host Device to Device Host Local Memor y Global Memory Constant Memory Texture Memory Local Memor y Local Memor y Local Memor y

25 Programma di esempio // include di sistema #include <stdio.h> #include <assert.h> int main( int argc, char** argv) { //puntatore all'area di memoria sull'host float *h_a; //dimensioni di tale area di memoria int dima; //variabile contatore int n; // puntatori alle aree di memoria sul device float *d_a, *d_b; // allocazione ed inizializzazione della memoria sull'host // definizione delle dimensioni dima = 8; //esecuzione della malloc h_a = (float *) malloc(dima*sizeof(float)); //inizializzazione for (n=0; n<dima; n++) { h_a[n] = (float) n; } // Allocazione della memoria sul device size_t memsize = dima*sizeof(float); cudamalloc( (void**)&d_a, memsize ); cudamalloc( (void**)&d_b, memsize ); } // Memcopy dall'host al device cudamemcpy( d_a, h_a, memsize, cudamemcpyhosttodevice ); // Memcopy da device a device cudamemcpy( d_b, d_a, memsize, cudamemcpydevicetodevice ); // Cancellazione dei dati nell'area di memoria sull'host for (n=0; n<dima; n++) { h_a[n] = 0.f; } // Copia dal device all'host cudamemcpy( h_a, d_b, memsize, cudamemcpydevicetohost ); // verify the data on the host is correct for (n=0; n<dima; n++) { assert(h_a[n] == (float) n); } // Liberazione della memoria sul device cudafree( d_b ); cudafree( d_a ); // liberazione della memoria dell'host free(h_a); // Se il programma arriva fin qua, tutto corretto! printf("corretto!\n"); return 0;

26 Il costo di accesso alla memoria I registri sono estremamente veloci ma sono risorse limitate Anche le memorie cache tendono a essere di dimensioni ridotte Per grandi data sets, la memoria globale fornisce read/write access Gli accessi avvengono in circa cicli di clock Gli accessi non sono mantenuti in cache Per coprire la latenza di memoria, l'hardware fornisce veloci cambi di contesto quando la memoria è acceduta È necessario che ci sia una grande quantità di calcoli da eseguire per coprire l'alto costo di accesso alla memoria I programmi devono essere intelligenti I compilatori spesso non forniscono la necessaria ottimizzazione in fatto di velocità, ma piuttosto di dimensioni del codice Può essere a volte conveniente ricalcolare un risultato invece di accedere alla memoria.

27 Ottimizzare query SQL con CUDA L'alto grado di parallelismo che caratterizza le GPU le rende molto appetibili per implementare query SQL in modo efficace ed efficiente Prenderemo in considerazione alcune query d'esempio effettuate con SQLite

28 SQLite, perchè? Opensource Leggero e di piccole dimensioni Fornito come codice C, molto ottimizzabile direttamente dal compilatore del progetto

29 SQLite - funzionamento Per poter migliorare qualcosa bisogna prima capire come funziona SQLite trasforma ogni query SQL in una sequenza di opcode, simili a codice assembler Ad ogni opcode corrisponde un comando preciso eseguito all'interno del database

30 SQLite funzionamento (cont) Analizzando la sequenza di opcode ottenuti è possibile individuare punti critici sui quali ottimizzare Il programma scritto in opcode viene eseguito da una macchina virtuale che controlla l'esecuzione del codice tramite switch e jump.

31 Esperimento - descrizione Data set composto solo da numeri interi ed in virgola mobile con precisione singola e doppia Tutto il data set (1-5 milioni di tuple) risiede in memoria al momento di effettuare le query, che sono tutte di tipo SELECT

32 Esperimento - sistema Processore Intel Xeon X5550 (2,66GHz quadcore con supporto a 8 hardware thread e banda massima 32GB/s) Kernel Linux GB di memoria Nvidia TESLA C1060 (240 streaming multiprocessors, 4GB memoria e banda massima di 102GB/s)

33 Esperimento data set Generato con il generatore di numeri casuali della libreria scientifica GNU Una colonna per ogni tipo di dato ha una distribuzione uniforme nell'intervallo [-99.0,99.0], Una colonna ha una distribuzione normale con una sigma di 5 ed una ha distribuzione normale con sigma 20 5 milioni di tuple contenenti un id, tre interi e tre floating point. Indicheremo con uniformt e normaltn tali colonne dove T è i oppure f per indicare se si tratta di dato intero o floating point ed N è 5 o 20 a seconda della sigma.

34 Esperimento - query

35 Esperimento query (cont)

36 Esperimento da query a opcode

37 Esperimento da query a opcode (cont) Non tutti gli opcode sono rilevanti ai fini dell'esperimento e non saranno perciò implementati Il flusso del programma è regolato da jump, non tutti gli opcode sono eseguiti in sequenza Alcuni opcode sono eseguiti per ogni riga del data set e sono quindi parallelizzabili Si passa per un formato intermedio chiamato Sphyraena

38 Esperimento da query a opcode (cont) [ ] // find the first OP_Next for(i = 0; i < vdbe->nop && o[i].opcode!= OP_Next; i++); // set start to the destination of OP_Next when it jumps back // to start the next row int start = o[i].p2; [...]

39 Esperimento da query a opcode switch(op->opcode) { case OP_Int64 : // p4 normally stores a pointer to an int64, // dereference for the gpu op->p4.li = o[i].p4.pi64[0]; break; (cont) case OP_Real : // p4 normally stores a pointer to a double, // dereference for the gpu op->p4.d = o[i].p4.preal[0]; break; // SQLite stores the type of aggregate as a string, // translate it to an int case OP_AggStep : case OP_AggFinal : agg_name = o[i].p4.pfunc->zname; if(strcmp(agg_name, SPHYRAENA_AGG_STR_COUNT) == 0) { op->p4.i = SPHYRAENA_AGG_COUNT; } else if(strcmp(agg_name, SPHYRAENA_AGG_STR_MAX) == 0) { op->p4.i = SPHYRAENA_AGG_MAX; } else if(strcmp(agg_name, SPHYRAENA_AGG_STR_MIN) == 0) { op->p4.i = SPHYRAENA_AGG_MIN; } else if(strcmp(agg_name, SPHYRAENA_AGG_STR_SUM) == 0) { op->p4.i = SPHYRAENA_AGG_SUM; } else if(strcmp(agg_name, SPHYRAENA_AGG_STR_AVG) == 0) { op->p4.i = SPHYRAENA_AGG_AVG; } break; }

40 Esperimento - risultati

41 Bibliografia