UNIVERSITA DEGLI STUDI DI PARMA TECNICHE DI PROGRAMMAZIONE PORTABILI PER LA SIMULAZIONE DI SISTEMI FISICI SULLE ARCHITETTURE GPU E MANY-CORE

Transcript

1 UNIVERSITA DEGLI STUDI DI PARMA DIPARTIMENTO DI FISICA E SCIENZE DELLA TERRA CORSO DI LAUREA TRIENNALE IN FISICA ANNO ACCADEMICO 2013/2014 TECNICHE DI PROGRAMMAZIONE PORTABILI PER LA SIMULAZIONE DI SISTEMI FISICI SULLE ARCHITETTURE GPU E MANY-CORE Relatore: Prof. Roberto Alfieri Candidato: Paolo Leoni Correlatore: Prof. Roberto De Pietri

2

3 Introduzione Nel 1965, un famoso postulato noto come Prima Legge di Moore[1] enunciava che le prestazioni dei processori, ed il numero di transistor ad essi relativo, raddoppiano ogni 18 mesi. Questo postulato, ha previsto correttamente lo sviluppo dei microprocessori fino al Come si può vedere dall immagine, il numero dei transistor con l andare degli anni ha effettivamente seguito le previsioni di Moore, ma lo stesso non si può dire per il clock, il quale nel ha visto un sostanziale arresto di crescita. Tutt ora (nel 2014) siamo ancora mediamente fermi ad un clock singolo pari a circa 3 Ghz, se la legge di Moore fosse ancora applicabile alla frequenza di clock oltre che al numero di transistor, dovremmo avere oggi clock superiori ai 10 Ghz. Il motivo per cui ciò non è avvenuto è principalmente dovuto ad un limite strutturale dei materiali di cui sono composti gli stessi processori. La presa di coscienza da parte dei produttori hardware che l epoca di Moore era cessata, ha determinato la nascita dell era dei multi-core, ovvero dei processori dotati di più core all interno di un singolo socket CPU 1. Dal punto di vista del programmatore, questo passaggio rappresenta un cambiamento significativo nello sviluppo del software. Mentre durante l epoca di Moore si poteva contare su un rapido e progressivo aumento delle prestazioni permesso semplicemente dallo sviluppo hardware, oggi per ottenere prestazioni sempre migliori lo sviluppo software deve essere più attento all implementazione e tenere conto di come l architettura mette a disposizione le risorse disponibili. Si è quindi assistito alla necessità di implementare, al fine di aumentare le prestazioni dei sistemi di calcolo, sistemi intrinsecamente paralleli anche a livello di singolo socket di silicio. 1 Nel Marzo 2005, sulla rivista online Dr. Dobb s Journal, fu pubblicato un celebre articolo sull argomento dal titolo Free lunch is over di Herb Sutter, reperibile all indirizzo web 3

4 In questo processo stanno emergendo due tendenze parallele: nella prima si integrano molti processori tradizionali ( core di calcolo) nel singolo elemento di silicio (ordine 8-16 per i processori consumer) fino al limite di ordine 100 core nei sistemi dedicati al calcolo come i coprecessori PHI della Intel; nella seconda, seguendo la tendenza di sviluppo introdotta dalle schede grafiche, vengono realizzati dei coprocessori matematici (definite GP-GPU, general purpose graphical processing units ) in cui è integrato su un sicolo socket di silicio un ordine di oltre 1000 unità di calcolo a virgola mobile destinate unicamente ad accelerare le prestazioni di calcolo numerico. Nell ambito degli HPC (High Performance Computing) di particolare interesse Scientifico, ci si trova davanti ad architetture spesso piuttosto complesse (e col tempo questa complessità tende ad aumentare), risulta quindi molto importante lo sviluppo di tecniche e strumenti che permettano un calcolo sempre più efficiente e veloce tramite questo particolare tipo di elaboratori. Linguaggi come OpenMP, OpenACC e OpenMPI vengono in aiuto al programmatore proprio per favorire lo sfruttamento delle risorse di device che, pur essendo installati nella stessa macchina, hanno architteture anche molto diverse tra loro, il tutto nel modo più trasparente e più semplice possibile. Lo scopo principale dello sviluppo tecnologico nel campo dell HPC è l aumento delle prestazioni di calcolo, il quale si può ottenere su vari livelli: Figura 1: rappresentazione dei diversi livelli di parallelismo teoricamente possibili per un HPC[2] cluster: tipicamente un HPC mette a disposizione più nodi connessi tra di loro, a questo livello si pone il problema di sfruttare in modo coordinato la potenza di calcolo dei nodi connessi, al fine di ottenere quello che viene chiamato weak scaling, ovvero la capacità di aumentare le dimensioni del problema studiato senza aumentare i tempi di calcolo del singolo nodo. In questo caso sono di notevole aiuto le API 2 di programmazione come OpenMPI. accelerators: gli acceleratori di calcolo sono oggetto di grande interesse attualmente, soprattutto quelli con architettura di tipo General Purpose GPU (GPGPU). 2 il termine API sta per Application Programming Interface, indica un insieme di librerie che permettono di interfacciarsi con il software. In questo caso particolare si intende un API in grado di integrarsi nel codice sorgente grazie a delle particolari funzioni di lbreria o direttive #pragma. 4

5 In generale si tratta di periferiche collegate direttamente ai nodi in grado di velocizzare notevolmente il calcolo rispetto all host. A seconda del tipo di hardware utilizzato, queste periferiche possono lavorare in modalità offload (accesso indiretto all acceleratore) o in modalità nativa (accesso diretto all acceleratore). Data la diversità di queste architetture rispetto all host, in questo caso si evidenzia molto l importanza di avere un API che permette di utilizzare l acceleratore in modo da mantenere un buon rapporto prestazioni / semplicità di utilizzo. node / socket /core / hyperthreads: in questo caso si tratta di suddividere il calcolo tra le unità di elaborazione del singolo nodo, ciò che vogliamo ottenere è, a parità di dimensione del problema, una diminuzione del tempo di calcolo, ovvero, lo strong scaling. Spesso già in questo modo è possibile ottenere un ottimo aumento delle prestazioni rispetto al calcolo seriale, ovvero si ottiene una buona scalabilità (anche su elaboratori tradizionali come le workstations). In questo caso il programmatore può appoggiarsi a strumenti come OpenMP, un tipo particolare di API in grado di gestire dinamicamente la suddivisione di processi con i quali può essere eseguito un particolare calcolo. Spesso i singoli core delle CPU possono inoltre eseguire più di una istruzione in parallelo (hyperthreading), ciò consente un livello di scalabilità in più (anche se in questo caso la scalabilità non è sempre buona). Un ulteriore ottimizzazione può essere data dall analisi della cosiddetta hardware affinity, ovvero una distribuzione dei processi che tenga conto della disposizione fisica delle componenti (livello socket). superscalar / pipeline / vector: questi livelli di ottimizzazione dipendono fortemente dall architettura, essi riguardano la capacità delle singole unità di elaborazione di gestire il calcolo al loro interno. In determinati ambiti, assume una certa importanza lo sfruttamento della cosiddetta vettorizzazione, ovvero la possibilità di fare molti calcoli nell unità di tempo grazie al fatto di poter gestire molti dati con una sola istruzione, questo è ciò che accade nelle unità SIMD delle CPU (Single Instruction Multiple Data). In questo senso l industria hardware ha come obiettivo l ottenimento di registri SIMD sempre più lunghi, in modo che la singola istruzione possa elaborare sempre più dati in un solo ciclo. Tuttavia è possibile sfruttare questa caratteristica solo se il calcolo è vettorizabile, e questo non sempre è possibile. In generale quando l utente si trova davanti ad un elaboratore HPC, si pone il problema di avvicinarsi il più possibile a quella che è la performance di picco. Questa tuttavia non è quasi mai facile da raggiungere, poiché per ottenere tale potenza il software andrebbe scritto in un linguaggio di basso livello (vicino al linguaggio macchina), in modo da ottenere il massimo dell ottimizzazione dalla particolare architettura che si sta utilizzando. Di fatto però, essa risulta un operazione spesso estremamente dispendiosa in termini di tempo e poco fattibile nella pratica. Si evidenzia quindi il problema di ottenere uno speedup che sia il più elevato possibile, mantenendo al tempo stesso un buon livello di semplicità in quello che viene chiamato porting del software. Il tempo speso per il porting sta acquisendo un importanza crescente nello sviluppo del software, per questo motivo è nata l esigenza di disporre di strumenti di programmazione che permettano al programmatore di sfruttare una buona parte delle performance di picco senza un elevato dispendio di tempo in termini di lavoro di scrittura del codice. In questo lavoro di tesi sono state studiate alcune delle nuove tecnologie di accelerazione di calcolo in funzione di un applicabilità orientata al porting di applicazioni scientifiche. Per poter eseguire lo studio è stato sviluppato un software ad hoc che potesse simulare (con le stesse caratteristiche algoritmiche di base, ma al tempo stesso in modo descrittivo rispetto ad un problema semplice) il comportamento di un software scientifico tipico destinato allo studio dell evoluzione nel tempo di un sistema descritto da equazioni differenziali alle derivate parziali discretizzate su una 5

6 griglia rettangolare o cubica. L algoritmo scelto è stato Game of Life di John Conway. Esso implementa una semplice regola di evoluzione e conserva tutte le caratteristiche necessarie al nostro studio, come la possibilità di separare la griglia di calcolo in sottodomini e di avere un controllo fine sull esecuzione. Poichè la densità di calcoli secondo l algoritmo originale è piuttosto bassa, abbiamo aggiunto una funzione di calcolo vettoriale il cui peso è parametrizzato con l obiettivo di testare la capacità di vettorizzazione nei diversi device studiati. In particolare, grazie alla possibilità di lavorare sul cluster Eurora messo a disposizione dal Cineca di Bologna, è stato possibile mettere a confronto la potenza di calcolo di un nodo convenzionale (2 CPU Sandy Bridge da 8 core Gflops), con due acceleratori di calcolo di ultima generazione: l acceleratore Intel Xeon PHI MIC (1,01 Tflops) e la GPGPU Nvidia Tesla K20 (1,1 Tflops), inoltre è stata studiata l integrazione di queste tecnologie in un architettura cluster multinodo. Parallelamente sono state studiate le problematiche di implementazione delle API di programmazione necessarie al calcolo parallelo, in particolare è stata studiata l integrazione di OpenMPI, OpenMP e OpenACC, focalizzandoci sull utilizzo di quest ultima, un API nata con l obiettivo di facilitare e uniformare la programmazione degli acceleratori (in particolare GPGPU). 6

7

8 1 Hardware Dal punto di vista dell hardware HPC, stiamo assistendo ad una transizione da sistemi seriali collegati in parallelo a sistemi, sempre collegati in parallelo, dotati di elevata accelerazione vettoriale, attraverso particolari device chiamati coprocessori o acceleratori di calcolo. Attualmente l industria dell hardware fornisce principalmente due possibilità di implementazione a livello di coprocessore: acceleratori di tipo manycore, in cui si cerca di inserire un elevato numero di core all interno di un architettura dalle caratteristiche simili a quelle tradizionali. In questo caso l aumento di prestazioni è dato da un numero mediamente elevato di unità di calcolo che conservino però anche molte delle caratteristiche computazionali dei processori tradizionali. In questo tipo di tecnologie il numero di core di calcolo in un device può essere dell ordine di 100 unità. acceleratori di tipo GPGPU, dove si cerca di sfruttare l elevato parallelismo hardware delle GPU. In questi device le singole unità di calcolo sono più elementari (non hanno a disposizione lo stessa sistema di componenti logici delle CPU) inoltre funzionano normalmente ad un clock più basso, tuttavia possono essere presenti in un numero notevolmente elevato sullo stesso device. Tipicamente in un acceleratore di tipo GPGPU è presente un numero di core di calcolo che può andare dalle 1000 alle 3000 unità. In questo lavoro di tesi, abbiamo cercato di esplorare entrambe le strade attraverso due esemplari ben rappresentativi delle due tecnologie: Intel Xeon PHI MIC come device manycore e Nvidia Tesla Kepler 20 come device GPGPU, il tutto mantenendo un confronto con la tecnologia convenzionale di riferimento, nel nostro caso il processore Sandy Bridge installato sull host utilizzato per i test. Figura 2: l andamento del numero delle unità di calcolo dei device con gli anni, le GPGPU tendono ad aumentarne sempre di più la quantità. Il device Intel MIC si posiziona in una zona intermedia poiché cerca di raccogliere entrambe le caratteristiche: elevato parallelismo del device ed elevata prestazione di calcolo del singolo core. 8

9 Figura 3: l andamento della potenza in Gflops delle singole unità di calcolo dei device lungo gli anni. Sulle GPGPU la potenza per singolo core aumenta abbastanza lentamente, poiché rispetto a tale tecnologia l industria si sta focalizzando sull aumento del numero di unità di calcolo all interno dello stesso socket. 9

10 1.1 CPU Intel Xeon Sandy Bridge Questo processore possiede molte caratteristiche del tutto simili ai processori in commercio comunemente utilizzati nelle workstation. Come per i modelli equivalenti nelle workstation, anche i Sandy Bridge possono in linea teorica aumentare le prestazioni grazie all hyperthreading, tecnologia che consente al processore di elaborare istruzioni in più thread separati nello stesso core. Questi particolari processori possono gestire fino a 2 thread per ogni core fisico, ciò significa che ogni nodo può teoricamente gestire fino a 32 processi separati. Inoltre una differenza importante rispetto alle CPU più convenzionali, è la lunghezza dei registri di elaborazione delle unità SIMD, che in questo caso arriva fino a 256 bit (questa caratteristica è anche nota come Advanced Vector extensions, nei processori tradizionali invece la lunghezza dei registri SIMD è di 128 bit). Le due CPU Sandy Bridge sull host sono collegate da un bus QPI (Intel Quickpath Internconnect), un bus seriale introdotto da Intel nel 2008 in grado di raddoppiare la banda di comunicazione tra processore e chipset rispetto alla tecnologia precedente, il Quad Pumped. Figura 4: schema di connessione dei due processori Intel Xeon Sandy Bridge sullo stesso nodo. La velocità del bus QPI è fondamentale affinché le due CPU possano lavorare insieme senza perdita di prestazioni. La performance di picco di questo processore per i calcoli in doppia precisione è di 134,4 Gflop/s. 10

11 1.2 L acceleratore Intel Xeon PHI (MIC) L acceleratore Intel Xeon PHI MIC (Many Integrated Core)[3], nasce con l intento di creare un hardware di tipo manycore che potesse però essere programmabile in modo simile alle CPU convenzionali. Ciò è dovuto al fatto che fondamentalmente l architettura del device risulta molto simile a quella dell host. Alcune caratteristiche lo rendono particolarmente interessante per il calcolo: Ogni acceleratore MIC è equipaggiato con 60 core fisici con clock da 1Ghz. Ogni core sul MIC è in grado di gestire fino a 4 thread separati, la capacità teorica di parallelizzazione del device quindi arriva fino a 240 thread. Le unità SIMD (Single Instruction Multiple Data) di ogni core possono elaborare fino a 512 bit di dati con una singola istruzione (capacità doppia rispetto alle SIMD dei processori Sandy Bridge). Questa caratteristica rende i MIC particolarmente adatti per i calcoli che utilizzano la vettorizzazione. La memoria dedicata è di 8 Gbyte. Oltre alle caratteristiche più strettamente inerenti al calcolo, il MIC si rivela interessante anche per la sua notevole versatilità. A differenza degli acceleratori GPU, questo tipo di coprocessore è in grado di comportarsi quasi come se fosse un host tradizionale, questo grazie al fatto che al suo interno fa funzionare un micro-sistema operativo basato su linux che è in grado di comunicare con l esterno come se si trovasse su una rete locale (attraverso uno stack virtuale TCP/IP che comunica tramite il bus PCIe). Questa particolare caratteristica ci ha permesso di poter utilizzare il MIC nella cosiddetta modalità nativa 3, ciò significa che in questa modalità (diversamente da quello che accade con le GPU) sostanzialmente tutto il software viene gestito dal coprocessore, proprio come se fosse un host. Questo approccio in un certo senso semplifica molto il porting di un software su questa architettura (anche se come vedremo non ne elimina del tutto le problematiche), ma di fatto in questo modo l host viene ridotto a semplice tramite tra l acceleratore ed il resto della rete. La performance di picco in doppia precisione per questo device è di 1011 Gflop/s. 3 l acceleratore Intel MIC può essere utilizzato anche in modalità offload, ma questo approccio con il MIC si è dimostrato decisamente più complicato rispetto alla modalità nativa. Motivo per cui in questo lavoro di tesi ci siamo focalizzati principalmente su di essa. 11

12 Figura 5: schema di connessione dell acceleratore Intel Xeon PHI MIC. Lo stack virtuale TCP/IP consente un utilizzo molto trasparente del device, il quale in questa modalità, è raggiungibile tramite tradizionale connessione via ssh. 12

13 1.3 L acceleratore Nvidia Tesla Kepler 20 L acceleratore Nvidia Tesla Kepler 20 è un modello di GPGPU pensato appositamente per incrementare le performance di calcolo. A livello di architettura, essa conserva gran parte delle peculiarità che contraddistinguono le GPU (fatta eccezione per l uscita video, che nella serie Tesla è assente). Vi è una profonda diversità tra questo tipo di hardware e quello dell host o anche solo del MIC. Capirne le differenze è fondamentale per poter affrontare al meglio le problematiche che si incontrano lungo tutto il lavoro di porting. Mentre la CPU rappresenta un entità di calcolo autonoma, la quale, oltre ai core, monta anche un complesso sistema di unità di controllo interno che le consentono un organizzazione molto efficiente e versatile del lavoro computazionale, la GPU d altra parte non potrà mai essere svincolata da una CPU che le impartisca dei comandi. Per questo principale motivo la programmazione su GPGPU necessita di una particolare attenzione. Figura 6: una rappresentazione stilizzata delle differenze di architettura tra CPU e GPU. Nella GPGPU le unità di controllo occupano uno spazio molto ridotto rispetto alla CPU, poiché prevale la necessità di avere un elevatissimo numero di core di calcolo. Le GPU in generale, sono state fin dall inizio appositamente pensate con una grandissima attitudine al calcolo parallelo, ciò è dovuto al loro scopo originario, che è quello di eseguire un enorme mole di calcoli su oggetti grafici 3D in tempo reale. Tipicamente, una GPGPU attualmente in commercio contiene un numero totale di core di elaborazione che può essere dell ordine di 10³. Questi piccoli core (il cui clock è di solito relativamente basso, intorno ai 600 Mhz), sono raggruppati in macro-sistemi di elaborazione, detti Stream Multi Processor (o SMX), i quali contengono, oltre ai core, anche le altre componenti necessarie alla gestione dei dati, come il warp scheduler, il register file, e i diversi tipi di memoria alle quali possono accedere i thread dello stesso SMX. Nel nostro caso particolare, la K20 può distribuire il calcolo su 2496 core, divisi tra 15 SMX. Per i calcoli in doppia precisione, la performance di picco dell acceleratore Nvidia Tesla K20 è di 1170 Gflop/s. 13

14 Figura 7: uno schema dell acceleratore K20. Gli SMX della scheda sono stati pensati per poter lavorare separatamente rispetto agli altri. Figura 8: schema dettagliato di uno dei 15 SMX che compongono la K20. Nello stesso SMX, i core della GPGPU si trovano in una condizione di work sharing poiché condividono lo stesso blocco di memoria. 14

15 Mentre con l acceleratore Intel MIC potevamo scegliere tra due modalità di utilizzo, in questo caso la K20 è utilizzabile esclusivamente in modalità offload. La modalità offload, implica che solo una parte del software venga effettivamente trasferita ed eseguita dall acceleratore, in particolare tutte le funzioni eseguite in offload si chiamano generalmente kernels. I kernels possono essere sia di calcolo che di trasferimento dati, ma in generale sono comunque chiamati dall host ed eseguiti dal device. Figura 9: rappresentazione della modalità offload per le GPU. Il collo di bottiglia nella timeline di esecuzione è rappresentato dall accesso alla memoria principale del sistema, condizionato dalla velocità del bus PCIe. C è un evidente collo di bottiglia nell utilizzo di questo acceleratore, che è rappresentato dal bus PCIe attraverso il quale è collegato all host. Benchè il trasferimento dati tra device e host possa raggiungere gli 8 GB/s, l eccessivo numero di trasferimenti durante il calcolo può influire negativamente sulle prestazioni, questo problema si può in parte risolvere a seconda delle situazioni sfruttando la capacità del device di fare overlap tra i kernels. L overlap permette al device non solo di eseguire contemporaneamente il calcolo di due funzioni diverse, ma anche di calcolare e trasferire dati in modo asincrono, facendo risparmiare una notevole quantità di tempo di esecuzione. Anche in questo caso è necessario porre grande attenzione a come si imposta l asincronìa dei kernels, poiché questa potrebbe altrimenti produrre risultati numerici scorretti. 15

16 1.4 Il prototipo EURORA Per effettuare test su hardware così differente, è stato di particolare aiuto l utilizzo del prototipo HPC Eurora (EURopean many integrated core Architecture), messo a disposizione dal CINECA 4 di Bologna. Eurora nasce con l obiettivo di valutare le nuove architetture per i sistemi tier-0 5 di prossima generazione, tra cui gli acceleratori di calcolo. Eurora è un cluster composto da 65 nodi, di cui uno di login, ognuno dei 64 nodi di computazione è composto da un host (2 CPU Intel Xeon Sandy Bridge da 8 core) e da due acceleratori. 32 nodi utilizzano due acceleratori Intel Xeon PHI (MIC), mentre gli altri 32 sono accoppiati a due acceleratori Nvidia Tesla Kepler nodi utilizzano 2 CPU SandyBridge E con clock pari a 2 Ghz, mentre gli altri 32 utilizzano 2 CPU SandyBridge E5-2687W con clock pari a 3.10 GHz. La Ram a disposizione della maggior parte dei nodi (58) è di 16 Gb, nei nodi restanti (6) è possibile allocare fino a 32 Gb. Tutti i nodi sono interconnessi tra loro da una rete Qlogic Infiniband, in grado di garantire una connessione a banda elevata e bassa latenza. Lo storage dei dati viene effettuato tramite dischi SSD da 160 Gbyte (uno per nodo). Dal punto di vista del supporto software, sulla macchina è stato installato il sistema CentOS 6.4 con il kernel Linux ed il software PBSpro 12.2 per la gestione delle code di esecuzione sul cluster. I compilatori disponibili sul cluster Eurora sono tre: The Portland Group, Inc. C Compiler v con framework OpenMPI v Intel C Compiler v con frameowrk Intel MPI v GNU Compiler Collection v con framwork Open MPI v il CINECA è la maggiore istituzione di supercomputing in Italia, è gestita da un consorzio di diverse Università italiane (69) e istituti di ricerca. 5 tier-0 indica il livello più alto in una classificazione di HPC ad alte prestazioni di calcolo e alta capacità. 16

17

18 2 Le API utilizzate Parallelamente all evoluzione dell hardware, anche l approccio rispetto alla programmazione deve potersi evolvere per mantenere la tecnologia sfruttabile ad un buon livello di rendimento. Per fare il porting su un cluster come Eurora, è necessario integrare nello stesso codice due diversi modelli di calcolo 6 : un modello a memoria distribuita (o sistema distribuito) e un modello a memoria condivisa. Figura 10: rappresentazione di un sistema a memoria distribuita (a) e un sistema a memoria condivisa (b). Il modello a memoria distribuita presuppone un sistema in cui i nodi di calcolo sono collegati da una rete decentralizzata, nella quale lavorano autonomamente ad una porzione del problema da risolvere utilizzando i dati che sono stati trasferiti nella propria memoria locale. L esecuzione viene svolta da processi in grado di comunicare tra loro attraverso lo scambio di messaggi, anche e soprattutto tra nodi diversi nella stessa rete. Questa operazione viene effettuata grazie ad una libreria apposita in grado di gestire questo scambio di messaggi attraverso il protocollo MPI (Message Passing Interface), nel nostro caso in particolare è stata utilizzata la libreria OpenMPI. Il modello a memoria condivisa invece, affronta il problema in un sistema che vede una serie di processi che devono svolgere l elaborazione condividendo la stessa memoria fisica (tipicamente all interno di un singolo nodo di calcolo). Generalmente si ha a disposizione un architettura con più unità di elaborazione, l API di programmazione in questo caso si occupa della suddivisione del poblema in diversi thread di esecuzione sullo stesso nodo (o device), in modo da distribuire il carico di lavoro tra le unità di calcolo fisiche (core). I thread in questo caso possono accedere alla stessa porzione di memoria principale sul device. Nel nostro caso particolare, dovendo interagire con due tipi di architetture particolarmente differenti, è stato necessario integrare per questo scopo due API: OpenMP per il calcolo su acceleratore MIC (modalità nativa) e su host, e OpenACC per il calcolo su GPGPU. 6 il codice senza alcuna modifica è in grado di funzionare, ma utilizzando un solo core ed un solo nodo per l intera esecuzione del programma. Questa modalità, che è quella più tradizionale, viene anche detta modalità seriale e, come vedremo, risulta particolarmente lenta se paragonata alla versione parallela. 18

19 Per poter sfruttare appieno le potenzialità di un cluster come Eurora, è necessario far interagire i due modelli sulla stessa macchina, in modo che il calcolo venga svolto sfruttando il massimo delle risorse a disposizione. 19

20 2.1 OpenMPI OpenMPI rappresenta un implementazione libera del protocollo MPI, gli obiettivi dello standard sono quelli di ottenere un aumento delle performance di calcolo, una buona scalabilità e portabilità[4][5]. Figura 11: struttura base di un programma MPI. Anche nel modello MPI sono presenti un momento iniziale in cui vengono creati e suddivisi i processi di lavoro, ed un momento finale in cui questi si riuniscono nel processo principale. Nel protocollo MPI la comunicazione tra i processi avviene attraverso lo scambio di messaggi. Lo standard definisce come il dato deve essere rappresentato, come specificare il destinatario del messaggio e come implementare la comunicazione. I tipi di dato sono definiti dallo standard MPI, nel quale sono definiti i tipi corrispondenti per i dati più comuni (e.g., MPI_INT, MPI_DOUBLE_PRECISION, MPI_CHAR), mentre per costruire tipi di dato più complessi esistono primitive apposite. Il destinatario di un messaggio viene identificato specificando un comunicatore, il tag e il rank. Il comunicatore identifica un contesto di comunicazione al quale appartiene un gruppo di processi, il comunicatore di default è MPI_COMM_WORLD, che è quello che indica il contesto di comunicazione con tutti i processi. Il tag è un etichetta che permette di caratterizzare ulteriormente il messaggio all interno del comunicatore. Il rank invece è un numero intero che identifica in maniera univoca il processo destinatario. MPI può svolgere la comunicazione tra processi in diversi modi, di default viene utilizzata la modalità bloccante e asincrona. La modalità bloccante è quella in cui il processo attende il completamento della primitiva la quale, se è asincrona, non attende la risposta dal processo ricevente. Le funzioni di libreria più comuni per lo scambio di messaggi sono MPI_Recv(), MPI_Send() e MPI_Sendrecv(). Nel nostro caso specifico ci siamo appoggiati a quest ultima per lo scambio di messaggi tra i nodi di calcolo. La principale differenza rispetto alle altre due, è che la funzione MPI_Sendrecv() combina in una 20

21 Figura 12: rappresentazione grafica dei comunicatori MPI Figura 13: rappresentazione di una comunicazione MPI tra due processi attivi su nodi differenti. sola chiamata l invio di un messaggio ad un destinatario e la ricezione di un altro messaggio da un altro processo. I parametri richiesti dalla funzione sono gli stessi di MPI_Recv() e MPI_Send(), ma rispetto a queste ultime MPI_Sendrecv() offre il vantaggio di lasciare al sottosistema di comunicazione il compito di controllare le dipendenze tra invii e ricezioni evitando così il verificarsi di un possibile deadlock 7. Nella modalità utilizzata da noi per effettuare i test, viene creato un processo MPI per ogni nodo di calcolo e ogni processo comunica tramite la funzione MPI_Sendrecv(). 7 il deadlock è quella particolare condizione in cui due o più processi si bloccano a vicenda a causa del fatto che ognuno di essi aspetta che l altro abbia finito. 21

22 2.2 OpenMP OpenMP è un API[6] utile per agire sul cosiddetto strong scaling delle performance, ovvero la capacità di eseguire lo stesso problema in minor tempo. Tipicamente ci si trova di fronte ad un architettura multi- o many-core a memoria condivisa, con il problema quindi di poter sfruttare in modo semplice le risorse messe a disposizione dall hardware. L approccio seguito da OpenMP (e come vedremo anche da OpenACC) è quello delle pragma, sostanzialmente questo consiste nell inserire all interno del codice delle particolari direttive di preprocessore per fornire delle richieste al compilatore sul tipo di operazioni da svolgere in determinate parti del programma. Queste direttive operano quasi come se fossero dei suggerimenti, il compilatore le valuta e, se sono compatibili con lo standard utilizzato, ne verifica l attuabilità. Se la richiesta è fattibile, durante l operazione di linking il compilatore inserisce nel binario il codice corrispondente alla richiesta. Tipicamente l utilizzo di OpenMP all interno del programma è finalizzato alla suddivisione (fork) del carico di lavoro di una o più funzioni del programma in thread di esecuzione, da inviare alle diverse unità di calcolo del sistema utilizzato. Una volta che la funzione è stata calcolata, i thread vengono riuniti nel processo principale (join) ed il programma prosegue. Figura 14: una rappresentazione della suddivsione in thread OpenMP all interno di un programma. A seconda di come sono inserite le direttive, possono essere parallelizzati uno o tutti i task. Prendiamo come esempio il seguente semplice programma: #include <stdio.h> int main(void) { #pragma omp parallel printf("hello, world.\n"); return 0; } La direttiva #pragma omp parallel indica la richiesta al compilatore di suddividere se possibile in n-processi lo statement che segue (utilizzando le parentesi graffe può essere indicato anche un insieme di statement). Il numero di processi con cui viene suddiviso il task, viene letto dalla variabile d ambiente OMP_NUM_THREADS,ma può essere anche settato all interno del programma tramite la funzione di libreria omp_set_num_threads(n) 8. 8 per l utilizzo delle funzioni di libreria è necessario includere il file <omp.h> nell header del programma. 22

23 Il risultato è che viene inviata la stringa Hello, world. allo standard output un numero di volte pari ai processi con cui è stato eseguito il programma. Uno dei problemi su cui si deve porre attenzione nell applicare queste direttive è la race condition, ovvero quel fenomeno per cui ogni processo cerca di svolgere la funzione nel minor tempo possibile, inviando così in output il risultato senza attendere che l altro abbia terminato. Questo fenomeno di asincronìa tra processi che lavorano sullo stesso task fa parte di quell insieme di problematiche di cui tenere conto quando si fa il porting di un applicazione, altrimenti si corre il rischio di ottenere dei risultati non corretti. Uno degli strumenti che ci permettono di risolvere questo problema è la barrier, la quale può essere sia implicita che esplicita. La barrier è un punto del codice in cui il sistema attende che tutti i processi abbiano terminato le operazioni prima di procedere, in questo modo il programma prosegue solo se tutti i processi hanno completato il task assegnato, garantendo così un risultato coerente. Una barrier è implicita se ad esempio utilizziamo la direttiva #pragma omp parallel (come nell esempio precedente), con quest ultima il compilatore inserisce una barrier alla fine dell elenco di statement definito dalla pragma, in questo modo non si verificano race condition. In alternativa la barrier può essere esplicitata (ad esempio se dobbiamo risincronizzare i processi all interno della stessa parallel), utilizzando la direttiva #pragma omp barrier. Il numero di processi con cui suddividiamo i task deve necessariamente tenere conto dell architettura se non si vogliono degradare le prestazioni. In un sistema con 2 core ad esempio, la suddivisione in 2 processi può essere una scelta ottimale, d altraparte se aumentiamo di molto il numero di processi rispetto al numero dei core fisici, si rischia di degradare le prestazioni a causa dell overload di operazioni che si genera nella CPU durante l esecuzione. Fisicamente l hardware è capace di gestire un numero limitato di operazioni, se si richiede una suddivisione dei task eccessiva, una parte delle operazioni verrà svolta inevitabilmente in modo seriale, perdendosi così ogni vantaggio derivante dall approccio parallelo. Se la CPU in questione supporta l hyperthreading (ad esempio è capace di processare 2 thread per core), può essere conveniente in questo caso suddividere i task in 2 processi per core anziché 1 per poter aumentare le performance. Il potenziale di questa tecnologia non è sempre sfruttabile, ciò dipende molto dal tipo di calcolo che il processore deve svolgere e dal processore stesso. Nei nostri test ad esempio abbiamo potuto constatare che l acceleratore Intel MIC gestisce meglio l hyperthreading sul singolo core di quanto faccia la CPU Intel Sandy Bridge del nodo (host), motivo per cui per i test eseguiti sul nodo abbiamo deciso di non saturare completamente i thread del core, al contrario dei test effettuati su Intel MIC. 23

24 2.3 OpenACC Da quando è nata l idea di svolgere calcoli su sistemi GPGPU, si è contemporaneamente creata la necessità di creare un linguaggio che permettesse al programmatore di interfacciarsi con le risorse di questo tipo di hardware, molto diverso dai sistemi convenzionali. Per le GPGPU prodotte da Nvidia, venne creato nel 2006 un estensione ai linguaggi di programmazione più diffusi (come C, C++ o Fortran) chiamata CUDA (Compute Unified Device Architecture). 9 Per le GPGPU di altri produttori, è invece possibile utilizzare un linguaggio (dall approccio molto simile a CUDA) chiamato OpenCL. Sviluppato inizialmente da Apple, OpenCL divenne poi proprietà nel 2008 di un consorzio senza scopo di lucro, il Khronos Group. Contrariamente a CUDA, OpenCL può essere utilizzato su un più ampio spettro di architetture, dalle CPU convenzionali fino alle GPGPU. Sia CUDA che OpenCL, sono stati concepiti con l obiettivo di accelerare il calcolo, basandosi sul concetto di offload del kernel di esecuzione. Queste estensioni permettono di ottenere un notevole controllo delle risorse di calcolo, e quindi di raggiungere un buon livello di ottimizzazione, ma ci sono fondamentalmente due controindicazioni importanti al loro utilizzo: Il codice scritto con queste estensioni è utilizzabile solo con architetture compatibili, questo è particolarmente vero per CUDA, sfruttabile solo con le GPU Nvidia. Questo aspetto limita di molto la portabilità del codice. Essendo un linguaggio di livello intermedio, l ottimizzazione si paga con un elevata difficoltà di integrazione e manutenzione del codice. In sostanza il software diventa piuttosto complicato da sviluppare e da mantenere. Con l obiettivo di creare un interfaccia di programmazione che garantisse una migliore portabilità del codice mantenendo un livello di complessità più gestibile, nel 2012 venne creata una corporation no profit con il contributo di diverse compagnie. Questa interfaccia, chiamata OpenACC (Open Accelerator), ha mantenuto volutamente molti tratti simili ad OpenMP, questo anche per facilitare i programmatori che avessero già una buona esperienza con questo genere di linguaggio. Anche OpenACC infatti, si basa sull utilizzo delle direttive pragma, affiancate però in questo caso dalla parola chiave acc. La funzione svolta da OpenACC è assimilabile a quella di un traduttore di funzioni. Quando un codice scritto con OpenACC viene compilato, viene specificato al compilatore anche il tipo di architettura su cui deve essere avviato il programma in offload, in questo modo quando il compilatore rileva delle direttive OpenACC cerca di tradurre le porzioni di codice che vogliamo eseguire sull acceleratore nei kernel associati al linguaggio di più basso livello (come CUDA o OpenCL). Se ad esempio vogliamo compilare OpenACC per un architettura Nvidia, il compilatore cercherà automaticamente di tradurre ciò che noi abbiamo indicato come kernels OpenACC, in kernels CUDA. Dopo questa operazione il codice CUDA viene effettivamente compilato tramite il driver Nvidia in codice macchina compatibile con la GPU Nvidia. 9 con Cuda viene di solito indicata anche l architettura delle GPU Nvidia di nuova generazione, un numero di versione permette inoltre di associare l architettura al modello corrispondente (e.g. Kepler 20 supporta l architettura Cuda 3.5) 24

25 Il passaggio di traduzione tra OpenACC e CUDA/OpenCL viene svolto grazie ad un sistema di riconoscimento che è in grado di rilevare i loop adatti alla parallelizzazione e successivamente di trovare la configurazione ottimale dei parametri hardware per fare sì che l accelerazione avvenga in modo efficiente. Figura 15: diagramma del processo di compilazione di un codice scritto con OpenACC. Di fatto, OpenACC rappresenta un linguaggio di traduzione, che permette di generare in modo più semplice funzioni CUDA o OpenCL. Le estensioni CUDA e OpenCL utilizzano per loro conto una rappresentazione dei sottoprocessi abbastanza diversa dai processori convenzionali. Questa rappresentazione è stata pensata con l obiettivo di suddividere il problema di calcolo compatibilmente con l architettura del device. In OpenACC, le entità virtuali utilizzate per indicare i processi di calcolo sul device sono indicate come gang, workers e vector. Queste rappresentazioni hanno un loro corrispettivo nell estensione associata (che sia OpenCL o CU- DA), il programmatore quindi dovrà tenerne conto nel caso dovesse agire manualmente su questi parametri. Tipicamente le gang, corrispondono ai block del codice CUDA e ai work-group nel codice Open- CL, mentre i vector corrispondono ai thread nel codice CUDA e ai work-item nel codice OpenCL. I workers, vengono invece rappresentati come un insieme di thread su CUDA (anche chiamato warp) o come un insieme di work-item su OpenCL. 25