4.1 Modalità di lettura dal file di di Relap prima della realizzazione della libreria

(1)

C a p i t o l o 4

PRESTAZIONI IN LETTURA

4.1 Modalità di lettura dal file di

restart

di Relap prima della

realizzazione della libreria

Prima della realizzazione della libreria HDFRelapReader, venivano utilizzate per la lettura di dati del file di restart di Relap due possibili modalità differenti:

- La prima modalità prevedeva l’utilizzo di software, i quali, una volta caricato l’intero file di restart, si occupavano di costruire un modello 2D che permetteva di visualizzare graficamente le variabili di interesse. Il problema è che, essendo le dimensioni del file di restart dell’ordine dei 1,5 – 2 GB, il tempo per accedere ai dati risultava essere, nel caso migliore, di un minuto (accesso e costruzione del modello).

- La seconda modalità, detta procedura di strip, prevedeva in un primo tempo l’estrazione di un sottoinsieme di dati riguardanti determinate variabili (quantità + nodo) di interesse dal file di simulazione completo, la generazione di un altro file con il sottoinsieme di dati selezionato e, come nel caso precedente, la costruzione di un modello 2D per la visualizzazione. Il problema, in questo caso, risiedeva nel fatto che, nonostante l’accesso alla

(2)

porzione di dati interessati risultasse più veloce, la generazione del file contenente tale porzione richiedeva un certo tempo e tale tempo doveva essere speso ogni qualvolta si rendesse necessario cambiare l’insieme di variabili da monitorare. Inoltre, il numero di variabili monitorate per strip poteva essere al massimo 999; era certo possibile generare più strip per avere la possibilità di mantenere tempi rapidi su un numero di variabili maggiore, ma non era possibile incrociare i dati delle porzioni separate.

4.2 Obiettivo delle prove di lettura

Prima di procedere all’utilizzo effettivo del formato HDF nel progetto, secondo l’organizzazione mostrata nel capitolo 2, era necessario verificare che proprio la scelta di utilizzare il formato di file HDF fosse giustificata da prestazioni in lettura decisamente migliori di quelle ottenute secondo le modalità descritte nel paragrafo 4.1. Questo perché la necessità di ottenere letture dei dati “immediate” era un requisito fondamentale per l’utilizzabilità del prototipo da sviluppare.

Inoltre, poiché il lavoro di creazione della libreria di lettura oggetto di questa tesi procedeva di pari passo con quello di creazione della libreria di scrittura, un altro scopo legato ai test effettuati su alcuni metodi di lettura era quello di mostrare quale tra i tipi di allocazione dei

(3)

dati sul file HDF (contiguo o chunked) portasse ad ottenere prestazioni migliori in lettura.

4.3 Struttura generale di un dataset

Le tabelle da cui si vogliono prelevare dati nelle operazioni di lettura si trovano nel gruppo SIMULATIONS/RELAP/OUT/restart. Tale gruppo contiene un numero variabile di gruppi (N), uno per ogni restart della simulazione; all’interno di ognuno di essi vi sono i gruppi che identificano le categorie delle diverse quantità e, dentro questi, proprio le quantità stesse (Figura 4.1).

Fig. 4.1 – Percorso dei dati da leggere

Le dimensioni di una tabella associata ad una quantità variano in base ai nodi in cui la quantità viene misurata ed al numero di istanti dello

(4)

specifico restart della simulazione. Si possono trovare restart della durata di un solo istante temporale così come restart di anche 3000 istanti temporali. Ovviamente le prove più significative dei metodi di lettura sono quelle per la ricerca di dati all’interno di tabelle di grandi dimensioni, costituite da circa 3000 righe per 5000 colonne. In Figura 4.2 si può vedere un esempio di porzione di tabella associata ad una quantità, in questo caso la quantità p della categoria volume.

Fig. 4.2 – Porzione della tabella dei valori associati alla quantità p della categoria volume

(5)

4.4 Prove di lettura

Nei paragrafi seguenti vengono illustrate le modalità utilizzate per svolgere delle prove di lettura ed i risultati ottenuti.

4.4.1 Metodi oggetto delle prove

Le prove di lettura sono state effettuate su 4 metodi dell’interfaccia RelapReader; tali metodi sono:

 RelapReader.getTimeValue(quantity, node): ricerca la coppia

formata da quantità e nodo passata come argomento e restituisce i valori misurati ad ogni istante insieme al valore dell’istante stesso. Il tempo di esecuzione di tale metodo risulta, come visibile dalla serie di grafici più avanti, tale da giustificare l’utilizzo di tabelle allocate in formato chunked; questo perché, a differenza degli altri metodi per i quali la semplice archiviazione per riga su HDF risultava ottima per migliorare le prestazioni descritte nel paragrafo 4.1, il metodo in questione presentava tempi di esecuzione molto elevati (comunque non paragonabili a quelli riportati nel paragrafo 4.1) e, pertanto, non soddisfacenti.

 RelapReader.getQuantityValue(node, timeIndex): ricerca il

nodo passato come primo argomento all’interno delle tabelle nodes di ogni quantità e, se tale nodo è presente, restituisce il valore associato alla quantità all’istante che si trova all’indice passato come secondo argomento del metodo nella tabella dei tempi. Infatti, come detto nel capitolo 2, gli istanti di una simulazione si trovano all’interno di una tabella in forma di array,

(6)

precisamente time nella categoria general; poiché passare ai metodi il valore dell’istante risultava troppo complesso per un utilizzatore (si tratta di numeri con molte cifre decimali), si è preferito utilizzare gli indici dell’array time per definire un dato istante.

 RelapReader.getNodeValue(quantity, timeIndex): ricerca la

quantità passata come primo argomento e restituisce i valori della quantità stessa in ogni nodo all’istante temporale passato come secondo argomento.

 RelapReader.getValue(quantity, node, timeIndex):

restitui-sce un singolo valore per la quantità passata come primo argomento del metodo, al nodo passato come secondo argomento e nell’istante passato come terzo argomento.

4.4.2 Ambiente e metodologia delle prove

Le diverse prove sono state effettuate su tre files di simulazione di Relap, memorizzati nel formato HDF in 7 differenti versioni per ciascuno, a seconda della dimensione dei chunk scelta per l’allocazione dei dataset ed in modo da verificare anche quanto la dimensione delle tabelle, dipendente dal tipo di restart, potesse incidere sulle prestazioni delle operazioni di lettura. I 21 risultati, 3 file di restart per 7 dimensioni dei chunk, ottenuti per ogni metodo sono stati poi raggruppati, calcolando la media, in un unico grafico che rappresentasse l’andamento generico dei tempi di accesso e prelievo dei dati.

I files originali del simulatore sono:

- 15631a5Nasapr.h5

(7)

- CL2_2ALOCA_BPos1_025A.h5

Fig. 4.3 – Dimensioni dei file di test in relazione al tipo di allocazione scelto

Il computer utilizzato per le prove presentava le caratteristiche seguenti:

Processore INTEL CORE2 DUO CPU T6570 2,10 GHZ, RAM 4 GB, OS WINDOWS 7 64 bit

Ovviamente i tempi di accesso al dato e di lettura variano in base al tipo di macchina utilizzata per svolgere le diverse operazioni. Inoltre le dimensioni dei files stessi utilizzati per i test variano in base alla dimensione del chunk selezionato in fase di scrittura, come mostrato in Figura 4.3.

Occorre distinguere due procedure differenti svolte, una per il calcolo dei tempi medi ed una per il calcolo dei tempi massimi di esecuzione. Nel caso dei tempi medi i passi eseguiti sono stati i seguenti:

1) Sono stati considerati tre file di restart di Relap (vedere sopra). 0 500.000 1.000.000 1.500.000 2.000.000 2.500.000 KB

Dimensione dei file

CL2_2ALOCA_BPos1_025A .h5

CL2_2ALOCA_Pos1BOT_1e -2.h5

(8)

2) Per ciascuno di questi sono state generate 7 versioni in HDF5, ciascuna con un diverso metodo di chunking.

3) Per ciascun file di restart è stato estratto l’elenco delle quantità simulate e sono stati scelti arbitrariamente un nodo associato a ciascuna con un istante di simulazione ed il relativo indice. Questi dati sono stati memorizzati in un file contenente N righe (una per ciascuna quantità). Ogni riga è formata da 4 campi: quantity, node, timestep, timeIndex

4) Per ogni file di restart e su ciascuna delle 7 versioni vengono invocati i 4 metodi di lettura.

5) Ogni metodo viene invocato N volte, usando ogni volta i parametri della riga corrispondente nel file di test.

6) Viene misurato il tempo di esecuzione di ciascuna invocazione

t

_mrvn

dove:

m indica il metodo 1 <= m <= 4

r indica il numero di file di restart 1 <= r <= 3

v indica la versione del file in base al chunking scelto 1 <= v <= 7

n indica il numero di riga nel file di test 1 <= n <= N 7) Si calcola la media su n come

t

_{mrv =}

(1/N) ∑ t

_mrvn

8) Ripetizione dei passi da 5) a 7) per 10 volte, ottenendo

T

(i)

mrv con i = 1…10

9) Per ogni i si calcola la media su r:

T

(i)*

(9)

Che rappresenta il valore finale ottenuto nel calcolo dei tempi medi di esecuzione.

Nel caso dei tempi massimi, riportati poi nei grafici seguenti, la procedura comprendeva i seguenti passi:

1) Stesse azioni svolte dai punti 1) a 6) nel caso del calcolo dei tempi medi.

2) Prelievo del valore massimo sulle N invocazioni

T

max

mrv

= max

1<=n<=N

(t

mrvn

)

3) Stesse azioni svolte nel calcolo dei tempi medi dal punto 8) al punto 10), ottenendo:

T

max(i)

mv

= (1/3) ∑

r

T

max(i)mrv

4.4.3 Dimensioni dei chunk riportate nei grafici

Una precisazione sulle dimensioni dei chunk che si trovano indicate nei diversi grafici: quando si trova un chunk di dimensione NxN, significa che la tabella con i valori associati ad una determinata quantità viene suddivisa, per la memorizzazione in fase di scrittura, in blocchi di NxN dati. Inoltre quando si trova indicato 1xnumCol significa che ogni chunk corrisponde ad una riga, perciò risulta che i dati sulla stessa riga sono contigui, mentre quelli lungo una colonna non lo sono, portando a tempi di lettura per riga molto veloci ed a tempi di lettura per colonna molto lenti.

(10)

4.4.4 Andamento dei tempi massimi di esecuzione

I grafici seguenti mostrano i risultati delle prove effettuate sui 4 metodi di lettura. Per ognuno di essi vengono mostrati 2 grafici: il primo mostra l’andamento dei tempi massimi di esecuzione per le 10 ripetizioni sul totale delle chiamate al metodo, uguale al numero delle quantità del restart letto, mentre il secondo mostra il caso peggiore tra i tempi massimi di esecuzione sulle 10 ripetizioni.

Tutti i grafici riportano la media dei valori dei tempi massimi di lettura dai tre file di restart selezionati per i test, ossia, nel primo grafico dei tempi massimi, ad esempio, l’andamento è il risultato della media dei massimi tempi di esecuzione di un metodo sul file 15631a5Nasapr.h5, insieme a quelli ottenuti sul file CL2_2ALOCA_Pos1BOT_1e-2.h5 ed a quelli calcolati sul file CL2_2ALOCA_BPos1_025A.h5.

1)

Metodo getTimeValue(quantity, node)

Restituisce i valori della quantità passata come primo parametro, al nodo passato come secondo parametro, per ogni step temporale della simulazione, insieme al tempo stesso.

(11)

Fig. 4.4 - Tempi massimi di esecuzione del metodo getTimeValue.

Dalla Figura 4.4 si può notare come la prima esecuzione “cold” sia più lenta rispetto alle successive per le quali interviene il meccanismo della cache. Inoltre in questo caso la differenza delle prestazioni in lettura tra un file memorizzato per riga e uno chunked NxN è notevole.

Infatti, con riferimento alle Figure 2.4 e 2.5 del Capitolo 2, si ricorda che, nel caso di prelievo di dati contigui su una riga di una tabella, il tempo di accesso risulta molto breve, mentre nel caso di prelievo di dati su una colonna, tale tempo è M volte maggiore, con M numero di righe della tabella. Il metodo getTimeValue ricerca i valori di una quantità su un nodo per tutti i passi temporali della simulazione, pertanto, nel caso di scrittura per riga (riportata in figura come 1xnumCol), per avere l’insieme di dati cercato dal metodo, che si trovano lungo una colonna determinata dall’indice del nodo passato come parametro, occorre caricare tutte le righe, ognuna della quali forma un blocco, perciò tutta la tabella, con la conseguenza di ottenere tempi di esecuzione molto elevati (circa 20 secondi per la prima esecuzione).

0 5000 10000 15000 20000 25000 1 2 3 4 5 6 7 8 9 10 Te m po (m s) Numero di ripetizione

Tempi massimi

metodo getTimeValue(quantity, node)

1xnumCol 25x25 50x50 100x100 150x150 200x200 500x500

(12)

In Figura 4.5 è mostrato il caso peggiore.

Fig. 4.5 – Worst case per i diversi tempi massimi di lettura

2) Metodo getQuantityValue(node, timeIndex)

Restituisce tutti i valori delle diverse quantità, insieme alle quantità stesse, misurati al nodo passato come primo argomento ed al tempo specificato come secondo argomento. In Figura 4.6 i tempi massimi ed in Figura 4.7 è mostrato il caso peggiore.

0 2000 4000 6000 8000 10000 12000 14000 16000 18000 20000 Te m po (m s)

Tempi massimi: worst case

metodo getTimeValue(quantity, node)

1xnumCol 25x25 50x50 100x100 150x150 200x200 500x500

(13)

Fig. 4.6 – Tempi massimi di esecuzione del metodo getQuantityValue

Si noti, anche in questo caso, come la prima esecuzione “cold” sia più lenta rispetto alle successive per le quali interviene il meccanismo della cache.

0 200 400 600 800 1000 1200 1 2 3 4 5 6 7 8 9 10 Te m po (m s) Numero di ripetizione

Tempi massimi

metodo getQuantityValue(node, timeIndex)

1xnumCol 25x25 50x50 100x100 150x150 200x200 500x500 0 200 400 600 800 1000 1200 T em po (m s)

Tempi massimi: worst case

metodo getQuantityValue(node, timeIndex)

1xnumCol 25x25 50x50 100x100 150x150 200x200 500x500

(14)

3) Metodo getNodeValue

Restituisce tutti i valori per ogni nodo, insieme al nodo stesso, per la quantità passata come primo argomento, al tempo passato come secondo argomento.

Fig. 4.8 – Tempi massimi di esecuzione del metodo getNodeValue

Nelle Figure 4.8 e 4.9 si può vedere rispettivamente l’andamento dei tempi massimi ottenuti dalle 10 esecuzioni ed il caso peggiore sui diversi tempi massimi.

0 20 40 60 80 100 120 140 160 1 2 3 4 5 6 7 8 9 10 T em po (m s) Numero di ripetizione

Tempi massimi

metodo getNodeValue(quantity, timeIndex)

1xnumCol 25x25 50x50 100x100 150x150 200x200 500x500

(15)

4) Metodo getValue

Restituisce un valore singolo, quello misurato per la quantità passata al metodo come primo argomento, al nodo passato come secondo argomento, all’istante passato come terzo argomento.

Nelle Figure 4.10 e 4.11, anche in questo caso, sono mostrati i tempi massimi per le diverse esecuzioni ed il caso peggiore ottenuto tra i tempi massimi stessi. 0 50 100 150 200 250 Te m po (m s)

Tempi massimi: worst case

metodo getNodeValue(quantity, timeIndex)

1xnumCol 25x25 50x50 100x100 150x150 200x200 500x500

(16)

Fig. 4.10 – Tempi massimi di esecuzione del metodo getValue

4.5 Risultati delle prove

Dalle diverse prove effettuate si può vedere come la scrittura delle tabelle in formato chunked NxN presenti vantaggi in termini di tempi

0 50 100 150 1 2 3 4 5 6 7 8 9 10 T em po (m s) Numero di ripetizione

Tempi massimi

metodo getValue(quantity, node, timeIndex)

1xnumCol 25x25 50x50 100x100 150x150 200x200 500x500 0 20 40 60 80 100 120 140 160 Te m po (m s)

Tempi massimi: worst case

metodo getValue(quantity, node, timeIndex)

1xnumCol 25x25 50x50 100x100 150x150 200x200 500x500

(17)

d’accesso al dato, specialmente, come già accennato, in relazione al primo dei metodi testati; questo fatto, da solo, in relazione anche all’importanza attribuita al metodo, che cerca i dati associati ad una quantità in un nodo, giustifica la decisione di adottare come modalità di scrittura delle tabelle del file HDF quella chunked NxN. Tale tipo di allocazione ha come conseguenza rispetto a quella tradizionale, una variazione della dimensione del file HDF risultante (si veda la figura 4.3) dalla scrittura, ma tale variazione è comunque praticamente irrilevante ed inoltre non sempre si tratta di un incremento delle dimensioni del file su disco.

È stato deciso di scegliere come tipo di allocazione in fase di scrittura del file HDF, quello che prevede la creazione di tabelle con chunk di dimensione 100x100, in quanto rappresentava il migliore compromesso per ottenere buoni tempi di esecuzione per tutti i diversi metodi di lettura dei dati, anche se le prestazioni risultavano comunque ottime in generale con quasi tutte le dimensioni dei chunk testate.

Si nota anche come le prestazioni, per lo stesso metodo, non variano in base al contenuto del file di simulazione, ma solamente in base al tipo di allocazione, in altre parole, solamente in base al tipo di chunk scelto in scrittura.