Scarica il pdf con la mia tesi - Parallel Programming Laboratory

UNIVERSITÀ DI PADOVAFACOLTÀ DI INGEGNERIACORSO DI LAUREA IN INGEGNERIA INFORMATICADIPARTIMENTO DI ELETTRONICA ED INFORMATICATESI DI LAUREAParallelizzazione dicodice Tree-SPHRelatore: Ch.mo Prof. Gianfranco BilardiCorrelatori: Ch.mi Proff. Lauro Moscardini e Giuseppe TormenLaureando: Filippo GioachinPadova, 1 Luglio 2002 Anno Accademico 2001-02

Ai miei genitori,nella speranza di dare loromolte altre soddisfazioni.

IndiceSommariovii1 Introduzione 12 Gli algoritmi utilizzati 32.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 Codici Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2.1 Algoritmo di Barnes-Hut . . . . . . . . . . . . . . . . . . . . 42.2.2 Apertura dell’albero . . . . . . . . . . . . . . . . . . . . . . 42.2.3 Aggiornamento dell’albero . . . . . . . . . . . . . . . . . . . 62.3 Codici SPH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3.1 Calcolo di densità . . . . . . . . . . . . . . . . . . . . . . . . 82.3.2 Calcolo di pressione e forza . . . . . . . . . . . . . . . . . . 82.4 Integrazione temporale . . . . . . . . . . . . . . . . . . . . . . . . . 103 Strategie di parallelizzazione 133.1 La decomposizione . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.1.1 Distribuzione random . . . . . . . . . . . . . . . . . . . . . . 143.1.2 Distribuzione spaziale . . . . . . . . . . . . . . . . . . . . . 153.2 Le comunicazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2.1 Ricezione dei dati per eseguire il calcolo localmente . . . . . 173.2.2 Esportazione dei dati ed esecuzione del calcolo in remoto . . . 183.3 Lo sbilanciamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.3.1 Il caricamento iniziale . . . . . . . . . . . . . . . . . . . . . 223.3.2 Mantenimento dati . . . . . . . . . . . . . . . . . . . . . . . 243.3.3 La ridefinizione dei domini . . . . . . . . . . . . . . . . . . . 254 Modifiche al codice 274.1 Implementazione in MPI . . . . . . . . . . . . . . . . . . . . . . . . 274.2 Buffer di comunicazione . . . . . . . . . . . . . . . . . . . . . . . . 274.3 Spostamento di particelle . . . . . . . . . . . . . . . . . . . . . . . . 294.4 Ricerca dei vicini e domini interni . . . . . . . . . . . . . . . . . . . 304.5 Metodi di scrittura dei file . . . . . . . . . . . . . . . . . . . . . . . . 334.5.1 File di restart . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.5.2 Snapshot . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.6 Modifiche alla struttura modulare . . . . . . . . . . . . . . . . . . . . 374.7 Modifiche al file dei parametri . . . . . . . . . . . . . . . . . . . . . 395 Prestazioni 416 Conclusioni 47A Glossario 49B Utilizzo del codice 53

Elenco delle figure2.1 Esempio di albero oct-tree per l’algoritmo di Barnes-Hut . . . . . . . 52.2 Rappresentazione del criterio geometrico di apertura dell’albero . . . 62.3 Andamento della spline relativa all’equazione 2.9 . . . . . . . . . . . 93.1 Distribuzione random di particelle . . . . . . . . . . . . . . . . . . . 153.2 Distribuzione di particelle mediante domini . . . . . . . . . . . . . . 163.3 Rappresentazione del processo di importazione dei dati residenti suglialtri processori per effettuare il calcolo in locale. . . . . . . . . . . . . 173.4 Rappresentazione del processo di esportazione dei dati per il calcoloin remoto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.5 Riposizionamento del taglio principale all’interno della distribuzionedi particelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.6 Protocollo di scambio delle particelle tra i due blocchi di processoricomponenti il taglio . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.7 Schema di come avviene il caricamento iniziale dei dati per l’avvio diuna nuova simulazione. . . . . . . . . . . . . . . . . . . . . . . . . . 234.1 Schema di come vengono utilizzati i buffer per il calcolo delle forze inremoto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.2 Rappresentazione di come avviene lo spostamento delle particelle trale due parti di un taglio quando si necessità di un ribilanciamento. . . 294.3 Illustrazione di come avviene la definizione di dominio interno. . . . . 314.4 Metodo di ricerca binaria del raggio di smussamento delle particelle dimateria barionica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.5 Procedura di salvataggio di un file di restart . . . . . . . . . . . . . . 344.6 Procedura di salvataggio di uno snapshot . . . . . . . . . . . . . . . . 364.7 Schema delle inclusioni dei moduli . . . . . . . . . . . . . . . . . . . 385.1 Immagine a redshift zero di una simulazione con due ammassi di galassiead alta risoluzione con sola materia oscura . . . . . . . . . . . 45

SommarioLa ricerca scientifica utilizza sempre di più le simulazioni al calcolatore per convalidarele teorie e necessita sempre di maggiore potenza di calcolo per eseguire simulazionisempre più elaborate.In questo lavoro di tesi verrà presentato il progetto di parallelizzazione di un programmaTree-SPH per simulare l’evoluzione temporale di un sistema fisico, programmautilizzato dal Dipartimento di Astronomia dell’Università di Padova per studiarei vari problemi aperti della cosmologia. Lo scopo di questo progetto è di ridurre itempi di calcolo mediante l’impiego di multiprocessori e quindi di permettere il miglioramentodelle simulazioni. Verranno descritti gli algoritmi utilizzati e le strategieimpiegate durante il processo di parallelizzazione nonché le scelte implementative. Inconclusione verranno indicati i limiti di tale sviluppo e le prospettive future.

Capitolo 1IntroduzioneLa cosmologia è la parte dell’astrofisica che si interessa a diversi problemi relativiall’universo, come ad esempio la sua formazione ed evoluzione temporale nonché dellaformazione delle sue strutture interne, come galassie o ammassi di galassie. Per questoè necessario utilizzare delle simulazioni temporali per far evolvere dei sistemi fisici dacondizioni iniziali note e verificare la correttezza delle teorie attuali.È necessaria una breve descrizione di come la teoria attuale ipotizzi la formazioneed evoluzione dell’universo. Il modello del Big Bang prevede che all’inizio ci siaappunto un grande scoppio dal quale, partendo da un punto estremamente caldo edenso, si origina l’espansione dell’universo. Successivamente nel fluido, fino a quelmomento omogeneo, iniziano a formarsi delle piccole fluttuazioni di densità causandodelle variazioni che, sotto le forze gravitazionali del fluido stesso, hanno dato originealle strutture visibili ai giorni nostri come stelle, galassie e ammassi di galassie. Lecondizioni iniziali note sono quindi una descrizione del fluido allo stato primordialecontenente queste piccole fluttuazioni.Queste simulazioni richiedono un enorme quantitativo di calcoli e, anche su macchinemolto veloci, necessitano di giornate di computazioni per arrivare al risultato.L’accuratezza di tali risultati, inoltre, dipende fortemente da almeno due fattori: il primoè il numero di particelle o corpi che compongono la simulazione, in quanto un loroaumento permette una migliore definizione del sistema, il secondo è la fisica alla basedelle elaborazioni in quanto più dettagli fisici e più contributi di forze sono consideratie meglio è.Questi due fattori sono però contrastati dal tempo di calcolo in quanto sia per aumentareil numero di particelle sia per aumentare la fisica considerata si necessitanodi maggiori computazioni e quindi maggior tempo di attesa per avere i risultati, tempoche può raggiungere un mese anche per simulazioni non eccessivamente grandi.Per tale motivo poter utilizzare più di un processore per distribuire il lavoro tradi essi permette di ridurre drasticamente i tempi e di avere quindi la possibilità diincrementare la precisione delle simulazioni stesse.A tale scopo nasce questo lavoro: permettere la scrittura di un codice parallelo pereffettuare queste simulazioni. La base di partenza è un codice sequenziale già esistentescritto in Fortran 90 sviluppato da un laureando dell’Università di Venezia a cui si

2 Introduzione Cap. 1fa riferimento per ulteriori approfondimenti sugli aspetti maggiormente relativi alleimplementazioni seriali (vedi [Favaretto, 6]).Nel capitolo 2 si introdurranno quindi gli algoritmi già implementati nel codicesequenziale per i calcoli delle forze e l’avanzamento delle particelle. Si passa neicapitoli successivi ad analizzare ciò che è stato fatto per generare il codice paralleloed in particolare nel capitolo 3 si analizzano le scelte effettuate per quanto riguarda lestrategie di parallelizzazione mentre nel capitolo 4 si illustrano più in dettaglio qualisono state le modifiche effettuate sul codice durante l’implementazione. Segue unabreve analisi sulla scalabilità e le conclusioni. In appendice un glossario dei terminiastronomici e informatici utilizzati.

Capitolo 2Gli algoritmi utilizzati2.1 IntroduzionePer la risoluzione dei problemi legati alla cosmologia si utilizzano codici che effettuanosimulazioni temporali. Innanzitutto in queste simulazioni sono presenti due tipidi particelle: le particelle barioniche e quelle di materia oscura.Le prime rappresentano la materia visibile ed è formata principalmente da gas(idrogeno ed elio) con alcune tracce di altri materiali pesanti quali ferro etc. Le secondeinvece rappresentano materia a noi non visibile perché non emette alcuna radiazioneche la renda osservabile e la cui presenza ci è rilevata in modo indiretto per spiegareil moto delle stelle all’interno delle galassie per effetto della forza gravitazionale. Sipensa che nell’universo la maggior parte di materia, circa il 90%, sia di questo secondotipo.In queste simulazioni rientrano due tipi di forze cui sono soggette le particellein esame. La più importante è la forza gravitazionale, cui sono sottoposte tutte leparticelle presenti indipendentemente dal loro tipo e spiegata nella Sez. 2.2 a pag. 3.Un’altra forza molto importante è quella idrodinamica causata dall’interazione tra leparticelle all’interno di un fluido; questo secondo tipo di forze coinvolge solamente leparticelle di materia barionica ed è spiegata nella Sez. 2.3 a pag. 6.In questo capitolo vengono considerate infine le tecniche utilizzate per l’integrazionetemporale nella Sez. 2.4 a pag. 10.2.2 Codici TreePer le simulazioni di tipo cosmologico le principali interazioni tra i corpi sono ditipo gravitazionale. Si ricorda che la forza interagente tra due corpi o particelle è datadalla seguente formula vettoriale:F 1 = G m 1 · m 2|r 12 | 3 r 12 (2.1)

4 Gli algoritmi utilizzati Cap. 2dove G è la costante di gravitazione universale G = 6.672 −8 cm 3 g·s 2 , m 1 e m 2 sonole masse dei due corpi, r 12 è il vettore che congiunge la particella 1 con la particella 2e F 1 è la forza agente sulla particella 1.Un inconveniente di tale forza che non ne permette l’utilizzo pratico in una simulazionereale è che ogni particella interagisce con tutte le altre dando origine a O(N 2 )interazioni, una complessità troppo elevata: quando il numero di particelle arriva aqualche milione le interazioni richieste sono dell’ordine di 10 12 !2.2.1 Algoritmo di Barnes-HutA questo punto si necessita di una qualche semplificazione nella quantità di calcolida eseguire a discapito, ovviamente, dell’accuratezza delle forze stesse. Tale semplificazionepuò essere data dall’uso di strutture ad albero che si basano sul seguenteconcetto:Per il calcolo delle forze cui è soggetto un corpo nello spazio possiamoraggruppare un insieme di particelle lontane dal corpo stesso nel lorocentro di massa.che può essere espresso matematicamente nel seguente modo:F i = G∑j≠im i · m j|r ij | 3 r i j ≈ G m i · M|r i,cm | 3 r i,cm (2.2)dove M è la somma delle masse raggruppate insieme e r i,cm è il vettore congiungentela particella in esame con il centro di massa del raggruppamento.Questo ci permette di creare un albero in cui lo spazio totale viene diviso ricorsivamentein blocchi di particelle vicine, associati ai nodi interni, fino ad arrivare allefoglie in cui c’è una sola particella. Associando poi ad ogni nodo un insieme di datisufficienti a descrivere in buona approssimazione il gruppo di particelle che essocontiene, possiamo calcolare una sola interazione tra il nodo e una particella lontanaanziché tante interazioni tra tutte le particelle del nodo e la particella lontana: questo èl’algoritmo di Barnes-Hut.In Figura 2.1 e ripresa da [Favaretto, 6] si può vedere un esempio della creazionedi un albero utilizzato per l’algoritmo approssimato.In particolare un insieme di dati sufficienti contiene tipicamente la massa totaledelle particelle nel nodo, il centro di massa con relativa velocità e il baricentro, unalista di tutte le particelle contenute e una espansione del quadrupolo.La complessità computazionale della costruzione di un tale albero, qui chiamatooct-tree, si può dimostrare essere O(N lgN) per una distribuzione abbastanza uniformedelle particelle (vedi [Favaretto, 6, pp. 19-20] per maggiori dettagli).2.2.2 Apertura dell’alberoUn problema da gestire in tale algoritmo è il seguente: quando si può considerarevalida l’approssimazione data dall’albero e quando invece è necessario espandere ilnodo?

Sez. 2.2 Codici Tree 5Figura 2.1: Esempio di albero oct-tree per l’algoritmo di Barnes-HutPer rispondere a questa domanda il metodo più semplice è di tipo geometrico propostoda Barnes-Hut: un nodo viene aperto quando il gruppo di particelle è sufficientementedistante dalla particella su cui si vogliono calcolare le forze:lr < θ (2.3)dove θ è una costante ben definita, l e r sono rispettivamente il lato del cubo contenutonel nodo e la distanza della particella dal centro di massa come si può vedere in Figura2.2 in una rappresentazione grafica di tale criterio, la figura è tratta da [Favaretto, 6].L’inconveniente principale di questo tipo di apertura è che quando c’è una distribuzioneabbastanza uniforme alcune particelle hanno forze molto piccole dovute allacancellazione di forze uguali e contrarie molto più grandi. Poiché questo metodo cercadi limitare l’errore relativo, quando si effettuano queste cancellazioni l’errore assolutopuò risultare molto elevato (può superare anche l’entità della forza stessa).Per ovviare a tale inconveniente si potrebbe pensare di ridurre il valore di θ ilche porterebbe però ad un notevole incremento del numero di interazioni quando nonnecessario a discapito del tempo di calcolo.Un metodo migliore consiste invece nel considerare l’accelerazione della particellaa old e aprire l’albero maggiormente quando questa è piccola in modo da minimizzarel’errore assoluto. Un tale criterio può essere espresso dalla seguente formula:Ml 4 > α|a old |r 6 (2.4)dove M è la massa contenuta nel nodo, l e r sono sempre il lato del cubo e la distanzatra particella e centro di massa. α è una costante opportuna.Studi (si veda [Springel, 7] e le sue referenze) hanno dimostrato che questo criterioè più efficiente del precedente. Il primo resta ancora necessario qualora non si abbiaa disposizione una stima per l’accelerazione della particella (come tipicamente accadeal primo passo di simulazione).

6 Gli algoritmi utilizzati Cap. 2Figura 2.2: Rappresentazione del criterio geometrico di apertura dell’albero2.2.3 Aggiornamento dell’alberoAltro problema riguarda il garantire che un nodo contenga dei valori coerenti conle particelle che contiene. La domanda è allora: quando e con che modalità aggiornarei nodi dell’albero?Poiché non è possibile ricalcolare un nodo interno ogni volta che una delle sue particelleviene spostata (ne cadrebbe ogni vantaggio computazionale), si può pensare aduna linearizzazione in un intorno dell’istante temporale a cui i dati si riferiscono. Per ladefinizione di tale intorno si può prendere come riferimento la velocità di spostamentodel centro di massa v cm del nodo secondo la seguente formula:v cm · dt < βl (2.5)dove l è sempre il lato del cubo che il nodo contiene e β è una opportuna costante. dtrappresenta l’intervallo di tempo tra l’istante cui si riferiscono i dati del nodo e l’istantein cui si vogliono stimare.Quando il centro di massa si è spostato più del consentito si ricalcolano i valoricaratteristici del nodo tramite la lista delle particelle contenute nel nodo. Per evitarepoi che le particelle si spostino al di fuori del dominio di competenza del nodo si ricostruisceinteramente l’albero ad intervalli regolari, tipicamente 0.1N calcoli di forzadove N è il numero di particelle (si veda Sez. 2.4 pag. 10).2.3 Codici SPHSPH, ovvero Smoothed Particles Hydrodynamics, è una tecnica lagrangiana percalcolare forze di tipo idrodinamico dovute alla pressione cui sono sottoposte le parti-

Sez. 2.3 Codici SPH 7celle di un fluido. A differenza delle forze gravitazionali che sono a lungo raggio, ossiasu una particella interagiscono tutte le altre fino alle più lontane, queste seconde sonoa corto raggio ossia decadono a breve distanza e su una particella influiscono solo leparticelle ad essa più vicine.Il vantaggio del metodo lagrangiano rispetto ad un metodo euleriano è che mentrequest’ultimo prevede di avere una griglia a passo costante ai cui incroci vengono associatele masse delle regioni circostanti, il primo prevede di avere delle particelle da“seguire” a cui è associata una propria massa. Questo permette di avere una “grigliavariabile” in modo da fare più calcoli dove sono concentrate più particelle (ossia avereuna griglia equivalente con passo piccolo) e sprecare poco tempo dove ci sono pocheparticelle (ossia avere una griglia equivalente con passo largo).Altra caratteristica fondamentale di questo tipo di forze è che non coinvolge tutti itipi di particelle ma solo alcuni e quindi richiede di essere inserita solo quando questesono presenti. È a questo punto necessaria una precisazione: l’universo conosciutoè formato da due tipi di materia, la materia barionica (quasi interamente formata daidrogeno ed elio) che è quella a noi visibile e che interagisce sia gravitazionalmenteche idrodinamicamente e una grande quantità di materia detta “materia oscura” (che ècirca 9÷10 volte superiore a quella barionica) che non è a noi visibile e che interagiscesolo gravitazionalmente.Il calcolo procede in due passi:1. si calcola la densità di materia per ogni particella,2. si calcola la pressione e la forza cui è soggetta ogni particella a causa dei suoivicini.Si è visto dalla pratica che tali calcoli hanno una precisione ottimale considerando unnumero N s di particelle vicini (tipicamente qualche decina). Dato infatti che come si èdetto questa è una tecnica di tipo Lagrangiano che va a creare una griglia “variabile”con una risoluzione maggiore nelle zone dove serve, ossia quelle più dense, e minorenelle zone meno dense. Con un numero maggiore di particelle si rischia di perdererisoluzione, con un numero inferiore si incorre in errori dovuti alla discretizzazionedei campi (shot-noise).Per definire la dimensione della griglia nel punto di interesse come detto si prendecome riferimento un intorno di tale punto contenente 40 particelle e a questo si associaun “raggio di smussamento” che, come dice il termine stesso, è il raggio di tale intorno.Dato che poi il sistema evolve nel tempo e le particelle si spostano si rende necessarioadattare dinamicamente tale raggio alle nuove conformazioni. Ciò viene fatto medianteun algoritmo che, a parte il primo passo, utilizza il raggio precedente h i e fa una stimadel nuovo raggio ĥ i in base alla velocità di variazione del raggio stesso ḣ i , discendentedall’equazione di continuità, che èḣ i = 1 3 h i(∇ · v) i (2.6)

8 Gli algoritmi utilizzati Cap. 2e del numero di vicini desiderato N s (che è impostabile da utente anche diverso da 40)dal quale per qualche motivo il raggio può discostarsi andando a contenere un numeroN i di vicini:⎡ĥ i = 1 2 h(old) i⎣1 + N 1 3 s⎤⎦ + ḣ i ∆t (2.7)N iil termine entro parentesi quadre serve per riportare il numero di vicini realmentecontenuti dal raggio verso il valore desiderato.Per quanto riguarda il primo passo per il quale non si hanno informazioni precedentisi provvede a stimare un raggio iniziale basandosi sull’albero oct-tree creato perle forze gravitazionali.Qui di seguito si analizzano i passi e le equazioni utilizzate per il calcolo delladensità e della forza idrodinamica.2.3.1 Calcolo di densitàPer calcolare la densità si utilizza un metodo di integrazione (che diventa poi unasommatoria data la discretizzazione effettuata nel trasporto sul calcolatore) su un insiemedi particelle vicine a quella in questione. Questo permette di avere una buonastima della densità nel punto di interesse considerato come nodo della “griglia virtuale”.Tale integrazione ha un kernel in modo da pesare in modo diverso i vicini più omeno lontani. Le equazioni sono:ρ i =N∑ m j W(r i j ,h i ) (2.8)j=1per calcolare la densità ρ della particella i in funzione delle N particelle circostanti jdove W rappresenta il kernel della funzione che tipicamente è una spline, ad esempio laseguente spline cubica usata all’inizio da Monaghan e Lattazio e poi ripresa nel nostrocodice (il cui andamento è riportato in Figura 2.3):⎧⎪⎨W(r,h) = 1 1 − 3 ( rh) 2 (2 +3 rh) 340 ≤ r( ) h ≤ 1πh 3 1⎪ ⎩4 2 −r 3h1

Sez. 2.3 Codici SPH 9Figura 2.3: Andamento della spline relativa all’equazione 2.9

10 Gli algoritmi utilizzati Cap. 2con γ coefficiente adiabatico del gas (nel nostro caso 5/3) e u i energia interna della particellain esame calcolata a partire dalla costante di Boltzmann k, dal peso molecolaremedio µ e dalla massa del protone m p in questo modo:u i =kT i(γ − 1)µm p(2.11)Infine avendo a disposizione la pressione si può passare a calcolare la forza agentesulla particella in esame mediante integrazione della seguente equazione di Eulero,equivalente idrodinamico della seconda legge della dinamica F = ma:∂v∂t+ (v · ∇)v = −∇Pρ(2.12)dove v è la velocità della particella. Qui non si riportano tutte le formule utilizzatedal programma, soluzione dell’equazione di continuità, con cui si può calcolarel’accelerazione (si veda [Favaretto, 6, pp. 14-15]).2.4 Integrazione temporaleCome ogni sistema che evolve nel tempo è necessario che sia iterativo e ad ognipasso vada ad aggiornare i dati relativi alle particelle per farli avanzare. Il passo diavanzamento dipende da quanto noi possiamo andare nel futuro nel predire i parametridi una particella considerando i dati ottenuti attendibili. Questo intervallo di temponon è uguale per tutte le particelle dato che l’attendibilità dei risultati dipende sostanzialmenteda quanto rapidamente varia la sua velocità di spostamento nel tempo: ossiadalla sua accelerazione. Una tipica funzione per calcolare l’intervallo di predicibilità∆t i di una particella 1 è:∆t i = α tol(2.13)|a i |oppure∆t i =α cour h ih i |(∇ · v) i | + max(c i ,|v i |)(1 + 0.6α visc )(2.14)nel caso di particelle soggette anche a forze idrodinamiche, dove α tol e c i sono duecostanti per determinare la precisione che si vuole nella stima della posizione nell’intervallo,α visc è un coefficiente di viscosità artificiale e α cour è un fattore di accuratezzadi Courant, a i e v i rispettivamente l’accelerazione e la velocità della particella e infineh i il raggio di smussamento.Queste formule, secondo [Springel, 7], danno i migliori risultati rispetto a tantealtre considerate.A questo punto si pone un problema di efficienza: se una particella è predicibilea grande distanza nel tempo è necessario aggiornarla sempre? Ovviamente la risposta1 con ∆t si intende l’estensione dell’intervallo di predicibilità, ossia la particella è predicibilenell’intervallo [t − 1 2 ∆t, t + 1 2 ∆t]

Sez. 2.4 Integrazione temporale 11è no ed infatti si prevede che sul totale di particelle presenti nel sistema quelle conmaggiore accelerazione vengano avanzate più volte con piccoli passi mentre quelle conmoto più uniforme vengano avanzate più raramente con passi più grandi. In sostanzaad ogni passo si vanno ad aggiornare solamente un gruppo di particelle che hanno ilpiù basso orizzonte di predicibilità nel futuro.Il calcolo evolve nei seguenti passi:1. si calcola il tempo massimo al quale tutte le particelle sono predicibili τ p =min{t i + 1 2 ∆t i , ∀i},2. si sceglie un gruppo di particelle G al limite inferiore della timeline 2 con un certocriterio di arresto, ad esempio quello utilizzato nel nostro codice è che ciascunadi esse sia avanzata per almeno metà del suo massimo timestep 3 permesso:G = {i : τ p ≥ t i + 1 4 ∆t i} (2.15)3. si predicono tutte le particelle del sistema nell’istante temporale τ p (che diventail tempo corrente della simulazione),4. si avanzano le particelle in G secondo il seguente schema sequenziale di calcoli:(a) posizioni di tutte le particelle in τ p˜r i = r i + v i (τ p −t i )(b) accelerazioni a metà del timestep per le particelle da avanzare a partire daicampi di forza Φ cui sono sottoposte= −∇Φ(˜r i )|˜rk(c) velocità nell’istante finalev (n+1)k= v (n)k+ 2a (n+ 1 2 )k(τ p −t k )(d) posizioni nell’istante finalea (n+ 1 2 )kr (n+1)k= r (n)k+[v (n)k+ v (n+1)k](τ p −t k )(e) nuovo istante corrente per le particellet nuovok= t k + 2(τ p −t k )A questo punto il tempo della simulazione è τ p e si può passare al prossimo passo diiterazione.2 per timeline si intende un elenco di tutte le particelle ordinate mediante il loro massimo tempo dipredicibilità nel futuro.3 per timestep si intende il passo di avanzamento di una particella.

12 Gli algoritmi utilizzati Cap. 2

Capitolo 3Strategie di parallelizzazioneIn questo capitolo vengono illustrate le scelte effettuate per la parallelizzazione.Esse non sono strettamente correlate con l’implementazione del codice ma piuttostosono ad alto livello andando a vedere gli aspetti più concettuali. Si discuterà quindidi come suddividere i dati tra i vari processori, di come effettuare i calcoli in mododistribuito una volta che i dati sono stati separati e di come trattare lo sbilanciamentoche insorge quando il lavoro affidato ad ogni processore può essere molto diverso.Per un’analisi più dettagliata delle implementazioni effettuate sul codice si rimandaal Cap. 4 a pag. 27.3.1 La decomposizioneLa principale caratteristica del parallelismo è quella di dividere il lavoro da eseguiresu più processori in modo da aumentarne la velocità di elaborazione. Per fare ciò è perònecessario che anche i dati siano distribuiti.Esistono alcune elaborazioni che richiedono una elevata quantità di calcoli su unmodesto insieme di dati in ingresso: in questo caso si può pensare di duplicare i datiall’interno dei vari processori e poi di riaggregare i risultati al termine delle operazioni.Nel nostro caso ciò non è applicabile perché la quantità di dati è elevata: è necessariomantenere delle informazioni per ogni particella presente nel sistema da simulareassieme alle strutture dati necessarie per gestirle. Una particella richiede all’incirca100 byte di memoria, se pensiamo ad un sistema con 10 milioni di particelle (realistico)otteniamo 1 Gbyte di dati a cui dobbiamo sommarne altrettanti per le strutturedati: il risultato non è facilmente duplicabile nella memoria di un singolo processoree comunque va a scapito della scalabilità. Inoltre si può pensare ad un interesse consimulazioni ancora più elevate che quindi diventerebbero impensabili con i modernisistemi.La strategia richiede quindi di suddividere i dati all’interno dei vari processori. Unprimo approccio può essere quello di pensare di assegnare ad un processore i dati chequesto necessita per eseguire il lavoro e di eseguire le elaborazioni il più possibile localmente.Anche ciò risulta impraticabile nel nostro caso perché la principale forza è

14 Strategie di parallelizzazione Cap. 3quella gravitazionale a cui sono soggette tutte le particelle nel sistema e la cui interazionecoinvolge tutte le altre particelle: quindi si necessita di sincronizzarsi ad ognipasso di simulazione per garantire che tale forza sia calcolata nel modo corretto congli algoritmi spiegati in precedenza (vedi Sez. 2.2 a pag. 3).3.1.1 Distribuzione randomUn primo tipo di suddivisione può essere distribuire le particelle tra i processoriin un modo random. Questo permetterebbe di non avere problemi di sbilanciamentodato che in media, per simulazioni sufficientemente elevate, ogni processore avanzeràlo stesso numero di particelle ad ogni passo ed ogni processore gestirà sempre delleparticelle in zone altamente dense che richiedono elevati calcoli e particelle in zonepiù rarefatte che ne richiedono meno (vedi Figura 3.1).Dato che l’ammontare del tempo richiesto per la gestione del ribilanciamento eper lo sbilanciamento che inevitabilmente compare raggiunge, per quanto riportato inletteratura, il 20÷25% del tempo totale di esecuzione del programma parallelo già su16 processori, il fatto di togliere quasi completamente questa componente del tuttoindesiderata del calcolo è un fattore a vantaggio di questo approccio. Il “quasi” indicache comunque non è possibile eliminarla interamente perché ad ogni passo i processoriavranno un numero di particelle da aggiornare che sarà leggermente diverso tra di loroper cui una qualche componente di sbilanciamento sarà sempre presente. Nei testcondotti tuttavia tale componente è sempre stata inferiore al 3%.Ciò richiederebbe come accorgimento che la distribuzione sia garantita essere randomall’inizio della simulazione perché altrimenti ciò potrebbe degradare le prestazioniglobali. Per quanto riguarda il nostro codice esso ha un input generato secondo unadistribuzione spaziale: ossia particelle vicine nel file sono vicine nello spazio, inoltreparticelle simili come comportamento medio nell’evoluzione sono anch’esse raggruppateassieme all’interno del file. Ciò ci consente di distribuire le particelle secondo unamodalità round-robin 1 che già da sola garantisce una distribuzione ottimale.Un problema sorge per quanto riguarda le particelle di gas soggette alle forze idrodinamichein quanto essendo queste forze a corto raggio coinvolgono particelle vicineche con questa distribuzione vengono a trovarsi in processori diversi, viene a caderequindi qualsiasi speranza di poter limitare le comunicazioni ed eseguire calcoli localmenteper delle particelle con tutti i vicini sullo stesso processore. In ogni caso èsempre possibile trovare il raggio di smussamento e quindi i vicini con cui interagisceanche in una situazione interprocessore (vedi Sez. 4.4 a pag. 30) anche se con unapenalizzazione in termini di tempo. Si rammenta comunque che per qualsiasi tipo didistribuzione esisteranno delle particelle con dei vicini su altri processori.Un altro problema più importante sorge invece in questo tipo di distribuzione, problemache rende inapplicabile questo metodo: per il calcolo delle forze gravitazionali(che occupano sempre la maggior parte del carico di lavoro) viene usato l’algoritmo diBarnes-Hut (vedi Sez. 2.2.1 a pag. 4) il quale approssima gruppi di particelle lontane1 round-robin significa distribuzione dei dati in modo circolare tra tutti i processori.

Sez. 3.1 La decomposizione 15Proc 0 Proc 1Proc 2 Proc 3Figura 3.1: Distribuzione random di particelleusando i loro centri di massa. Quando queste particelle sono distribuite su più processoriogni processore assocerà al suo gruppo di particelle un centro di massa e conquesto effettuerà una interazione con una particella da avanzare. A questo punto da unasola interazione originaria se ne vengono a creare N dove N è il numero di processoricoinvolti nella simulazione.Questo appesantimento dell’algoritmo che a parità di accuratezza esegue molti piùcalcoli porta ad un aumento considerevole del tempo di esecuzione (fino a 3 volte su8 processori!), aumento che cresce assieme al numero di processori e va a cancellarequasi tutto il vantaggio dato dalla parallelizzazione rendendo quindi inutilizzabile talemetodo di distribuzione.3.1.2 Distribuzione spazialeAltro metodo di distribuzione delle particelle, ampiamente utilizzato in letteratura,consiste nel distribuire le particelle in modo che un processore abbia particellespazialmente vicine tra di loro (vedi Figura 3.2).Questo modo di procedere consente di evitare il pesante inconveniente causatodalla distribuzione random e, nel caso di particelle di gas, permette di definire unaregione di spazio interna le cui particelle interagiscono solo localmente nel processoree non necessitano quindi di comunicazione per quanto riguarda le forze idrodinamiche(vedi Sez. 4.4 a pag. 30).Un inconveniente di questa distribuzione è che essendo la distribuzione di particellenon uniforme e inoltre evolvente nel tempo, è necessario modificare l’assegnazionedelle particelle ai vari processori dinamicamente. Altro inconveniente è che essendocinella simulazione zone in cui si addensano particelle in tali zone si hanno forze più

16 Strategie di parallelizzazione Cap. 3Proc 0 Proc 1Proc 4 Proc 5DecomposizioneProc 2 Proc 3Proc 6 Proc 7Figura 3.2: Distribuzione di particelle mediante dominielevate, ossia particelle che richiedono un maggiore sforzo computazionale. Come sivedrà più avanti sullo sbilanciamento (Sez. 3.3 a pag. 18) si dovrà pagare ciò conmemoria aggiuntiva. Come già accennato questo overhead di gestione è indesiderato esi deve cercare pertanto di minimizzarlo.Dato che nel salvataggio su file dei dati per poter all’occorrenza riavviare una simulazionesi perde traccia di come erano state distribuite le particelle tra i vari processori(a parte il caso particolare in cui ogni processore scrive un suo file), è necessario aggiungerequesta informazione da qualche parte come verrà spiegato nella Sez. 4.5 apag. 33.Nel nostro codice per quanto esposto qui e nel paragrafo precedente si è decisodi utilizzare questa seconda tecnica di ripartizione dei dati con tutti i vantaggi e glisvantaggi che porta. Pertanto nel seguito essa verrà presa come distribuzione base perle varie considerazioni.3.2 Le comunicazioniSi è visto quali sono le modalità di distribuzione delle particelle tra i vari processoricoinvolti nella simulazione, qui verranno ora presentate le strategie utilizzabili eutilizzate per permettere il calcolo sui dati distribuiti.Per quanto riguarda le forze gravitazionali 2 , che si ricorda sono a lungo raggio (vedisezione 2.2 a pag. 3), si presentano due modalità di comunicazione tra i processori perpermettere l’interazione tra tutte le particelle:1. un processore, quando deve avanzare una particella, riceve dagli altri i datinecessari per poter eseguire il calcolo;2 in questa trattazione vengono considerate solo le forze gravitazionali e non quelle idrodinamiche acorto raggio a cui, peraltro, possono essere applicati gli stessi ragionamenti.

Sez. 3.2 Le comunicazioni 17P 1P 2 P 3P 0tutti i dati sono disponibiliper i calcoli in localeFigura 3.3: Rappresentazione del processo di importazione dei dati residenti sugli altriprocessori per effettuare il calcolo in locale.Si può vedere come viene importata una grande quantità di dati per permettere alprocessore P 0 dell’esempio di svolgere tutti i calcoli sulle sue particelle.2. un processore, quando deve avanzare una particelle, invia i dati della particellaa tutti gli altri facendo fare i dati in remoto e riassemblando i risultati parziali altermine.3.2.1 Ricezione dei dati per eseguire il calcolo localmenteSe si utilizza questa tecnica di comunicazione un processore che possiede una particellaesegue tutti i calcoli inerenti ad essa. Un esempio di codice utilizzante questastrategia si può trovare in [Lia, 8]. Un primo inconveniente è che spesso si vengono atrovare zone altamente dense che, quando il numero di processori cresce, rischiano ditrovarsi tutte in pochi processori. Questo può creare problemi di ribilanciamento neltempo di esecuzione perché pochi processori si trovano sovraccaricati di lavoro già conpoche particelle mentre altri si trovano quasi privi.Altro problema fondamentale di questo metodo è che un processore necessita diricevere una grande quantità di informazioni riguardanti le particelle contenute neglialtri processori per poter eseguire i calcoli. Inoltre non può ricevere solo i dati delleparticelle perché altrimenti l’algoritmo di Barnes-Hut e la sua semplificazione nellacomplessità del problema verrebbe meno. Esso deve ricevere pertanto anche i dati

18 Strategie di parallelizzazione Cap. 3relativi ai nodi interni con cui effettuare i dati in forma aggregata. In Figura 3.3 si puòvedere come può avvenire questo modo di procedere.Si pone ora il problema di decidere quali dati importare perché l’apertura di un nodointerno dipende dalla distanza dalla particella ma anche (fattore più difficile da prevedere)dall’accelerazione della particella in esame. Processori diversi richiederebberoin linea di massima anche dati diversi data la diversa distanza tra di loro.Anche supponendo di avere degli strumenti per stabilire che cosa importare, oppuredecidendo di importare tutti gli alberi vicini, nasce il problema di dove sistemaretemporaneamente tutti i dati in arrivo dato che, come visto all’inizio del capitolo, è necessariodistribuire le particelle, essendo troppi i dati per essere mantenuti da un soloprocessore.Infine questi dati richiederebbero di essere importati ad ogni passo in quanto cisono sempre delle particelle che vengono spostate in ciascun processore e nessunotranne il processore che le detiene può sapere come si sono spostate.3.2.2 Esportazione dei dati ed esecuzione del calcolo in remotoPer tutti i motivi sopra esposti si è stati portati verso la seconda strategia di parallelizzazioneche qui verrà esposta.Dato che tutte le forze del sistema sono lineari non ha alcuna importanza l’ordinecon cui i calcoli vengono fatti, l’unica cosa importante è che siano effettuati tutti.Ciò porta a pensare di inviare i dati relativi alle particelle da avanzare a tutti gli altriprocessori, attendere che ciascuno di questi effettui su di esse una parte dei calcoli e poiriaggregare tutti i risultati parziali nel processore detentore della particella (vedi Figura3.4). Questo modo di procedere permette innanzitutto una migliore distribuzione delcarico di lavoro perché, anche se un processore che detiene particelle da avanzarenecessita di una maggiore quantità di calcoli dovendo aprire più nodi, il calcolo èdi per sé maggiormente partizionato.Pensare ad esportare le particelle è sensato perché ad ogni passo solo una piccolafrazione del totale di particelle viene aggiornato. Inoltre si può vedere inoltre che percalcolare le forze che agiscono su una particella non è necessario conoscere tutto diquella particella ma solo la sua posizione e poco altro (un po’ di più è necessario perle forze idrodinamiche). Quindi è possibile utilizzare dei buffer per mantenere questidati da inviare agli altri e su questi stessi ricevere i risultati parziali (di come vengonoutilizzati i buffer nel nostro programma se ne parla più in dettaglio nella Sez. 4.2 apag. 27)3.3 Lo sbilanciamentoPoiché come si è detto le particelle si muovono durante la simulazione, se si vuolecercare di limitare lo sbilanciamento che può insorgere tra i vari processori e usufruiredi una gestione delle forze idrodinamiche in modo da avere una regione completamenteinterna al processore, è necessario predisporre un meccanismo che aggiorni i confini

Sez. 3.3 Lo sbilanciamento 19P 0dati inizialiCalcoli parzialirisulatati totaliP 1Calcoli parzialiP 2Calcoli parzialiCalcoli parzialiP 3Figura 3.4: Rappresentazione del processo di esportazione dei dati per il calcolo inremoto.Si può vedere come il processore P 0 che ha delle particelle da avanzare (rappresentateda cerchi vuoti) mandi a tutti gli altri (compreso se stesso) i suoi dati attendendo chequesti facciano le elaborazioni in base ai dati in loro possesso e poi i risultati venganoriassemblati nel processore P 0 (rappresentati da cerchi pieni).

20 Strategie di parallelizzazione Cap. 3dei domini spaziali di pertinenza di ciascun processore dinamicamente. In Figura 3.5si può vedere come si procede allo spostamento di un taglio (in particolare di quelloche coinvolge tutti i processori).VecchioTaglioNuovoTaglioPrimaDopoFigura 3.5: Riposizionamento del taglio principale all’interno della distribuzione diparticelleInoltre, cosa fondamentale, poiché pochi processori si troveranno ad avere le particellepiù pesanti computazionalmente, è necessario assegnare a questi un numeroinferiore di particelle rispetto agli altri. Infatti nonostante il calcolo sia distribuito inremoto, il processore che detiene una particella richiederà un maggior numero di calcolidi tipo particella-particella dovendo aprire maggiormente i nodi, un processorelontano si troverà in una situazione di dover aprire meno i nodi in quanto distantedalle particelle avanzate e potrà usufruire dell’approssimazione data dall’algoritmo diBarnes-Hut.Punto fondamentale è che tutto lo spazio è coperto esattamente dai processori (comesi può vedere nelle Figure 3.2 e 3.5). Risulta anche che lungo il taglio principaletutti i processori devono adeguarsi ad avere un bordo comune, anche questo è fatto perpoter gestire il tutto in maniera efficiente.Per ridistribuire le particelle si lavora in modo ricorsivo: lungo un taglio si possonoindividuare due gruppi di processori i quali (in condizioni ottimali) dovrebberoimpiegare un uguale tempo di calcolo. Ognuno dei due gruppi calcola quanto tempo hautilizzato nelle computazioni complessivamente (somma dei tempi sui singoli processoridel gruppo) tolte tutte le comunicazioni e le attese, poi il gruppo che ha impiegatopiù tempo invia delle particelle al gruppo che ha lavorato meno.Questo semplice algoritmo permette di ridurre lo sbilanciamento in quanto tendere

Sez. 3.3 Lo sbilanciamento 21a rende uguale il lavoro effettuato da ciascun gruppo. Esso ha il vantaggio che, a parteper il taglio principale, il calcolo dei tempi e lo scambio di particelle può avvenire inparallelo.Dato che i livelli di suddivisione risentono degli scambi effettuati ai livelli superiori,si è ritenuto più efficiente effettuare il controllo solo su una dimensione alla volta equindi per un ribilanciamento globale si devono effettuare tre successive ridivisioni.L’equazione utilizzata per decidere quante particelle devono essere scambiate è laseguente:N · c part = t max −t min(3.1)2nella quale t max e t min corrispondono ai tempi relativi ai due gruppi, N è il numerodi particelle scambiate e c part è il costo di una particella, ossia quanto tempo è statomediamente utilizzato per gestire una particella all’interno di un processore.Una volta calcolato il numero di particelle da scambiare è necessario trovare unanuova posizione del taglio e questo viene fatto mediante una ricerca binaria all’internodel gruppo di processori che deve inviare in modo che selezioni tale taglio. Per motividi efficienza e per non entrare in cicli infiniti, vengono poi stabiliti due paramentri dicui uno da utente (ExchangePartTolerance) che permettono di interrompere la ricercaqualora non si riesca a trovare precisamente il taglio perché molte particelle sonoconcentrate in una sezione (l’arresto avviene quando si raggiunge la precisione dei realinel calcolatore) oppure qualora l’imprecisione sul numero di particelle selezionatedal nuovo taglio diventa inferiore all’errore commesso comunque dall’approssimazionedi considerare la media sui tempi di tutte le particelle (si veda la Sez. 4.7 per unadescrizione di questo parametro).Successivamente le particelle così selezionate vengono mandate all’altro gruppo diprocessori. Poiché però un processore può non avere posto a sufficienza per accoglieretutte le particelle che gli vengono inviate è stata stabilita anche una modalità per cui unprocessore ricevente può decidere di non accettare tutte le particelle ma di scegliere unnuovo taglio (ovviamente che riduce l’entità del taglio deciso da chi invia) in modo dalimitare il ribilanciamento per motivi di memoria insufficiente.Come si vede è necessario che un processore allochi più memoria di quella strettamentenecessaria a contenere le particelle per far fronte a questi sbilanciamenti nelcarico di lavoro. Stimare quanto sovradimensionare la memoria rispetto al minimoindispensabile per contenere tutte le particelle non è facile perché si contrastano dueaspetti: da una lato la necessità di avere molta memoria in più per permettere una ottimaleripartizione del carico di lavoro tra tutti i processori e dall’altra il vincolo dellamemoria fisica a disposizione nel calcolatore. Pertanto esiste un parametro impostabileda utente per permettere di stabilire a seconda della simulazione quanto sovradimensionarela memoria (MemoryFactor, vedi Sez. 4.7 a pag. 39 per una descrizione delparametro).In Figura 3.6 si può vedere graficamente come procede l’algoritmo.Per evitare instabilità se si è prossimi all’equilibrio vi è poi una condizione aggiuntivache inibisce lo scambio di particelle ossia quandot max −t min < t · ∆ imb

22 Strategie di parallelizzazione Cap. 3ReceiverQuante particelle inviareElenco particelleSendercalcolo di quante particelleinviare dall’altra parte mediantericerca binariainvio delle particellericezione delleparticelle e verificase spazio sufficienteNuova posizione asse di splitTempocancellazione particelle inviatecon successo dall’altra partedel taglioFigura 3.6: Protocollo di scambio delle particelle tra i due blocchi di processoricomponenti il tagliodove ∆ imb è un parametro impostabile da utente (ImbalanceTolerance, si vedaSez. 4.7 a pag. 39 per una descrizione del parametro) che indica quanto essere precisi et è invece indistintamente uno dei due tempi dato che, essendo tipicamente ∆ imb∼ = 0.05,i due tempi tendono ad avvicinarsi quando la relazione è soddisfatta.Nell’introdurre questo algoritmo di ribilanciamento sorgono alcuni problemi chesono trattati nei sottoparagrafi seguenti e sono:• caricamento iniziale dei dati formando la decomposizione• mantenimento della situazione della decomposizione per un riavvio• problemi qualora i tempi si bilanciano e si creano sfuocature nei bordi3.3.1 Il caricamento inizialeUn primo problema da affrontare riguarda come caricare i dati inizialmente dalfile. Dato che non esiste alcuna suddivisione dei domini preimpostata e, soprattuttoal crescere del numero di processori coinvolti, lo spazio di competenza assegnato aivari processori può non essere uguale dato che tipicamente la distribuzione iniziale diparticelle non è uniforme su tutto lo spazio, ma presenta delle concentrazioni in alcunipunti.

Sez. 3.3 Lo sbilanciamento 23P 0 calcolai dominiletturadatiP 0P 1Broadcast dei dominia tutti i processsoriP 2P 3ognuno caricai suoi datiP 1 P 2 P 3Figura 3.7: Schema di come avviene il caricamento iniziale dei dati per l’avvio di unanuova simulazione.Il processore P 0 legge i dati dal file e costruisce una tabella tridimensionale contenentein ogni cella il numero di particelle in quella regione. Successivamente considerandouniforme la distribuzione di particelle all’interno di ogni cella viene effettuata unaripartizione evidenziata in linea tratteggiata. Il processore P 0 invia i dati così ottenutia tutti gli altri. Infine ognuno va a caricare i dai di suo interesse dal file.

24 Strategie di parallelizzazione Cap. 3In alcuni codici come [Springel, 7] in cui esiste una gestione del ribilanciamentodiversa da quella da noi implementata viene caricato il file iniziale in modo round-robine poi viene generata una suddivisione che assegna a ciascun processore un eguale numerodi particelle e queste vengono scambiate tra i processori in memoria. Nel nostrocaso invece non è possibile perché l’algoritmo prevede di averne una suddivisione preesistente:è quindi necessario approntare un codice apposito che sopperisca a questoinconveniente.Per risolvere il problema viene in nostro aiuto il formato dei file di ingresso, formatoparticolare scritto dal prof. Tormen (vedi [Tormen, 9]), nei quali vengono elencatetutte le particelle con le loro posizioni, velocità e masse.È stato implementato un metodo, il cui funzionamento si può vedere graficamentein Figura 3.7, che va a leggere l’input e a mappare lo spazio di simulazione in una tabellatridimensionale in modo che in ogni cella della griglia sia indicata la quantità diparticelle in quella regione di spazio. Si va poi a partizionare il dominio considerandouniforme la distribuzione delle particelle all’interno di una cella (in figura il partizionamentogenerato è in linea tratteggiata). Da sperimentazioni si può vedere che giàcon qualche centinaio di celle per lato la decomposizione effettuata è errata di qualchepunto percentuale, del tutto irrilevante per il caricamento.La complessità di tale algoritmo, che viene eseguito da un solo processore il qualepropaga poi il risultato agli altri, è O(N + P). È lineare nel numero di particelle N inquanto queste vengono lette una sola volta dal file. È lineare nel numero di processoriperché dati P processori devono essere calcolati P − 1 tagli ognuno dei quale richiedeun numero proporzionale alla profondità del taglio e alla dimensione della tabella cheè una costante.Alla fine ogni processore va a leggere dal file di input i dati che gli interessano.3.3.2 Mantenimento datiDato che l’algoritmo è totalmente dinamico è necessario che i dati relativi ai dominisiano salvati su file qualora si voglia poter riavviare la simulazione in un secondomomento. Le modalità di riavvio di una simulazione (come spiegato in [Favaretto, 6,pp. 31]) sono due: mediante file di restart oppure mediante snapshot.Un file di restart contiene una copia della memoria al momento del salvataggio eviene utilizzato solo dal nostro programma pertanto non è necessaria la compatibilitàcon altri codici e si è potuto modificarne il formato in modo tale da salvare anche leinformazioni relative ai domini.Uno snapshot è invece un file contenente solo alcuni dati relativi alle particelle cheservono poi per delle analisi post-simulazione. Il fatto che tale file debba interagire conaltri programmi ha posto immediatamente dei vincoli sul suo formato. La soluzionesi è trovata andando a creare un file aggiuntivo, comune a tutti gli snapshot di unasimulazione, che contiene indicazione su quante particelle ogni processore contenevaal momento del salvataggio dello snapshot e di quale dominio gli competeva.In tale modo è poi possibile andare a recuperare dallo snapshot (che magari è scrittoda più file come si vedrà nella Sez. 4.5 a pag. 33) esattamente la situazione esistente

Sez. 3.3 Lo sbilanciamento 25al momento del salvataggio. Tale file va pertanto allegato agli snapshot per permetterneil riavvio, è invece ininfluente per l’analisi post-simulazione permettendo di nonmodificare tali altri programmi.3.3.3 La ridefinizione dei dominiAltro problema sorto è che durante l’evoluzione, qualora per lunghi intervalli ditempo i tempi impiegati dai vari processori siano pressoché uguali (o almeno tali danon eseguire lo scambio di particelle) oppure le spostamento di particelle avvenga semprenella stessa direzione, le particelle lungo i bordi dei domini si fondano tra i diversiprocessori andando a sfocare i bordi e riducendo i benefici della decomposizione adomini andando, alla lunga, a incontrare i problemi occorsi alla distribuzione random.Per tale motivo è stato implementato un altro metodo invocato dopo un certo numerodi decomposizioni fissato, nel nostro codice 3 decomposizioni globali (ossia effettuatesu tutti e tre gli assi), in modo da ridelineare i domini e permettere lo scambiodelle particelle che non competono più ad un processore.Si è visto dalle simulazioni che mentre senza l’utilizzo di questa accortezza unabuona parte delle particelle veniva a cadere al di fuori del dominio di competenza diun processore (fino ad averne anche più del 50%), con il suo utilizzo il numero diparticelle che fuoriesce dal dominio di competenza risulta essere inferiore al 3%.

26 Strategie di parallelizzazione Cap. 3

Capitolo 4Modifiche al codiceIn questo capitolo verranno ripercorse tutte le modifiche attuate nel codice perpermettere l’interazione tra i diversi processi e le nuove strutture dati introdotte.4.1 Implementazione in MPIDato che nel passaggio da un sistema monoprocessore ad uno multiprocessore è necessariogestire l’interazione tra i vari processori coinvolti nella soluzione del problemaè stato necessario utilizzare una libreria di routine atte a questo scopo. È stata pertantoscelta la libreria MPI in quanto ampiamente diffusa e supportata da vari tipologie dimacchine oltre che dalla macchina da noi utilizzata: RS/6000 SP della IBM.Queste librerie sono descritte in maggiore dettaglio in [MPI, 2] e [Aoyama, 1] pervari esempi di utilizzo. Qui verranno solamente riproposte quelle tipologie che sonostate utilizzate per i nostri scopi.Tra le varie tipologie di routine ne sono state prese in considerazione due: routinecollettive e routine point-to-point. Sono state valutate le prestazioni di entrambe all’internodel nostro programma per i compiti descritti nei paragrafi seguenti e si è visto chequelle collettive risultavano estremamente lente sul sistema da noi adottato rispetto aquelle point-to-point. È stato quindi adottato questo secondo sistema di comunicazionidescritto più in dettaglio nei paragrafi seguenti.Non è stato invece possibile sfruttare le routine per la gestione dei file in quantoqueste verranno supportate a partire dalla versione 2 di MPI mentre quella a nostradisposizione è la versione 1.2. Tale aggiornamento potrà essere fatto in un futuroqualora si abbiano a disposizione tali strumenti e soprattutto si senta la necessità dimaggiori prestazioni per scrittura dei file (per la gestione dei file si veda Sez. 4.5 apag. 33).4.2 Buffer di comunicazioneAllo scopo di permettere ai vari processori di scambiarsi i dati come spiegato nelcapitolo precedente (vedi Sez. 3.2.2 a pag. 18) sono stati creati due buffer di comunica-

28 Modifiche al codice Cap. 4zione: uno locale e uno globale la cui dimensione è impostabile dall’utente (CommSize,vedi Sez. 4.7 a pag. 39 per una descrizione del parametro).P 0P 1P 2P 3Dati da elaborare(in buffer Locale)Esportazione a tuttii processoriutilizzo di SendRecvper la comunicazionediretta con tutti iprocessori singolarmenteDati esportati per elaborazione(in buffer Globale)P 0P 1P 2P 3Ogni processorefa i calcoli sui datiricevuti con i datiin suo possessoP 0I contributi parziali dei variP 0P 1processori vengonoriaggregati sommandoliP 1P 2P 3Risultati totali riaggregati(in buffer Locale)utilizzo di SendRecvpiù somme eseguitelocalmenteRisultati parziali dei calcoli locali(in buffer Globale)P 2P 3Figura 4.1: Schema di come vengono utilizzati i buffer per il calcolo delle forze inremotoNel buffer locale vengono posti i dati dai singoli processori prima di essere esportatie i dati raccolti dai processori dopo le elaborazioni in remoto. Poiché in questi bufferdevono essere contenuti solo i dati relativi ad un processore la loro dimensione è metàdi quella dei buffer globali in quanto un processore non deve mai poter avere più dimetà di tutti i dati da gestire, altrimenti ci si troverebbe sicuramente in una situazionedi forte sbilanciamento, cosa da evitare.Nel buffer globale vengono invece posti tutti i dati provenienti da tutti i processoriin modo che quando un processore deve fare i suoi calcoli trovi tutto in un array unicoe possa scandirlo con maggiore facilità. Questi buffer vengono poi sovrascritti a manoa mano che i dati vengono consumati e si producono i risultati. In questo modo si evitadi dover allocare due buffer per mantenere input e output. Per evitare di cancellare datiprima che siano stati utilizzati basta avere l’accortezza di iniziare ad elaborare i dati apartire dalla fine del buffer qualora i dati in uscita siano più grandi di quelli in ingresso.La Figura 4.1 mostra come tale procedimento evolve nel tempo: ogni processoreha una certa quantità di particelle da avanzare e quindi su cui calcolare le forze. Questevengono inviate a tutti i processori (compreso se stesso) e posizionate nel buffer globale.A questo punto ogni processore può eseguire i calcoli con i dati in suo possesso

Sez. 4.3 Spostamento di particelle 29ReceiverSenderGlobaleGlobaleProcessori difrontieraProcessoreROOTLocaleAltri processorinon di frontieraLocaleAltri processoriFigura 4.2: Rappresentazione di come avviene lo spostamento delle particelle tra ledue parti di un taglio quando si necessità di un ribilanciamento.su tutte le particelle ricevute e sovrascrivere i dati iniziali con i risultati parziali (datiin grigio nella figura), infine questi vengono rimandati ai proprietari delle particelle iquali provvederanno a sommare tutti i contributi ricevuti e a sistemarli nel buffer localee da qui poi dove sono tenute le particelle.Ovviamente può accadere che il buffer globale non sia in grado di tenere tutte leparticelle da aggiornare, in questo caso si ripete la procedura più volte fino ad esauriretutti i dati. In ogni passo di trasmissione il buffer verrà a contenere le particelle da tutti iprocessori che necessitano aggiornamenti in maniera proporzionale a quante particellevogliono avanzare, in questo modo un processore avrà alcune particelle vicine su cuidovrà effettuare più calcoli e alcune particelle lontane su cui ne dovrà effettuare dimeno andando quindi a distribuire il carico in modo più uniforme possibile.4.3 Spostamento di particelleUna volta che il programma ha deciso secondo le modalità analizzate nella Sez. 3.3a pag. 18 che per ribilanciare i tempi di calcolo è necessario spostare delle particelle,queste vengono spostate mediante l’utilizzo dei buffer come illustrato in Figura 4.2.Come si può vedere, i processori che devono ricevere particelle si predispongonoa riceverle nel loro buffer globale per poi analizzarle e decidere se tenerle. È da evi-

30 Modifiche al codice Cap. 4denziare che non tutti i processori di sinistra ricevono le particelle, ma solo quelli difrontiera, ossia quelli che hanno un bordo sul taglio in movimento, in modo da nonmandare particelle a chi non è minimamente interessato risparmiando tempo. Ciò vienead essere un vantaggio quando il numero di processori coinvolto sale e si stannogestendo quei tagli che li coinvolgono tutti o in buona parte.Invece i processori che inviano si coordinano mandando le particelle ad uno solodi essi il quale si prende l’incarico di inviarle dall’altra parte del taglio. Come si puòvedere i processori che inviano usano il buffer locale per mandare le particelle al rootper il forwarding e quest’ultimo utilizza il buffer globale per poi rinviarle dall’altraparte.Ciò permette di non dovere instaurare una comunicazione tutti con tutti come perle ridefinizioni (vedi Sez. 3.3.3 a pag. 25) e per i calcoli di forze ma di semplificarel’invio mediante un forward. Questo può rappresentare un collo di bottiglia delloscambio, tuttavia si può notare che quando è coinvolto un numero sufficiente di processorilungo i tagli principali i tempi tenderanno ad essere abbastanza uguali tra le dueparti o comunque faranno spostare il tagli gradualmente. Nei tagli più piccoli, invece,dove ci può essere una maggiore variabilità, il processo è maggiormente parallelizzato.4.4 Ricerca dei vicini e domini interniPoiché come anticipato nella Sez. 3.1.2 a pag. 15 avendo una distribuzione adomini è possibile individuare una regione interna al processore tale che le particelle digas ivi contenute non necessitino di esportazione per i calcoli relativi all’idrodinamica,è necessario dividere le particelle in due gruppi: completamente interne ed esportabili.

Sez. 4.4 Ricerca dei vicini e domini interni 31P 1P 0dominio di competenza(le particelle possono fuoriuscire)dominio tagliato da tuttii domini di influenzadefinito internodominio di influenzadi tutte le particelledel processoreP 2Figura 4.3: Illustrazione di come avviene la definizione di dominio interno.L’esempio è relativo al processore P 0. Ogni processore contiene le sue particelle chepossono anche fuoriuscire dal suo dominio di competenza. In ogni caso viene cercatoil dominio (tratteggiato) di influenza di tutte le particelle di gas: esso è formato dallamassima estensione dei raggi di smussamento di tutte le particelle di gas. A questopunto con questi domini si va a “tagliare” il dominio del processore sotto analisi (P 0)andando a determinare una regione al cui interno le particelle interagiscono solo conparticelle situate nel processore (rettangolo in grassetto).Innanzitutto è necessario decidere come determinare se una particella necessiti diinterazioni con gli altri processori oppure no. A questo scopo viene implementato unmetodo che si preoccupa di calcolare tale regione interna, come illustrato in Figura 4.3.A questo punto le particelle che secondo quanto visto vengono dichiarate completamenteinterne non necessitano di attenzioni particolari rispetto a quanto fattonel programma sequenziale. Per le particelle esportabili sono invece necessarie delleaggiunte.Prima fra tutte la ricerca dei vicini, infatti da quanto visto anche nel Cap. 2.3 a pag.6 è necessario calcolare un raggio comprendente un numero di particelle prestabilito.Ciò viene fatto mediante una ricerca binaria, come si può vedere in Figura 4.4, tra unraggio minimo e uno massimo fino ad arrivare a definire il raggio voluto. Le condizionidi arresto di tale algoritmo sono due:• quando il numero di vicini contenuto nel raggio corrente è corretto a meno di unerrore definibile dall’utente nel file dei parametri(SPHNeighboursDeviation, vedi Sez. 4.7 a pag. 39)

32 Modifiche al codice Cap. 4massimocorrenteminimoFigura 4.4: Metodo di ricerca binaria del raggio di smussamento delle particelle dimateria barionica

Sez. 4.5 Metodi di scrittura dei file 33• oppure quando la differenza tra i due raggi è sufficientemente piccola da risultareinutile un maggior approfondimento (nel nostro codice tale dimensione è1/100.000 del raggio).Si è visto nelle simulazioni svolte che il numero di iterazioni per trovare un raggiocontenente 40±2 particelle sono necessari sempre meno di 10 iterazioni.In secondo luogo è necessario esportare tali particelle ed effettuare i calcoli inremoto. Ciò viene fatto come spiegato precedentemente nella Sez. 4.2 a pag. 27.Una sola differenza è stata necessaria per quanto riguarda il calcolo della pressione inquanto la particella in esame non deve essere considerata come negli altri calcoli ma,mentre per gli altri tale eliminazione avviene in modo implicito a causa del fatto chela posizione coincide, deve essere fatta in modo esplicito implementando un modo perriconoscere quando si sta considerando la particella in esame ed eliminarla.4.5 Metodi di scrittura dei fileInnanzitutto vi è il problema della dimensione di tali file in quanto il parallelismopermette di gestire una quantità maggiore di informazioni che quindi possono superarela capacità di un singolo file. Per tale motivo viene data la possibilità all’utente didecidere in quante parti un file debba essere diviso (NumberOfFiles, si veda 4.7 a pag.39 per maggiori dettagli). Questo permette anche una parallelizzazione nella scritturain quanto su file diversi è possibile una scrittura simultanea per quanto riguarda ilprogramma, ovviamente demandando il problema al sistema operativo.Esistono poi due tipi di file scritti dal programma:• file di restart che contiene tutti i dati relativi alla simulazione in corso e permetteil riavvio in caso di problemi• snapshot che contiene un sottoinsieme dei dati della simulazione necessari perle elaborazioni a posteriori e in grado anch’esso di permettere il riavvio di unasimulazione.Dato che, come si è già detto nella Sez. 3.3.2 a pag. 24, si è dovuto procedere in mododiverso nella gestione dei due tipi dati i diversi vincoli che su essi erano presenti diseguito si analizzano le metodologie impiegate nella scrittura e rilettura di tali file.4.5.1 File di restartPer questi file è stato deciso di far scrivere ad ogni processore la sezione di suacompetenza. Ciò principalmente per due motivi:1. la quantità di dati scritta è notevole in quanto tutte le informazioni contenute inmemoria sulle particelle vanno scritte,

34 Modifiche al codice Cap. 4P 0HeaderDati P0P 1Dati P1P 2Dati P2P 3Dati P3Figura 4.5: Procedura di salvataggio di un file di restart2. i dati relativi ad un processore sono scritti in posizioni contigue del file dato cheè stato possibile modificarne la struttura come già detto nella Sez. 3.2.2 a pag.18.Tale metodo di procedere ha il vantaggio che non si ha il problema di dover far transitarei dati da un processore ad un altro come nel caso in cui uno solo scriva tutto.Inoltre nel passaggio dei dati si dovrebbe affrontare il problema di dati diversi tra diloro, infatti ci sono interi, reali e booleani a diverse precisioni.In Figura 4.5 si può vedere graficamente come avviene la scrittura.Un inconveniente che è stato incontrato è che nella versione 1.2 di MPI presentenel sistema non sono implementate le routine di gestione parallela dei file per cui èstato necessario effettuarla manualmente serializzando le scritture effettuate dai diversiprocessori. In tale compito è stato utile poter utilizzare una struttura già esistente nelcodice sequenziale per gestire i file in formato binario alla quale sono state apportatealcune modifiche per permettere l’interazione su uno stesso file di più processi diversi.

Sez. 4.5 Metodi di scrittura dei file 35La struttura modificata del file di restart risulta essere la seguente:⎧Variabili di simulazione⎪⎨ Numero particelle processore 0Dati di validità generale.⎪⎩⎧Numero particelle processore n-1⎨ Dominio di competenza proc. 0Dati processore 0 Informazioni materia oscura proc. 0⎩Informazioni materia barionica proc. 0Altri processoriDati processore n-1⎧.⎨ Dominio di competenza proc. n-1Informazioni materia oscura proc. n-1⎩Informazioni materia barionica proc. n-1Per la rilettura di questo file per il riavvio si procede allo stesso modo andandoa leggere i dati globali all’inizio del file, spostandosi poi nella zona di propriacompetenza per leggere tutti gli altri dati.4.5.2 SnapshotPer gli snapshot è stata invece utilizzata una tecnica diversa di scrittura dovutaprincipalmente al vincolo sulla struttura di tale file che qui si riporta:⎧HeaderPosizioni⎪⎨VelocitàMateria oscura e gasPotenzialiID ⎪⎩⎧ Masse (di alcune)⎨ Energia specificaSolo gas (se c’è) Densità⎩Cooling (opzionale)Utilizzare la stessa tecnica usata per i file di restart risulta molto difficile data lanotevole frammentazione dei dati scritti da un processore all’interno del file. Per talemotivo è stata in questo caso scelta la soluzione di un unico processo che scrive il filee tutti gli altri inviano i dati a lui, come si può vedere in Figura 4.6. Inoltre per questifile si ha una maggiore omogeneità di dati in quanto sono tutti reali o al più interi, macomunque tutti della stessa dimensione.Dato che viene scritto più di un file per ognuno di essi esisterà un processore dedicatoalla scrittura. Tale meccanismo non rappresenta un collo di bottiglia significativoper il sistema poiché il tempo impiegato per la scrittura è relativamente piccolo rispettoal totale.Come spiegato in precedenza nella Sez. 3.3.2 a pag. 24, è stato poi aggiunto unfile che raccoglie le informazioni non presenti nello snapshot e necessarie al riavvio

36 Modifiche al codice Cap. 4InfoP 0dati generali(quantità, domini)P 1dati delleparticelleSnapshotparte 1P 2P 3dati delleparticelleSnapshotparte 2Figura 4.6: Procedura di salvataggio di uno snapshot

Sez. 4.6 Modifiche alla struttura modulare 37di simulazione. Tale file è unico per tutti gli snapshot creati durante la simulazione inquanto di piccole dimensioni. Come si può vedere dallo schema seguente, in esso sonopresenti le particelle possedute da ciascun processore e il dominio di competenza diciascuno.{ Numero di processori nella simulazioneDati globali⎧ Numero di processori per fileNumero snapshot⎪⎨ Quantità particelle e domini proc. 0Snapshot 1Altri snapshotSnapshot k⎪⎩⎪⎩.Quantità particelle e domini proc. n-1⎧.Numero snapshot⎪⎨ Quantità particelle e domini proc. 0.Quantità particelle e domini proc. n-1Tale file viene scritto da uno solo dei processori (processore 0) il quale raccoglie leinformazioni relative a tutti gli altri.In Figura 4.6 si può vedere anche la scrittura del file di info da parte del processore0.Per quanto riguarda il riavvio il processore 0 va a copiare tutti i dati relativi aglisnapshot precedenti a quello di riavvio in un nuovo file e poi comunica a tutti gli altriil dominio e quante particelle competono a ciascuno di essi. A questo punto ognunova a leggere il file contenente i suoi dati e a caricare ciò che gli serve.4.6 Modifiche alla struttura modulareRispetto a quanto riportato in [Favaretto, 6, pp. 54 e seg.] (a cui si rimanda perulteriori dettagli) sono state apportate poche modifiche alla struttura dei moduli.Principalmente è stato aggiunto un nuovo modulo chiamato “domain_m” il cuicompito è quello di gestire i domini, ossia il ribilanciamento del carico e la ridefinizionedei domini come spiegato nella Sez. 3.3 a pag. 18 e seguenti. Tale modulo va adutilizzare le variabili globali di sistema contenute nei diversi moduli:• GLOBAL_m per le definizioni delle strutture dati più generali,• BH_force_m per le definizioni degli alberi e• TI_timeline_m per le definizioni della timeline per gestire l’aggiornamento parzialedelle particelle.Viene poi utilizzato solamente all’interno del ciclo di “run” per le chiamate alle sueroutine.

38 Modifiche al codice Cap. 4Figura 4.7: Schema delle inclusioni dei moduli

Sez. 4.7 Modifiche al file dei parametri 39Un’altra modifica alle inclusioni è stata l’aggiunta dei TI_predict_m all’internodi SPH_neighbour_m. Ciò è stato fatto perché nella ricerca dei vicini dovendo iterarepiù volte sulle stesse particelle per trovare il raggio corretto (si veda Sez. 4.4 apag. 30), viene modificata la lista delle particelle da aggiornare ed è perciò necessarioripristinarla una volta finita la ricerca.In figura 4.7, ripresa da [Favaretto, 6, pp. 54], si può vedere la struttura preesistentedei moduli modificata con le aggiunte sopra elencate.4.7 Modifiche al file dei parametriLe modifiche riguardanti il file dei parametri sono delle aggiunte ai parametri preesistentie reperibili in [Favaretto, 6, appendice B]. Tali aggiunte sono elencate nellatabella seguente:Parametro Valore di default DescrizioneNumberOfFiles 1DomainDecompFrequency 0.2ImbalanceTolerance 0.05ExchangePartTolerance 0.05CommSize 4Il numero di parti in cui vienespezzato ogni file durantela scrittura, sia di restart chesnapshotIndica quanti calcoli di forze devonoessere fatti prima di ridecomporrei domini. Sarebbe benefosse un multiplo di TreeUpdatingLimitin modo da non sprecaretempo per ricostruire un alberose poi vanno ridecomposti idominiIndica di quanto devono discostarsitra di loro i tempi relativi aidue blocchi del taglio perché vengaeseguito il ribilanciamento sudi essiIndica la precisione con cui individuareil numero di particelle dainviare dall’altra parte del taglioquando si è deciso di ribilanciareLa dimensione del buffer di comunicazioneglobale espressa inMB

40 Modifiche al codice Cap. 4SPHNeighbousDeviation 2MemoryFactor 2Indica di quanto può discostarsiil numero di vicini individuatoda un raggio durante la ricercada quello desiderato perché laricerca terminiIl fattore di allocazione della memoria,esprime di quante voltela memoria allocata è sovradimensionataper compensare glisbilanciamenti di carico

Capitolo 5PrestazioniDato che sul codice non sono state effettuate operazioni di ottimizzazione e vi sonoanche delle scelte non presenti in letteratura come la decisione di rendere il ribilanciamentodel carico totalmente dinamico, il codice presenta ancora delle imperfezioni dasistemare, pertanto non sono stati fatti numerosi test per valutarne le prestazioni.I test qui presenti hanno lo scopo di valutare ad un primo stadio se le scelte effettuatee l’implementazione attuale sono validi nel loro complesso ossia se sono promettentiper dare buoni risultati.Per quanto detto i test sono stati effettuati con un solo processore utilizzando ilprogramma sequenziale di partenza per questa tesi, con quattro e con otto processori,non sono state fatte invece con un maggior numero di processori. Esistono infattiancora delle instabilità negli algoritmi da aggiustare.Tutte le simulazioni sono state effettuate su una macchina IBM RS/6000 SP con 4nodi da 4 processori ciascuno, processori Power3-II da 375MHz con 8MB di cache L2ciascuno e 2GB di ram per nodo acquistata di recente dal Dipartimento di Elettronicae Informatica della Facoltà di Ingegneria di Padova (per ulteriori informazioni sullamacchina o sulla sua configurazione si rimanda a [Benini, 5] e [Mazzon, 4]).Nota: il tempo “Totale” per il programma parallelo è sempre riferito alla sommadei tempi impiegati da tutti i processori coinvolti nella simulazione.Tutti i test derivano da una simulazione di una porzione significativa di universo abassa risoluzione eseguita in passato. Su di essa sono state individuate delle zone incui si sono formati degli ammassi di galassie. A questo punto partendo dalle stessecondizioni iniziali sono state sostituite alcune particelle a bassa risoluzione con dellealtre a risoluzione molto più elevata per poter andare a studiare più in dettaglio laformazione di queste particolari strutture.Le condizioni iniziali descrivono quindi tutte una sfera di circa 700 Mpc di diametrocontenente una buona prozione di universo a bassa risoluzione e al cui interno sitrova una zona di circa 50 Mpc ad alta risoluzione che andrà a formare le strutture inesame.Il primo test effettuato riguarda l’analisi di un singolo ammasso di galassie centratonella sfera di simulazione con 75000 particelle ad alta risoluzione e 49000 a bassarisoluzione da redshift (vedi glossario) z=35 a z=0. Nella tabella 5.1 si possono vedere

42 Prestazioni Cap. 5Monoprocessore 4 processori 8 processoriTotale (s) Rel. (%) Totale (s) Rel. (%) Totale (s) Rel. (%)Totale 49641 100.0 55643 100.0 59713 100.0Potenziale 4822 9.7 4795 8.6 4608 7.7Gravitazionale 39863 80.3 39039 70.2 40694 68.2Costruzione tree 4243 8.5 5020 9.0 2754 4.6Decomposizione 1013 1.8 1077 1.8Comunicazioni 137 0.2 887 1.5Sbilanciamento 4646 8.3 7344 12.3Varie ∼600 1.2 ∼600 1.1 ∼700 1.2Tabella 5.1: Risultati della simulazione con solo materia oscura di un ammasso digalassie ad alta risoluzione e un contorno a bassa risoluzioneMonoprocessore 4 processori 8 processoriTotale (s) Rel. (%) Totale (s) Rel. (%) Totale (s) Rel. (%)Totale 192402 100.0 216175 100.0 218133 100.0Potenziale 17249 9.0 17511 8.1 17291 7.9Gravitazionale 151038 78.5 143210 66.2 146723 67.3Costruzione tree 20265 10.5 39626 18.3 28684 13.1Decomposizione 6234 2.9 4783 2.2Comunicazioni 393 0.2 2412 1.1Sbilanciamento 6710 3.1 12558 5.8Varie ∼2450 1.3 ∼2600 1.2 ∼2500 1.2Tabella 5.2: Risultati della simulazione con solo materia oscura di due ammassi digalassie ad alta risoluzione e un contorno a bassa risoluzionea confronto i vari tempi impiegati nella varie zone del codice con a fianco le percentualirispetto al totale.Nella tabella 5.2 invece si possono vedere a confronto i tempi impiegati per simularel’evoluzione di due ammassi di galassie ad alta risoluzione descritte usando369000 particelle e un contorno a bassa risoluzione sempre con 49000 particelle, iltutto sempre centrato nella sfera con intervallo temporale da z=35 a z=0. Entrambequeste prime due simulazioni contengono solo elementi di materia oscura, quindisenza materia barionica e forze idrodinamiche.Nella voce “Varie” vengono raggruppate tutte quelle elaborazioni che richiedonoun ridotto ammontare di calcolo quali l’avanzamento delle particelle, la loro predizionemediante linearizzazione e la scrittura di file.Si può vedere come per entrambe queste simulazioni il tempo aggiuntivo introdottonella decomposizione, dalle comunicazioni e dallo sbilanciamento del carico tra i variprocessori raggiunge un massimo del 15% nella prima simulazione con 8 processori edel 10% nella seconda con un numero più elevato di particelle.Per quanto riguarda le forze gravitazionali o il calcolo del potenziale si notanoaddirittura delle riduzioni del tempo impiegato per eseguire i calcoli utilizzando la versioneparallela. Molto più variabile risulta invece la costruzione degli alberi risultando

43Monoprocessore 4 processori 8 processoriTotale (s) Rel. (%) Totale (s) Rel. (%) Totale (s) Rel. (%)Totale 71668 100.0 112420 100.0 126154 100.0Idrodinamica 12750 17.8 12425 11.0 15183 12.0Potenziale 4287 6.0 7216 6.4 6991 5.5Gravitazionale 43559 60.8 49069 43.6 50144 39.7Costruzione tree 9776 13.6 29664 26.4 19734 15.6Decomposizione 1072 1.0 1505 1.2Comunicazioni 410 0.4 3913 3.1Sbilanciamento 7564 6.7 23422 18.5Ricerca dei vicini 3887 3.5 4706 3.7Varie ∼1000 1.4 ∼1000 0.9 ∼900 0.7Tabella 5.3: Risultati della simulazione di un ammasso di galassie ad alta risoluzionedescritto sia con materia oscura che con materia barionica circondato da materia oscuraa bassa risoluzionemolto migliore nella prima simulazione e molto peggiore nella seconda.Per quanto riguarda la scalabilità nel passaggio dal sequenziale al parallelo si puònotare che passando a quattro processori il tempo totale 1 cresce del 12% circa mentrenel passaggio a otto processori l’incremento risulta del 20% nel primo caso e del 13%nel secondo.Tali risultati sono incoraggianti per il continuamento dello sviluppo del codice infavore della parallelizzazione.Nella tabella 5.3 invece viene presentata una simulazione contenente anche dellamateria barionica con quindi le forze idrodinamiche. In particolare si tratta della stessasimulazione di un singolo ammasso di galassie effettuata nel primo test in cui sono stateaggiunte delle particelle di gas in corrispondenza delle particelle di materia oscura adalta risoluzione. Qui la simulazione è stata svolta da z=35 a z=0.5 .Qui con l’aggiunta delle particelle di gas i tempi peggiorano sensibilmente, in particolareper lo sbilanciamento che passa al 18% del totale per il caso con otto processori.Qui il peggioramento nel passaggio dal programma sequenziale al parallelo risulta del76% nel caso a otto processori.Da quest’ultima simulazione si può vedere come sia ancora necessario stabiliremeglio le strategie di ribilanciamento per ridurre il tempo inutilizzato nell’attesa tra iprocessori.Sempre buono risulta invece il tempo utilizzato per effettuare la decomposizionedei domini validando l’ipotesi che utilizzare un metodo differenziale per ribilanciare ilcarico è promettente.Un’altra cosa che risulta da questi test è che il tempo utilizzato nella ricostruzionedegli alberi risulta generalmente maggiore nel programma parallelo indicando chesono effettuate più ricostruzioni degli alberi. Questo spinge verso la ricerca di quandovengono fatte queste ricostruzioni aggiuntive in modo da ridurne l’impatto sulleprestazioni.1 si ricorda che il tempo totale è sempre dato dalla somma dei tempi impiegati da tutti i processori

44 Prestazioni Cap. 5Viene infine riportata un’immagine (Figura 5.1), generata a partire dalla simulazionedi due galassie ad alta risoluzione con sola materia oscura (seconda simulazione),raffigurante il sistema a redshift zero, ossia allo stato finale.

Figura 5.1: Immagine a redshift zero di una simulazione con due ammassi di galassiead alta risoluzione con sola materia oscura45

46 Prestazioni Cap. 5

Capitolo 6ConclusioniLa parallelizzazione di un codice richiede uno studio approfondito del codice originalee successivamente di effettuare scelte sulle strategie utilizzabili per distribuireil lavoro tra i processori coinvolti. In questo lavoro si è analizzato un codice utilizzatoper la simulazione di sistemi fisici avente lo scopo di ricerca scientifica in ambito cosmologico.Sono stati considerati gli algoritmi utilizzati in tale codice e le modificheapportate per renderlo parallelo. Il risultato è un codice funzionante su cui sono statefatte delle simulazioni di prova.Sono state fatte scelte nuove per il tipo di codice elaborato come la gestione delribilanciamento mediante un algoritmo dinamico che va a minimizzare la differenza ditempo utilizzato dai diversi processori per svolgere il loro lavoro.Il lavoro non è tuttavia finito in quanto è necessario procedere sia ad una ottimizzazionedel codice andando ad analizzare più a livello macchina il suo comportamento,sia ad un raffinamento delle tecniche di definizione dei domini per aumentare le prestazionirispetto alla scalabilità e allo stesso tempo evitare l’istaurarsi di anomalie o dioscillazione di particelle tra i processori durante la simulazione.

48 Conclusioni Cap. 6

Appendice AGlossarioAAstrofisica Disciplina che studia la fisica oggetti astronomici come le stelle e le galassie.BBarioni vedi Materia barionica.Big Bang Il modello del Big Bang prevede un universo in espansione a partire da unpunto iniziale estremamente caldo e denso. L’istante iniziale è chiamato “grandeesplosione” o “Big Bang”.CCluster (o ammasso di galassie) Le più grandi strutture cosmiche gravitazionalmentelegate. Sono composte da almeno un centinaio di galassie, gas e materiaoscura.Condizioni iniziali Insieme di dati necessari per definire l’universo alle sue originie permettere quindi l’esecuzione di una simulazione. Esse contengono una descrizionedel fluido primordiale piccole fluttuazioni al suo interno (vedi Originedell’universo).Conservazione Si dice di quantità (carica elettrica, energia, quantità di moto...) cherimane costante nel tempo.Cosmologia Parte dell’astrofisica che si occupa della formazione ed evoluzione dell’universo.DDoppler, effetto Effetto che causa il cambiamento di frequenza delle onde emesse daun oggetto in movimento rispetto ad un altro e permette di misurare la velocitàdi allontanamento o avvicinamento dei due oggetti. Si può riscontrare nelle

50 Glossario Appendice AGonde sonore, come ad esempio una sirena che passa, o nella luce delle galassienell’universo in espansione.Galassie Sistema legato gravitazionalmente contenente vari miliardi di stelleGas vedi Materia barionicaHHubble, costante di L’universo osservabile è ritenuto uniforme in tutto le direzione ein espansione. Questa espansione è descrivibile per mezzo di un solo parametro.La costante di Hubble è data dalla velocità media di allontanamento di dueregioni qualsiasi dell’universo divise per la distanza che le separa.IInterazione La forza esercitata reciprocamente da due particelle soggette ad un qualchecampo, quale ad esempio il campo gravitazionale.JJob, file di File di testo contenente le direttive per la richiesta a LoadLeveler (vedi) dirisorse di calcolo.LLoadLeveler Sistema di gestione utilizzato su un multiprocessore per allocare i lavoridegli utenti sui vari processori disponibili distribuendo il carico in modoottimale.MMateria barionica Particelle pesanti che costituiscono la materia visibile dell’universo.Questa materia è composta principalmente da idrogeno ed elio con tracce dialtri materiali pesanti. Spesso i termini materia barionica e gas vengono utilizzaticome sinonimi, anche se non è propriamente corretto.Materia oscura Materia esistente nello spazio ma non visibile a noi perché non emettealcuna radiazione che la renda osservabile. La sua esistenza viene data dalleleggi di gravitazione per spiegare il movimento delle stelle attorno ai centri dimassa delle galassie a cui appartengono. Si presume che circa il 90% dellamateria sia oscura e che tale materia si estenda anche tra le galassie.MPI Message Passing Interface. È lo standard definito dall’omonimo Forum per lacostruzione di un’interfaccia di comunicazione basata sul paradigma “messagepassing” che sia pratica, portabile, efficiente e flessibile.

51Multiprocessore Sistema al cui interno si trovano più processori, utilizzato per distribuireil carico su di essi in modo da diminuire il tempo di attesa per ottenere irisultati finali.OOrigine dell’universo La teoria attuale sostiene che nell’universo subito dopo il BigBang (vedi) si sono formate delle piccole fluttuazioni di densità tali da causare,sotto l’effetto della gravità del fluido stesso, delle grosse disomogeneitàosservate oggi nella struttura visibile dell’universo.PParsec Unità di distanza (simbolo pc), pari a circa 3,26 anni luce. È usata per il calcolodelle distanze in ambito cosmologico, di solito i suoi multipli kpc e Mpc.Particella Nel nostro programma un qualsiasi corpo dotato di massa che entra nellasimulazione.Processo Un programma o comando che va effettivamente in esecuzione sulla macchinaed esegue il lavoro cui è destinato.RRedshift Spostamento verso il rosso nella luce emessa da galassie lontane. Esso ècausato dall’effetto Doppler (vedi) per cui è funzione della velocità relativa tradue galassie. Poiché l’universo è in continua espansione dal momento del BigBang (vedi), dalla teoria si sa che le galassie a noi più lontane si muovono convelocità relativa maggiore e la luce che da loro ci giunge proviene da istantitemporali più remoti. Pertanto in cosmologia per indicare il tempo si usa ilredshift.SSnapshot File generati dal programma durante una simulazione rappresentanti dellevere e proprie fotografie del sistema simulato, sono usati per analisi postsimulazione,permettono inoltre il riavvio della simulazione.SP IBM RS/6000 SP. Sistema scalabile organizzato in varie configurazioni che fornisceun sistema di calcolo multiprocessore ad elevata potenza.Submit Operazione con la quale un file di job viene sottoposto a LoadLeveler perl’esecuzione.

52 Glossario Appendice A

Appendice BUtilizzo del codiceDato che il codice parallelo richiede un’architettura particolare a multiprocessore eun sistema di gestione per l’utilizzo efficiente di tali risorse. Sulla macchina utilizzataper effettuare i test è presente come allocatore LoadLeveler (per ulteriori informazionisi rimanda a [LoadLeveler, 3]).Qui verranno illustrate le procedure per avviare il nostro programma sotto taleallocatore.Innanzitutto è necessario creare il file dei parametri per la simulazione che si intendeeseguire come per il programma sequenziale con l’aggiunta dei parametri indicatinella Sez. 4.7 a pag. 39. Successivamente è necessario creare un “file di job” dasottomettere al LoadLeveler per consentirgli di eseguire il nostro programma.Un tale file può avere la struttura seguente:#@ job_name = inSPHector#@ job_type = parallel#@ environment = MP_SHARED_MEMORY=yes#@ node_usage = NOT_SHARED#@ class = long#@ blocking = 4#@ error = /ext/Filippo/pardark1/error.txt#@ output = /ext/Filippo/pardark1/out.txt#@ network.MPI = css0, , US#@ total_tasks = 8#@ queue/home/gioachin/F-Sph /home/gioachin/dark1.paramCon tale file andiamo a chiedere al LoadLeveler di allocarci un programma su ottoprocessori (total_task) utilizzando 4 processori per ogni nodo (blocking) in modoesclusivo (node_usage). Questo evita che possano essere allocati altri programmi suinodi che stiamo usando, sappiamo che ci sono 4 processori per nodo e li vogliamousare in esclusiva.

54 Utilizzo del codice Appendice BChiediamo poi di utilizzare lo switch ad alte prestazioni per effettuare le comunicazionitra i nodi (network.MPI) e di usare invece la Shared_Memory per le comunicazioniall’interno dello stesso nodo (environment).Dichiariamo poi che il nostro programma è parallelo (job_type) e che necessita dilunghi tempi di calcolo (class) e chiediamo che i file di output e di error siano salvatidove desiderato (output e error), è buona norma che questi si trovino nella stessadirectory indicata nel file dei parametri per salvare gli altri file della simulazione inmodo da averli tutti assieme.Infine andiamo ad accodare il job appena creato (queue).L’ultima riga serve perché l’eseguibile è per default il file che contiene il file di jobe in questo modo andiamo a chiedere di eseguire su tutti i processori il programma danoi voluto: ossia la nostra simulazione.Per avere la descrizione di tutti i comandi utilizzati e di tutti gli altri disponibili sirimanda a [LoadLeveler, 3].In seguito è necessario chiedere a LoadLeveler di far partire il nostro programmaparallelo mediante il seguente comando:gioachin@spnd01:~$ llsubmit dark1.jobdove dark1.job è il file prima creato e al quale LoadLeveler risponde con il seguentemessaggio se tutto è andato correttamente:llsubmit:The job “spnd01.470” has been submitted.Ora dobbiamo attendere che si liberino i processori che abbiamo richiesto e che ilprogramma poi svolga il suo lavoro.Per ulteriori informazioni su come amministrare poi il job appena sottomesso sirimanda a [Mazzon, 4].

Bibliografia[Aoyama, 1][MPI, 2]Y. Aoyama, J. Nakano, RS/6000 SP: Practical MPI Programming,ITSO (1999)MPI: A Message-Passing Interface Standard 1.1, University ofTennessee, Knoxville, 1995[LoadLeveler, 3] LoadLeveler 2.2: Using and Administering, IBM Corp., 2000[Mazzon, 4][Benini, 5][Favaretto, 6][Springel, 7][Lia, 8][Tormen, 9]P. Mazzon, Progetto di un Laboratorio per la Programmazione diMultiprocessori, Università di Padova, tesi di laurea, 2002D. Benini, Configurazione e messa in opera di un multiprocessoreIBM RS/6000 SP3, Università di Padova, tesi di laurea, 2002R. Favaretto, Ottimizzazione di un codice tree-sph, Università diVeneria, tesi di laurea, 2000V. Springel, N. Yoshida, S. D.M. White, GADGET: a code forcollisionless and gasdynamical cosmological simulations, NewAstronomy, Vol. 6, pp. 79-117, 2001C. Lia, G. Carraro, A Parallel Tree-SPH Code for Galaxy Formation,MNRAS, Vol. 314, pp. 145-161, 2000G. Tormen, F. R. Bouchet, S. D. M. White, The structure and dynamicalevolution of dark haloes, MNRAS, Vol. 268, pp. 865-884,1997