Università degli Studi di Napoli Federico II

Transcript

1 Università degli Studi di Napoli Federico II Facoltà di Scienze MM.FF.NN. Corso di Laurea in Informatica Tesi sperimentale di Laurea Triennale Valutazione delle architetture GPGPU per il fitting mediante algoritmo di Price Relatori Candidato Prof. Guido Russo Fabrizio Botta Dr. Guglielmo De Nardo matr. N86/008 Dr. Silvio Pardi Anno Accademico

2 A coloro che ci sono stati, che ci sono e che ci saranno, durante il lungo viaggio della mia vita. Grazie. Science is what we understand well enough to explain to a computer. Art is everything else we do Donald Knuth Fabrizio Botta N86/008 Pagina 2 di 95

3 Indice generale Introduzione Il calcolo parallelo massivo L'evoluzione delle CPU moderne La storia delle GPU: dagli albori alla nascita di CUDA L'architettura CUDA Introduzione all'architettura CUDA La Compute Capability Anatomia di un programma CUDA Le prime architetture CUDA-enabled L'architettura Fermi: una nuova generazione Le innovazioni hardware dell'architettura Fermi Le ALUs dello Streaming Multiprocessor di Terza Generazione Le unità di load/store Le Special Function Units Il Dual Warp Scheduler NVidia ParallelDataCacheTM Supporto ECC per le memorie Esecuzione concorrente di più threads I vantaggi dell'architettura Fermi nella programmazione Spazio di indirizzi unificato e completa compatibilità con il C Kepler: il futuro delle GP-GPU L'High Performance Computing per la Fisica delle Alte Energie (HEP) Principali esperimenti di Fisica Esperimento CMS Esperimento ATLAS ALICE: A Large Ion Collider Experiment La statistica parametrica e il metodo della massima verosimiglianza L'algoritmo di Price Descrizione teorica...37 Fabrizio Botta N86/008 Pagina 3 di 95

4 5.2 Il diagramma di flusso La scelta dei parametri Domini di esistenza La dimensione della tabella Il criterio di stop Le librerie impiegate: CUDA vs Thrust La libreria CUDA Allocazione della memoria Trasferimenti dati Processi parallelizzati La libreria Thrust Vantaggi Allocazione della memoria Trasferimenti dati Definizione del contenuto di arrays Trasformazioni: B[i] = f(a[i]) e C[i]=f(A[i],B[i]) Riduzioni Fusioni tra operazioni Generazione di numeri casuali L'implementazione dell'algoritmo La parallelizzazione dell'algoritmo Strategie di memorizzazione La tabella dei valori iniziali Le osservazioni dell'esperimento Domini di esistenza Criteri di stop Il diagramma di flusso L'ambiente di test nvidia Tesla S I test di performance Condizioni per il test Considerazioni finali...57 Fabrizio Botta N86/008 Pagina 4 di 95

5 10. Bibliografia...58 Appendice A:Codice dell'algoritmo...61 A.1 main.cu...61 A.2 constants.cu...73 A.3 unary_ops.cuh...73 A.4 price.cuh...74 A.5 experiment.cu...76 A.6 price.cu...77 Appendice B:Ringraziamenti...95 Fabrizio Botta N86/008 Pagina 5 di 95

6 Indice delle illustrazioni Illustrazione 1: CPU vs GPU...9 Illustrazione 2: Schema di massima di un'architettura GPU thread-based...12 Illustrazione 3: Visione schematica dell'architettura Fermi...16 Illustrazione 4: Struttura di uno Streaming Multiprocessor (SM)...17 Illustrazione 5: Parallelismo Dinamico...23 Fabrizio Botta N86/008 Pagina 6 di 95

7 Indice delle tabelle Tabella 1: Confronto tra le architetture CUDA...19 Tabella 2: Confronti tra le potenzialità delle architetture Fermi e Kepler...22 Fabrizio Botta N86/008 Pagina 7 di 95

8 Introduzione Il seguente lavoro di tesi nasce con l'obiettivo di sfruttare la potenza di elaborazione massiva offerta dalle schede grafiche di nuova generazione in ambito di calcolo scientifico. L'algoritmo sviluppato cerca di rispondere all'esigenza degli studiosi di Fisica delle Alte Energie di analizzare gli incrementi prestazionali nell'utilizzare algoritmi GPU-oriented per elaborare i numerosi dati raccolti dai più disparati esperimenti. Per poter meglio approfondire questo argomento, il presente lavoro e' suddiviso in diversi capitoli, che cercano di enucleare sia i fondamenti teorici alla base di questa nuova disciplina, sia le metodologie pratiche di utilizzo delle librerie per il GP-GPU, sia i risultati elaborati dall'analisi dell'algoritmo prodotto. Nel Capitolo 1 è introdotto il concetto di calcolo parallelo massivo : partendo dallo sviluppo delle moderne CPU e dall'analisi delle differenze con il calcolo parallelo tradizionale, si ripercorre brevemente la sua storia e le motivazioni che ne hanno decretato lo sviluppo. Nel Capitolo 2 si approfondisce l'architettura CUDA-enabled, sviluppata da nvidia. Introducendo alcune note storiche, si evidenziano le caratteristiche funzionali dell'architettura Fermi, le cui schede Tesla sono state impiegate per eseguire il codice sviluppato. Si accenna infine alla nuova architettura Kepler, per avere una visione più esaustiva del percorso che sta compiendo la nvidia con la sua CUDA. Nel Capitolo 3 viene mostrata l'importanza del calcolo parallelo massivo in ambito scientifico. Qui sono presentati i principali esperimenti, sia Fabrizio Botta N86/008 Pagina 8 di 95

9 terminati che in corso, che giovano o hanno giovato della potenza di calcolo parallelo. Nel Capitolo 4 è descritto il problema della minimizzazione di funzioni, inerente all'inferenza parametrica. Qui viene spiegato in dettaglio il metodo della massima verosimiglianza, alla base dell'algoritmo realizzato. Nel Capitolo 5 è spiegato l'algoritmo di Price, implementato nel codice realizzato per questa tesi: viene qui analizzato tutto il flusso di esecuzione dell'algoritmo teorico presentato da Price nel Il capitolo termina con un'analisi sulla scelta dei valori da assegnare ai parametri di input dell'algoritmo. Il Capitolo 6 approfondisce le funzionalità principali delle librerie impiegate per l'algoritmo. Si analizzano mediante comparazione i vantaggi e gli svantaggi nell'utilizzo della libreria standard CUDA e della libreria aggiuntiva Thrust. La trattazione è arricchita da nozioni assimilate grazie all'esperienza nell'utilizzo di queste librerie. Nel capitolo 7, l'implementazione dell'algoritmo viene studiata nel dettaglio. Qui vengono giustificate le scelte attuate per ottimizzare l'elaborazione in termini di performance, sia dal punto di vista della parallelizzazione, che delle strategie di memorizzazione dei dati e delle variabili. Le parti successive di questo elaborato mostreranno i risultati derivanti dai test, eseguiti sul codice realizzato : nel Capitolo 8, viene descritto il calcolatore su cui è stato eseguito il codice, mentre nel Capitolo 9 vengono mostrati i dati risultati. Questi ultimi sono sintetizzati attraverso grafici che spiegano in maniera diretta, ma esaustiva, le considerazioni a cui si è arrivati. Fabrizio Botta N86/008 Pagina 9 di 95

10 Nel Capitolo 10 è possibile consultare la bibliografia, i cui numeri corrispondono a quelli utilizzati in tutto il resto della trattazione per indicare le fonti da cui si sono tratte le informazioni riportate. Quando possibile, le fonti sono correlate di URL. Nel capitolo 11, infine, sono elencati i ringraziamenti dell'autore. In appendice, è riportato integralmente il codice sviluppato. Fabrizio Botta N86/008 Pagina 10 di 95

11 1. Il calcolo parallelo massivo 1.1 L'evoluzione delle CPU moderne Fino al 2003, la gran parte degli sviluppatori di software sperava nell'evoluzione dei processori a core singolo, semestre dopo semestre, affinché i propri algoritmi potessero essere più veloci. Tuttavia, i problemi di dissipazione del calore e di consumo energetico rallentarono l'aumento della frequenza di calcolo e il numero di attività eseguibili ad ogni clock. Da questo momento in poi, le aziende di microprocessori avviarono due approcci per risolvere questo problema[1]. Il primo è detto multicore e si basa sull'eseguire codice sequenziale su uno dei due, tre, quattro o sei core disponibili, a seconda del modello: questo permette di eseguire più programmi contemporaneamente. Un esempio è il recente Intel Core i7 a quattro core, che può eseguire due threads per ogni core ognuno dei quali supporta l'intero set di istruzioni x86. L'altro approccio è detto manycore: esso si basa sulla parallelizzazione delle operazioni di un singolo programma. Un esempio attuale è la nvidia GeForce GTX 690, basata sulla recentissima architettura Kepler (la diretta evoluzione della Fermi, di cui parleremo più avanti): 16 unità di controllo, ognuna delle quali possiede 192 core, che possono eseguire un sottoinsieme del set di istruzioni x86. [2] Al 2009, fu stimato che il calcolo su GPU riusciva a dare un incremento della potenza di calcolo di 10 volte quello delle CPU, in termini di Fabrizio Botta N86/008 Pagina 11 di 95

12 Gigaflops. [3] Attualmente, il divario prestazionale è diminuito e fa supporre che, se i trend si manterranno costanti, ci potrà essere un annullamento di questo gap. [4] Questo considerevole gap, che comunque rimane, spinge gran parte della comunità di sviluppatori a proseguire questo approccio manycore per affrontare problemi di calcolo intensivo. La differenza nell'architettura tra CPU e GPU è il "segreto" di questo molto bassa per via della grande capienza delle cache memories. Le GPU, al contrario, hanno molte unità di controllo più semplici che controllano un numero molto più alto di unità di calcolo (32 per l'architettura Fermi, 192 per l'architettura Kepler[5]). Sebbene ogni unità di calcolo abbia a disposizione meno memoria cache, la banda di trasferimento dati tra caches e RAM grafica è decisamente più elevata. I grossi svantaggi risiedono nell'esigua banda di trasferimento da e verso la RAM della CPU e nella difficoltà di programmare queste schede dall'architettura così differente. Fabrizio Botta N86/008 Pagina 12 di 95

13 1.2 La storia delle GPU: dagli albori alla nascita di CUDA Le prime GPU erano progettate come acceleratori grafici, che supportavano solo specifici flussi di esecuzione di funzioni predeterminate, che erano configurabili ma non programmabili. A partire dalla seconda metà degli anni 90, le componenti hardware divennero sempre più programmabili, arrivando nel 1999 ad avere la prima GPU nvidia [6]. Nemmeno un anno dopo che nvidia coniò il termine GPU (acronimo di Graphic Processing Unit), artisti e progettisti di videogiochi non erano gli unici a lavorare con questa nuova tecnologia: i ricercatori, infatti, si resero conto da subito delle prestazioni di queste componenti nel calcolo in virgola mobile, portando alla nascita della programmazione per uso generico su GPU (o GP-GPU, General Purpose GPU programming). Tuttavia, a quei tempi questo tipo di programmazione era tutt'altro che facile anche per chi era già esperto di librerie grafiche quali la OpenGL. Infatti, per poter scrivere algoritmi eseguibili su GPU, i problemi riguardanti il calcolo scientifico dovevano essere riformulati in termini di trasformazioni geometriche su triangoli e quadrilateri. Nel 2003, un team di ricercatori diretto da Ian Buck sviluppò Brook, il primo modello di programmazione adottato in larga scala per estendere il C al calcolo parallelo. Usando concetti quali flussi ( streams ), kernels e operazioni di riduzione, Brook permetteva di gestire le potenzialità delle GPU mediante un linguaggio di alto livello[7].inoltre, i programmi sviluppati in Brook non solo erano più semplici da scrivere, ma era anche 7 volte più veloce del codice scritto direttamente per GPU. Fabrizio Botta N86/008 Pagina 13 di 95

14 Venendo a contatto con i risultati del team di Ian Buck e delle potenzialità della programmazione GP-GPU, nvidia assunse lo scienziato per sviluppare una soluzione specifica per eseguire codice C sulle GPU nvidia. A risultato di questa collaborazione, nvidia nel 2007 pubblicò CUDA (Compute Unified Device Architecture), un modello di programmazione per il calcolo parallelo massivo dedicato alle schede da essa realizzate. CUDA, attraverso i suoi strumenti di sviluppo, permette la realizzazione di applicativi generici in grado di sfruttare la potenza di calcolo delle GPU, promettendo netti aumenti prestazionali rispetto alle CPUs[8]. È accessibile dai linguaggi C/C++, Fortran, MatLab e Python e permette l'integrazione con le librerie DirectX, OpenGL, utilizzate prevalentemente per la rappresentazione grafica, e OpenACC, OpenCL e DirectCompute, altre librerie per il calcolo parallelo GP-GPU. Mediante l'utilizzo delle sue routines, è possibile effettuare trasferimenti dalla RAM alla memoria grafica senza sforzo, realizzare ed eseguire moduli kernel su GPU e codice ibrido CPU-GPU, potendo sfruttare i vantaggi di entrambi i mondi. Il 12 ottobre 2012 [9], il CUDA Toolkit ha raggiunto la versione 5.0. Fabrizio Botta N86/008 Pagina 14 di 95

15 2. L'architettura CUDA 2.1 Introduzione all'architettura CUDA Come si può osservare nell'illustrazione 1, un'architettura in grado di eseguire codice CUDA è organizzata in una serie di Streaming Multiprocessors (SMs), unità di calcolo formati da una Control Unit e numerosi CUDA cores detti Streaming Processors (SPs). Ogni GPU attualmente è fornita con una memoria GDDR, a cui ci si riferisce con il nome di global memory. Questa memoria differisce dalla RAM della CPU, in quanto è essenzialmente il buffer di memoria per i frame usato per la grafica. Per le applicazioni grafiche, essa memorizza i fotogrammi dei video, le informazioni per le textures di oggetti tridimensionali, ma per il Fabrizio Botta N86/008 Pagina 15 di 95

16 calcolo numerico è una memoria ad alto trasferimento dati, posizionata in un chip dedicato, che ha più latenza di una tipica memoria di sistema. Nel calcolo parallelo massivo, la maggiore banda di trasferimento compensa la latenza. Fabrizio Botta N86/008 Pagina 16 di 95

17 2.2 La Compute Capability Per poter estendere le funzionalità offerte da CUDA, mantenendo comunque la retro-compatibilità, è stato introdotto un valore numerico, detto Compute Capability. Esso indica le funzionalità che possono essere eseguite sulla macchina per cui il proprio codice viene compilato: ogni scheda prodotta da nvidia dopo l'introduzione di CUDA è fornita di questo valore. 2.3 Anatomia di un programma CUDA Un programma CUDA esegue particolari procedure, dette kernels. Essi eseguono in parallelo istruzioni su più threads. Il programmatore può organizzare a livello logico i threads come blocchi di threads o griglie di blocchi di threads ed eseguire un particolare kernel su quell'insieme di threads. Ogni thread all'interno del suo blocco esegue un istanza del kernel ed è fornito di un Thread Id, relativo al suo blocco thread, di un program counter, della memoria locale del thread e di dati di input e output. Un blocco di threads è un insieme di threads concorrenti che possono cooperare tra loro attraverso delle barriere di sincronizzazione e la memoria condivisa relativa al blocco. Ogni blocco ha il suo Block ID relativo alla sua griglia. Una griglia è un array di blocchi di threads che eseguono lo stesso kernel, opera sui dati mediante la global memory ed è sequenziale rispetto all'ordine di esecuzione dei differenti kernels. Fabrizio Botta N86/008 Pagina 17 di 95

18 2.4 Le prime architetture CUDA enabled La prima architettura CUDA, la G80, aveva 86,4 GB/s di banda per la memoria, più 8 GB/s per la comunicazione con la CPU. In pratica, un programma in CUDA poteva trasferire contemporaneamente da e verso la memoria RAM di sistema fino a 4GB/s, per un totale di 8GB/s. La differenza tra la banda di memoria e quella di comunicazione sembra essere una limitazione importante. Tuttavia, la velocità di trasferimento fornita dall'interfaccia PCI Express è paragonabile alla velocità del FSB della scheda madre, che è impiegato per il trasferimento tra CPU e memoria centrale. Con l'evoluzione tecnologica degli standards, la velocità di trasferimento per entrambi i canali di comunicazione sta aumentando di anno in anno. Le principali innovazioni offerte dall'architettura G80 sono: La possibilità di programmare in C su GPU, senza dover imparare ulteriori linguaggi di programmazione o perdersi nei meandri della programmazione a basso livello; Ha una strategia di gestione dei threads scalabile, eliminando la necessità di operare manualmente sui registri. Introduce il modello SIMT (Single-Instruction Multiple-Thread), dove una singola istruzione viene eseguita parallelamente su più threads. Introduce il concetto di memoria condivisa, per ottimizzare la comunicazione inter-thread. Il chip G80 ha 16 SMs, ognuno dei quali con 8 SPs, per un totale di 128 cores di elaborazione. Ogni core è fornito con un'unità MAD (Multiply- Add), che effettua una moltiplicazione ed un addizione in un unico ciclo di Fabrizio Botta N86/008 Pagina 18 di 95

19 clock, più un'unità per la moltiplicazione. Inoltre, è possibile eseguire a livello macchina anche funzioni speciali, quali la radice quadrata e le funzioni trascendenti. Con 240 SPs, il chip GT200 superava 1 TeraFLOPS. Poiché ogni SP è ottimizzato per il multi-threading massivo, può eseguire migliaia di threads per applicazioni: una applicazione ben parallelizzata esegue tra i 5000 e i threads contemporaneamente su questo chip. Una CPU Intel supporta al giorno d'oggi dai 2 ai 4 threads per core. Una G80 supportava fino a 768 threads per SM, che arriva ai per questo chip. Una GT200 supporta 1024 thread per SM, per un totale di circa threads. Il livello di parallelismo pertanto, cresce ancora oggi enormemente. Fabrizio Botta N86/008 Pagina 19 di 95

20 2.5 L'architettura Fermi: una nuova generazione Illustrazione 4: Visione schematica dell'architettura Fermi. Mentre le precedenti GPU CUDA erano comunque progettate per essere delle schede grafiche con delle funzionalità aggiuntive, l'architettura Fermi introduce le prime vere GPU per il calcolo generico [10]: C'è un miglioramento delle performance nelle applicazioni che impiegano calcoli a doppia precisione; Viene introdotto l'ecc per la protezione dei dati da errori; Fabrizio Botta N86/008 Pagina 20 di 95

21 C'è una separazione reale tra memoria condivisa e memoria globale, rendendo effettivamente reale la gerarchia di memorie cache; Sono state introdotti miglioramenti sulle operazioni atomiche, fondamentali per la coerenza dei dati in applicazioni parallele; Viene introdotto il supporto al C++, rendendo sempre meno ampio il divario concettuale tra sviluppo di software per CPU e per GPU. Come previsto, è aumentata la dimensione dei warps (CUDA core per SM) a 32 CUDA cores e si è raggiunti la soglia di 16 SMs, ma dal punto di vista fisico i veri miglioramenti sono dati dall'introduzione del GigaThread Engine, che decuplica la velocità di cambio di contesto e permette l'esecuzione parallela di più kernels su SM differenti, e dai Streaming Multiprocessor di Terza Generazione. 2.6 Le innovazioni hardware dell'architettura Fermi Le ALUs dello Streaming Multiprocessor di Terza Generazione Ogni SM, infatti, è stato fornito di 32 CUDA cores, ognuno dei quali ha un'alu per le operazioni tra interi ed un'altra ALU separata quelle in virgola mobile. Quest'ultima, a partire dalla GT200, è stata inoltre adeguata allo standard IEEE , dando la possibilità di impiegare l'istruzione FMA (Fused Multiply-Add). Nel calcolo scientifico, nell'algebra lineare e nella computer grafica, è frequente eseguire operazione nella forma D= A B+C. Le GPU delle precedenti generazioni ottimizzavano questo calcolo con l'istruzione MAD, che eseguiva entrambe le operazioni in un unico ciclo di clock. Fabrizio Botta N86/008 Pagina 21 di 95

22 L'architettura Fermi implementa la nuona FMA, che effettua una moltiplicazione ed un addizione con un unico step di arrotondamento, evitando perdita di accuratezza dei dati sia per calcoli a 32-bit che a 64-bit. Mentre l'alu per interi era fornita di soli 24-bit di precisione, supporta ora i 32-bit per tutte le istruzioni, adeguandosi agli standard dei linguaggi di programmazione, ed è ottimizzata per i calcoli a 64-bit Le unità di load/store Ogni Streaming Multiprocessor presente nell'architettura Fermi ha 16 unità di load/store (carico/memorizzazione), per permettere il calcolo degli indirizzi di origine e destinazione dei dati per tutti i threads di un warp in 2 cicli di clock Le Special Function Units Indispensabili per il calcolo scientifico ad alte prestazioni, le funzioni trascendenti, come seno e coseno, sono calcolate mediante Unità per Funzioni Speciali (Special Function Unit, SFUs). Ogni SFU esegue un istruzione per thread per clock ed è disaccoppiata all'unita di dispatch, permettendo a quest'ultima di gestire le unità di esecuzione mentre la SFU è occupata Il Dual Warp Scheduler Lo Streaming Multiprocessor effettua lo scheduling dei threads a gruppi di 32, detti warps. Ogni SM dispone di due Warp Schedulers, ognuno dei quali ha un'unità per il dispatch delle istruzioni. Il doppio scheduler quindi seleziona due warps e rilascia un'istruzione da ogni warp ad un gruppo di 16 CUDA cores, 16 unità load/store o 4 SFUs. Molte istruzioni possono essere rilasciate simultaneamente, come quelle che interessano interi, accesso alla memoria o funzioni trascendenti. Solo le Fabrizio Botta N86/008 Pagina 22 di 95

23 operazioni a doppia precisione non posso essere rilasciate in contemporanea con altre. GPU G80 GT200 Fermi Transistors 681 million 1.4 billion 3.0 billion CUDA Cores Double Precision Floating None 30 FMA ops / clock 256 FMA ops /clock Point Capability Single Precision Floating 128 MAD 240 MAD ops / 512 FMA ops /clock Point Capability ops/clock clock Special Function Units (SFUs) / SM Warp schedulers (per SM) Shared Memory (per SM) 16 KB 16 KB Configurable 48 KB or 16 KB L1 Cache (per SM) None None Configurable 16 KB or 48 KB L2 Cache None None 768 KB ECC Memory Support No No Yes Concurrent Kernels No No Up to 16 Load/Store Address Width 32 bit 32 bit 64 bit Tabella 1: Confronto tra le architetture CUDA NVidia ParallelDataCache TM In applicazioni che impiegando il calcolo su GPU, non è sempre un vantaggio affidarsi alla memoria condivisa. Alcuni algoritmi si adattano naturalmente alla memoria condivisa, in altri c'è la necessità di una memoria cache, in altri ancora una combinazione tra le due. L'architettura Fermi possiede una gerarchia di memoria che si adatta alle varie tipologie di programmi sopra elencate. Mentre nelle tradizionali GPU, vi sono memorie read-only per le texture e memorie write-only per il processamento dei pixel, che si adattano con difficoltà ai comuni programmi C e C++, questa nuova architettura implementa un'unica pipeline di richiesta sia per i load che per gli store in memoria, con una cache L1 per SM e una L2 comune che gestisce tutte le operazioni (load, store, texture). Fabrizio Botta N86/008 Pagina 23 di 95

24 I 64 KB di cache L1, inoltre, sono configurabili in due modi: 48KB di Shared Memory con 16KB di cache o viceversa. Questa innovazione, che triplica le dimensioni della memoria condivisa, permette di poter triplicare le performances di quei programmi che fanno un uso molto estensivo di questo tipo di memoria. Per i programmi i cui accessi alla memoria non sono noti a priori, i 48KB di cache L1 migliorano le performance rispetto all'accesso diretto alla DRAM. La Fermi è fornita di ulteriori 768KB di cache L2 unificata, che migliorano le performance sia di quei programmi che non conoscono a priori le aree di memoria che verranno indirizzate, sia di quelli che impiegano più Streaming Multiprocessors per leggere dati comuni Supporto ECC per le memorie Il modello architetturale in questione supporta l'error Correcting Code per la protezione dei dati in memoria da alterazioni. Esso permette di correggere i singoli errori in memoria e individuare i doppi errori su ogni singolo bit nell'accesso ai dati, permettendo al programma di essere riavviato piuttosto che elaborare dati corrotti. A partire dai registri locali ai threads fino alla DRAM globale, tutte le memorie delle schede Fermi sono dotate di protezione ECC. Inoltre, tutte le schede nvidia sono adeguate allo standard PCI Express per i Controlli di Ridondanza Ciclici (CRC) con re-invio a livello datalink. Supporta l'analogo standard per le GDDR5 durante le trasmissioni di dati attraverso il bus di memoria Esecuzione concorrente di più threads La Fermi supporta la possibilità di eseguire kernels differenti sulla GPU in maniera parallela. Se, per esempio, un programma debba effettuare due Fabrizio Botta N86/008 Pagina 24 di 95

25 operazioni indipendenti che impiegano meno threads di quelli disponibili, è possibile eseguirli in parallelo per sfruttare tutta la potenza offerta. 2.7 I vantaggi dell'architettura Fermi nella programmazione Spazio di indirizzi unificato e completa compatibilità con il C++ Fermi, con il set di istruzioni PTX 2.0, implementa uno spazio di indirizzi che racchiude le tre diverse tipologie di indirizzo (locale al thread, locale al blocco e globale) per le operazioni load/store di accesso alla memoria. Con il PTX 1.0 le istruzioni load/store potevano essere indirizzate solo ad uno specifico spazio di memoria noto a tempo di compilazione. Con un spazio unificato di indirizzamento a 40-bit, è possibile indirizzare memoria nell'ordine dei Terabytes e il prossimo passo sarà un indirizzamento a 64- bit, già supportato a livello di astrazione logica. Con questo tipo di indirizzamento, la Fermi supporta programmi C++ puri. In C++, tutte le variabili e le funzioni risiedono in oggetti passati attraverso puntatori. Mediante un'unità di traduzione degli indirizzi, l'hardware Fermi permetterà di accedere correttamente all'area indirizzata dal puntatore, dinamicamente. Sono supportate anche le funzioni virtual, i puntatori a funzione, l'allocazione e deallocazione dinamica mediante new e delete e la cattura degli errori mediante try e catch. 2.8 Kepler: il futuro delle GP GPU In parte seguendo, in parte rivoluzionando gli sviluppi delle GPU, l'architettura Kepler [11] ha portato ulteriori miglioramenti, trasformando Fabrizio Botta N86/008 Pagina 25 di 95

26 sempre più le GPU in avanzati processori di calcolo parallelo ad alte prestazioni. Un'implementazione completa della Kepler GK110 [12] include 15 Streaming Multiprocessor (ora definiti SMX) e sei controller di memoria a 64-bit. Alcune schede possono avere meno SMX. Ogni warp, in questa architettura, ha 192 CUDA cores per SMX, ben 6 volte in più rispetto alla precedente Fermi. FERM I FERM I KEPLE R KEPLE R Compute Capability Threads / Warp Max Warps / Multiprocessor Max Threads / Multiprocessor Max Thread Blocks / Multiprocessor bit Registers / Multiprocessor Max Registers / Thread Max Threads / Thread Block Shared Memory Size Configurations (bytes) 16K 48K 16K 48K 16K 32K 48K 16K 32K 48K Max X Grid Dimension 2^16 1 2^16 1 2^32 1 2^32 1 Hyper Q No No No Yes Dynamic Parallelism No No No Yes Tabella 2: Confronti tra le potenzialità delle architetture Fermi e Kepler Le reali innovazioni, però, sono legate alla gestione dei kernel: kernels acquisiscono maggiore dinamismo, permettendo allo sviluppatore di richiamare kernels all'interno di kernels attraverso il Parallelismo Dinamico. Questo permette una suddivisione più ragionata della memoria impiegata e un controllo maggiore sul flusso di controllo. Con questa caratteristica, la GPU può decidere Fabrizio Botta N86/008 Pagina 26 di 95

27 autonomamente se è necessario effettuare nuovi calcoli, escludendo la CPU e quindi trasferimenti di memoria inutili. L'Hyper-Q permette invece di eseguire codice GPU da più cores simultaneamente, riducendo i tempi di attesa della CPU e sfruttando enormemente la GPU, fino ad un massimo di 32 connessioni Illustrazione 5: Parallelismo Dinamico simultanee tra CPU e GPU (la Fermi ne possiede solo una). L'unità di gestione della Grid (Grid Management Unit) è il supporto hardware alle nuove necessità riscontrate dal Parallelismo Dinamico: essa si occupa di gestire il rilascio delle nuove griglie computazionali ed effettuare scheduling su quelle esistenti. La nvidia GPUDirect TM è la capacità delle nuove GPU Kepler di scambiare dati tra GPU dislocate anche in server differenti collegati ad una rete, senza passare dalla CPU e dalla memoria di sistema. La caratteristica di DMA Remoto permette anche a dispositivi di terze parti come SSDs e schede di rete di accedere direttamente a più GPU Fabrizio Botta N86/008 Pagina 27 di 95

28 dello stesso dispositivo, diminuendo drasticamente le latenze di trasferimento dati e messaggi. Fabrizio Botta N86/008 Pagina 28 di 95

29 3. L'High Performance Computing per la Fisica delle Alte Energie (HEP) Una delle più interessanti applicazioni del calcolo parallelo massivo è dato dalle applicazioni per supercomputer di tipo scientifico. Per esempio, la comunità di ricerca nel campo della biologia tende ad uno studio sempre più a livello molecolare. Sebbene i microscopi possono essere considerati il più importante strumento di ricerca nella Biologia Molecolare, vi sono delle forti limitazioni, che possono essere aggirate con i modelli computazionali. Mediante questo tipo di simulazione, possiamo studiare il fenomeno molto più nel dettaglio e verificare molte più ipotesi di quelle che potremmo anche solo immaginare con solo gli strumenti tradizionali: le prospettive miglioreranno con il passare del tempo e con il costante aumento della potenza di calcolo. Inoltre, molti problemi di natura combinatoria e statistica che prima non erano affrontabili mediante algoritmi sequenziali (se non dopo un'ottimizzazione a livello matematico), possono essere ora parallelizzabili spesso con non troppa difficoltà e, in alcuni casi, come per gli ordinamenti, si è potuta raggiungere una complessità asintotica inferiore a quella ottimale per una macchina sequenziale. [13] Fino ad ora, molti esperimenti hanno giovato e giovano della potenza di calcolo parallelo CPU e/o GPU dei supercomputers di tutto il mondo, soprattutto nel campo della Fisica delle Alte Energie. Infatti, solitamente in un esperimento HEP (High Energy Physics), le collisioni tra particelle generano una notevole quantità di dati. Poichè si Fabrizio Botta N86/008 Pagina 29 di 95

30 parla di Terabytes e Petabytes di dati al secondo, è necessario effettuare subito delle scremature per poter memorizzare solo i dati interessanti. Pertanto, in tutto il mondo si sta valutando se il passaggio al calcolo parallelo massivo con le GPU possa realmente costituire un vantaggio, sia per il triggering che per le fasi successive di analisi dei dati. Per esempio, nel corso dell'esperimento NA62, si è cercato di utilizzare le GPU per il primo livello di triggering dei dati: uno dei punti cruciali in questo ambito è limitare al minimo il collo di bottiglia del trasferimento dati [14]. La fase in cui si colloca la sperimentazione effettuata in questo lavoro di tesi è nel campo del fitting: nel momento in cui i dati vengono analizzati dai fisici, il fit permette loro di studiare il fenomeno analiticamente trovando i parametri che meglio approssimano una funzione modello (scelta dallo scienziato in base alle esigenze dell'esperimento) che rappresenta il campione dei dati osservati. Con questi strumenti, è possibile per lo scienziato descrivere il fenomeno attraverso le variabili esaminate, determinare relazioni di casualità o concasualità tra varie caratteristiche di esso e ridurre eventuali rumori presenti nei dati di misura. Mediante queste analisi, è possibile confermare o confutare le tesi dell'esperimento effettuato. Parallelamente al mio lavoro di tesi, numerosi gruppi di ricerca stanno studiando le performance delle GPU nel campo del fit di dati. GooFit, per esempio, è un progetto di porting GPU della nota libreria RooFit, impiegata dal CERN per il fit dei dati prodotti dai loro esperimenti. Rispetto a RooFit, i test su dati di prova risultano essere oltre 100 volte più veloci. [15] Fabrizio Botta N86/008 Pagina 30 di 95

31 3.1 Principali esperimenti di Fisica Per avere un'idea più chiara sulla quantità di dati realmente prodotta dagli attuali esperimenti HEP, di seguito sono descritti alcuni tra i più importanti attualmente in corso Esperimento CMS L'esperimento CMS (Compact Muon Solenoid) si avvale dell'omonimo rivelatore di particelle del CERN di Ginevra e, insieme all'esperimento Atlas, ha come obiettivo la dimostrazione delle osservazioni sperimentali del bosone di Higgs, una particella subatomica di notevole importanza per la verifica del Modello Standard, l'attuale modello teorico che cerca di unificare e rendere coerenti tutte le conoscenze di fisica che l'uomo ha attualmente. a. Oltre al bosone di Higgs, gli obiettivi dell esperimento coprono una serie di ricerche fondamentali, come la ricerca di particelle supersimmetriche, lo studio della fisica del quark b, e la violazione della simmetria CP [16]. Ogni giorno solo questo esperimento, per riuscire a studiare questa particella, produce 40 Terabytes di dati al secondo. Per non incappare in problemi di memoria, i dati interessanti devono essere rapidamente scremati da quelli non interessanti e ciò deve essere effettuato nel minor tempo possibile: la parallelizzazione di questo processo rende l'analisi di questa mole di dati possibile. Dopo questa scrematura, il sistema produce solo 100 Megabytes di dati al secondo. L'analisi di questi dati viene effettuata dai centri di ricerca di tutto il mondo, attraverso l'uso della Grid EGEE, una gigantesca griglia computazionale che interessa e collega tutti i principali centri di ricerca accademica del mondo. Fabrizio Botta N86/008 Pagina 31 di 95

32 3.1.2 Esperimento ATLAS Atlas è un altro rivelatore di particelle del CERN: ATLAS è progettato per esplorare diversi tipi di fenomeni fisici che potrebbero essere rilevati nelle collisioni ad alta energia dell'lhc. Alcune di questi sono conferme o migliori misure del modello standard, mentre altri sono ricerche per nuove teorie fisiche. Questo esperimento è stato fondamentale per la rivoluzionaria scoperta del bosone di Higgs. Essa è una particella fondamentale per la comprensione del concetto di massa nella Fisica delle Alte Energie. Essa non è statica come nella Fisica classica e, secondo il Modello Standard, deriva dall'interazione tra particelle subatomiche con un vuoto che si ipotizzava essere riempito da bosoni detti di Higgs, dallo scienziato che ne ha indicato per primo l'osservabilità. Poiché questa particella è molto instabile, è stato possibile studiarla attraverso l'analisi dei prodotti delle interazioni e dei decadimenti delle particelle figlie. In questo contesto, il fit della massa e dell'energia delle particelle osservate è stato fondamentale per la scoperta del bosone. Infatti, studiando queste variabili in maniera analitica, è stato possibile determinare le anomalie che hanno permesso di identificare il bosone di Higgs. Parallelamente ed indipendentemente, anche il progetto CMS, sebbene il suo rivelatore sia meno adatto di quello dell'atlas, ha rilevato analoghe anomalie [17][18]. L'esperimento ATLAS ha, tra gli altri obiettivi, lo studio dell'asimmetria tra il comportamento della materia e dell'antimateria, conosciuta come violazione CP. Gli attuali esperimenti sulla violazione CP, come il BaBar e il Belle, non hanno ancora rilevato sufficienti violazioni nel modello standard per spiegare l'assenza dell'antimateria nell'universo. È possibile Fabrizio Botta N86/008 Pagina 32 di 95

33 che nuovi modelli fisici introdurranno delle violazioni CP aggiuntive, facendo luce sul problema; questi modelli possono essere verificati direttamente dalla produzione di nuove particelle oppure indirettamente dalle proprietà dei mesoni B (L'esperimento LHCb, ad essi dedicati, è probabilmente più indicato per il compito). Le proprietà del quark top, scoperto al Fermilab nel 1995, sono state finora scoperte solo approssimativamente. Grazie alla maggiore energia e al maggior numero di eventi, l'lhc produrrà un grande numero di quark top, permettendo ad ATLAS di compiere molte più misure sulla sua massa e sulle sue interazioni con le altre particelle. Queste misure forniranno informazioni indirette sui dettagli del Modello Standard, forse rivelando inconsistenze che porteranno a nuove teorie fisiche. Misure di analoga precisione verranno effettuate per altri tipi di particelle conosciute; per esempio, l'atlas potrà eventualmente misurare la massa del bosone W col doppio della precisione finora raggiunta [19]. Questo esperimento genera una quantità ancora più impressionante di dati: 25 Megabyte per 40 milioni di eventi al secondo, per un totale di 1 Petabyte/sec. L'esperimento si avvale di tre scremature: la prima avviene mediante un sistema elettronico interno al rivelatore e le altre due in un supercomputer che, attraverso elaborazioni parallele, seleziona i dati validi Dopo la terza selezione dei dati, l'esperimento produce 100MB/sec, ovvero 1 Petabyte all'anno ALICE: A Large Ion Collider Experiment È un esperimento dell'lhc di Ginevra in cui verranno studiate le collisioni fra nuclei di piombo. Fabrizio Botta N86/008 Pagina 33 di 95

34 Usando nuclei di atomi con molti protoni e neutroni, l'energia degli urti sarà tale che i fisici sperano di osservare un plasma di quark e gluoni: uno stato della materia esistito per pochi milionesimi di secondo subito dopo il Big Bang, a densità e temperature estreme [20]. L'esperimento necessita di un ingente quantità di risorse computazionali: infatti, in Finlandia, è stato attuato un progetto per la realizzazione di una Grid dedicata ad ALICE utilizzando il framework dedicato AliEn. Nel 2007, la CSC (Centrum of Scientific Computation) ha superato le 200 CPU dedicate solo a questo esperimento [21]. Fabrizio Botta N86/008 Pagina 34 di 95

35 4. La statistica parametrica e il metodo della massima verosimiglianza La statistica parametrica è una branca della statistica inferenziale che studia una popolazione supponendo di conoscere la legge di probabilità che la governa, ignorando il valore dei parametri della stessa. Nell'esempio che verrà poi applicato all'algoritmo, supponiamo che i dati osservati seguano l'andamento di una variabile normale N (μ, σ) con µ e σ incognite. Per trovare una stima di questi parametri, l'algoritmo si baserà in parte su un procedimento noto alla letteratura: il metodo della massima verosimiglianza (Maximum Likelihood Estimation, MLE). Supponiamo di avere un campione di n osservazioni indipendenti x 1, x 2,, x n provenienti da una distribuzione con una funzione di densità di probabilità f 0 (.), appartenente ad una certa famiglia di distribuzioni f (. θ), θ Θ (dove θ è un vettore di parametri per questa famiglia), chiamata modello parametrico ( o funzione modello), tale che f 0 = f (. θ 0 ). Il valore θ 0 è incognito ed è definito valore atteso del parametro. E' preferibile trovare lo stimatore θ il più vicino possibile al valore atteso θ 0. Per applicare il metodo della massima verosimiglianza, si specifica inizialmente la funzione di densità congiunta relativa al vettore aleatorio composto dalle singole osservazioni. Data l'ipotesi di indipendenza, f (x 1, x 2,,x n θ)= f ( x 1 θ) f ( x 2 θ) f (x n θ). Possiamo interpretare questa funzione da un altro punto di vista, considerando le osservazioni x 1, x 2,, x n parametri di questa funzione, mentre θ sarà la variabile della funzione che può assumere valori liberamente. Fabrizio Botta N86/008 Pagina 35 di 95

36 Questa funzione è detta funzione di verosimiglianza: n L(θ x 1, x 2,,x n )= f (x 1, x 2,,x n θ)= f ( x i θ). i=1 Nella pratica, dato che la funzione logaritmo è monotona e non influenza i massimi della funzione, è più conveniente lavorare con il logaritmo della funzione di verosimiglianza, detta log-likelihood: n ln L(θ x 1, x 2,,x n )= ln f ( x i θ). i=1 Il metodo, quindi, stima θ 0 trovando quel valore di θ che massimizza L (o ln L): θ mle arg max L(θ x 1,,x n ). θ Θ E' possibile analogamente lavorare con l'opposto della log-likelihood (chiamata Negative Log-Likelihood, o NLL), trovando quindi il minimo di quest'ultima: Sebbene il metodo garantisca la stima del parametro, non esistono soluzioni generiche applicabili matematicamente a qualsiasi classe di funzione.[22] La gran parte dei procedimenti impiegati per l'inferenza parametrica richiedano il calcolo di gradienti (ossia, vettori n-dimensionali contenenti le derivate parziali di una funzione ad n incognite), ma esistono alcuni metodi numerici che non richiedono particolari caratteristiche associate alla funzione, come derivabilità o continuità. L'algoritmo sviluppato per questa tesi utilizza proprio un metodo del genere, detto di Ricerca Casuale Controllata, spiegato più approfonditamente nel capitolo successivo. θ mle arg min θ Θ n ln f ( x i θ) i=1 Fabrizio Botta N86/008 Pagina 36 di 95

37 5. L'algoritmo di Price 5.1 Descrizione teorica Le caratteristiche essenziali dell'algoritmo di Price [23] (conosciuto anche col nome di Ricerca Casuale Controllata, o dall'inglese CRS, Controlled Random Search) sono descritte dal diagramma di flusso in Fig. 2. Specificando i limiti inferiori e superiori di ognuna delle n variabili e un numero intero N, definiamo uno spazio di variabili iniziale V e scegliamo casualmente N punti di test appartenenti allo spazio V. Valutiamo quindi la funzione di verosimiglianza f X per ogni tupla di parametri (indicati dalle coordinate dei punti precedentemente determinati) e memorizziamo i risultati in un array A. Ad ogni iterazione, calcoliamo un nuovo punto P, derivato dagli N punti di V e calcolato mediante una formula descritta nel dettaglio più avanti nella trattazione. Stabilito che il nuovo punto P sia interno ai limiti dello spazio V, valutiamo la funzione di verosimiglianza f X nel punto P, denotando lo stesso come f p. Comparando quest'ultimo ad f M, il massimo tra le valutazioni della funzione f X su V, se f p < f M, allora sostituiamo il punto M con P nell'array. Se al contrario, P è esterno allo spazio di valori V, allora P è scartato ed un nuovo punto viene scelto dall'insieme di possibili punti. Con il procedere dell'esecuzione dell'algoritmo, l'insieme degli N punti tenderà ad accumularsi intorno al minimo, inferiore del corrente f M. La probabilità che i punti convergano al minimo globale dipende dalla dimensione N, dalla complessità della Fabrizio Botta N86/008 Pagina 37 di 95

38 funzione f X, dalla natura dei limiti dello spazio V e dal modo con cui i punti di test vengono scelti. Poiché l'algoritmo ha come obiettivo la ricerca del minimo globale, l'esaustività nella ricerca è di maggiore importanza rispetto alla velocità di convergenza al potenziale minimo. Inoltre, se l'algoritmo è più efficiente della semplice ricerca random, la probabilità di successo ( f p < f M ) ad ogni tentativo dev'essere sufficientemente alta. L'algoritmo di Ricerca Casuale Controllata raggiunge un ragionevole compromesso tra i vincoli di ricerca e di convergenza, spesso incompatibili tra loro, definendo un insieme di potenziali successivi candidati, impiegando gli N punti inizialmente memorizzati. Ad ogni iterazione, vengono scelti n+1 punti R 1, R 2,, R n+1 distinti tra gli N (con N» n ) in memoria. Tra questi viene designato arbitrariamente un vertice R n+1 come polo e il nuovo candidato P è definito come punto immagine del polo rispetto al centroide, G, dei rimanenti n punti. Quindi: dove P, G e R n+1 rappresentano i vettori posizione, in uno spazio n- dimensionale, dei relativi punti. Il numero di modi differenti in cui possono essere scelti gli n+1 punti è rappresentato dalla combinazione di N elementi su n+1 posti, quindi N C n+1 e poiché la scelta di R n+1 come polo è arbitraria (un dato insieme di n+1 punti può essere generato in qualsiasi ordine), il numero totale di successivi candidati (tutti equiprobabili) associati ad una configurazione di N punti è: (n+1) N C n+1= ( N n+1). P=2 G R n+1 Fabrizio Botta N86/008 Pagina 38 di 95

39 5.2 Il diagramma di flusso Illustrazione 6: Diagramma di flusso dell'algoritmo teorico. Fabrizio Botta N86/008 Pagina 39 di 95

40 5.3 La scelta dei parametri Domini di esistenza L'imposizione di vincoli richede di limitare la ricerca del minimo ad un determinato spazio di valori: se P si trova fuori dallo spazio di dominio V, allora è scartato. Se si pongono criteri molto restrittivi, è necessario scegliere una dimensione della tabella ragionevolmente grande, per assicurarsi che ci sia un numero abbastanza grande di candidati validi da calcolare (i punti calcolati nella tabella soddisfano a priori le condizioni di dominio) La dimensione della tabella Più è grande il valore di N, più abbiamo possibili candidati per il minimo globale. D'altro canto, un N troppo grande rallenterebbe la convergenza dell'algoritmo. La scelta di questo valore dipende da molto dalla natura della funzione, dalla capacità di calcolo della macchina e dal numero di osservazioni. Attraverso l'esperienza, è possibile scegliere un valore ideale che concilia prestazioni ed accuratezza. Sebbene sia stato richiesto che N» n, è sufficiente che la relazione tra questi due valori sia lineare e non esponenziale. Questo parametro non influisce sulla precisione del valore stimato, che dipende esclusivamente dalla casualità Il criterio di stop L'algoritmo, dal punto di vista teorico, non presenta dei criteri di stop ben definiti. Fabrizio Botta N86/008 Pagina 40 di 95

41 6. Le librerie impiegate: CUDA vs Thrust 6.1 La libreria CUDA L'algoritmo implementato effettua parte dell'elaborazione su CPU e parte su GPU. Per poter controllare l'elaborazione su GPU, nel nostro caso specifico nvidia, si è fatto uso del kit di sviluppo CUDA, detto anche CUDA Toolkit. Esso è l'ambiente di sviluppo dedicato realizzato da nvidia ed è composto da uno speciale compilatore C/C++, librerie dedicate all'accesso alla memoria delle GPU, librerie matematiche ottimizzate e strumenti di diagnostica e debug. Per estendere le funzionalità del C/C++ al GP-GPU, la libreria CUDA offre delle funzioni e sintassi specifiche per la creazione di processi paralleli e per la gestione della memoria Allocazione della memoria Attraverso la funzione cudamalloc[24], è possibile allocare spazio di memoria sulla memoria globale della Gpu. Essa necessita di un tradizionale puntatore singolo: non è possibile utilizzare gli indirizzamenti indiretti alla memoria della Gpu. ESEMPIO CUDA MALLOC E' possibile utilizzare anche alcuni tipi di dati primitivi aggregati, ottimizzati per l'uso su GPU: essi sono int2, int3, float2, float3, double2, double3 e rappresentano arrays di 2 o 3 elementi, impiegati spesso per la rappresentazione di punti nello spazio. Sono preferibili agli equivalenti Fabrizio Botta N86/008 Pagina 41 di 95

42 arrays tradizionali di quelle dimensioni. Inoltre, la libreria CUDA mette a disposizione anche particolari CUDA Arrays. Della suddetta funzione, ne esistono le varianti cudamallocarray, cudamalloc3darray, per le variabili multidimensionali dedicate, cudamallochost, per l'utilizzo della pinned memory e cudamallocpitch, per l'ottimizzazione dell'allocazione di arrays tradizionali. Il compilatore effettua un'ulteriore ottimizzazione automatica: se una variabile è impiegata sempre come costante (con il prefisso const), essa verrà allocata nella constant memory, velocizzando gli accessi ad essa. Al termine di un programma, è necessario deallocare la memoria utilizzata su device, richiamando la routine cudafree[25] per ogni variabile utilizzata Trasferimenti dati La libreria CUDA permette, mediante la funzione cudamemcpy[26], di copiare un insieme di bytes in una variabile che risiede su GPU (d'ora in poi detta variabile device o, viceversa, trasferire il contenuto di una porzione della global memory in una variabile che punta ad una porzione di memoria principale (d'ora in poi detta variabile host ). ESEMPIO CUDAMEMCPY Processi parallelizzati In CUDA, le porzioni di codice che verranno parallelizzate su Gpu sono dette kernels. E' possibile identificare un kernel dalla parola chiave global, posta prima del tipo di ritorno: essa identifica una funzione che è possibile chiamare da una procedura eseguita su host, ma che effettuerà elaborazioni su device. In un kernel è possibile eseguire funzioni di tipo device, definire un insieme di parametri di input allo stesso modo di una tradizionale funzione, ma non Fabrizio Botta N86/008 Pagina 42 di 95

43 possono restituire alcun valore di ritorno. Pertanto, è necessario passare una variabile device per riferimento in modo tale da immagazzinare in essa i risultati delle elaborazioni. Nella versione 4.0 del CUDA Toolkit, non è possibile richiamare metodi device di classi all'interno di un kernel. E' stato reso possibile dalla versione 5.0, disponibile in rete, ma non utilizzata per questo progetto. E' possibile passare dati strutturati, ma non impiegare indirizzamenti indiretti ad aree di memoria: per questo motivo, una variabile strutturata passata per riferimento deve avere tutti i membri allocati staticamente. Le variabili dichiarate all'interno di un kernel possono puntare sia alla memoria globale, sia alla memoria condivisa (quando esse hanno la parola chiave shared posta prima del tipo dichiarato). Per l'identificazione del thread in cui è eseguito il processo, esistono le variabili dedicate threadidx, blockidx, che identificato mediante coordinate spaziali (x,y,z) il thread eseguito e blockdim che indica la dimensione dei blocchi di threads. L'indice del thread univoco rispetto a tutta la griglia è calcolabile mediante la formula (per componenti) index= blockidx blockdim+ threadidx. Comunemente, i dati da elaborare in un kernel sono memorizzati in arrays: utilizzando questa formula, è possibile determinare l'indice del dato dell'array (o degli arrays) che verrà elaborato in quel preciso thread. KERNEL DI ESEMPIO 6.2 La libreria Thrust Vantaggi Nonostante le funzioni messe a disposizione, la libreria CUDA tradizionale necessita di un approccio orientato alla memoria per sviluppare software Fabrizio Botta N86/008 Pagina 43 di 95