Il codice

Sorge quindi la necessità di un adattamento del codice: esso deve essere rivisto in modo da poter essere eseguito su un insieme di architetture eterogenee, come CPU, GPU e FPGA, provenienti potenzialmente da produttori diversi.

La sda che ci si pone in questo contesto è piuttosto complessa: gli algoritmi imple- mentati per CPU dal punto di vista del software design sono molto diversi da quelli che girano su GPU, e questi ultimi sono a loro volta diversi da quelli che girano su FPGA. Si pensi, ad esempio, che le applicazioni scritte per GPU generalmente sfruttano mas- sivamente il parallelismo sui dati; questo è invece dicile da ottenere sulle CPU con buoni risultati di performance. Inoltre, lo spostamento di dati dalla CPU alla GPU è un'operazione molto costosa dal punto di vista delle prestazioni e può facilmente diven- tare il collo di bottiglia dell'intero software. Questo problema è molto meno evidente in applicazioni che girano esclusivamente su CPU. Quello che si sta cercando è quindi una tecnologia che oltre a permettere di scrivere un unico programma che giri su diverse architetture, consenta anche di ottenere delle buone performance su ciascuna di esse.

opportuno processo di compilazione, sono integrati alla restante applicazione.

5_{Le GPU, o graphics processing unit, sono particolari tipi di coprocessori specializzati nella graca}

computerizzata; negli ultimi anni stanno avendo un grande successo anche nella programmazione paral- lela generica, nota come GPGPU. In questo secondo contesto, il modello di programmazione più diuso prevede la presenza di un host il quale demanda alla GPU l'esecuzione di speciche routine, chiamate kernel. Questi sono eseguiti in parallelo sulle unità computazionali della GPU seguendo un approccio SIMD (single instruction, multiple data).

2.2. Il problema delle risorse di calcolo 33 Alcuni primi passi in questa direzione sono già stati fatti per il Run 3 di LHC: una parte del codice dell'High-Level Triggering è stata portata in CUDA per essere eseguita su GPU NVIDIA. I risultati ottenuti sono promettenti ma il test è molto specico: il codice implementato gira su un unico tipo di acceleratore, le GPU, e per di più di un unico produttore, la NVIDIA. Si rendono necessari la ricerca e lo sviluppo di possibili soluzioni che superino questa limitazione. Tali tecnologie saranno valutate in termini di portabilità di prestazioni su dispositivi eterogenei al ne di individuare quale tra queste sia la più adatta alle esigenze di CMSSW. Si sono individuate di conseguenza le quattro più promettenti:

Alpaka è una libreria C++ che fornisce un layer di astrazione per lo sviluppo di codice da eseguire su acceleratori eterogenei. Nasce nel 2015 presso l'Università di Dresda come libreria per esperimenti di sica a bassa energia; negli anni si è evoluta come prodotto a disposizione della comunità scientica ed è attualmente mantenuta dal- l'istituto CASUS del centro di ricerca Helmholtz-Zentrum Dresden-Rossendorf [22]. Il codice del progetto è open-source ed è disponibile su GitHub [23].

Alpaka è una libreria indipendente da qualsiasi piattaforma hardware e suppor- ta un vasto numero di back-end tra i quali CUDA [17], HIP7 _{[24], TBB [13],}

OpenMP8 _{[25]. Il suo modello di esecuzione prevede l'utilizzo della CPU come}

host, mentre i kernel sono eseguiti in parallelo sugli acceleratori o su CPU. Il co- dice che gira su questi dispositivi può essere scritto indipendentemente dall'hard- ware sottostante; in questo modo è possibile rimandare anche a runtime la scelta dell'architettura sul quale eseguirlo.

7_{HIP, o Heterogeneous-Computing Interface for Portability, è un dialetto di C++ dell'ecosistema}

ROCm progettato per facilitare la conversione in C++ delle applicazioni CUDA al ne di renderle portabili su GPU NVIDIA e AMD.

8_{OpenMP è una API multi-piattaforma per la creazione di applicazioni parallele su sistemi a memoria}

Per facilitare gli sviluppatori che provengono da un ambiente CUDA, è stata rea- lizzata un'interfaccia utente in C++ chiamata CUPLA [26]. Essa ore ai program- matori un ambiente Alpaka che si basa su griglie, blocchi e thread, del tutto simile a quello fornito dalla NVIDIA.

Alpaka è una tecnologia molto promettente, sia per le prestazioni che permette di ottenere, sia perché l'istituto di ricerca che sviluppa questa nuova tecnologia ha dimostrato interesse nel sostenere i progetti di CMS.

Kokkos è un modello di programmazione sviluppato dai Sandia National Laborato- ries9 _{[27] che, come Alpaka, denisce astrazioni per la scrittura di software parallelo}

su acceleratori eterogenei in contesti di High Performance Computing (o HPC) [28]. L'ecosistema di Kokkos comprende, in aggiunta, primitive per la gestione dei da- ti, kernel matematici e strumenti di debug ed è disponibile con licenza libera su GitHub [29].

Attualmente Kokkos supporta NVIDIA CUDA, AMD ROCm e OpenMP, tuttavia gli sviluppatori sono impegnati nella realizzazione di estensioni per altri back-end. Anche questo modello di programmazione utilizza una sintassi simile a quella di CUDA e supporta TBB.

SYCL è uno standard proposto da Khronos Group10 _{[30] per lo sviluppo di codice}

parallelo in contesti eterogenei [2]. È un modello di programmazione astratto e di alto livello che nasce sopra al back-end OpenCL con l'obiettivo di permettere agli sviluppatori di scrivere in un unico sorgente il codice da eseguire su un insieme eterogeneo di dispositivi.

9_{I Sandia National Laboratories sono due importanti laboratori del Dipartimento dell'Energia sta-}

tunitense (DOE). Essi si occupano dello sviluppo di componenti per le armi nucleari e di questioni di sicurezza nazionale per la National Nuclear Security Administration (NNSA).

10_{Khronos group è un consorzio di oltre 150 aziende leader nel settore ICT che si occupa di sviluppare}

2.2. Il problema delle risorse di calcolo 35 SYCL è conforme allo standard C++ in quanto ne mantiene sintassi e semantica. Uno degli obiettivi di SYCL è quello di indirizzare codice su un numero sempre crescente di dispositivi diversi. Questo impone ai programmatori alcuni limiti all'utilizzo delle funzionalità di C++ nelle routine da eseguire sugli acceleratori, tra queste: puntatori a funzione, eccezioni, funzioni ricorsive e chiamate a funzioni virtuali.

Nello sviluppo di SYCL, Khronos group collabora con la comunità di C++: nelle linee guida per le future implementazioni di questo standard, infatti, è riportata la necessità di estendere C++ anché supporti la programmazione su dispositivi eterogenei [31].

Attualmente esistono quattro implementazioni di SYCL: ComputeCPP, hipSY- CL, triSYCL e DPC++; ciascuna di queste sarà approfondita nella sezione 3.2. Dal momento che questo standard è oggetto di tesi, in questo contesto non sarà approfondito ulteriormente; una sua descrizione più accurata si trova nel capitolo 3. oneAPI è un nuovo modello di programmazione proposto da Intel che si pone l'obiettivo di unicare lo sviluppo di codice indirizzato ad architetture eterogenee [19]. Questa tecnologia implementa lo standard SYCL e lo estende con nuove caratteristiche e funzionalità. L'ecosistema oneAPI comprende il linguaggio di programmazione Data Parallel C++ (DPC++), diversi strumenti, librerie, ed un'interfaccia di basso livello per l'esecuzione di codice sui dispositivi Intel. Nel progetto che ha portato alla stesura di questo elaborato è stato approfondito e utilizzato oneAPI; una sua descrizione più dettagliata è riportata nei capitoli successivi.