tesi di laurea - Riccardo Cecolin

1. `
Universita Degli Studi di Trieste
`
Facolta di Ingegneria
Dipartimento di Elettrotecnica, Elettronica ed Informatica
Tesi di Laurea in
Sistemi Operativi
Monitoraggio di applicazioni software
mediante modelli di Markov
Laureando : Relatore :
Riccardo CECOLIN Chiar.mo Prof. Enzo MUMOLO
Anno Accademico 2009-2010

3. Indice
1 Introduzione 7
1.1 Struttura della tesi . . . . . . . . . . . . . . . . . . . . . . . . 9
2 Concetti preliminari 11
2.1 Prestazioni di un sistema di calcolo . . . . . . . . . . . . . . . 11
2.2 Tracce di indirizzi . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 Parametrizzazione delle tracce . . . . . . . . . . . . . . . . . . 13
2.4 I Modelli di Markov Nascosti . . . . . . . . . . . . . . . . . . 16
3 Valgrind 19
3.1 Coregrind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3 Cachegrind, analisi di un tool . . . . . . . . . . . . . . . . . . 21
3.4 Sviluppo di un Tool . . . . . . . . . . . . . . . . . . . . . . . 22
3.5 Modifiche a Coregrind . . . . . . . . . . . . . . . . . . . . . . 23
3.5.1 Wrapper interno . . . . . . . . . . . . . . . . . . . . . 24
3.5.2 Thread wrapper . . . . . . . . . . . . . . . . . . . . . 24
3.5.3 Thread injection . . . . . . . . . . . . . . . . . . . . . 25
3.5.4 External state . . . . . . . . . . . . . . . . . . . . . . 25
4 Spec 27
4.1 CPU2006 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.1.1 Benchmark . . . . . . . . . . . . . . . . . . . . . . . . 27
4.1.2 Speed Ratio . . . . . . . . . . . . . . . . . . . . . . . . 28
4.1.3 Throughput Ratio . . . . . . . . . . . . . . . . . . . . 28
4.2 Misurazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3 Configurazione . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.4 Esecuzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.5 Benchmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.5.1 401.bzip2 . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.5.2 445.gobmk . . . . . . . . . . . . . . . . . . . . . . . . 31
4.5.3 458.sjeng . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.5.4 403.gcc . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3

4. 4.5.5 464.h264ref . . . . . . . . . . . . . . . . . . . . . . . . 32
4.5.6 400.perlbench . . . . . . . . . . . . . . . . . . . . . . . 32
4.5.7 429.mcf . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.5.8 462.libquantum . . . . . . . . . . . . . . . . . . . . . . 32
4.5.9 456.hmmer . . . . . . . . . . . . . . . . . . . . . . . . 33
4.5.10 471.omnetpp . . . . . . . . . . . . . . . . . . . . . . . 33
4.5.11 473.astar . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.5.12 483.xalancbmk . . . . . . . . . . . . . . . . . . . . . . 33
5 Analisi delle tracce di indirizzi 35
5.1 Addestramento hmm . . . . . . . . . . . . . . . . . . . . . . . 36
5.2 Test hmm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.3 Addestramento reti neurali . . . . . . . . . . . . . . . . . . . 38
5.4 Test reti neurali . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.5 Analisi offline . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.5.1 Hmm . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.5.2 Reti neurali . . . . . . . . . . . . . . . . . . . . . . . . 40
5.6 Analisi con Valgrind . . . . . . . . . . . . . . . . . . . . . . . 40
5.6.1 Tracehmm . . . . . . . . . . . . . . . . . . . . . . . . . 41
6 Risultati sperimentali 45
6.1 Risultati test offline . . . . . . . . . . . . . . . . . . . . . . . 46
6.1.1 Test di verifica hmm . . . . . . . . . . . . . . . . . . . 46
6.1.2 Test di verifica reti neurali . . . . . . . . . . . . . . . . 47
6.2 Analisi su Valgrind . . . . . . . . . . . . . . . . . . . . . . . . 48
6.2.1 Test di verifica . . . . . . . . . . . . . . . . . . . . . . 50
6.2.2 Test di classificazione . . . . . . . . . . . . . . . . . . 50
7 Applicazioni 63
7.1 Monitoraggio e sicurezza . . . . . . . . . . . . . . . . . . . . . 63
7.1.1 Whitelist . . . . . . . . . . . . . . . . . . . . . . . . . 63
7.1.2 Blacklist . . . . . . . . . . . . . . . . . . . . . . . . . . 64
7.2 Allocazione di risorse . . . . . . . . . . . . . . . . . . . . . . . 64
7.2.1 Sistemi operativi . . . . . . . . . . . . . . . . . . . . . 64
7.2.2 Ambienti di virtualizzazione . . . . . . . . . . . . . . . 64
7.3 Implementazione . . . . . . . . . . . . . . . . . . . . . . . . . 65
7.3.1 User space . . . . . . . . . . . . . . . . . . . . . . . . . 65
7.3.2 Kernel space . . . . . . . . . . . . . . . . . . . . . . . 66
7.3.3 Virtualizzazione . . . . . . . . . . . . . . . . . . . . . 66
8 Conclusione 69
4

5. A Documentazione tools offline 71
A.1 train, test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
A.2 genset zero, genset one, ntrain, ntest . . . . . . . . . . . . . . 72
B Documentazione tools Valgrind 73
B.1 tracebin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
B.2 tracehmm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5

6. 6

7. Capitolo 1
Introduzione
Il problema principale affrontato in questa tesi ` quello della classificazione
e
dei processi in esecuzione su un calcolatore. Pi` precisamente usando misure
u
effettuate sul processo in esecuzione, nel nostro caso gli indirizzi virtuali di
accesso in memoria, sono stati addestrati dei modelli statistici di tipo Marko-
viano che descrivono il processo e che consentono di riconoscerlo durante la
sua esecuzione.
Il problema affrontato si inquadra nel campo generale della Modellazione
del carico di lavoro (Workload Modeling) che ` un argomente trattato nella
e
Ingegneria del Software. Lo scopo del Workload Modeling ` quello di fornire
e
degli strumenti che portino a migliorare le prestazioni dei sistemi di calcolo.
Ad esempio, se si riesce a riconoscere che una applicazione in esecuzione
richieder` determinate risorse, si pu` agevolare l’esecuzione preallocando le
a o
risorse richieste.
La motivazione di questo lavoro ` sia quella di definire degli algoritmi per
e
operare classificazioni dei processi in esecuzione, sia quella di realizzare delle
operazioni di tuning del sistema adattandolo ai carichi di lavoro usualmente
sopportati. Un ulteriore obiettivo ` quello di implementare delle metodologie
e
di adattamento dinamico al workload in esecuzione, ottimizzando i sistemi
pur conservandone la flessibilit`. L’approccio adottato ` quello di model-
a e
lare la sequenza di indirizzi virtuali con un Modello di Markov Nascosto
opportunamente adattato all’impiego.
Una branca dell’Ingegneria del Software si occupa di questo tipo di
analisi: accanto agli sforzi per progettare un software che ben si adatta
a una specifica architettura hardware si possono aggiungere quelli per pro-
gettare una certa architettura ottimizzata rispetto ai compiti che questa sar` a
chiamata a svolgere durante il suo impiego.
Accanto a questo livello di progetto si affianca poi un livello diretta-
mente superiore che consiste nel progetto del nucleo del S.O. che permetter` a
di gestire efficacemente questi carichi di lavoro: gestione dell’I/O su dis-
co, gestione delle risorse di memoria, gestione delle sincronizzazione IPC,
7

8. gestione del networking, ecc.
Ecco quindi nascere la necessit` di sapere il tipo di carichi in gioco e
a
la possibilit` di modellare questi workload con degli strumenti che ci per-
a
mettono poi di implementare schemi di design e tuning del sistema hard-
ware/software che materialmente eseguir` il compito richiesto.
a
Un altro obiettivo dell’Ingegneria del Software a cui ci si avvicina par-
lando di classificazione di workload ` quello della misura delle prestazioni di
e
una CPU. Anche in questo senso le aspettative sono ampie: identificazione
di aree di sviluppo e incremento di prestazioni, monitoraggio di richieste di
risorse, identificazione di colli di bottiglia del software.
Il problema
La classificazione dei workload non ` un’operazione semplice perch` presup-
e e
pone di poter accedere a informazioni sul processo che spesso non possiamo
reperire senza turbare l’esecuzione stessa del processo. Sviluppare degli stru-
menti software che monitorizzano alcuni parametri di esecuzione di work-
load pu` essere molto difficile, fermo restando sempre il pericolo di falsare la
o
misura che si sta operando. L’idea quindi ` di usare delle metriche di misura
e
che non turbino l’esecuzione e che possano essere facilmente elaborate, suc-
cessivamente, per un’analisi e uno studio a posteriori. A questo scopo una
metodologia che sembra opportuna ` quella di estrarre delle informazioni su
e
tipo e quantit` di richiesta di risorse di memoria durante l’esecuzione di un
a
processo, cio` quella di estrarre da un processo in esecuzione la sequenza
e
degli indirizzi virtuali, che possono costituire tracce di indirizzi. Queste
informazioni possono essere memorizzate su memorie di massa e rese di
pubblico dominio, come fatto da diverse organizzazioni come il Performance
Evaluation Laboratory della Brigham Young University.
L’obiettivo
Un obiettivo di questa tesi ` quello di verificare se la sequenza degli indirizzi
e
virtuali pu` essere utilizzata per classificare un processo in esecuzione e con
o
che accuratezza. Se la classificazione ` possibile, vogliono esaminare due
e
strade: una ` quella di classificare un processo e l’altra ` quella di verificare
e e
il processo, cio` di verificare che un processo sia quello che dichiara di essere.
e
L’approccio seguito ` stato quello di supporre che i workload possano
e
essere descritti da un punto di vista statistico come processi di Markov.
Si sono quindi usate librerie che realizzano Modelli di Markov di tipo dis-
creto che ci hanno permesso di operare delle classificazioni considerando il
workload nel suo complesso. In accordo con i lavori [1], [2] e [3], abbiamo
pensato di analizzare metriche di memoria per individuare le tipologie locali
dei workload.
8

9. 1.1 Struttura della tesi
I capitoli si articolano nel modo seguente:
Capitolo 2 Prestazioni di un sistema di calcolo in particolare in riferimento
agli accessi in memoria.
Capitolo 3 Struttura di Valgrind, framework di instrumentazione per lo
sviluppo di strumenti di analisi dinamica.
Capitolo 4 Analisi di SPEC CPU2006, suite di benchmark standard per
valutare processore, memoria e compilatore di un sistema.
Capitolo 5 Analisi, classificazione e verifica delle tracce di indirizzi e doc-
umentazione dei tool sviluppati.
Capitolo 6 Presentazione e discussione dei pi` importanti risultati sper-
u
imentali conseguiti nella classificazione di tracce di processi e nella
classificazione di workload.
Capitolo 7 Applicazioni pratiche del tool sviluppato e possibili modalit`
a
di messa in atto in sistemi in stato di produzione.
Capitolo 8 Considerazioni finali che riassumono il lavoro svolto.
9

10. 10

11. Capitolo 2
Concetti preliminari
2.1 Prestazioni di un sistema di calcolo
La performance di un sistema si pu` definire come la capacit` del sistema
o a
di eseguire un compito, o workload, in relazione a determinati parametri.
La performance pu` essere valutata in termini misurabili utilizzando diverse
o
metodologie: in relazione al tempo impiegato per completare un determinato
processo, ai watt consumati, al tempo di risposta. Gli obiettivi di una
misurazione possono essere di rilevare differenze nel sistema prima e dopo
delle modifiche o di confrontare il sistema con altri.
Per poter avere dei risultati comparabili tra architetture diverse che
eseguono software differente sono stati sviluppati dei benchmarks, i quali
forniscono un dato misurabile ed oggettivo delle capacit` di un macchina.
a
I benchmark pi` diffusi sono SPEC sviluppato da Standard Performance
u
Evaluation Corporation e ConsumerMark sviluppato da EEMBC, Em-
bedded Microprocessor Benchmark Consortium. Ogni benchmark fornisce
un workload in modo deterministico che quindi pu` essere utilizzato per mis-
o
urare la capacit` di calcolo intero, floating point, di input/output, di banda
a
di accesso alla memoria del sistema in esame. I benchmark valutano l’ese-
cuzione di questo workload con un numero che pu` quindi essere rapportato
o
ad altri sistemi/architetture.
Un fattore significativo per la misura e la caratterizzazione di un work-
load ` dato dalla sequenza di indirizzi corrispondenti agli accessi in memoria
e
[4]. Questo valore pu` essere utilizzato per calcolare la frequenza di miss
o
sulle memorie cache del sistema o per misurare la localit` spaziale delle
a
istruzioni o dei dati. In Fig. 2.1 ` riportata l’analisi di cache miss rate di
e
dati e istruzioni di un processo (bzip2) in diversi momenti della sua ese-
cuzione. Su una macchina moderna, un cache L1 miss pu` significare 10
o
cicli di cpu persi, un cache L2 miss fino a 200. Un cache profiling adeguato
pu` rivelarsi estremamente utile per capire come ottimizzare l’esecuzione di
o
un’applicazione. Una configurazione tipica attuale ` data da una cache di
e
11

12. livello 1 con istruzioni e dati separati (I1, D1) e una cache di livello 2 unifi-
cata (I2 + D2). Per ottenere dati dettagliati sui rapporti miss/request delle
Figura 2.1: Cache miss rate durante una esecuzione di bzip2
memorie cache si fa uso di simulatori, i quali propongono un modello di ger-
archia di memoria il pi` simile possibile a quello delle architetture reali cos`
u ı
da fornire dei dati attendibili per risolvere problemi di performance dovu-
ti agli accessi alla memoria. I simulatori di memoria cache leggono come
input tracce di indirizzi, ovvero dei file contenenti la sequenza di indirizzi
corrispondenti accessi in memoria effettuati durante l’esecuzione.
2.2 Tracce di indirizzi
Le tracce posso essere sia file di testo ascii sia binari, tipicamente oltre
agli indirizzi sono riportate anche delle informazioni ulteriori riguardanti
ogni singolo accesso in memoria: dimensione in byte dell’accesso, modalit`a
lettura/scrittura... Un formato comunemente utilizzato ` quello prodotto
e
dal tool lackey presente nel framework Valgrind, che genera tracce ascii nel
formato qui commentato:
I 0023C790,2 # instruction read all’indirizzo 0x0023C790
S BE80199C,4 # data store di 4 byte all’indirizzo 0xBE80199C
L BE801950,4 # data load di 4 byte all’indirizzo 0xBE801950
M 0025747C,1 # data modify di 1 byte all’indirizzo 0x0025747C
In lackey lettura e scrittura di una stessa locazione in modo consecutivo sono
riportate come data modify. Altri formati di tracce sono quelli definiti dal
12

13. simulatore di memorie cache dinero, che prevede sia formati ascii simili a
quello di lackey sia un formato binario che permette di risparmiare spazio
su disco, importante in quanto le tracce possono raggiungere dimensioni
notevoli. Questi formati sono, in caso di sistema a 32bit:
traditional compatibile anche con dineroIII, ` un formato ascii definito
e
C AAAAAAAA con C modalit` di accesso e i campi A per l’indirizzo.
a
2 04000850
2 04000852
1 be8f1f4c
extended include anche informazioni sulla dimensione in byte dell’accesso
alla memoria, C AAAAAAAA SS con SS dimensione in byte dell’accesso
i 04000850 2
i 04000852 5
r bec3446c 4
i 04000a90 1
w bec34468 4
binary vengono memorizzati 8 byte per accesso, AAAASSCP
AAAA indirizzo
SS dimensione dell’accesso
C modalit` (read,write,instruction fetch-0,1,2)
a
P byte di padding
Nel caso delle tracce ascii per la conversione da un formato all’altro ` stato
e
sviluppato uno script sed:
#!/usr/bin/sed
/^=/d
s/,[0-9]+$//
s/^Is/2/
s/^sS/1/
s/^sL/0/
s/sMs([0-9a-f]*)/0 1n1 1/
2.3 Parametrizzazione delle tracce
Dalle tracce di accessi in memoria devono essere rimosse le informazioni
ridondanti ed estratti i tratti principali, riducendo la quantit` di dati da
a
processare. Comportamenti sequenziali o ciclici nell’esecuzione sono di fatto
13

14. inclusi nel dominio spettrale della traccia, quindi si pu` operare una com-
o
pressione in questo dominio mantenendo le informazioni pi` significative. I
u
cicli per esempio introducono picchi nello spettro mentre una sequenza di
indirizzi lineare produrr` una componente continua. Si vogliono utilizzare
a
quindi strumenti di analisi dei segnali per elabolare la sequenza di indirizzi.
Figura 2.2: Spettrogramma di una sequenza di indirizzi contenente cicli
annidati
La sequenza di indirizzi ` tempo variante, per cui si utilizza un’analisi
e
spettrale a breve termine. Nella fase di apprendimento gli indirizzi ver-
ranno divisi in segmenti di lunghezza limitata sui quali verr` applicata la
a
trasformata discreta del coseno. La DCT ` una operazione comunemente
e
utilizzata nella trasformazione dei segnali, utile per ridurre la ridondanza in
quanto distribuisce pi` energia possibile nei primi coefficienti. Calcolata la
u
DCT su un certo numero di segmenti vengono presi i primi coefficienti della
DCT di ogni segmento e su di essi applicata la quantizzazione vettoriale.
Il procedimento di quantizzazione vettoriale suddivide lo spazio in settori
ad ognuno dei quale associa un vettore centroide, ogni vettore viene quindi
associato al centroide pi` vicino ottenendo un insieme di indici relativi ai
u
centroidi. Tali indici sono utilizzati come input per HMM.
Utilizzare solo i primi valori della DCT ha l’effetto di approssimare i pic-
chi della sequenza originale pur mantenendone il comportamento generale.
14

15. Figura 2.3: La sequenza di vettori di indirizzi viene trasformata in una
sequenza di vettori n-dimensionali
Figura 2.4: Viene applicata la quantizzazione vettoriale per trovare i
centroidi e di ogni vettore calcolato il centroide pi` vicino
u
15

16. 2.4 I Modelli di Markov Nascosti
Una catena markoviana a tempo discreto ` una sequenza aleatoria qn tale
e
che la variabile successiva dipende solamente dalla variabile precedente. Il
sistema pu` essere quindi descritto da una sequenza di stati, che corrispon-
o
dono a degli eventi osservabili. Ad ogni istante del tempo discreto il sistema
passa da uno stato all’altro con una certa probabilit` di transizione.
a
Figura 2.5: Modello di Markov nascosto
Lo stato attuale qn riassume quindi la storia del sistema per prevedere
l’elemento successivo qn+1 .
Una catena di Markov ` un modello troppo restrittivo per poter essere
e
applicato al problema di interesse. Il modello pu` essere esteso al caso in
o
cui le osservazioni siano una funzione probabilistica dello stato e quindi non
osservabili direttamente. Le osservazioni sono cio` nascoste. Un modello di
e
Markov nascosto ` caratterizzato da:
e
• il numero di stati N , con l’insieme degli stati S = S1 , .., SN e con qt lo
stato al tempo t
• il numero di simboli osservati M , ovvero la dimensione dell’alfabeto
discreto. Indichiamo l’insieme dei simboli con V = V1 , ..., VM
• la matrice di transizione tra stati A = [aij ] dove
aij = P [qt+1 = Sj |qt = Si ] 1 ≤ i, j ≤ N
` la probabilit` di passare dallo stato Si allo stato Sj .
e a
• la distribuzione delle osservazioni nello stato j: bj (k), dove
bj (K) = P [Vk |qt = Sj ] 1≤j≤N 1≤k≤M
` la probabilit` di osservare il simbolo Vk se all’istante t il sistema si
e a
trova nello stato j.
16

17. • il vettore delle probabilit` iniziali π, dove
a
πj = P [q1 = Sj 1≤j≤N
` la probabilit` che il sistema si trovi all’istante iniziale nello stato Sj
e a
Si pu` quindi indicare un modello di Markov nascosto con λ = (A, B, π).
o
Il processo di apprendimento di un modello di Markov implica la ricerca
dei parametri (A, B, π) tali da massimizzare la probabilit` di riconoscere la
a
sequenza di osservazioni. Poich` non si conosce una soluzione analitica che
e
trovi un massimo assoluto si utilizza una procedura iterativa. L’algoritmo
di Baum-Welch in [5] fa questo in modo efficiente utilizzando soltanto la
sequenza di simboli emessi come dati di addestramento. La parte nascosta
di un hmm, cio` la sequenza di stati, non pu` essere scoperta, ma pu` essere
e o o
interpretata in qualche modo significativo. L’algoritmo di Viterbi in [6]
permette di generare la sequenza pi` probabile di stati relativi ad un dato
u
modello hmm. Inoltre avendo una sequenza di simboli l’algoritmo di Viterbi
rende possibile verificarne l’affinit` con un modello hmm una calcolandone
a
la probabilit`.
a
17

18. 18

19. Capitolo 3
Valgrind
Pi` i sistemi hardware e software crescono in complessit` pi` si rivelano
u a u
necessari sistemi per verificarne la correttezza. Per migliorare qualit` e a
robustezza dei programmi possono essere utilizzati dei tool di analisi o in-
strumentazione. Questi tool effettuano diversi tipi di operazioni per deter-
minare informazioni di interesse relative ai programmi. Gli approcci utiliz-
zati si possono suddividere in analisi statica e dinamica, analisi dei sorgenti
o dell’eseguibile binario.
Si definisce analisi dinamica di un software l’analisi di questi mentre ` in
e
esecuzione su un processore reale o virtuale, a differenza dell’analisi statica
che si propone di verificare eventuali propriet` del software analizzandone
a
l’object-code compilato o il codice sorgente, senza eseguire il software. I tool
di instrumentazione dinamica permettono di analizzare il 100% del codice
che viene eseguito in user mode senza richiedere accesso al codice sorgente
ma seguendo soltanto un flusso di esecuzione. I tool di analisi statica per-
mettono di seguire tutte le diramazioni del codice ma non hanno accesso
allo stato dell’applicazione in esecuzione. I due approcci si possono ritenere
complementari.
I parametri ottenuti dai tool di analisi dinamica riguardano spesso la
quantit` memoria utilizzata in varie fasi di esecuzione, le chiamate alle fun-
a
zioni di allocazione/rilascio, errori di scrittura/lettura nei buffer allocati,
race conditions nel caso di programmi multithreaded... Tali tool possono
anche dare accesso allo spazio di indirizzamento del processo e ai registri
della cpu.
Quando un tool di analisi permette di intervallare il proprio codice con
quello dell’eseguibile analizzato allora esso si pu` definire tool di instrumen-
o
tazione. Per accedere alla traccia di indirizzi generata da un’applicazione ed
elaborarla per poter addestrare HMM con essa si ` reso necessario l’utilizzo
e
un tool di instrumentazione dinamica.
Valgrind ` un framework di instrumentazione sul quale ` possibile svilup-
e e
pare tool di analisi dinamica[7]. Valgrind viene distribuito con un insieme
19

20. di tool gi` predisposti per le operazioni pi` comuni di instrumentazione,
a u
quali gestione di memoria, threading... Il framework offre inoltre un’inter-
faccia per poter sviluppare altri tool a seconda dell’esigenza. La natura open
source del framework, distribuito sotto licenza GNU GPLv2, permette an-
che di modificare i tool esistenti o perfino il codice sorgente del framework
stesso, coregrind.
3.1 Coregrind
Il framework ` progettato [8] per non richiedere una nuova compilazione o
e
linking delle applicazioni che deve eseguire, permette di analizzare eseguibili
gi` esistenti. Passando come parametro a Valgrind il nome dell’eseguibile
a
da lanciare questo viene caricato in memoria insieme alle librerie ad esso
associate. Le istruzioni del programma vengono tradotte in un linguaggio
RISC-like indipendente dall’architettura, chiamato VEX IR, per essere poi
eseguite su una cpu virtuale.
Ogni istruzione tradotta viene passata ad il tool in esecuzione (scelto
come parametro da linea di comando), il quale aggiunge il proprio codice
di instrumentazione, per poi essere simulata. VEX IR ` pi` simile alla rap-
e u
presentazione del codice com’` organizzata internamente in un compilatore
e
che ad un linguaggio assemblativo. Le istruzioni VEX sono organizzate in
blocchi IRSB che possono contenere da 1 a 50 istruzioni. I blocchi hanno
un solo punto di ingresso ma ` possibile che l’esecuzione esca dal blocco da
e
pi` di un punto.
u
I programmi multi-threaded sono supportati ma l’esecuzione di questi ` e
serializzata con un sistema di semafori in modo tale che soltanto un thread
venga eseguito simultaneamente dal core di Valgrind. Lo scheduling dei
thread viene effettuato dal sistema operativo.
3.2 Tools
I tools presenti nella distribuzione ufficiale di Valgrind sono 10: Memcheck,
Cachegrind, Callgrind, Helgrind, DRD, Massif, DHAT, Ptrcheck, BBV,
Lackey. Memcheck, Massif e DHAT sono tool relativi all’utilizzo della memo-
ria dinamica: Memcheck rileva errori nell’accesso alla memoria allocata,
mentre Massif e DHAT effettuano analisi sull’utilizzo di questa.
Sempre collegato agli accessi in memoria e strettamente orientato all’ot-
timizzazione della performance delle applicazioni ` Cachegrind: un simu-
e
latore di memoria cache che analizzando gli accessi effettuati dal programma
client riporta informazioni utili per la sua ottimizzazione.
20

21. 3.3 Cachegrind, analisi di un tool
L’implementazione di Cachegrind [9] prevede l’aggiunta di codice di instru-
mentazione ad ogni accesso in memoria per aggiornare il simulatore di cache
interno. Ogni istruzione prima di essere eseguita ` tradotta in un linguag-
e
gio RISC intermedio e passata al tool, che controlla se fa riferimenti alla
memoria (load/store) o se ` un’istruzione di fetch: in caso positivo la passa
e
al simulatore.
Il modello di memoria implementato in Cachegrind ` configurabile in
e
alcuni aspetti, fisso in altri. Sono configurabili dimensione totale, dimensione
dei blocchi (linee) e associativit`. Il numero e tipo delle memorie invece non
a
lo `, sono presenti due memorie cache L1 indipendenti, una per le istruzione
e
e una per i dati: Li1, Ld1 e una cache L2 condivisa. Caratteristiche:
• Rimpiazzamento LRU
• Write-allocate (una miss in scrittura su un dato lo porta in cache L1)
• Cache L2 inclusiva
• Bit selection hash table
Limiti:
• Fa uso di indirizzi virtuali, diversi da quelli che verrebbero inseriti nella
cache realmente
• Le syscall non vengono tracciate, quindi i riferimenti effettuati in
modalit` kernel non hanno effetto
a
• Gli altri processi in esecuzione non hanno effetto sulla cache simulata
Le opzioni per l’inizializzazione della memoria cache simulata devono essere
passate da linea di comando:
valgrind --tool=cachegrind [options] ./program
--I1=<size>,<associativity>,<line size>
--D1=<size>,<associativity>,<line size>
--L2=<size>,<associativity>,<line size>
--cache-sim=no|yes [yes]
--branch-sim=no|yes [no]
--cachegrind-out-file=<file>
Cachegrind presenta anche una funzionalit` che analizza il numero di branch
a
predette correttamente dalla cpu, il flag -branch-sim=yes attiva questa fun-
zionalit`. Ogni esecuzione di Valgrind produce un file di output, controllato
a
da -cachegrind-out-file, di default nella forma cachegrind.out.%p con
21

22. %p pid del processo avviato. Questo file pu` essere poi utilizzato da degli
o
scripts (es. cg_annotate) per produrre statistiche pi` dettagliate.
u
Il simulatore produce in output numero di reference, miss e miss-rate del
fetch di istruzioni, della lettura di dati e della scrittura di dati per entrambi
i livelli di cache. Per ulteriori analisi ` possibile fare uso di due script dis-
e
tribuiti assieme a cachegrind: cg_merge e cg_annotate. cg_merge permette
di generare i risultati complessivi di esecuzioni multiple della stessa appli-
cazione combinando diversi file di log cachegrind.out. cg_annotate analizza
in modo molto approfondito i file di log e produce percentuali di cache miss
relative ad ogni file, ad ogni funzione o ad ogni singola linea di codice (se
l’eseguibile include informazioni di debugging).
3.4 Sviluppo di un Tool
L’architettura del framework prevede una netta distinzione tra Coregrind e
i tool. Coregrind fornisce il supporto all’infrastruttura di instrumentazione,
traduzione delle istruzioni, gestione della memoria, scheduling lasciando al-
cune operazioni indefinite sotto forma di prototipi di funzioni, che devono
essere implementate nei singoli tool. Coregrind fornisce anche altri servizi
ai tool che verranno descritti in seguito.
I tool vengono compilati insieme a Coregrind per generare un nuovo
eseguibile che viene selezionato dal parametro -tool all’avvio di Valgrind.
Le funzioni necessarie perch` il tool possa essere compilato correttamente
e
sono:
pre_clo_init() E’ disponibile per inizializzare le strutture di memoria in-
terne del tool. E’ possibile inoltre dichiarare a quali eventi dell’ese-
cuzione il tool ` interessato e registraci delle callback:
e
track_pre_thread_ll_create, track_new_mem_stack ...
post_clo_init() Questa funzione viene chiamata dopo che ` stato effet-
e
tuato il parsing dei parametri passati da linea di comando per filtrare
quelli relativi a coregrind. Va qui effettuato il parsing delle opzioni
relative al tool ed ` possibile procede ulteriormente con le operazioni
e
di inizializzazione.
instrument() Ogni volta che l’esecuzione entra in un nuovo blocco viene
chiamata instrument() con il blocco come input. Questa funzione ha
il compito di interpolare le istruzioni con il codice di instrumentazione
(chiamate a funzioni del tool) e ritornare un nuovo blocco. Per il
fatto che i blocchi hanno diversi punti d’uscita non ` assicurato che
e
tutte le istruzioni del blocco vengano eseguite, per questo il codice di
instrumentazione va bufferizzato nel blocco d’uscita insieme ad esse e
non eseguita direttamente in instrument().
22

23. fini() Stampa dei risultati e rilascio delle risorse. E’ possibile accede anche
all’exit code del programma client.
Il framework mette a disposizione anche altri strumenti per analizzare il
codice in esecuzione, se si ha la possibilit` di ricompilare l’applicazione di pu`
a o
fare uso di client requests, per comunicare direttamente col tool tramite
macro inserite nel codice sorgente del client. Utili soprattutto per il debug-
ging, il framework ne propone alcune e ogni tool ne implementa di proprie.
Alcuni esempi:
RUNNING_ON_VALGRIND Ritorna 1 se l’applicazione viene eseguita all’interno
di Valgrind, 0 se su una vera CPU. Utile ad esempio per creare dei
salti condizionali ed omettere alcune parti dell’esecuzione che rallen-
terebbero troppo l’esecuzione simulata.
VALGRIND_PRINTF(format, ...) Stampa un messaggio formattato sul file
di log di Valgrind insieme ai messaggi del tool.
VALGRIND_PRINTF_BACKTRACE(format, ...) Stampa lo stato corrente del-
la stack
VALGRIND_COUNT_ERRORS Ritorna il numero di errori rilevati finora dal tool
E’ possibile implementare le proprie client request, modificando il codice
dei tool ` quindi possibile far comunicare le proprie applicazioni con il
e
framework.
Un’altra funzionalit` prevista ` quella di effettuare function wrapping
a e
di funzioni di libreria per analizzarne parametri passati e valori di ritorno.
E’ presente un sistema di pattern per intercettare gruppi di funzioni con
nome simile (il nome a cui fare riferimento ` quello interno generato dal
e
compilatore). La funzione di wrapping
I_WRAP_SONAME_FNNAME_ZZ(libpthreadZdsoZd0, pthreadZucreateZAZa)
intercetter` quindi le chiamate a tutte le funzioni che corrispondono al pat-
a
tern pthread_create@* nella libreria libpthread.so.0, quindi di tutte
le versione delle glibc (pthread_create@GLIBC_2.3, ...@GLIBC_2.4). Le
funzioni di wrapping possono poi chiamare l’originale con le macro
VALGRIND_GET_ORIG_FN(fn);
CALL_FN_W_WW(result, fn, x,y);
3.5 Modifiche a Coregrind
L’utilizzo di Valgrind per l’addestramento di HMM richiede la possibilit` a
di eseguire la stessa applicazione client sotto il tool di instrumentazione
23

24. diverse volte variando i parametri di input. E’ stata analizzata la strut-
tura interna di Coregrind e sono state individuate le fasi principali del suo
avvio per selezionare quelle candidate ad essere modificate per ottenere tale
funzionalit`.
a
3.5.1 Wrapper interno
La prima soluzione sviluppata consiste in un wrapper scritto in POSIX C.
E’ stata modificata le funzione main_process_cmd_line_options affinch` e
riconoscesse l’opzione -wrap=<yes|no>. Se il parametro viene posto a yes
il valore della stringa VG_(args_the_exename), che si riferisce all’eseguibile
da lanciare, viene artificialmente posto al nome del wrapper. Valgrind lo
esegue passandogli gli argomenti da variare ed esso sostituisce il simbolo
(arbitrariamente posto a con l’argomento variabile (nel caso di gzip con
il nome del file da comprimere), quindi effettua una fork ed si sostituisce
(execvep) con l’eseguibile client. Il processo padre chiamando wait attende
che il figlio completi l’esecuzione (per non sovrappore l’output dei due) e
rientra nel ciclo.
Il vantaggio di questo sistema ` che ` completamente trasparente per il
e e
client, esso non necessita di ricompilazione e la modifica rispetta l’architet-
tura di Valgrind. Lo svantaggio principale ` che l’uso di fork/execve im-
e
plica la reinizializzazione del tool ad ogni esecuzione del programma client.
Non ` quindi possibile mantenere un determinato stato del tool in memoria
e
tra un’esecuzione e l’altra (in particolare ` la chiamata a execve che causa
e
il problema, Valgrind la gestisce semplicemente sostituendosi con un altro
processo di Valgrind e non ricaricando un nuovo eseguibile).
Il wrapper ` stato inserito nel sistema di build di Valgrind e pertanto auto-
e
maticamente compilato ed installato insieme al resto dei sorgenti.
3.5.2 Thread wrapper
La seconda soluzione ` mirata a risolvere il problema sorto nella prima:
e
mantenere uno stato tra le varie esecuzioni. Il sorgente del client andr` a
modificato in modo tale da essere eseguito come funzione in un thread: il
wrapper gestisce delle struct contenti gli argomenti da passare ai diversi
thread e li esegue sequenzialmente, aspettando che uno finisca prima di
lanciare il successivo. Questo viene fatto in quanto i thread condividendo lo
spazio di indirizzamento potrebbero entrare in conflitto su eventuali variabili
globali.
Per l’implementazione ` stata usata la libreria pthread ed ` stato con-
e e
statato che risolve i problemi della prima ma comporta un notevole svantag-
gio obbligando a modificare e ricompilare il client, seppur minimamente. La
funzione main del wrapper ` da compilare assieme al client. Il programma
e
client dovr` essere modificato per accettare come parametro un puntatore
a
24

25. ad una struttura contentente argc, argv ed envp e dovr` terminare la sua
a
esecuzione chiamando pthread_exit anzich` exit.
e
3.5.3 Thread injection
Per trovare una soluzione che mantesse lo stato interno del tool tra le varie
esecuzioni e che non richiedesse modifiche al client ` stata fatta un’analisi
e
approfondita del sistema di thread e dello scheduler di coregrind, il frame-
work sul quale si basano i tool di Valgrind. Seguendo il flow dell’esecuzione
di Valgrind sono stati effettuati diversi test prima per ripetere l’esecuzione
di un thread gi` concluso e poi per duplicarlo artificialmente, senza che esso
a
avesse chiamato clone.
L’implementazione di questo motodo ` risultata possibile, ed ` stato
e e
individuato nella funzione run_thread_for_a_while il punto ideale per ef-
fettuare l’inserimento del thread artificiale, in quanto il pi` vicino all’ese-
u
cuzione delle istruzioni sulla cpu virtuale di Valgrind. Tale funzione (in
scheduler.c) ` stata modificata affinch` anteponesse alla prima istruzione
e e
del client un chiamata a ML_(do_fork_clone). Con questa Valgrind duplica
il thread che stava eseguendo in quel momento (che non condivider` per` a o
lo spazio di indirizzamento). Sono state effettuate con successo multiple
esecuzioni con una singola inizializzazione del tool scelto (ma con multiple
finalizzazioni). Il passo successivo ` stato sostituirla con la chiamata ad una
e
funzione ancora pi` interna di coregrind, do_clone.
u
Questa modifica ha permesso di avere pi` thread eseguiti sequenzial-
u
mente (Valgrind permette il multithreading ma esegue sempre un thread
alla volta) con una sola inizializzazione e una sola finalizzazione del tool scel-
to. Tuttavia non rispetta l’architettura originale del framework e potrebbe
portare ad instabilit`, necessita quindi un maggiore approfondimento prima
a
di essere utilizzata con sicurezza.
3.5.4 External state
Se il progetto prevede invece lo sviluppo di un nuovo tool da zero la soluzione
ottimale si rivela quella di salvare lo stato del tool in un file copiandovi
le strutture di memoria come si trovano al momento della chiamata alla
funzione fini() e ripristinarle all’esecuzione successiva. I tool di Valgrind
non sono per` linkati alla libreria c standard quindi ` necessario usare la
o e
versione reimplementata nel framework di tutte le funzioni di IO, definite
negli headers della directory include/ dei sorgenti.
25

26. 26

27. Capitolo 4
Spec
Spec 2006 si presenta come lo standard per la misura e la valutazione delle
prestazioni di un sistema. L’utilizzo di un set di benchmark standard rende
possibile la comparazione dei risultati tra macchine, compilatori e opzioni
di compilazione differenti tra loro.
4.1 CPU2006
Spec CPU2006 si concentra sulla performance del processore, sull’architet-
tura della memoria e sulla capacit` del compilatore di produrre codice ot-
a
timizzato [10]. Altri fattori che spesso incidono sulle performance delle ap-
plicazioni (networking, I/O) sono qui considerati trascurabili, in quanto i
singoli benchmark sono stati sviluppati per ottenere il maggiore impatto
possibile sulla cpu e sulla memoria rispetto al resto delle componenti del
sistema. Spec si compone di due suite di benchmark principali:
• CINT2006
• CFP2006
La prima effettua un’analisi delle performance del sistema nelle operazioni
su valori interi, la seconda nel caso di operazioni a virgola mobile (floating
point). Ognuna delle due suite di compone di diversi benchmark (12 per
CINT2006, 17 per CFP2006).
4.1.1 Benchmark
Un benchmark di SpecCPU2006 non ` altro che un’applicazione che effet-
e
tua una serie di operazioni ben definite che hanno l’effetto di aumentare il
carico di lavoro della cpu. Dei benchmark di SpecCPU2006 si misura speed,
ovvero quanto rapidamente l’esecuzione viene completata, e throughput,
quanti flussi di esecuzione si riescono a completare per unit` di tempo.
a
27

28. 4.1.2 Speed Ratio
Lo standard di SpecCPU2006 definisce come ratio il rapporto tra il tempo
di esecuzione di un benchmark sulla macchina e un tempo di riferimento de-
terminato da Spec. E’ con questo valore che ` possibile mettere in relazione
e
il proprio risultato con risultati ottenuti su sistemi differenti.
4.1.3 Throughput Ratio
Vengono eseguite multiple (n) istanze del benchmark contemporaneamente.
Il valore di throughput corrisponde al rapporto tra il tempo impiegato per
completare l’esecuzione di tutte le istanze ed n. Il throughput ratio ` e
quindi il rapporto tra il throughput della macchina e il valore di riferimento
di Spec.
4.2 Misurazioni
La suite CINT2006 pu` essere eseguita in quattro modalit` differenti:
o a
SPECint2006 La media geometrica ottenuta su 12 ratio, normalizzati su
3 esecuzioni ognuno. Benchmark compilati in modalit` peak.
a
I 12 benchmark vengono eseguiti 3 volte, calcolandone il
valore di speed ratio. Delle 3 esecuzioni di ogni benchmark
viene presa la mediana e utilizzata per calcolare la media
√
geometrica sui 12: G = r0 r1 · · · r11 . La media geometri-
ca G viene utilizzata come risultato del test. I benchmark
sono utilizzati in modalit` peak: per ognuno di essi possono
a
essere specificati flag di compilazione personalizzati cos` da
ı
ottimizzarne l’esecuzione.
SPECint base2006 La media geometrica ottenuta su 12 ratio, normaliz-
zati su 3 esecuzioni ognuno. Benchmark compilati in modalit` base.
a
Il valore di G viene calcolato allo stesso di SPECint2006,
ma i benchmark vengono utilizzati in modalit` base: i flag
a
di compilazione devono essere uniformi tra tutti e 12. La
modalit` base ` pi` restrittiva della modalit` peak.
a e u a
SPECint base2006 La media geometrica del valore di throughput ratio
dell’esecuzione dei 12 benchmark in madalit` peak.
a
SPECint base2006 La media geometrica del valore di throughput ratio
dell’esecuzione dei 12 benchmark in modalit` base.
a
Allo stesso modo di CINT2006, anche CFP2006 prevede quattro modal-
it` di esecuzione differenti:
a
28

29. SPECfp2006 La media geometrica ottenuta su 17 ratio, normalizzati su 3
esecuzioni ognuno. Benchmark compilati in modalit` peak.
a
SPECfp base2006 La media geometrica ottenuta su 17 ratio, normalizzati
su 3 esecuzioni ognuno. Benchmark compilati in modalit` base.
a
SPECfp rate2006 La media geometrica del valore di throughput ratio
dell’esecuzione dei 17 benchmark in madalit` peak.
a
SPECfp rate base2006 La media geometrica del valore di throughput
ratio dell’esecuzione dei 17 benchmark in madalit` base.
a
4.3 Configurazione
Per eseguire SpecCPU2006 ` necessario scrivere un file di configurazione rel-
e
ativo al proprio sistema. Le opzioni di configurazione si possono dividere
in opzioni relative alla compilazione ed esecuzione dei singoli benchmark e
relative all’output e ai report che genera la suite. E’ quindi necessario speci-
ficare il path dei compilatori C, C++, Fortran, flag di compilazione comuni
a tutti i benchmark e opzionalmente anche flags personalizzati per ogni sin-
golo benchmark (utilizzati per le misurazioni peak). Per poter pubblicare
il report dell’esecuzione della suite ` necessario descrivere in modo partico-
e
lareggiato hardware e software sulla quale ` stata eseguita: architettura, n◦
e
di cpu, n ◦ di core per cpu, quantit` di memoria disponibile, motherboard,
a
sistema operativo, versione dei compilatori... Si possono anche definire le
preferenze per quanto riguarda l’output dei risultati, se html, pdf, ascii.
Un altro requisito affich` i proprio risultati siano marcati come reportable
e
` produrre il file flags.xml, dove va commentata ogni opzione passata al
e
compilatore.
4.4 Esecuzione
Per compilare ed eseguire i benchmark si utilizza runspec. Il procedi-
mento da effettuare per testare se l’installazione e la configurazione del-
la suite ` andata a buone file ` source ./shrc per settare le variabili
e e
d’ambiente, quindi runspec -config=example.cfg -fakereportable -F
flags-simple.xml -size=ref -tune=base int e nella directory result
verr` generato il report. Runspec prende come argomento uno o pi` bench-
a u
mark da eseguire (int, fp, all). Le principali opzioni che regolano l’esecuzione
del tool sono:
-action Definisce l’azione da compiere: build compila i benchmark, run
compila(se necessario) ed esegue. clean rimuove file temporanei ed
eseguibili compilati.
29

30. -rate Se non presente il tool procede in modalit` speed run. Se presente
a
(argomento n) esegue n benchmark in parallelo, il test sar` quindi un
a
test di throughput
-tune Settabile a base, peak o all. Default base.
-reportable Per generare un report valido
Le seguenti opzioni sono utili per effettuare dei test su un singolo benchmark
o in modalit` particolari ma non permettono di generare un report valido:
a
-size Dimensioni del set di input, test, train o ref (reference). Reference `
e
il set pi` ampio, con il quale l’esecuzione dura pi` a lungo
u u
-iterations Numero di volte che ogni benchmark va eseguito. Obbligato-
riamente a 3 nel caso di reportable runs.
4.5 Benchmarks
SpecCPU2006 si prefigge di calcolare le prestazioni di un sistema simulando
un workload il pi` verosimile possibile, per questo molte dei benchmark sono
u
delle versioni adattate e modificate di applicazioni reali. Tali applicazioni
hanno in comune un’elevata intensit` computazionale: la maggior parte del
a
tempo speso da esse ` dedicato ad operazioni di calcolo, con pochissimo
e
overhead causato da input/output. Sono state apportate delle modifiche ai
sorgenti affich` i test eseguano la gran parte delle operazioni di IO in memo-
e
ria e non su file, e affich` la memoria utilizzata rimanga inferiore ad 1GB per
e
evitare che il sistema debba effettuare swap verso il disco. Le applicazioni
sono state scelte basandosi anche su criteri di portabilit`, in quanto Spec-
a
CPU2006 pu` essere compilato su una moltitudine di architetture e sistemi
o
operativi differenti.
4.5.1 401.bzip2
401.bzip2 ` la versione adattata a SpecCPU2006 del programma bzip2, il
e
quale effettua compressione dati. 401.bzip2 si basa sulla versione 1.0.3
di bzip2 di Julian Seward, con la differenza che 401.bzip2 non effettua
operazioni di I/O se non nella lettura dei file da comprimere. Tutta la
compressione e la decompressione avviene quindi in memoria.
I file utilizzati per la compressione e decompressione sono:
chicken.jpg JPEG image data, 638K
liberty.jpg JPEG image data, 283K
input.source POSIX tar archive, contenente il codice sorgente di perl-
5.8.5, 50M
30

31. text.html HTML document text, 130K
input.program Mach-O executable ppc, 7.7M
input.combined file composto da alcune parti molto comprimibili e altre
meno, 52M. Si ` rivelato essere la combinazione dei file precedenti (le
e
immagini JPEG, il sorgente di perl e il file html)
Ogni file viene compresso e decompresso 3 volte, a fattore crescente: 5, 7 e 9.
I risultati della decompressione sono poi confrontati con il set di input per
validare la buona riuscita del test. 401.bzip inizializza in memoria 3 buffer
di dimensione adeguata ad ospitare il file di input, lo stream compresso e lo
stream decompresso. Dopo aver caricato il file, le successive operazioni di
lettura e scrittura sono effettuate tutte in memoria senza snaturare il codice
di bzip2 tramite le define:
./bzlib.h:98: #define read(a,b,c) spec_read(a,b,c)
./bzlib.h:104: #define write(a,b,c) spec_write(a,b,c)
spec_read e spec_write non sono altro che wrapper di memcpy che gestis-
cono gli EOF e che fanno corrispondere ai file descriptor i buffer preceden-
temente allocati.
4.5.2 445.gobmk
445.gobmk ` una versione di GNU Go alla quale vengono presentate diverse
e
posizioni di gioco. Il gioco del Go ` considerato un problema di intelligen-
e
za artificiale che richiede uno sforzo computazionale elevato in quanto le
combinazioni possibili di pezzi sulla scacchiera (goban) nella partita sono
moltissime.
I file di input utilizzati benchmark sono file di testo che descrivono diverse
posizioni di gioco, l’output corrisponde nella mossa successiva da effettuare.
4.5.3 458.sjeng
458.sjeng ` una versione leggermente modificata di Sjeng 11.2, un program-
e
ma che gioca a scacchi ed analizza e valuta posizioni di gioco. La versione
proposta da Spec rende le ricerche nell’albero delle varianti delle mosse deter-
ministiche e quindi il workload del test sempre uguale. L’input di riferimento
del test ` composto da 9 differenti posizioni di gioco e dalla profondit` alla
e a
quale vanno analizzate da Sjeng.
4.5.4 403.gcc
403.gcc ` basato sulla versione 3.2 di GNU gcc, configurato per generare
e
codice assembly x86-64 per un processore AMD Opteron con diverse flag di
31

32. ottimizzazione abilitate. 403.gcc ` stato adattato da Spec alterando l’euris-
e
tica nelle scelte di utilizzare funzioni inline affinch` il programma spendesse
e
pi` tempo nell’analisi del codice sorgente e utilizzasse pi` memoria della
u u
versione standard. L’input ` dato da file sorgente per i quali deve essere
e
generato l’assembly corrispondente.
4.5.5 464.h264ref
464.h264ref ` l’implementazione di Karsten S¨hring dello standard di com-
e u
pressione video H.264/AVC. Le modifiche introdotte dal team di Spec facil-
itano la portabilit` del codice ma sono state ridotte al minimo per garantire
a
che il test si avvicinasse il pi` possibile ad un caso d’uso reale di video en-
u
coding. In particolare, ` stata rimossa la parte dei sorgenti riguardante il
e
decoder (il test effettua solo la compressione in h264, non la decompressione)
ed ` stato soppresso l’output a file di log per minimizzare l’I/O. L’input `
e e
composto da due video in formato raw ognuno dei quali viene compresso con
due profili differenti (good compression e best compression).
4.5.6 400.perlbench
400.perlbench ` Perl v5.8.7 al quale sono state rimosse tutte le feature rel-
e
ative ai singoli sistemi operativi. A questi sono stati aggiunti alcuni moduli
esterni: SpamAssassin, MailTools, Digest-MD5, HTMLParser... I moduli
vengono utilizzati per la manipolazione di messaggi email trasformandoli in
pagine html, calcolandone checksum md5 e rilevando con che probabilit` si a
tratta di spam.
4.5.7 429.mcf
429.mcf deriva da un software di scheduling del traffico utilizzato in ambito
pubblico. 429.mcf genera un elevato carico sulla cpu eseguendo un algoritmo
che implementa il metodo del simplesso su rete. Il codice del programma
originale ` stato modificato per ridurre il numero di cache miss e quindi incre-
e
mentare l’impatto sulla cpu rispetto alla memoria. Questo ` stato ottenuto
e
modificando l’ordine degli elementi persenti nelle struct maggiormente uti-
lizzate dal benchmark. L’input al benchmark consiste in un file di testo
contente un insieme di percorsi da ottimizzare.
4.5.8 462.libquantum
462.libquantum simula un computer quantistico, eseguendo l’algoritmo di
fattorizzazione di Peter Shor. Il benchmark si aspetta in input un numero
e resituisce l’elenco dei suoi fattori. Su un computer quantistico l’algorit-
mo trova i fattori con margine d’errore arbitrariamente piccolo in tempo
polinomiale rispetto alla dimensione del numero in input.
32

33. 4.5.9 456.hmmer
456.hmmer utilizza algoritmo hmm per analizzare sequenze di dna. In input
il benchmark si aspetta un file database contente i modelli di riferimento e
una sequenza nella quale effetuare la ricerca delle sequenze del database.
4.5.10 471.omnetpp
471.omnetpp simula una vasta rete ethernet basandosi sul sistema di simu-
lazione discreto OMNeT++. OMNeT++ implementa completamente CS-
MA/CD, i frame ethernet e IP per una simulazione del carico sulle reti. Il
benchmark simula una rete contente circa 8000 computer e 900 tra switches
e hubs suddivisi in diverse subnet. Il benchmark prende in input la topologia
di una rete e la configurazione degli host, e procede aumentando esponenzial-
mente il volume di traffico simulando anche perdite di pacchetti. In ouput
sono prodotte statistiche dettagliate sulla simulazione.
4.5.11 473.astar
473.astar deriva da una libreria di ricerca del percorso minimo utilizzata
per le intelligenze artificiali nei videogames. In input accetta una mappa in
formato binario e il tipo di algoritmi da applicare per poi stampare le vie
possibili per il raggiungimento della destinazione.
4.5.12 483.xalancbmk
483.xalancbmk deriva da Xalan-C++, un software che processa documenti
XML trasformandoli secondo fogli di stile XSL. Implementa lo standard
W3C delle XSL Transformations e di XML. Per renderlo un benchmark di
Spec ` stato selezionato un test-set da processare di notevole dimensioni
e
(100MB) consistente in un file XML e un foglio di stile XSL da trasformare
in HTML.
33

34. 34

35. Capitolo 5
Analisi delle tracce di
indirizzi
L’obiettivo dell’analisi consiste nel riuscire ad riconoscere a che program-
ma corrisponde un processo sconosciuto in esecuzione utilizzando soltanto
la sequenza di indirizzi di memoria a cui accede. Si vuole testare l’efficacia
di apprendimento di hmm (modelli di Markov) e delle reti neurali nel ri-
conoscere tratti caratteristici dello spettro delle tracce. Per poter utilizzare
tali algoritmi di machine learning ` necessario trasformare la sequenza di in-
e
dirizzi in una forma accettabile dai modelli, procedendo inizialmente con una
compressione della stessa: la traccia viene suddivisa in segmenti e di questi
viene calcolata la trasformata del coseno. I primi parametri della traformata
vengono presi come vettore rappresentante il segmento. Tali vettori vengono
quindi quantizzati tramite un algoritmo di k-means clustering per ottenere
una sequenza di chiavi appartenenti ad un alfabeto e quindi ad un dominio
discreto. E’ con queste sequenze di chiavi che vengono addestrati i modelli
di Markov e le reti neurali.
Per la fase di analisi sono stati utilizzati come programmi i 12 benchmark
SPECint, i quali possono generare un numero ancora pi` elevato di possibili
u
processi in quanto ogni benchmark ha associati pi` possibili input, fino a 8
u
nel caso di gcc. Sono stati sviluppati due gruppi di tool per effettuare la
classificazione delle tracce, uno dei quali utilizza modelli di Markov e l’altro
reti neurali addestrate tramite back-propagation. Per ognuno di essi sono
presenti tool di addestramento, tool di test e un vasto insieme di script per
automatizzare il processo di analisi. I tool sono stati sviluppati interamente
in C mentre lo scripting ` stato effettuato in Ruby. Come piattaforma di
e
sviluppo e test ` stato scelto un sistema Debian GNU/Linux.
e
35

36. 5.1 Addestramento hmm
Partendo da una traccia di indirizzi generata dall’esecuzione di un bench-
mark si vuole ottenere il modello hmm corrispondente a tale workload. E’
stato sviluppato un tool in ansi C che effettua la parametrizzazione spettrale
di un segmento della traccia e genera un nuovo modello hmm.
Definita V la dimensione del vettore di indirizzi sui quali applicare la
DCT, la trasformata discreta del coseno, e N il numero di vettori scelti per
la finestra di questa fase dell’addestramento, sono individuati sulla traccia
sul disco V N vettori. Di ognuno di questi viene calcolata la DCT e ne
vengono salvati i primi Cs elementi. Nel tool la DCT ` stata implementata
e
in C utilizzando come riferimento i paramentri di scala proposti in GNU
Octave [11].
Figura 5.1: I modelli hmm vengono addestrati utilizzando l’algoritmo di
Baum-Welch su sequenze di centroidi
Il procedimento descritto comporta una compressione dei dati disponi-
bili, avendo ora in memoria N vettori di dimensione Cs si vuole discretizzare
questo insieme utilizzando un algoritmo di k-means clustering. L’imple-
mentazione nel tool ` stata effettuata utilizzando come base algoritmica un
e
sorgente ansi C sviluppato da Henrik Gruden, Gabriele Cutazzo, Cristiano
Vanon, Enzo Mumolo. Tale sorgente ` stato esteso e adattato per poter allo-
e
care tutte le strutture dati dinamicamente e gestire input e ouput bufferizzati
in memoria. L’algoritmo produce in output un insieme di Cn centroidi che
faranno parte del modello hmm e perci` devono essere memorizzati su disco.
o
Per i centroidi ` stato definito un formato di output binario. Ogni elemento
e
dell’insieme di N vettori generati precedentemente pu` ora essere associato
o
36

37. ad un centroide: si procede quindi con una ulteriore compressione da N
vettori di Cs elementi a N interi appartenenti all’alfabeto di Cn centroidi.
Ora che si ` ottenuta una sequenza di numeri interi ` possibile pro-
e e
cedere con l’addestramento di una hmm discreta di S stati: ` stata utiliz-
e
zata la libreria sviluppata da Tapas Kanungo [12] che applica l’algoritmo
di BaumWelch per trovare la matrice degli stati della hmm. Tale libreria
(open source) ` stata modificata per effettuare tutto il lavoro in memoria
e
senza richiedere input da file, affinch` tutto il procedimento dalla sequen-
e
za di indirizzi fino al completamento dell’addestramento potesse avvenire
senza effettuare I/O su disco e affinch` fosse possibile definire la dimen-
e
sione di tutte le strutture dati da linea di comando o comunque runtime e
non a tempo di compilazione, per ottenere la massima flessibilit` nei test
a
successivi.
5.2 Test hmm
Con i file del modello hmm e dei centroidi ` possibile testare una traccia
e
qualsiasi: il procedimento di parametrizzazione spettrale ` lo stesso ma i
e
centroidi in questo caso non verranno calcolati ma caricati e verr` applicato
a
l’algoritmo di Viterbi, il quale produce in output una probabilit`: la prob-
a
abilit` che la sequenza di indirizzi della traccia in ingresso appartenga a tale
a
modello hmm. Per mantere l’integrit` tra il tool di addestramento e quello
a
di test essi sono stati sviluppati come un unico sorgente che viene compilato
in modi differenti a seconda dei flag passati al compilatore da GNU make.
Figura 5.2: Viene calcolata la probabilit` di appartenenza di una traccia ad
a
un modello con l’algoritmo di Viterbi utilizzando centroidi e modello hmm
37

38. 5.3 Addestramento reti neurali
Come algoritmo di machine learning comparativo per i modelli di Markov
nascosti sono state scelte le reti neurali [13]. Una rete neurale simula il
comportamento dei neuroni biologici per ottenere un effetto di memoria e
riconoscere pattern e similarit` tra gli input assegnati. Le reti utilizzate in
a
questo caso si compongono di diversi neuroni organizzati in strati, con gli
strati completamente connessi tra loro, ovvero ogni neurone di un determi-
nato strato ` connesso con tutti i neuroni dello strato precedente i quali
e
fungono da input. Ogni connessione tra i neuroni ha un peso. Ogni neurone
calcola il proprio valore di output effettuando la somma pesata di tutte le
connessioni in input ed applicando a questa somma una funzione di soglia,
1
tipicamente la sigmoide f (x) = 1+e−x .
Figura 5.3: Viene utilizzata la sequenza di centroidi come input per la rete
Una rete di architettura cos` definita ` determinata quindi univocamente
ı e
dai valori dei pesi. Sono stati utilizzati 3 strati: input layer, hidden layer, e
output layer. E’ stato fatto uso di apprendimento supervisionato, ovvero ad
ogni esempio per il quale si vuole addestrare la rete ` associato anche l’output
e
desiderato. Per tutto il codice relativo alle reti non si ` fatto affidamento
e
a librerie presenti in letteratura, ` stato implementato ex-novo utilizzando
e
l’algoritmo di back-propagation dell’errore per effettuare l’aggiornamento
dei pesi.
Per poter effettuare una comparazione tra il modello di apprendimento
hmm e le reti neurali nel caso della classificazione di tracce di indirizzi ` stato
e
utilizzato lo stesso procedimento di parametrizzazione spettrale. Ottenuta
la sequenza di N interi questi sono riportati in forma binaria su log2 Cn bit
ognuno, cos` che ogni bit 0, 1 diventi un input per il primo strato di neuroni.
ı
38

39. Tali input vengono utilizzati in gruppi di mlog2 Cn come esempi di un set di
apprendimento per la rete reurale. Il set di apprendimento viene generato
sovrapponendo un esempio di mlog2 Cn input col successivo in diversi modi
per addestrare la rete alla sequenza di simboli.
5.4 Test reti neurali
Per il test di una rete viene selezionato un punto casuale della traccia dal
quale far partire la lettura degli indirizzi, ottenuto un set di N interi quantiz-
zando i vettori risultato della dct questi vengono riportati in forma binaria
allo stesso modo della fase di addestramento e mappati sugli input della rete.
L’output della rete ` dato da un valore reale compreso tra [0, 1].
e
5.5 Analisi offline
L’analisi offline prevede di analizzare una traccia di indirizzi pre-generata
leggendola dal disco. Per generare le tracce ` stata sviluppata un’estensione
e
di Valgrind, tracebin, che genera le tracce in formato binario. Il formato
del file ` definito dalle chiamate a VG_(write) presenti in tracebin:
e
VG_(write)(fd_bin,&addr,sizeof(Addr));
VG_(write)(fd_bin,&ss,sizeof(UShort));
VG_(write)(fd_bin,&op,sizeof(Char));
VG_(write)(fd_bin,&padding,sizeof(Char));
Sono registrati indirizzo, dimensione in byte e modalit` di accesso. L’ottavo
a
byte ` di padding ed ` sempre 0xFF.
e e
Sono state quindi generate due tracce per ogni benchmark con diversi
input scelti tra quelli previsti da SPECint. Per la prima fase di analisi sono
stati utilizzati 4 diversi benchmark, 2 tracce per ognuno di essi variandone
l’input tra la prima e la seconda esecuzione. I benchmark utilizzati con
relativi input e dimensione delle tracce sono:
400.perlbench checkspam (37GB), diffmail (40GB)
401.bzip2 chicken.jpg (55GB), text.html (45GB)
403.gcc 166.i (58GB), 200.i (51GB)
445.gobmk nntgs.tst (31GB), score2.tst (32GB)
5.5.1 Hmm
Sono stati sviluppati due programmi che effettuano addestramento e test
delle tracce. Il primo produce come output due file caratterizzanti il modello
addestrato (relativi a centroidi ed hmm), il secondo applica l’algoritmo di
39

40. Viterbi e stampa un valore floating point corrispondente alla probabilit` che
a
la traccia processata corrisponda al modello addestrato. I due programmi
sono configurabili tramite le seguenti opzioni:
./train [options] <tracefile>
./test [options] -C [centroids file] -H [hmm file] <tracefile>
-w <int> numero di blocchi di indirizzi da processare, def 1000
-d <int> numero di indirizzi per blocco, default 1024
-v <int> dimensione dei vettori da quantizzare, default 16
-c <int> numero di centroidi, default 64
-n <int> numero di stati della hmm, default 12
-s <int> offset dal quale iniziare l’analisi, default 0
-D <string> output directory, default "/tmp"
5.5.2 Reti neurali
Per le reti neurali sono stati sviluppati 3 programmi: un programma segue
il processo di parametrizzazione precedentemente spiegato per generare un
due training set: uno generato dalla traccia di riferimento e un set generato
da altre tracce scelte casualmente. Un secondo programma effettua l’ap-
prendimento addestrando la rete per riconoscere con output vicino a 1.0 il
training set generato dalla traccia di riferimento e con output vicino a 0
il training set generato dalle altre tracce. Un programma ancora diverso
effettua il test prendendo un segmento da una traccia definita da linea di
comando.
Separando in diversi tool il lavoro ` stato possibile parallelizzare gli step
e
dei procedimenti ed effettuare addestramenti di reti con diversi parametri a
partire dallo stesso training set.
5.6 Analisi con Valgrind
L’analisi offline comporta uno svantaggio ineludibile, l’accesso al disco: per
processare diversi GB di traccia occorre molto tempo. Effettuare l’analisi di-
rettamente all’interno di Valgrind mentre il programma ` in esecuzione per-
e
metterebbe di evitare di dover generare, memorizzare e leggere i file traccia.
E’ stato sviluppato quindi un tool per Valgrind che applica la parametriz-
zazione spettrale ed esegue apprendimento e test di hmm utilizzando diret-
tamente gli indirizzi di memoria via via che vengono generati dai benchmark.
A tale tool ` stato dato il nome di tracehmm ed ` stato inserito nel sistema
e e
di compilazione di Valgrind assieme agli altri tool della distribuzione.
Il porting all’interno del framework dei tool sviluppati per l’analisi of-
fline non pu` essere effettuato direttamente in quanto sia i tool sia coregrind
o
non possono utilizzare alcuna libreria utilizzata anche dal client, nemmeno
40

41. glibc. Per quanto riguarda la libreria standard ` stato necessario riscri-
e
vere tutte le chiamate di scrittura/lettura da file e di allocazione e copia
della memoria affinch` utilizzassero il sottinsieme di funzioni libc reimple-
e
mentate all’interno del framework appositamente per questo scopo. Inoltre
non essendo possibile utilizzare nemmeno la libreria matematica sono state
selezionate le funzioni necessarie per l’analisi (cos,sqrt,log) ed inserite in
modo indipendente dalla libm insieme ai sorgenti del tool. Per verificare che
l’importazione fosse stata effettuata correttamente ` stata anche effettuata
e
una comparazione dei risultati con quelli ottenuti eseguendo le istruzioni
SSE2 non portabili fcos,fsqrt,fyl2x come assembly inline. Anche l’ar-
chitettura dei tool precedenti ` stata cambiata per rispettare la struttura
e
interna di Valgrind, che non offre l’accesso ad un flusso di istruzioni lineare
ma prevede che venga inserito codice di instrumentazione in tutti i blocchi di
istruzioni tradotti, i quali verranno eseguiti solo se l’esecuzione raggiunger`
a
quel particolare punto.
5.6.1 Tracehmm
Il tool sviluppato presenta un’interfaccia completamente configurabile da
opzioni da linea di comando:
usage: valgrind --tool=tracehmm [options] prog-and-args
--new=<model.hmm> train a new hmm model
--resume=<model.hmm> resume training
--test=<model.hmm> test hmm model
--centroids=<model.ct> centroids file
--skip=<int> memory blocks to skip
--window=<int> window size
--verbose=yes|no verbose [yes]
--vverbose=yes|no very verbose [no]
--ct-n=<int> num of centroids
--st-n=<int> num of statuses
Con esso ` possibile effettuare sia l’apprendimento di un nuovo modello sia
e
caricare un modello precedentemente generato e riprendere l’addestramen-
to. Questa seconda funzionalit` si rivela utile per addestrare un modello
a
generico di un benchmark indipendente dall’input assegnatogli inizialmente,
effettuando diversi cicli di addestramento variando l’input assegnato.
Durante l’esecuzione di un programma ogni volta che si entra in un nuovo
blocco di istruzioni questo viene tradotto in VEX IR con il quale coregrind
chiama la funzione th_instrument del tool. Questa funzione ha il com-
pito di manipolare il blocco di istruzioni aggiungendo il proprio codice di
instrumentazione nella forma tipicamente di chiamate a funzioni C e di ri-
tornare un nuovo blocco. In questa fase sarebbe anche possibile rimuovere
o modificare istruzioni esistenti.
41

42. Figura 5.4: Struttura di tracehmm
Tracehmm riconosce le istruzioni che effettuano accessi in memoria e
prepone ad ognuna di esse nel blocco di istruzioni che ritorner` a coregrind
a
una chiamata alla funzione th_addresshandler con il meta-indirizzo del-
l’istruzione interessata come parametro.
Non ` possibile registrare gli indirizzi in questo momento dell’instrumen-
e
tazione in quanto non sono ancora indirizzi ma meta-indirizzi, questo perch` e
il blocco che ` stato analizzato n` ha un flusso di esecuzione lineare (single-
e e
entry, multiple-exit) n` ` assicurato che venga eseguito soltanto una volta:
ee
Valgrind effettua il caching della traduzione dei blocchi. I meta-indirizzi
contengono quindi informazioni su come ottenere l’indirizzo dell’accesso in
memoria e non l’indirizzo stesso: quando il blocco verr` eseguito coregrind
a
trover` le chiamate a th_addresshandler, generer` l’indirizzo reale e la
a a
funzione cos` chiamata potr` aggiungere l’indirizzo al suo buffer. Per le in-
ı a
struction fetch ` pi` semplice in quanto basta passare a th_addresshandler
e u
il valore del program counter.
th_addresshandler per prima cosa controlla per` di aver rispettato l’offset
o
indicato dall’opzione -skip=offset: i primi of f set · buf f ersize indirizzi
vengono scartati come richiesto dall’utente. Quindi un vettore di indirizzi
viene gradualmente riempito fino a raggiungere la dimensione stabilita per
quale iniziare l’analisi: effettuare la DCT del vettore e salvarne i risultati.
Questo viene ripetuto per un numero di volte definito da -window perch` poi
e
42

43. venga chiamata th_action_NORETURN() (` stata rispettata la convenzione
e
interna a Valgrind per i nomi delle funzioni) e l’analisi prosegua allo stesso
modo dei tool offline.
43

44. 44

45. Capitolo 6
Risultati sperimentali
Il procedimento di analisi delle tracce ` stato suddiviso in due parti: analisi
e
offline e analisi in Valgrind. Nel primo caso ` stato analizzato un insieme
e
di 4 benchmark, nel secondo ` stato possibile effettuare prove sull’insieme
e
completo dei 12 benchmark di SPECint. I 4 benchmark del primo insieme
di test sono stati scelti in base ad un criterio di disponibilit` di input: gcc,
a
bzip2, gobmk e perlbench presentano ognuno 4 o pi` file sui quali ef-
u
fettuare l’addestramento rispetto ad altri benchmark i quali offrono meno
possibilit` di scelta.
a
Figura 6.1: Processo di classificazione di una traccia sui modelli
Le modalit` di test utilizzate sono due, alle quali ` stato dato il nome di
a e
verifica e classificazione. La modalit` di verifica consiste nell’addestrare
a
con un benchmark B un modello hmm e eseguire su questo modello test
di affinit` con B e poi con tutti gli altri benchmark. Per ognuno viene
a
quindi confrontata la probabilit` che il modello corrisponda alla traccia con
a
la probabilit` generata da B. La percentuale di casi per i quali la probabilit`
a a
del benchmark effettivamente corrispondente alla traccia ` maggiore rispetto
e
agli altri indica la percentuale successo del test di verifica.
Il test di classificazione invece prevede di addestrare un insieme di modelli
completo, uno per ogni benchmark, e con questi effettuare il test di un
benchmark B: se il modello che ` stato addestrato con B risponde con un
e
45

46. probabilit` pi` alta degli altri il test ha avuto successo. In particolare per
a u
ogni coppia formata da traccia e benchmark che dichiara di essere deve essere
effettuata la scelta tra:
• H0 ≡ il processo corrisponde al benchmark dichiarato
• H1 ≡ il processo non corrisponde
Per decidere tra le due ipotesi viene effettuato un test di affinit` ovvero
a
calcolata le probabilit` P di appartenenza della sequenza:
a
P (H0 )
• P (H1 ) > Θ allora l’ipotesi viene accettata
P (H0 )
• P (H1 ) < Θ viene rifiutata.
Come descritto in dettaglio a pag. 51 si vuole trovare un valore di Θ che
massimizzi numero di riconoscimento corretti, ovvero che limiti al massimo
i casi per cui si ottiene un falso positivo o un falso negativo. Tali eventi
si verificano quando un modello presenta affinit` maggiore con il benchmark
a
eseguito rispetto a tutti gli altri pur non essendo quello realmente corrispon-
dente (falso positivo) o quando un processo dichiara di appartenere ad un
benchmark che in realt` non gli corrisponde e questo non viene riconosciuto
a
(falso negativo).
6.1 Risultati test offline
I limiti imposti dalla metodologia di analisi offline hanno permesso di effet-
tuare test su porzioni di tracce di dimensioni limitate, in particolare ` stato
e
scelto di effettuare solamente test di verifica in quanto pi` rapido del test di
u
classificazione. Il processo di riconoscimento utilizzato in questa fase prevede
di addestrare un modello hmm utilizzando una sola traccia e testarlo con
tutte le 8 tracce del set di 4 benchmark scelto. Se il test di Viterbi produce
una probabilit` maggiore per le due tracce appartenenti al benchmark as-
a
sociato al modello allora il test ha avuto successo. Per quanto riguarda le
reti neurali un valore prossimo a 1 dato dal neurone di output significa che
la traccia ` stata riconosciuta.
e
6.1.1 Test di verifica hmm
Per trovare i valori ottimali dei parametri di addestramento ` stato svilup-
e
pato uno script che effettua test variando il numero di stati, di centroidi,
di blocchi di indirizzi e la dimensione dei vettori per addestrare e testare i
modelli. Parametri ottimali per le 4 tracce prese in esame in questa fase sono
stati trovati in 64 centroidi e 12 stati (fig 6.2), con i quali ` stato possibile
e
riconoscere tutte le 8 tracce nel caso di segmenti di addestramento e test
di dimensione contenuta. Con tali parametri le tracce di bzip rispondono
46

47. con valori molto pi` elevati rispetto alle altre quando testate su un modello
u
hmm addestrato con bzip, e lo stesso per gcc, gobmk e perlbench.
Figura 6.2: precisione nel riconoscimento al variare di stati e centroidi
Nel grafico in fig 6.3 ` rappresentata l’affinit` (in ordinata) di ognuna
e a
delle 8 tracce (in ascissa) rispetto ad un modello di hmm addestrato a ri-
conoscere un determinato benchmark (in legenda). Le tracce sono disposte a
coppie, la prima coppia a sinistra corrisponde ai benchmark 400.perl.diffmail
e 400.perl.checkspam. I valori per i primi due punti rispetto all’asse delle
ascisse sono maggiori rispetto a tutti gli altri, la traccia ` stata quindi ri-
e
conosciuta come proventiente dal benchmark 400.perl. Le stesse consid-
erazioni si possono fare per gli altri benchmark: 401.bzip2 (punti 3 e 4),
403.gcc (punti 5 e 6) e 445.gobmk (ultimi due punti).
Comparando i singoli risultati tra loro si pu` notare che alcuni bench-
o
mark siano pi` facili da riconoscere rispetto ad altri. I risultati relativi a
u
401.bzip2 presentano molto scarto tra quelli ottenuti nei test con il loro mod-
ello e quelli di altri benchmark. Inoltre addestramenti di modelli differenti
ma relativi allo stesso benchmark portano a risultati compatibili tra loro nei
test, indicando una buona generalizzazione degli stessi.
6.1.2 Test di verifica reti neurali
Lo stesso procedimento ` stato utilizzato per provare l’efficacia delle reti
e
neurali in questo contesto. Effettuando un singolo test delle 8 tracce su 4
reti non si ottengono risultati validi, ma siccome la procedura di calcolo del-
l’output di una rete neurale ` molto pi` rapida dell’algoritmo di Viterbi per
e u
47

48. Figura 6.3: test offline hmm su 8 tracce
una hmm, per ogni test traccia/modello sono stati calcolati numerosi out-
put della rete prendendo come punto d’ingresso diversi punti della traccia.
Escludendo i valori massimi e minimi di questo set di risultati ` possibile
e
notare un trend nel riconoscimento delle tracce. Nel grafico in fig 6.4, rela-
tivo ad una rete addestrata con perlbench, si pu` notare come la sequenza
o
di test relativi alle due tracce generate con perlbench sia sempre superiore
ai test effettuati con le tracce degli altri benchmark.
Estendendo questo processo a tutti e 4 i benchmark non si ottengono
per` gli stessi risultati(fig 6.5): gcc ` risultato non riconoscibile e anche
o e
altre tracce non sono state riconoscibili al 100%.
Con i risultati ottenuti si ricava che l’apprendimento tramite hmm dis-
crete risulta pi` efficace rispetto alle reti neurali nel caso di tracce parametriz-
u
zate spettralmente. Per fase analisi successiva si ` scelto quindi di effettuare
e
test pi` estesi utilizzando soltanto hmm.
u
6.2 Analisi su Valgrind
Lo sviluppo del tool tracehmm ha permesso di effettuare una serie di test
molto pi` estesa variando i training set mantenendo tempi di esecuzione
u
ragionevoli. Sono stati effettuati nuovamente i test di verifica descritti in
precedenza seguiti da estesi test di classificazione.
48

49. Figura 6.4: serie di test di riconoscimento di perlbench utilizzando reti
neurali
Figura 6.5: precisione nel riconoscimento di 8 tracce con le reti neurali
49

50. 6.2.1 Test di verifica
Prima di utilizzare tutti i 12 benchmark di Spec sono stati effettuati nuova-
mente i test di verifica su 4 tracce utilizzando per` pi` input a disposizione,
o u
per un totale di 16 tracce provenienti dagli stessi 4 benchmark, ottenendo
gli stessi risultati dei test offline. In fig. 6.6 si possono vedere i risultati dello
stesso test di verifica effettuato per` sull’insieme completo dei 12 benchmark,
o
ottenendo una percentuale di riconoscimento media dell’80%.
Figura 6.6: Risultati test di verifica su 12 benchmark, 30 tracce
6.2.2 Test di classificazione
Per la fase di apprendimento sono stati utilizzati tutti i 12 benchmark di
Spec INT2006, di ogni benchmark ` stato calcolato un modello hmm utiliz-
e
zando i valori ottimali di centroidi e di stati ottenuti nei test offline effettuati
precedentemente (64 centroidi, 12 stati). Ogni modello ` stato addestrato
e
eseguendo il benchmark pi` di una volta variandone l’input, al fine di otten-
u
erne un modello il pi` generalizzato possibile. Sono stati sperimentati tre
u
diversi modi di apprendimento dei modelli, utilizzando parti differenti della
traccia in ingresso.
standard Definita W la dimensione della finestra di indirizzi da utilizzare
per il calcolo dei centroidi e per un primo apprendimento, S il numero
di indirizzi da scartare prima di iniziare l’apprendimento, di ogni in-
put vengono utilizzati per l’addestramento N finestre di indirizzi W a
partire da S + W k. Fig: 6.7
50

51. dimensioni ridotte Definita W la dimensione della finestra di indirizzi da
utilizzare per il calcolo dei centroidi e per un primo apprendimento, S
il numero di indirizzi da scartare prima di iniziare l’apprendimento, di
ogni input vengono utilizzati per l’addestramento N finestre di indirizzi
W/2 a partire da S + (W/2)k. Fig: 6.8
sovrapposizione Definita W la dimensione della finestra di indirizzi da
utilizzare per il calcolo dei centroidi e per un primo apprendimento, S
il numero di indirizzi da scartare prima di iniziare l’apprendimento, di
ogni input vengono utilizzati per l’addestramento N finestre di indirizzi
W a partire da S + (W/R)k. Fig: 6.9
I test vengono effettuati applicando l’algoritmo di Viterbi ad un bench-
mark per ogni modello. Il valore di output (probabilit`) del test di Viterbi
a
del modello corrispondente al benchmark eseguito viene preso come valore di
riferimento. I valori corrispondenti agli altri modelli vengono confrontati con
questo, se presentano affinit` maggiore con il benchmark eseguito vengono
a
contati come falsi positivi.
Per trovare i falsi negativi viene eseguito un benchmark ma preso come
modello di riferimento uno corrispondente ad una traccia diversa. In questo
caso se il modello presenta pi` affinit` rispetto a tutti gli altri modelli si `
u a e
in presenza di un falso negativo. L’affinit` di un’esecuzione con quella di
a
riferimento si calcola come il rapporto tra la probabilit` del modello preso
a
in considerazione moltiplicata per un valore θ rispetto a quella del modello
di riferimento. Al variare di θ quindi un determinato benchmark produrr` a
pi` o meno falsi positivi/negativi.
u
Per ogni modello di addestramento preso in considerazione sono stati
eseguiti i benchmark con diversi input in ingresso e calcolata poi la per-
centuale di errore al variare di θ. Con i parametri utilizzati si riesce quindi
ad ottenere una precisione media nella classificazione delle tracce di circa
80% come presente in Fig. 6.12, ovvero dove le linee di falsi positivi e falsi
negativi si intersecano.
Al crescere dell’insieme di test il modello di apprendimento migliore cam-
bia, e sono necessari insiemi di test pi` grandi per un corretto riconosci-
u
mento delle tracce. Sono stati effettuati test su tutti i 12 benchmark di
SpecCPU2006 e calcolato i valori ottimale di θ. In Fig 6.14 si ottengono i
risultati migliori, assestando intorno al 25% l’errore di classificazione delle
tracce.
Utilizzando il set completo di benchmark di SPECint la precisione dei
risultati diminuisce ma si assesta comunque tra 70% e 80% utilizzando una
metodologia di apprendimento adeguata.
51

52. Figura 6.7: In chiaro a sinistra la parte di traccia utilizzata per definire i
centroidi. A destra le parti utilizzate per la prosecuzione dell’addestramento
standard
Figura 6.8: In chiaro a sinistra la parte di traccia utilizzata per definire i
centroidi. A destra le parti utilizzate per la prosecuzione dell’addestramento
a finestre di dimensioni ridotte
Figura 6.9: In chiaro a sinistra la parte di traccia utilizzata per definire i
centroidi. A destra le parti utilizzate per la prosecuzione dell’addestramento
con sovrapposizione
52

53. Figura 6.10: Risultati con addestramento del tipo standard con 4 bench-
mark, 4 input per benchmark (16 tracce). L’addestramento standard
prevede di utilizzare lo stesso numero di segmenti di traccia per il calcolo
dei centroidi e per la prosecuzione dell’addestramento.
53

54. Figura 6.11: Risultati con addestramento del tipo dimensioni ridotte
con 4 benchmark, 4 input per benchmark (16 tracce). Tale tipo di addestra-
mento prevede di utilizzare un numero di segmenti di traccia molto ampio
per calcolare i centroidi nel modo pi` accurato possibile e un numero di
u
segmenti minore per la prosecuzione dell’addestramento.
54

55. Figura 6.12: Risultati con addestramento del tipo sovrapposizione con 4
benchmark, 4 input per benchmark (16 tracce). Tale tipo di addestramento
prevede di utilizzare un segmenti di traccia parzialmente sovrapposti per
l’addestramento, come in fig. 6.9.
55

56. Figura 6.13: Risultati con addestramento del tipo standard con 12 bench-
mark, 30 tracce totali. L’addestramento standard prevede di utilizzare lo
stesso numero di segmenti di traccia per il calcolo dei centroidi e per la
prosecuzione dell’addestramento.
56

57. Figura 6.14: Risultati con addestramento del tipo dimensioni ridotte
con 12 benchmark, 30 tracce totali. Tale tipo di addestramento prevede
di utilizzare un numero di segmenti di traccia molto ampio per calcolare i
centroidi nel modo pi` accurato possibile e un numero di segmenti minore
u
per la prosecuzione dell’addestramento.
57