General-Purpose Computing on Graphic Processing Unit (GPGPU): metodi e tecnologie per lo sviluppo di applicazioni

Microprocessori basati su singolo processore (CPU), hanno visto una rapida crescita di performances ed un abbattimento dei costi per circa venti anni. Questi microprocessori hanno portato una potenza di calcolo nell’ordine del GFLOPS (Giga Floating Point Operation per Second) sui PC Desktop e centinaia di GFLOPS su clusters di server. Questa ascesa ha portato nuove funzionalità nei programmi, migliori interfacce utente e tanti altri vantaggi. Tuttavia questa crescita ha subito un brusco rallentamento nel 2003 a causa di consumi energetici sempre più elevati e problemi di dissipazione termica, che hanno impedito incrementi di frequenza di clock. I limiti fisici del silicio erano sempre più vicini. Per ovviare al problema i produttori di CPU (Central Processing Unit) hanno iniziato a progettare microprocessori multicore, scelta che ha avuto un impatto notevole sulla comunità degli sviluppatori, abituati a considerare il software come una serie di comandi sequenziali. Quindi i programmi che avevano sempre giovato di miglioramenti di prestazioni ad ogni nuova generazione di CPU, non hanno avuto incrementi di performance, in quanto essendo eseguiti su un solo core, non beneficiavano dell’intera potenza della CPU. Per sfruttare appieno la potenza delle nuove CPU la programmazione concorrente, precedentemente utilizzata solo su sistemi costosi o supercomputers, è diventata una pratica sempre più utilizzata dagli sviluppatori. Allo stesso tempo, l’industria videoludica ha conquistato una fetta di mercato notevole: solo nel 2013 verranno spesi quasi 100 miliardi di dollari fra hardware e software dedicati al gaming. Le software houses impegnate nello sviluppo di videogames, per rendere i loro titoli più accattivanti, puntano su motori grafici sempre più potenti e spesso scarsamente ottimizzati, rendendoli estremamente esosi in termini di performance. Per questo motivo i produttori di GPU (Graphic Processing Unit), specialmente nell’ultimo decennio, hanno dato vita ad una vera e propria rincorsa alle performances che li ha portati ad ottenere dei prodotti con capacità di calcolo vertiginose. Ma al contrario delle CPU che agli inizi del 2000 intrapresero la strada del multicore per continuare a favorire programmi sequenziali, le GPU sono diventate manycore, ovvero con centinaia e centinaia di piccoli cores che eseguono calcoli in parallelo. Questa immensa capacità di calcolo può essere utilizzata in altri campi applicativi? La risposta è si e l’obiettivo di questa tesi è proprio quello di constatare allo stato attuale, in che modo e con quale efficienza pùo un software generico, avvalersi dell’utilizzo della GPU invece della CPU.

Gpu-based many-core architecture emulation: A double level approach

The efficient emulation of a many-core architecture is a challenging task, each core could be emulated through a dedicated thread and such threads would be interleaved on an either single-core or a multi-core processor. The high number of context switches will results in an unacceptable performance. To support this kind of application, the GPU computational power is exploited in order to schedule the emulation threads on the GPU cores. This presents a non trivial divergence issue, since GPU computational power is offered through SIMD processing elements, that are forced to synchronously execute the same instruction on different memory portions. Thus, a new emulation technique is introduced in order to overcome this limitation: instead of providing a routine for each ISA opcode, the emulator mimics the behavior of the Micro Architecture level, here instructions are date that a unique routine takes as input. Our new technique has been implemented and compared with the classic emulation approach, in order to investigate the chance of a hybrid solution.

Conversione a OpenCL di un simulatore cardiaco parallelo

In questa tesi discuteremo come è possibile effettuare la traduzione di un software parallelo scritto in linguaggio CUDA ad uno in linguaggio OpenCL. Tratteremo le tecnologie utilizzate per lo sviluppo di un simulatore cardiaco parallelo e discuteremo in particolar modo come derivare da queste una versione che ne permetta l’esecuzione su schede video e processori arbitrari. Questa versione verrà messa poi a confronto con quelle già esistenti, per analizzarne prestazioni ed eventuali cambiamenti strutturali del codice. Quanto affermato sopra è stato possibile in gran parte grazie ad un wrapper chiamato SimpleCL pensato per rendere la programmazione OpenCL simile a quella in ambiente CUDA. OpenCL permette di operare con le unità di calcolo in maniera molto astratta, ricordando vagamente i concetti di astrazione di memoria e processori della controparte NVIDIA. Ragionevolmente SimpleCL fornisce solamente una interfaccia che ricorda chiamate CUDA, mantenendo il flusso sottostante fedele a quello che si aspetterebbe OpenCL.

Large-scale Network Analysis on Distributed Architectures

Questa dissertazione esamina le sfide e i limiti che gli algoritmi di analisi di grafi incontrano in architetture distribuite costituite da personal computer. In particolare, analizza il comportamento dell'algoritmo del PageRank così come implementato in una popolare libreria C++ di analisi di grafi distribuiti, la Parallel Boost Graph Library (Parallel BGL). I risultati qui presentati mostrano che il modello di programmazione parallela Bulk Synchronous Parallel è inadatto all'implementazione efficiente del PageRank su cluster costituiti da personal computer. L'implementazione analizzata ha infatti evidenziato una scalabilità negativa, il tempo di esecuzione dell'algoritmo aumenta linearmente in funzione del numero di processori. Questi risultati sono stati ottenuti lanciando l'algoritmo del PageRank della Parallel BGL su un cluster di 43 PC dual-core con 2GB di RAM l'uno, usando diversi grafi scelti in modo da facilitare l'identificazione delle variabili che influenzano la scalabilità. Grafi rappresentanti modelli diversi hanno dato risultati differenti, mostrando che c'è una relazione tra il coefficiente di clustering e l'inclinazione della retta che rappresenta il tempo in funzione del numero di processori. Ad esempio, i grafi Erdős–Rényi, aventi un basso coefficiente di clustering, hanno rappresentato il caso peggiore nei test del PageRank, mentre i grafi Small-World, aventi un alto coefficiente di clustering, hanno rappresentato il caso migliore. Anche le dimensioni del grafo hanno mostrato un'influenza sul tempo di esecuzione particolarmente interessante. Infatti, si è mostrato che la relazione tra il numero di nodi e il numero di archi determina il tempo totale.

Ottimizzazione delle performance del framework biolabicaocheck

I documenti cartacei vengono attualmente rimpiazzati dalle loro versioni elettroniche, che contengono anche alcune caratteristiche biometriche; questo ha permesso il controllo automatico, sia quando il documento viene rilasciato, sia quando l'identità della persona deve essere verificata. Per rendere questo possibile è necessario che la fotografia rispetti degli standard di qualità. Lo standard ISO/IEC 19794-5 fornisce alcune guide linea ed esempi di immagini di volto accettabili e non-accettabili. Negli ultimi anni, molte aziende hanno sviluppato SDK con lo scopo di implementare i test proposti dallo standard. La tesi si prefigura il compito di fornire un framework che fornisca buone prestazioni, sia per quanto riguarda i tempi sia per l'accuratezza dei risultati.

Firmware development and testing for L1/L2 IBL upgrade

Il lavoro di questa tesi riguarda principalmente l'upgrade, la simulazione e il test di schede VME chiamate ReadOut Driver (ROD), che sono parte della catena di elaborazione ed acquisizione dati di IBL (Insertable B-Layer). IBL è il nuovo componente del Pixel Detector dell'esperimento ATLAS al Cern che è stato inserito nel detector durante lo shut down di LHC; fino al 2012 infatti il Pixel Detector era costituito da tre layer, chiamati (partendo dal più interno): Barrel Layer 0, Layer 1 e Layer 2. Tuttavia, l'aumento di luminosità di LHC, l'invecchiamento dei pixel e la richiesta di avere misure sempre più precise, portarono alla necessità di migliorare il rivelatore. Così, a partire dall'inizio del 2013, IBL (che fino a quel momento era stato un progetto sviluppato e finanziato separatamente dal Pixel Detector) è diventato parte del Pixel Detector di ATLAS ed è stato installato tra la beam-pipe e il layer B0. Questa tesi fornirà innanzitutto una panoramica generale dell'esperimento ATLAS al CERN, includendo aspetti sia fisici sia tecnici, poi tratterà in dettaglio le varie parti del rivelatore, con particolare attenzione su Insertable B-Layer. Su quest'ultimo punto la tesi si focalizzerà sui motivi che ne hanno portato alla costruzione, sugli aspetti di design, sulle tecnologie utilizzate (volte a rendere nel miglior modo possibile compatibili IBL e il resto del Pixel Detector) e sulle scelte di sviluppo e fabbricazione. La tesi tratterà poi la catena di read-out dei dati, descrivendo le tecniche di interfacciamento con i chip di front-end, ed in particolare si concentrerà sul lavoro svolto per l'upgrade e lo sviluppo delle schede ReadOut Drivers (ROD) introducendo le migliorie da me apportate, volte a eliminare eventuali difetti, migliorare le prestazioni ed a predisporre il sistema ad una analisi prestazionale del rivelatore. Allo stato attuale le schede sono state prodotte e montate e sono già parte del sistema di acquisizione dati del Pixel Detector di ATLAS, ma il firmware è in continuo aggiornamento. Il mio lavoro si è principalmente focalizzato sul debugging e il miglioramento delle schede ROD; in particolare ho aggiunto due features: - programmazione parallela delle FPGA} delle ROD via VME. IBL richiede l'utilizzo di 15 schede ROD e programmandole tutte insieme (invece che una alla volta) porta ad un sensibile guadagno nei tempi di programmazione. Questo è utile soprattutto in fase di test; - reset del Phase-Locked Loop (PLL)} tramite VME. Il PLL è un chip presente nelle ROD che distribuisce il clock a tutte le componenti della scheda. Avere la possibilità di resettare questo chip da remoto permette di risolvere problemi di sincronizzazione. Le ReadOut Driver saranno inoltre utilizzate da più layer del Pixel Detector. Infatti oltre ad IBL anche i dati provenienti dai layer 1 e 2 dei sensori a pixel dell’esperimento ATLAS verranno acquisiti sfruttando la catena hardware progettata, realizzata e testata a Bologna.

Chapel: analisi delle prestazioni su architetture a memoria distribuita

Nel presente elaborato si analizzeranno le prestazioni del linguaggio di programmazione parallela Chapel sul kernel Integer Sort di NAS Parallel Benchmarks. Questo algoritmo, a livello pratico, è utilizzato per studi o applicazioni sui metodi particellari. Saranno introdotti i concetti fondamentali di programmazione parallela e successivamente illustrate le principali caratteristiche di MPI e Chapel. Verranno poi approfonditi Integer Sort e i rispettivi dettagli implementativi, concludendo con un'analisi di prestazioni dei due linguaggi sul kernel preso in esame.

Programmazione funzionale in spazio logaritmico: una libreria di funzione aritmetiche

In questa Tesi forniamo una libreria di funzioni aritmetiche che operano in spazio logaritmico rispetto all'input. Partiamo con un'analisi dei campi in cui è necessario o conveniente porre dei limiti, in termini di spazio utilizzato, alla computazione di un determinato software. Vista la larga diffusione del Web, si ha a che fare con collezioni di dati enormi e che magari risiedono su server remoti: c'è quindi la necessità di scrivere programmi che operino su questi dati, pur non potendo questi dati entrare tutti insieme nella memoria di lavoro del programma stesso. In seguito studiamo le nozioni teoriche di Complessità, in particolare quelle legate allo spazio di calcolo, utilizzando un modello alternativo di Macchina di Turing: la Offline Turing Machine. Presentiamo quindi un nuovo “modello” di programmazione: la computazione bidirezionale, che riteniamo essere un buon modo di strutturare la computazione limitata in spazio. Forniamo poi una “guida al programmatore” per un linguaggio di recente introduzione, IntML, che permettere la realizzazione di programmi logspace mantenendo però il tradizionale stile di programmazione funzionale. Infine, per mostrare come IntML permetta concretamente di scrivere programmi limitati in spazio, realizziamo una libreria di funzioni aritmetiche che operano in spazio logaritmico. In particolare, mostriamo funzioni per calcolare divisione intera e resto sui naturali, e funzioni per confrontare, sommare e moltiplicare numeri espressi come parole binarie.