Profilazione utente in ambienti virtualizzati

UNIVERSITÀ DEGLI STUDI DI TRIESTE
Dipartimento di Ingegneria e Architettura
Corso di Laurea Magistrale in Ingegneria Informatica
Tesi Di Laurea
Prolazione utente in ambienti
virtualizzati
Laureando
Pietro Corona
Matricola IN1400023
Relatore
Prof. Nolich Massimiliano
Anno Accademico 2012/2013

Dedicato alla mia famiglia e a Greta

Ringraziamenti
• La mia gratitudine va al prof. Nolich per il suo preziosissimo aiuto e per
la sua innita disponibilità.
• Ringrazio il prof. Mumolo per i preziosi consigli dati in fase di analisi
dei risultati.
iii

Introduzione
Nei moderni sistemi di elaborazione dati delle aziende, sia grandi che medio-
piccole, la virtualizzazione è una tecnica sempre più diusa. Essa permette,
ad esempio, di consolidare numerosi server in un'unica macchina sica, oppure
ai provider di servizi di Web hosting di orire ai propri clienti una macchi-
na dedicata senza la necessità di aggiungere una macchina sica all'interno
del loro data center. Questo comporta numerosi vantaggi dal punto di vista
della gestione (manutenzione, backup ecc...). In tale scenario risulta fonda-
mentale un eciente utilizzo delle risorse. La prolazione dell'utente, inteso
sia come utente umano che come programma in esecuzione su una macchina,
è una tecnica che permette di predire il comportamento dell'utente attraverso
l'identicazione con un modello noto a priori. Per prolare l'utente, quindi, è
necessaria la creazione di uno o più modelli che rappresentino i comportamenti
di interesse dell'utente nell'ambito considerato. Ad esempio questi comporta-
menti potrebbero riguardare l'utilizzo delle risorse. Per la creazione dei modelli
è necessario raccogliere dati sul comportamento dell'utente, da cui si estrarran-
no le features di interesse per la creazione dei modelli e / o l'identicazione del
comportamento utilizzandone uno esistente. Se il comportamento che si vuo-
le modellare è l'utilizzo delle risorse, questo processo viene denito workload
characterization. In letteratura esistono delle proposte (esempio [MAER09] )
di framework per il workload characterization in ambienti virtualizzati.
Obiettivo della tesi
Partendo da tali premesse, il problema arontato nella tesi, che fa parte del pro-
blema più generale della prolazione utente, è l'identicazione di un program-
ma in esecuzione su una macchina virtuale. L'obiettivo principale è realizzare
un sistema che permetta di riconoscere, attraverso i dati ricavabili dall'API
del Virtual Machine monitor, il programma in esecuzione sulla macchina vir-
tuale. L'obiettivo principale comporta il raggiungimento dei seguenti obiettivi
intermedi:
iv

INTRODUZIONE v
• capire se è possibile ricavare dati utili dai virtual machine monitor pre-
senti sul mercato;
• assicurarsi che la raccolta dei dati non impatti eccessivamente nelle per-
formance;
• realizzare i modelli dei programmi;
• testare i modelli realizzati;
il tutto in un ambiente il più simile possibile agli ambienti reali. La realizza-
zione di un sistema che risolva il problema esposto è da ritenersi importante
in quanto:
• potrebbe interessare ai sistemisti come strumento di scheduling e alloca-
zione ottimale delle risorse;
• potrebbe interessare ai gestori di server virtualizzati per monitorare il
workload del server;
• potrebbe essere impiegato per modellare il comportamento di malware.
Struttura della tesi
Il primo capitolo tratta il problema della virtualizzazione in generale, con
l'obiettivo di inquadrare il problema nella giusta prospettiva.
Nel secondo capitolo viene fatta una carrellata sulle tecniche di machine
learning impiegate nella realizzazione del sistema di user proling.
Il terzo capitolo tratta la suite di benchmark Spec CPU2006, utilizzata per
avere dei programmi la cui esecuzione è facilmente ripetibile nelle stesse con-
dizioni.
Nel quarto capitolo viene fatta una valutazione dei principali Virtual Ma-
chine Monitor presenti sul mercato al ne di scegliere quello più adatto allo
scopo, illustrandone vantaggi e svantaggi
Il quinto capitolo descrive il Virtual Machine Monitor VirtualBox, assieme
alla sua API.
Nel sesto capitolo viene trattata l'analisi dei dati che estratti dall'API di
VirtualBox.
Il settimo capitolo contiene una descrizione del software realizzato.
L'ottavo capitolo contiene la descrizione e i risultati degli esperimenti rea-
lizzati.

Indice
Introduzione iv
Obiettivo della tesi . . . . . . . . . . . . . . . . . . . . . . . . . . . . iv
Struttura della tesi . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
Indice vi
Elenco delle gure x
1 Macchine Virtuali 1
1.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Virtualizzazione . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Vantaggi delle macchine virtuali . . . . . . . . . . . . . . . . . . 2
1.4 Tassonomia della macchine virtuali . . . . . . . . . . . . . . . . 3
1.4.1 Macchine virtuali a livello di processo . . . . . . . . . . . 4
1.4.2 Macchine virtuali a livello di sistema . . . . . . . . . . . 5
2 Tecniche di Machine Learning 6
2.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Reti neurali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1 Il neurone articiale . . . . . . . . . . . . . . . . . . . . 8
2.2.2 Connessioni tra i neuroni . . . . . . . . . . . . . . . . . . 10
2.2.3 Funzioni di attivazione e output . . . . . . . . . . . . . . 10
2.2.4 Topologie di rete . . . . . . . . . . . . . . . . . . . . . . 10
2.2.5 Addestramento di una rete neurale . . . . . . . . . . . . 11
2.3 K-means . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4 Modelli di Markov nascosti . . . . . . . . . . . . . . . . . . . . . 13
2.5 DCT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.6 Dempster-Shafer Therory . . . . . . . . . . . . . . . . . . . . . . 15
3 Spec 16
3.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
vi

INTRODUZIONE vii
3.2 CPU2006 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3 Benchmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3.1 401.bzip2 . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3.2 445.gobmk . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3.3 458.sjeng . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3.4 403.gcc . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3.5 464.h264ref . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3.6 400.perlbench . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3.7 429.mcf . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.8 462.libquantum . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.9 456.hmmer . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.10 471.omnetpp . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.11 473.astar . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.12 483.xalancbmk . . . . . . . . . . . . . . . . . . . . . . . 20
3.4 Input dei benchmark . . . . . . . . . . . . . . . . . . . . . . . . 20
4 Valutazione di diversi VMM 21
4.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2 Valutazione dei VMM . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.1 VMware vSphere Hypervisor . . . . . . . . . . . . . . . . 21
4.3 VMware Player . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3.1 Virtual Box . . . . . . . . . . . . . . . . . . . . . . . . . 22
5 Virtual Box 24
5.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.2 VirtualBox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.2.1 Virtualizzazione software-based . . . . . . . . . . . . . . 24
5.2.2 Virtualizzazione hardware-assisted . . . . . . . . . . . . . 25
5.2.3 Virtualizzazione delle periferiche . . . . . . . . . . . . . . 25
5.3 API di Virtual Box . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.3.1 Considerazioni sulla API . . . . . . . . . . . . . . . . . . 26
6 Analisi dei dati 29
6.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.2 Aspetti legali . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.3 Memory References . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.3.1 Caratterizzazione della sequenza dei memory references . 30
6.3.2 Divisione in frame . . . . . . . . . . . . . . . . . . . . . 30
6.3.3 Divisione in blocchi . . . . . . . . . . . . . . . . . . . . . 32
6.3.4 Analisi spettrale tramite DCT . . . . . . . . . . . . . . . 33
6.4 Indicatori sull'utilizzo delle risorse . . . . . . . . . . . . . . . . . 34

INTRODUZIONE viii
6.4.1 Caratterizzazione della sequenza di indicatori sull'utiliz-
zo delle risorse . . . . . . . . . . . . . . . . . . . . . . . . 36
7 Software realizzato 38
7.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
7.2 Strumenti utilizzati . . . . . . . . . . . . . . . . . . . . . . . . . 38
7.3 Sistema di acquisizione dati . . . . . . . . . . . . . . . . . . . . 39
7.3.1 Architettura . . . . . . . . . . . . . . . . . . . . . . . . . 40
7.3.2 Funzionamento . . . . . . . . . . . . . . . . . . . . . . . 41
7.3.3 Problemi riscontrati durante lo sviluppo . . . . . . . . . 42
7.4 Creazione delle frame . . . . . . . . . . . . . . . . . . . . . . . . 45
7.4.1 Funzionamento . . . . . . . . . . . . . . . . . . . . . . . 46
7.5 Divisione in blocchi e clustering . . . . . . . . . . . . . . . . . . 48
7.5.1 Funzionamento . . . . . . . . . . . . . . . . . . . . . . . 48
7.6 Addestramento e test di rete neurale . . . . . . . . . . . . . . . 51
7.6.1 Funzionamento . . . . . . . . . . . . . . . . . . . . . . . 51
7.7 Addestramento e test di HMM . . . . . . . . . . . . . . . . . . . 54
7.8 Software per la fusione con Dempster-Shafer . . . . . . . . . . . 54
7.8.1 Funzionamento . . . . . . . . . . . . . . . . . . . . . . . 55
7.9 Riepilogo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
8 Esperimenti 59
8.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
8.2 Preparazione ambiente . . . . . . . . . . . . . . . . . . . . . . . 59
8.3 Dataset acquisiti . . . . . . . . . . . . . . . . . . . . . . . . . . 59
8.3.1 Sistema utilizzato per i test . . . . . . . . . . . . . . . . 60
8.4 Esperimenti preliminari . . . . . . . . . . . . . . . . . . . . . . . 60
8.4.1 Test tempi di acquisizione . . . . . . . . . . . . . . . . . 61
8.4.2 Impatto sulle performance . . . . . . . . . . . . . . . . . 61
8.5 Clusterizzazione Kmeans . . . . . . . . . . . . . . . . . . . . . . 62
8.6 Test del sistema realizzato Kmeans - Rete neurale con memory
reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
8.6.1 Dimensioni e tempo di sovrapposizione delle frame . . . 64
8.6.2 Coecienti della DCT da considerare . . . . . . . . . . . 65
8.6.3 Numero di blocchi . . . . . . . . . . . . . . . . . . . . . 65
8.6.4 Numero di cluster . . . . . . . . . . . . . . . . . . . . . . 66
8.6.5 Numero di epoche di addestramento . . . . . . . . . . . 67
8.6.6 Selezione dei programmi per i test . . . . . . . . . . . . . 67

INTRODUZIONE ix
8.6.7 Riepilogo . . . . . . . . . . . . . . . . . . . . . . . . . . 69
8.6.8 Confronto rete neurale con HMM . . . . . . . . . . . . . 69
8.6.9 Impatto della frequenza di campionamento sui memory
references . . . . . . . . . . . . . . . . . . . . . . . . . . 70
8.7 Test del sistema realizzato Kmeans - Rete neurale con gli indi-
catori sull'utilizzo delle risorse . . . . . . . . . . . . . . . . . . . 71
8.8 Test della fusione dati con la tecnica di Dempster-Shafer . . . . 72
8.9 Esempio di funzionamento in ambiente reale . . . . . . . . . . . 73
Conclusioni e sviluppi futuri 75
Riepilogo del lavoro svolto . . . . . . . . . . . . . . . . . . . . . . . . 76
Sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Bibliograa 79

Elenco delle gure
1.1 La virtualizzazione consiste nella costruzione di un isomorsmo. . . 3
1.2 Il codice portabile viene eseguito sull'implementazione specica del-
la macchina virtuale per una certa piattaforma. . . . . . . . . . . . 5
2.1 Componente base della rete neurale: il neurone. La regola di
propagazione è la somma pesata standard degli ingressi. . . . . . . 8
2.2 Neurone biologico. . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Modello di Markov nascosto . . . . . . . . . . . . . . . . . . . . . . 13
5.1 VirtualBox ha un'architettura a livelli . . . . . . . . . . . . . . . . 26
5.2 Misurazioni puntuali dei tempi di risposta dell'API nei due modi
di utilizzo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.1 Sequenza di valori del registro IP assunti durante l'esecuzione del
programma PerlBench . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.2 Sequenza di valori del registro IP assunti durante un'altra esecu-
zione del programma PerlBench . . . . . . . . . . . . . . . . . . . . 31
6.3 Operazione di framing del segnale . . . . . . . . . . . . . . . . . . . 32
6.4 Operazione di divisione in blocchi di una frame del segnale . . . . . 32
6.5 DCT del segnale . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.6 Percentuale utilizzo CPU User per 3 programmi in 2 esecuzioni
ciascuno. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.7 Percentuale utilizzo CPU Kernel per 3 programmi in 2 esecuzioni
ciascuno. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.8 Ram libera per 3 programmi in 2 esecuzioni ciascuno. . . . . . . . . 35
6.9 Fusione degli indicatori. . . . . . . . . . . . . . . . . . . . . . . . . 37
7.1 Architettura del software di acqusizione dati dalla VM. . . . . . . . 40
7.2 Esempio di struttura del database delle frame. . . . . . . . . . . . . 47
7.3 Architettura del software di fusione con Dempster-Shafer a partire
dai riconoscitori di memory reference e dati sull' utilizzo delle risorse. 55
7.4 Flusso dei dati nei programmi sviluppati. . . . . . . . . . . . . . . . 58
x

Elenco delle gure xi
8.1 Tempi di acquisizione dati misurati per 1000 campioni. . . . . . . . 61
8.2 Tempi di esecuzione di bzip e gcc sulla macchina virtuale durante
l'acquisizione e non. . . . . . . . . . . . . . . . . . . . . . . . . . . 62
8.3 Tasso di corretto riconoscimento in funzione della durata della frame 63
8.4 Tasso di corretto riconoscimento in funzione del numero di programmi 64
8.5 Tasso di corretto riconoscimento in funzione della durata della frame 65
8.6 Tasso di corretto riconoscimento in funzione della percentuale di
sovrapposizione delle frame . . . . . . . . . . . . . . . . . . . . . . 66
8.7 Tasso di corretto riconoscimento in funzione del numero dei coe-
cienti della DCT, con e senza componente continua. . . . . . . . . . 67
8.8 Tasso di corretto riconoscimento in funzione del numero di blocchi. 68
8.9 Tasso di corretto riconoscimento in funzione del numero di cluster. . 69
8.10 Tasso di corretto riconoscimento in funzione del numero di epoche
di addestramento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
8.11 Tasso di corretto riconoscimento in funzione del numero di pro-
grammi. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
8.12 Tasso di corretta identicazione in funzione dell'abbattimento della
frequenza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
1 Distribuzione di dettaglio del carico di lavoro. . . . . . . . . . . . . 77
2 Distribuzione per tipologia del carico di lavoro. . . . . . . . . . . . 77

Capitolo 1
Macchine Virtuali
1.1 Introduzione
I moderni computer sono delle strutture complesse e la loro esistenza è pos-
sibile solo grazie all'abilità dei progettisti di gestire questa complessità. La
chiave per gestire la complessità nei computer è la loro divisione in livelli di
astrazione separati da interfacce ben denite. I livelli di astrazione permettono
di nascondere o semplicare i dettagli implementativi dei livelli inferiori e nel
contempo di semplicare la progettazione dei livelli superiori. Ad esempio un
programmatore può leggere e scrivere i le senza nessuna conoscenza su co-
me funziona l'hard disk. I livelli sono organizzati gerarchicamente con i livelli
bassi implementati nell'hardware e i livelli alti implementati nel software. Nei
livelli hardware, tutti i componenti sono sici, hanno proprietà tangibili e le
interfacce sono denite in modo tale da permettere la connessione sica tra
le varie parti. Nei livelli software i componenti sono logici con pochi vincoli
imposti dalle caratteristiche siche. Ogni livello viene eseguito su una parti-
colare macchina. Ad esempio, dal punto di vista del sistema operativo, una
macchina è composta in gran parte dall'hardware mentre dal punto di vista
dei programmi utente, la macchina è una combinazione del sistema operativo
e delle porzione dell'hardware accessibili tramite istruzioni di livello utente.
Il vantaggio di denire delle interfacce tra i vari livelli consiste nel fatto che
gli sviluppatori hardware e software possono lavorare più o meno in modo in-
dipendente. Ad esempio i set di istruzioni permettono di slegare lo sviluppo
dei processori da quello dei compilatori. Il problema maggiore è dovuto al-
l'esistenza di diverse speciche di interfaccia[JS05]. Quindi programmi scritti
per processori con diversi set di istruzioni (Intel IA-32 e IBM PowerPC), o
per diversi sistemi operativi (Windows e Linux) non sono compatibili tra di
loro, nel senso che programmi scritti per una certa piattaforma non possono
1

CAPITOLO 1. MACCHINE VIRTUALI 2
essere eseguiti su un'altra. Un altro problema consiste nella dipendenza del
software dalle risorse hardware. Per risolvere questo problema i sistemi opera-
tivi mettono a disposizione un'interfaccia astratta per l'accesso all'hardware,
ad esempio per la memoria e per l'I/O. Questo approccio assume implicita-
mente che le risorse hardware di un sistema siano gestite da un unico sistema
operativo. Tuttavia questo approccio limita la essibilità del sistema non solo
vincolando il software che può esservi eseguito ma anche in termini di sicurezza
e robustezza, specialmente quando il sistema è multiutente.
1.2 Virtualizzazione
La virtualizzazione permette di rilassare i vincoli sopra esposti in modo da au-
mentare la essibilità del sistema nel senso sopra esposto. Quando un sistema
(o sottosistema) è virtualizzato, la sua interfaccia e le sue risorse sono mappa-
te nell'interfaccia e nelle risorse del sistema reale che lo implementa. Questo
trasforma il sistema reale in un sistema diverso o addirittura in un insieme di
sistemi diversi. Formalmente la virtualizzazione consiste nella costruzione di
un isomorsmo, illustrato in gura 1.1, che mappa un sistema virtuale ospite
(guest) in un sistema ospitante (host) [GJP74]. Questo isomorsmo mappa
lo stato del sistema guest nello stato del sistema host (funzione V in gura)
in modo tale che per ogni sequenza di operazioni ei che modica lo stato nel
guest da Si a Sj ci sia una corrispondente sequenza di operazioni ei nell'host
che ne modica lo stato da Si a Sj .
Sebbene un tale isomorsmo possa essere utilizzato anche per caratteriz-
zare un'astrazione del sistema sottostante facciamo la seguente distinzione: la
virtualizzazione dierisce dall'astrazione in quanto essa non maschera il livello
sottostante. Infatti il livello di astrazione in un sistema virtuale è spesso lo stes-
so del sistema sottostante. Il concetto di virtualizzazione può essere applicato
ai sottosistemi, come i dischi, ma anche a intere piattaforme. Una macchina
virtuale è implementata aggiungendo uno strato software alla macchina reale.
1.3 Vantaggi delle macchine virtuali
In generale, una macchina virtuale, può risolvere i problemi di compatibilità
e i limiti dell'hardware delle macchine reali garantendo così un elevato grado
di portabilità del software. L'utilizzo di più macchine virtuali in un sistema
multiutente garantisce una migliore sicurezza grazie all'isolamento. Inoltre è
possibile sfruttare al meglio le risorse disponibili. Le macchine virtuali rendo-

Figura 1.1: La virtualizzazione consiste nella costruzione di un isomorsmo.
no inoltre possibile, impiegando tecniche di emulazione, l'utilizzo di software
scritto per altre piattaforme.
1.4 Tassonomia della macchine virtuali
Dal punto di vista di un processo utente, la macchina consiste nella spazio
di memoria indirizzabile assegnato al processo, i registri della CPU e le istru-
zioni che ne permettono l'esecuzione. L'I/O è accessibile solo attraverso le
chiamate al sistema operativo, spesso raggruppate in librerie che sono parte
integrante del processo. Dal punto di vista del processo utente, la macchina è
costituita dal sistema operativo e dall'hardware sottostante. Dal punto di vista
del sistema operativo, invece, la macchina è costituita soltanto dell'hardware
sottostante. In modo analogo possiamo denire macchine virtuali a livello di
processo e a livello di sistema operativo. Una macchina virtuale a livello di pro-
cesso è in grado di eseguire un singolo processo. In questo caso il software della
macchina virtuale si colloca sopra il sistema operativo. La macchina virtuale
emula sia le istruzioni a livello utente sia le chiamate di sistema. Una macchina
virtuale a livello di sistema fornisce un ambiente completo. In questo caso il
software di virtualizzazione viene collocato idealmente sopra l'hardware. Nelle
macchine virtuali a livello di sistema, il software virtualizzante viene spesso
chiamato anche Virtual Machine Monitor (VMM).

1.4.1 Macchine virtuali a livello di processo
Le macchine virtuali a livello di processo forniscono alle applicazioni utente
un ambiente ABI (Application Binary Interface) virtuale. Un ambiente ABI
è l'insieme delle chiamate di sistema e delle istruzioni della CPU che sono
eseguibili a livello utente. Di questa tipologia di macchine virtuali fanno parte
le categorie descritte in seguito.
• Multiprogrammazione. La maggior parte dei moderni sistemi opera-
tivi supporta l'esecuzione contemporanea di più processi utente. Ogni
processo ha l'illusione di avere a disposizione l'intera macchina. Il siste-
ma operativo assegna al processo uno spazio di indirizzamento, l'accesso
ai le e alle periferiche. Inoltre gestisce l'assegnazione delle risorse in
base ad una certa politica (es. round robin). Il sistema operativo quindi
crea una macchina virtuale a livello di processo per ogni processo utente
in esecuzione.
• Emulatori. Vengono impiegati quando è necessario eseguire program-
mi compilati per un'ISA dierente (ma stesso sistema operativo). Un
esempio è il Digital FX!32 System che permette l'esecuzione di program-
mi scritti per Windows NT su piattaforma IA-32, su Windows NT per
architettura Alpha.
• Ottimizzatori binari SAME-ISA. L'ISA dei sistemi host e guest è lo
stesso. Eettuano proling del codice eseguibile al ne di ottimizzarlo
dinamicamente.
• High level language virtual machines. Le macchine virtuali de-
scritte in precedenza hanno come obiettivo primario quello di rendere
portabili i programmi utente da un sistema ad un altro. Le High level
language virtual machines risolvono il problema in un modo diverso. In-
fatti l'ambiente virtualizzato non corrisponde a nessun ambiente reale. Il
sistema viene progettato focaliazzndo l'attenzione sulla portabilità multi-
piattaforma, evitando l'implementzione di macchine virtuali per ciascuna
coppia host - guest. Il software compilato per la macchina virtuale è fa-
cilmente portabile a patto che esista l'implementazione della macchina
virtuale per la piattaforma di destinazione (si veda la gura 1.2). Esempi
di questa categoria sono Java VM e Microsoft CLI (Common Language
Infrastructure).

Figura 1.2: Il codice portabile viene eseguito sull'implementazione specica
della macchina virtuale per una certa piattaforma.
1.4.2 Macchine virtuali a livello di sistema
Le macchine virtuali a livello di sistema forniscono un ambiente virtualizza-
to completo a partire dall'hardware. Possono impiegare anche tecniche di
emulazione nel caso di dierenti ISA. Vengono impiegate principalmente per
permettere l'esecuzione (anche simultanea) di dierenti sistemi operativi (es.
Linux su Windows) e per fornire maggiori garanzie di isolamento negli ambien-
ti multiutente. Il VMM cattura le istruzioni privilegiate eseguite dal sistema
operativo guest, controlla la loro correttezza e le esegue sulla macchina reale
in modo trasparente. Il VMM può essere posto direttamente sull'hardware
oppure sopra il sistema operativo host. Nel primo caso è richiesta la rimozione
di eventuali sistemi operativi installati. Nel secondo caso, invece, il VMM è
installato come un comune programma sopra il sistema operativo host. In que-
sto caso parleremo di hosted VM. Il principale vantaggio di questa soluzione
è che vengono sfruttati i servizi di sistema per la gestione delle periferiche e
delle risorse che non devono essere implementati nel VMM. Lo svantaggio con-
siste nell'avere molti strati software aggiuntivi a discapito dell'ecienza. Un
esempio del primo tipo è il famoso VMware vSphere Hypervisor. Esempi del
secondo tipo sono VMware Player e Oracle Virtual Box

Capitolo 2
Tecniche di Machine Learning
2.1 Introduzione
Per machine learning si intende il processo che porta alla costruzione, a partire
da un insieme di dati, di un modello che descriva i dati stessi. Un modo tipi-
camente utilizzato per realizzare quanto espresso, è postulare l'esistenza di un
qualche tipo di meccanismo parametrico per la generazione dei dati, di cui non
conosciamo però i valori esatti dei parametri. Questo processo fa tipicamente
riferimento a tecniche di tipo statistico. L'estrazione di leggi generali a partire
da un insieme di dati osservati viene denominata induzione, e si contrappone
alla deduzione in cui, a partire da leggi generali, si vuole prevedere il valore di
un insieme di variabili. L'induzione è il meccanismo fondamentale alla base del
metodo scientico, attraverso il quale si vogliono derivare delle leggi generali
(tipicamente descritte in linguaggio matematico) a partire dall'osservazione di
alcuni fenomeni. L'osservazione comprende la misurazione di un insieme di
variabili del fenomeno oggetto di studio, e la successiva acquisizione dei dati
che sono rappresentativi del fenomeno osservato. Il modello ottenuto potrà
quindi essere utilizzato per eettuare previsioni sull'evoluzione del fenomeno
analizzato. Questo metodo si denisce inferenza.
2.2 Reti neurali
Le reti neurali articiali sono nate per riprodurre attività tipiche del cervello
umano come la percezione di immagini, il riconoscimento di forme, la com-
prensione del linguaggio, il coordinamento senso-motorio, ecc. Le reti neurali
articiali possono essere caratterizzate come modelli di computazione in cui la
complessità computazionale viene mutuata da una maggiore complessità spa-
ziale. La computazione è di tipo collettivo ed emerge come proprietà dell'evo-
6

CAPITOLO 2. TECNICHE DI MACHINE LEARNING 7
luzione dinamica della rete. Ogni decisore locale (neurone) non ha visibilità
della computazione globale e concorre alla soluzione globale in modo sfuma-
to. La rete è robusta rispetto a malfunzionamenti locali. Vengono impiegate
solitamente per le loro capacità di adattamento (apprendimento), di genera-
lizzazione, di classicazione (o clusterizzazione) delle informazioni. In seguito
illustriamo pregi e difetti di questo modello computazionale.
• Pregi:
largo impiego come classicatori;
robustezza rispetto ai pesi (guasti);
risposte in tempo reale nel caso di realizzazione hardware e molto
veloci quando emulate via software;
la metafora biologica lascia ben sperare in futuri miglioramenti.
• Difetti:
manca una loro formalizzazione matematica adeguata;
non ci sono garanzie sulla qualità delle soluzioni trovate; e in gene-
rale non si ottengono soluzioni ottime;
problema dei falsi minimi;
escono sempre scontte nel confronto con algoritmi dedicati;
altissima complessità strutturale;
dipendenza dei pesi dal problema (il che rende dicile la realizza-
zione hardware) determinati durante l'addestramento;
Una rete neurale articiale è composta da un insieme di semplici unità di
elaborazione le quali comunicano inviando segnali l'una all'altra attraverso un
gran numero di connessioni pesate. Per denire una rete neurale articiale
dobbiamo denire:
• insieme di unità di elaborazioni (neuroni,celle)
• uno stato di attivazione yk per ogni unità, il quale è equivalente all'uscita
dell'unità
• connessioni tra le unità. Generalmente ogni connessione è denita da un
peso wjk che determina l'eetto che il segnale di uscita dell'unità j ha
sull'unità k
• una regola di propagazione, che determina l'eettivo complessivo degli
input, detto sk, di una unità a partire dagli ingressi esterni

• una funzione di attivazione Fk la quale determina il nuovo livello di
attivazione, basandosi sull'eetto complessivo degli input sk(t) e il livello
corrente di attivazione yk(t)
• un ingresso di disturbo θk per ogni unità
• le regole di apprendimento
• un ambiente nel quale il sistema dovrà operare, cioè nel quale prelevare
i segnali di ingresso e fornire i i segnali in uscita
La gura 2.1 rappresenta questi concetti. Si confronti con un neurone biologico
2.2.
Figura 2.1: Componente base della rete neurale: il neurone. La regola di
propagazione è la somma pesata standard degli ingressi.
2.2.1 Il neurone articiale
Il neurone articiale è un modello matematico molto semplicato del neurone
biologico. Ad ogni input yj è associato un peso wjk. Il disturbo θk viene
fatto fariare secondo la propensione del neurone ad attivarsi, per modicare la
soglia di attivazione del neurone stesso. Una singola unità (chiamata neurone
per analogia biologica) kesegue un lavoro semplice: riceve gli input dai vicini
o dall'esterno ed elabora il segnale di uscita il quale sarà propagato agli altri
neuroni secondo questo algoritmo:
1. per ogni connessione i caricare i valori degli input yi e dei pesi relativi
wik

Figura 2.2: Neurone biologico.
2. calcolare il valore sk tenendo conto degli input, dei pesi, e del disturbo
3. calcolare il valore della funzione di attivazione Fk con sk
4. l'output del neurone yk è il risultato della funzione di attivazione
Riassumendo:
yk(t) = F(sk(t) + θk) (2.1)
Oltre a questo deve essere in grado di modicare i pesi delle connessioni. Il
sistema è intrinsecamente parallelo nel senso che le unità eseguono la compu-
tazione contemporaneamente. Si distinguono tre tipi di neuroni: neuroni di
input, che ricevono i dati dall'esterno della rete, neuroni di output, che forni-
scono i dati in uscita dalla rete e neuroni nascosti, i cui segnali, cioè, restano
connati all'interno della rete. Nel corso del funzionamento, i neuroni possono

aggiornarsi in modo sincrono o asincrono. Nel modo sincrono tutti i neuro-
ni aggiornano la loro funzione di attivazione contemporaneamente; nel modo
asincrono ogni neurone ha una creta probabilità di aggiornare la sua funzio-
ne di attivazione al tempo t, e solitamente un solo neurone alla volta viene
aggiornato.
2.2.2 Connessioni tra i neuroni
Nella maggior parte dei casi si assume che ogni neurone porti un contributo
additivo al neurone al quale è collegato. L'input totale sk è semplicemente la
somma pesata dei diversi output dei neuroni collegati più il disturbo θk:
sk(t) =
j
wjk(t)yj(t) + θk(t) (2.2)
Per wjk positivi si dice che l'ingresso eccita il neurone e per wjk negatitvi si
dice che l'ingresso inibisce il neurone. Deniamo neuroni sigma, i neuroni la
cui regola di propagazione segue la 2.2.
2.2.3 Funzioni di attivazione e output
è necessario avere delle regole per stabilire quale sia l'eetto dell'input com-
plessivo sull'attivazione del neurone. Resta così denata una funzione Fk che,
sulla base dell'input complessivo sk(t) e l'attivazione corrente del neurone yk(t)
produce il nuovo valore dell'attivazione:
yk(t + 1) = Fk(yk(t), sk(t)) (2.3)
Molto spesso Fk dipende solo dall'input complessivo in quell'istante e quindi
la 2.3 può essere scritta come
yk(t + 1) = Fk(sk(t)) = Fk(sk(t) =
j
wjk(t)yj(t) + θk(t)) (2.4)
Normalmente Fk ha valori nell'intervallo [−1, +1]. Le funzioni più usate sono
la funzione segno, la funzione lineare, o la funzione sigmoide 2.5
yk = F(sk) =
1
1 + e−sk
(2.5)
2.2.4 Topologie di rete
Come topologia, le reti neurali possono essere distinte in due casi:

• reti feed-forward, dove il usso delle informazioni tra l'ingresso e l'uscita
viaggia a senso unico verso l'uscita. L'elaborazione può essere estesa a
molti livelli di neuroni, ma non deve essere presente nessun feedback,
ossia non sono presenti connessioni dall'uscita all'ingresso dei neuroni
dei livelli precedenti o dello stesso livello.
• reti ricorsive. Contrariamente alle feed-forward queste reti presentano
connessioni di feedback. La dinamica della rete è importante. La re-
te è vincolata ad evolvere verso uno stato stabile in cui le funzioni di
attivazione non cambiano.
Esempio classico del primo tipo è il Perceptron, mentre del secondo tipo è la
rete di Hopeld.
2.2.5 Addestramento di una rete neurale
Una rete neurale deve essere congurata in modo tale che l'applicazione degli
ingressi produca l'uscita desiderata. È quindi necessario modicare il peso
delle connessioni. Una tecnica potrebbe essere impostare direttamente i pesi,
usando una qualche forma di conoscenza a priori. Un altro metodo potrebbe
essere quello di addestrare la rete modicando iterativamente i pesi in base
a qualche regola di apprendimento. Possiamo ulteriormente dividere questo
secondo caso in:
• Apprendimento supervisionato: la rete è addestrata fornendo una serie
di esempi composti da input e rispettivo output atteso.
• Apprendimento non supervisionato: un neurone di uscita è addestrato
a rispondere a delle classi di input. In questo paradigma, il sistema
deve dividere autonomamente gli input in classi. A dierenza dell'altro
metodo non vengono denite a priori le classi in cui gli input sono divisi.
Per maggiori approfondimenti sugli algoritmi di apprendimento si rimanda a
[BK96] e [PBL]
2.3 K-means
K-means [Mac67] è un algoritmo di apprendimento non supervisionato che ri-
solve il problema di clusterizzare, ovvero di classicare, un insieme di nvettori
di dimensione m in k classi, con k ssato a priori. L'idea principale è de-
nire k centroidi, uno per ogni cluster. Come primo passo dell'algoritmo, i
centroidi devono essere posizionati nello spazio (m-dimensionale) in modo da

massimizzare la distanza tra essi. Il passo successivo prevede di prendere tutti
gli n vettori appartenenti all'insieme dei dati e associarli al centroide più vi-
cino, creando così k cluster. Successivamente si ricalcolano i centroidi come
baricentro dei cluster risultanti dal passo precedente. Nel passo seguente si
riassociano i vettori ai nuovi centroidi. Si rieseguono questi ultimi passi nché
la posizione dei centroidi varia sensibilmente da un'interazione ad un altra.
Formalmente, l'algoritmo ha come scopo la minimizzazione di una funzione
obiettivo:
J =
k
j=1
n
i=1
x
(j)
i − cj
2
(2.6)
dove con la scrittura x
(j)
i si intende che il vettore xi partecipa alla somma se
appartiene al cluster j e x
(j)
i − cj
2
è la distanza tra il vettore xi e il centroide
cj. Formalmente l'algoritmo è composto dai seguenti passi:
1. Scegliere K punti dello spazio m-dimensionale dove si trovano gli n dati
da classicare. Questi punti rappresentano i centroidi iniziali;
2. Assegnare ogni vettore xi al centroide cj più vicino;
3. Ricalcolare la posizione dei K centroidi come baricentro di ciascun clu-
ster;
4. Ripetere i passi 2 e 3 no a che i centroidi restano nella medesima posi-
zione da un'iterazione alla successiva. Il risultato è un raggruppamento
degli oggetti che porta alla minimizzazione della funzione 2.6.
Sebbene si possa dimostrare che l'algoritmo termina sempre, non necessaria-
mente esso trova la congurazione ottimale, corrispondente al minimo della
funzione obiettivo. L'algoritmo è sensibile alla selezione iniziale dei centroidi.
Esso può essere eseguito con diversi centroidi iniziali per ridurre questo eetto.
L'algoritmo si può classicare come algoritmo greedy (avido). Esso presenta
alcuni difetti:
• Il modo di inizializzare i centroidi non viene specicato dall'algoritmo.
Di solito si scelgono a caso k vettori nell'insieme dei dati
• Il risultato ottenuto dipende dalla scelta dei centroidi iniziali, e frequen-
temente porta ad una soluzione subottima. La soluzione, come già detto,
consiste nel ripetere l'algoritmo con diversi centroidi iniziali e considerare
il valore migliore della funzione obiettivo;

• Può accadere che ad una certa iterazione dell'algoritmo, alcuni cluster ri-
sultino vuoti e quindi che il relativo centroide non possa essere ricalcolato.
La soluzione di questo problema è lasciata alle varie implementazioni.
• Il risultato dipende dalla metrica utilizzata per misurare xi − cj .
• Il risultato dipende dal valore k
L'ultimo problema in particolare è dovuto al fatto che non si conosce a priori
il numero di cluster in cui si vuole dividere l'insieme. Sfortunatamente non
esiste, in generale, un metodo per trovare il numero ottimale di cluster. Un
approccio semplice consiste nel provare diversi valori di k incrementando il
valore di volta in volta. Un valore troppo elevato porta ad un numero maggiore
di cluster vuoti. Per approfondimenti si veda [Moo]
2.4 Modelli di Markov nascosti
Figura 2.3: Modello di Markov nascosto
Una catena markoviana a tempo discreto è una sequenza aleatoria qn tale
che la variabile successiva dipende solamente dalla variabile precedente. Il
sistema può essere quindi descritto da una sequenza di stati, che corrispondono
a degli eventi osservabili. Ad ogni istante del tempo discreto il sistema passa da
uno stato all'altro con una certa probabilità di transizione. 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
applicato al problema di interesse. Il modello può essere esteso al caso in
cui le osservazioni siano una funzione probabilistica dello stato e quindi non

osservabili direttamente. Le osservazioni sono cioè nascoste. Un modello di
Markov nascosto è caratterizzato da:
• 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 (2.7)
è la probabilità di passare dallo stato Si allo stato Sj .
• la distribuzione delle osservazioni nello stato j : bj(k), dove
bj(K) = P[Vk|qt = Sj], 1 ≤ j ≤ N, 1 ≤ k ≤ M (2.8)
è la probabilità di osservare il simbolo Vk se all'istante t il sistema si
trova nello stato j.
• il vettore delle probabilità iniziali π, dove
πj = P[q1 = Sj], 1 ≤ j ≤ N (2.9)
è la probabilità che il sistema si trovi all'istante iniziale nello stato Sj
Si può quindi indicare un modello di Markov nascosto con λ = (A, B, π). Il
processo di apprendimento di un modello di Markov implica la ricerca dei pa-
rametri (A, B, π) tali da massimizzare la probabilità di riconoscere la sequenza
di osservazioni. Poiché non si conosce una soluzione analitica che trovi un mas-
simo assoluto si utilizza una procedura iterativa. L'algoritmo di Baum-Welch
in [LEBW70] fa questo in modo eciente 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 interpretata
in qualche modo signicativo. L'algoritmo di Viterbi in [JF73] permette di
generare la sequenza più probabile di stati relativi ad un dato modello hmm.
Inoltre avendo una sequenza di simboli l'algoritmo di Viterbi rende possibile
vericarne l'anità con un modello hmm calcolandone la probabilità.

2.5 DCT
La trasformata discreta del coseno o DCT (dall'inglese Discrete Cosine Tran-
sform), è la più diusa funzione che provvede alla compressione spaziale, capace
di rilevare le variazioni di informazione tra un'area e quella contigua trascu-
rando le ripetizioni[Wik]. Ad esempio, è utile per ridurre la ridondanza di un
segnale in quanto tende a concentrare più energia possiblie in meno coecienti
possibile (compressione energetica)[Str99].
2.6 Dempster-Shafer Therory
La teoria di Dempster-Shafer è una teoria matematica delle attestazioni, in-
tendendo con attestazione qualsiasi cosa supporti un'asserzione. Permette di
combinare insieme attestazioni provenienti da diverse fonti e arrivare ad un
grado di credibilità (belief) dell'asserzione, tenendo conto di tutte le attesta-
zioni disponibili. Per maggiori informazioni si veda [Sga11]. Tale tecnica è
stata considerata nel corso della tesi in quanto applicata con successo in casi
analoghi. L' articolo [AM13] fornisce uno spunto per l'utilizzo di tale tecnica
negli esperimenti successivi.

Capitolo 3
Spec
3.1 Introduzione
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 dierenti tra loro.
3.2 CPU2006
Spec CPU2006 si concentra sulla performance del processore, sull'architettura
della memoria e sulla capacità del compilatore di produrre codice ottimizzato
[Doc]. Altri fattori che spesso incidono sulle performance delle applicazioni
(networking, I/O) sono qui considerati trascurabili, in quanto i singoli ben-
chmark 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 eettua un'analisi delle performance del sistema nelle operazioni su
valori interi, la seconda nel caso di operazioni a virgola mobile ( foating point).
Ognuna delle due suite si compone di diversi benchmark (12 per CINT2006,
17 per CFP2006).
16

CAPITOLO 3. SPEC 17
3.3 Benchmarks
SpecCPU2006 si pregge di calcolare le prestazioni di un sistema simulando un
workload il più verosimile possibile, per questo molti dei benchmark sono delle
versioni adattate e modicate di applicazioni reali. Tali applicazioni hanno in
comune un'elevata intensità computazionale: la maggior parte del tempo speso
da esse è dedicato ad operazioni di calcolo, con pochissimo overhead causato
da input/output. Sono state apportate delle modiche ai sorgenti anché i
test eseguano la gran parte delle operazioni di IO in memoria e non su le,
e anché la memoria utilizzata rimanga inferiore ad 1GB per evitare che il
sistema debba eettuare swap verso il disco. Le applicazioni sono state scelte
basandosi anche su criteri di portabilità, in quanto Spec- CPU2006 può essere
compilato su una moltitudine di architetture e sistemi operativi dierenti.
3.3.1 401.bzip2
401.bzip2 è la versione adattata a SpecCPU2006 del programma bzip2, il quale
eettua compressione dati. 401.bzip2 si basa sulla versione 1.0.3 di bzip2 di
Julian Seward, con la dierenza che 401.bzip2 non eettua operazioni di I/O
se non nella lettura dei le da comprimere. Tutta la compressione e la decom-
pressione avviene quindi in memoria. Ogni le 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 buer di dimensione adeguata ad ospitare il le di in-
put, lo stream compresso e lo stream decompresso. Dopo aver caricato il le,
le successive operazioni di lettura e scrittura sono eettuate tutte in memoria
senza snaturare il codice di bzip2 tramite le dene:
./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 gestiscono
gli EOF e che fanno corrispondere ai le descriptor i buer precedentemente
allocati.
3.3.2 445.gobmk
445.gobmk è una versione di GNU Go alla quale vengono presentate diverse
posizioni di gioco. Il gioco del Go è considerato un problema di intelligenza
articiale che richiede uno sforzo computazionale elevato in quanto le combina-
zioni possibili di pezzi sulla scacchiera (goban) nella partita sono moltissime.

CAPITOLO 3. SPEC 18
I le di input utilizzati benchmark sono le di testo che descrivono diverse
posizioni di gioco, l'output corrisponde nella mossa successiva da eettuare.
3.3.3 458.sjeng
458.sjeng è una versione leggermente modicata di Sjeng 11.2, un programma
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 deterministiche
e quindi il workload del test sempre uguale. L'input di riferimento del test è
composto da 9 dierenti posizioni di gioco e dalla profondità alla quale vanno
analizzate da Sjeng.
3.3.4 403.gcc
403.gcc è basato sulla versione 3.2 di GNU gcc, congurato per generare codice
assembly x86-64 per un processore AMD Opteron con diversi ag di ottimiz-
zazione abilitati. 403.gcc è stato adattato da Spec alterando l'euristica nelle
scelte di utilizzare funzioni inline anché il programma spendesse più tempo
nell'analisi del codice sorgente e utilizzasse più memoria della versione stan-
dard. L'input è dato da le sorgenti per i quali deve essere generato l'assembly
corrispondente.
3.3.5 464.h264ref
464.h264ref è l'implementazione di Karsten Sühring dello standard di compres-
sione video H.264/AVC. Le modiche introdotte dal team di Spec facilitano
la portabilità del codice ma sono state ridotte al minimo per garantire che il
test si avvicinasse il più possibile ad un caso d'uso reale di video encoding.
In particolare, è stata rimossa la parte dei sorgenti riguardante il decoder (il
test eettua solo la compressione in h264, non la decompressione) ed è stato
soppresso l'output a le di log per minimizzare l'I/O. L'input è composto da
due video in formato raw ognuno dei quali viene compresso con due proli
dierenti (good compression e best compression).
3.3.6 400.perlbench
400.perlbench è Perl v5.8.7 al quale sono state rimosse tutte le feature relative
ai singoli sistemi operativi. A questi sono stati aggiunti alcuni moduli esterni:
SpamAssassin, MailTools, Digest-MD5, HTMLParser... I moduli vengono uti-
lizzati per la manipolazione di messaggi email trasformandoli in pagine html,
calcolandone checksum md5 e rilevando con che probabilità si tratta di spam.

CAPITOLO 3. SPEC 19
3.3.7 429.mcf
429.mcf deriva da un software di scheduling del traco utilizzato in ambito
pubblico. 429.mcf genera un elevato carico sulla cpu eseguendo un algorit-
mo che implementa il metodo del simplesso su rete. Il codice del programma
originale è stato modicato per ridurre il numero di cache miss e quindi in-
crementare l'impatto sulla cpu rispetto alla memoria. Questo è stato ottenuto
modicando l'ordine degli elementi persenti nelle struct maggiormente utilizza-
te dal benchmark. L'input al benchmark consiste in un le di testo contenente
un insieme di percorsi da ottimizzare.
3.3.8 462.libquantum
462.libquantum simula un computer quantistico, eseguendo l'algoritmo di fat-
torizzazione di Peter Shor. Il benchmark si aspetta in input un numero e
resituisce l'elenco dei suoi fattori. Su un computer quantistico l'algoritmo tro-
va i fattori con margine d'errore arbitrariamente piccolo in tempo polinomiale
rispetto alla dimensione del numero in input.
3.3.9 456.hmmer
456.hmmer utilizza algoritmo hmm per analizzare sequenze di dna. In input il
benchmark si aspetta un le database contente i modelli di riferimento e una
sequenza nella quale eetuare la ricerca delle sequenze del database.
3.3.10 471.omnetpp
471.omnetpp simula una vasta rete ethernet basandosi sul sistema di simula-
zione discreto OMNeT++. OMNeT++ implementa completamente CSMA/
CD, i frame ethernet e IP per una simulazione del carico sulle reti. Il ben-
chmark 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 congurazione degli host, e procede aumentando esponenzialmen-
te il volume di traco simulando anche perdite di pacchetti. In ouput sono
prodotte statistiche dettagliate sulla simulazione.
3.3.11 473.astar
473.astar deriva da una libreria di ricerca del percorso minimo utilizzata per le
intelligenze articiali 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.

CAPITOLO 3. SPEC 20
3.3.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 (100MB)
consistente in un le XML e un foglio di stile XSL da trasformare in HTML.
3.4 Input dei benchmark
Per ciascun benchmark sono presenti 3 dierenti classi di input, che riportiamo
in ordine di complessità:
• test;
• train;
• ref.
Per ogni benchmark sono stati misurati i tempi di esecuzione di ciascuna classe
di input. Utilizzando un parametro è possibile specicare il numero di esecu-
zioni del programma da eettuare in ogni esecuzione del benchmark. Consi-
derando una durata temporale ssata a priori è pertanto possibile calcolare il
numero di esecuzioni del programma per ogni benchmark.

Capitolo 4
Valutazione di diversi VMM
4.1 Introduzione
Al ne di perseguire l'obiettivo del lavoro è stato necessario esaminare alcuni
VMM presenti sul mercato. Ovviamente la scelta naturale è ricaduta su mac-
chine virtuali di sistema in modo da avere a disposizione tutte le statistiche
e le informazioni necessarie. Tra queste in particolare sono stati presi in con-
siderazione i seguenti VMM: VMware vSphere Hypervisor, VMware Player e
Virtual Box.
4.2 Valutazione dei VMM
Nelle fasi preliminari della tesi sono stati presi in considerazione vari prodotti
sia gratuiti che a pagamento. I prodotti a pagamento, pur presentando features
di notevole pregio per un utilizzo commerciale, non si sono rivelati migliori di
quelli gratuiti ai ni della tesi. Un altro fattore tenuto in considerazione è la
diusione sul mercato di questi prodotti.
4.2.1 VMware vSphere Hypervisor
Versione gratuita del software VMware vShpere. è un VMM da installara
direttamente sull'hardware. La gestione avviene completamente da remoto.
Vantaggi:
• non essendoci il sistema operativo host ha un overhead ridotto;
• API ben documentate.
Svantaggi:
21

CAPITOLO 4. VALUTAZIONE DI DIVERSI VMM 22
• API non permettono di collezionare dati sul funzionamento (registri cpu);
• necessità di una macchina dedicata all'installazione.
4.3 VMware Player
VMware Player è un software freeware di virtualizzazione (virtual machine)
prodotto da VMware la cui prima versione è stata rilasciata nel dicembre del
2005. Si tratta di un hosted VMM. è in grado di creare ed eseguire qualunque
immagine di macchina virtuale precedentemente creata.
Vantaggi:
• si installa come una normale applicazione;
• API ben documentate;
• ottime performance.
Svantaggi:
• API non permettono di collezionare dati sul funzionamento (registri cpu);
• overhead maggiore dovuto a un maggior numero di strati software;
• non open source.
4.3.1 Virtual Box
VirtualBox o Oracle VM VirtualBox (e precedentemente Sun VirtualBox, Sun
xVM VirtualBox e Innotek VirtualBox), è un hosted VMM open source per
architettura x86 che supporta Windows, GNU/Linux e Mac OS X come sistemi
operativi host, ed è in grado di eseguire Windows, GNU/Linux, OS/2 Warp,
OpenBSD e FreeBSD come sistemi operativi guest.
Vantaggi:
• le API disponibili permettono di collezionare statistiche e dati relativi
allo stato interno;
• software open source;
• semplicità di utilizzo paragonabile ad analoghi prodotti commerciali.
Svantaggi:
• scarsa documentazione delle API (mancano sopratutto esempi);

CAPITOLO 4. VALUTAZIONE DI DIVERSI VMM 23
• leggermente meno performante rispetto a VMware Player [VMSD12].
Tenendo conto dell'obiettivo della tesi, Virtual Box è risultato il migliore, so-
pratutto perché sono disponibli le API che permettono di raccogliere informa-
zioni di basso livello sulla macchina virtuale. Esiste, in ambiente VMware un
tool denominato VProbe che è in grado di fornire analoghe informazioni sulla
macchina virtuale. Il suo utilizzo è possibile solo tramite console e la raccolta
dati risulta dicoltosa in quanto il formato dei dati presentati in output non
è personalizzabile. Inoltre il tempo tra un dato e il successivo è superiore alla
decina di millisecondi.

Capitolo 5
Virtual Box
5.1 Introduzione
In questo capitolo viene descritto il VMM VirtualBox insieme alla sua API.
Verrà eettuata una breve presentazione del prodotto e verranno presentate
le modalità di utilizzo. In particolare verranno descritti i metodi utilizzati per
collezionare i dati.
5.2 VirtualBox
Come accennato precedentemente 4.3.1, Virtual Box è un VMM open source
sviluppato da Sun Microsystems (oggi Oracle). Permette la creazione e l'e-
secuzione di macchine virtuali. è multipiattaforma, funziona sia in ambiente
Windows sia in ambiente Linux, su architettura x86 e x64. Può funziona-
re anche in assenza di hardware dedicato alla virtualizzazione. In seguito
vengono descritte le caratteristiche salienti di questo software. Per maggiori
approfondimenti consultare [Cora]
5.2.1 Virtualizzazione software-based
In assenza di virtualizzazione hardware-assisted, VirtualBox adotta la tecnica
della traduzione binaria per eseguire istruzioni privilegiate in modalità uten-
te. Questa modalità supporta solo sistemi operativi guest a 32-bit. Virtual
Box utilizza una tecnica detta Code Scanning and Analysis Manager (CSAM)
per rilevare le istruzioni privilegiate prima della loro esecuzione e chiama il
Patch Manager (PATM) per operare una loro traduzione. La traduzione av-
viene sostituendo il codice privilegiato con un salto a delle routine VM-safe
presenti nel codice di Virtual Box. Il codice user-mode invece viene eseguito
24

CAPITOLO 5. VIRTUAL BOX 25
direttamente nell'hardware dell'host. Inoltre Virtual Box contiene un ricom-
pilatore dinamico basato su QEMU per ricompilare il codice real mode (es.
bios, bootloader)
5.2.2 Virtualizzazione hardware-assisted
VirtualBox supporta sia la virtualizzazione hardware VT-x di Intel sia AMD-V
di AMD. Queste tecnologie permettono di eseguire ciascuna macchina virtuale
in uno spazio di indirizzamento separato e ogni istruzione privilegiata viene
eseguita del processore host. La compatibilità con alcuni sistemi operativi
guest (es. 64bit) è subordinata alla presenza di tali tecnologie nel sistema
host.
5.2.3 Virtualizzazione delle periferiche
Le macchine virtuali create con Virtual Box supportano le seguenti periferiche:
• hard disk: sono supportate le immagini di dischi create anche con altri
prodotti (es. VMware);
• dischi ottici: possono essere connessi a dispositivi sici presenti nell'host
oppure essere agganciati a immagini ISO;
• sistem video: supporta una scheda video virtuale VESA compatibile.
Programmi da installare nei sistemi guest permettono di migliorare le
performance video e di aggiungere funzionalità come ad esempio la rego-
lazione automatica della risoluzione in base alle dimensioni della nestra
della VM;
• schede di rete: le schede di rete virtuali sono compatibili con la maggior
parte dei sistemi operativi senza necessità di driver specici. I dispositivi
possono essere congurati in vari modi, ad esempio in modo da eettua-
re il NAT attraverso il VMM, condividere una specica scheda di rete
dell'host oppure creare una rete solo tra host e guest;
• Scheda audio: sono disponibili le periferiche audio l'Intel HD Audio,
l'Intel ICH AC'97 e la SoundBlaster 16;
• Controller USB: di default è emulato un controller USB 1.1 o, in alterna-
tiva, installando opportune estensioni closed-source è possibile aggiun-
gere un controller 2.0. Ogni periferica connessa con l'host può essere
utilizzata da una VM.

5.3 API di Virtual Box
L'SDK, di cui è dotato Virtual Box, permette a terzi di sviluppare applicazioni
interagenti con Virtual Box. Come si può vedere in gura 5.1 Virtual Box è
stato progettato a livelli. L'area colorata in arancione rappresenta il codice
eseguito in modalità privilegiata, l'area colorata in blu rappresenta il codice
eseguito nello spazio utente.
Figura 5.1: VirtualBox ha un'architettura a livelli
Alla base troviamo il VMM vero e prorio (hypervisor). è il cuore del motore
di virtualizzazione, controlla l'esecuzione delle macchine virtuali e garantisce
la sicurezza e l'assenza di conitti tra le macchine virtuali e con l'host. Sopra
l'hypervisor troviamo dei moduli che forniscono funzionalità aggiuntive. Ad
esempio il server RDP (Remote Desktop Protocol). Il livello delle API è im-
plementato sopra questi blocchi funzionali. Le funzionalità che questo livello
espone sono descritte in dettaglio nella SDK Reference [Corb]
5.3.1 Considerazioni sulla API
VirtualBox è dotato di un web service che, una volta in esecuzione, agisce da
server HTTP, accetta connessioni SOAP e le processa. L'interfaccia è descritta
in un le WSDL. In questo modo è possibile scrivere programmi client in
qualsiasi linguaggio di programmazione che abbia a disposizione i tools per
elaborare i le WSDL, ad esempio Java, C++, .NET PHP, Python, Perl.
Inoltre per Java e Python l'SDK contiene delle librerie già pronte all'uso.
Internamente l'API è implementata utilizzando come modello di riferimento

COM. In Windows è utilizzato Microsoft COM. Negli altri host, dove COM
non è presente è possibile utilizzare XPCOM, un'implementazione gratuita di
COM. Segue un'analisi dei principali vantaggi e svantaggi delle due modalità
di utilizzo dell'API.
Web service COM / XPCOM
Vantaggi
Supporta molti linguaggi di
programmazione
I client possono essere su
macchie remote
Basso overhead
Molto semplice da utilizzare
con Java e Pyhton
Svantaggi
Overhead signicativo do-
vuto alla serializzazione e
deserializzazione dell'XML
Usabile solo da linguaggi
che supportano COM
I client devono stare sullo
stesso host della macchina
virtuale
Nonostante i vantaggi dell'utilizzo dell'API tramite web service si è utilizzato
il metodo COM perché permette un minor overhead e quindi una maggiore
quantità di dati raccolti nell'unità di tempo. A riprova di quanto aermato è
stato condotto un esperimento. I dati raccolti (valori del registro IP della cpu)
sono stati aancati da un timestamp. Nella gura 5.2 si nota come l'accesso
all'API tramite COM è molto più veloce. L'esperimento ha dimostrato che il
modo di utilizzo tramite web service è in grado, mediamente, di collezionare
un dato ogni 5, 9621ms mentre utilizzando COM si riesce a collezionare un
dato ogni 0, 4901ms.
Altre funzioni interessanti riguardano la collezione di dati relativi a stati-
stiche sull'utilizzo delle risorse. L'API prevede delle funzioni per:
• specicare quali sono i gruppi di indicatori di interesse (CPU, RAM,
Rete, Disco);
• impostare l'intervallo di misura (intervallo minimo di 1s);
• impostare la dimensione della frame per le statistiche (min, max, media);
• eettuare query di dettaglio sul singolo indicatore (CPU spazio utente,
CPU spazio Kernel, dimensione del le di paging...).
Per maggiori informazioni si veda [Cora].

Figura 5.2: Misurazioni puntuali dei tempi di risposta dell'API nei due modi
di utilizzo

Capitolo 6
Analisi dei dati
6.1 Introduzione
Comprendere il funzionamento interno dei software commerciali a partire dalle
tracce di esecuzione richiede un grande sforzo. Il primo problema che si in-
contra è l'enorme quantità di dati da elaborare. Normalmente queste tracce si
compongono di migliaia o milioni di eventi. In questo capitolo viene arontata
l'analisi dei dati sui riferimenti alla memoria generati dall'IP della CPU e sugli
indicatori di utilizzo delle risorse.
6.2 Aspetti legali
I dati che andremo ad acquisire riguardano lo stato interno di una macchina
virtuale. Questi dati sono raccolti idealmente dall'azienda proprietaria del-
la server farm (o comunque dell'host sul quale esegue la macchina virtuale).
Potrebbero sussistere problemi legali riguardo alla violazione della privacy de-
gli utenti utilizzatori delle macchine virtuali. Dal Dl n. 196 06/2003 [Par]si
riscontrano questi fatti:
• visto l' articolo 4, i dati raccolti dal sistema non rientrano nella deni-
zione di dati personali in quanto risulta impossibile identicare l'utente
come persona sica o giuridica mediante l'uso dei dati raccolti;
• visto l'articolo 5 comma 3 l'utilizzo dei dati acquisiti non può ritenersi
per uso personale. È quindi necessario informare l'utente in base alle
disposizioni dell'articolo 7.
Da notare comunque che i dati raccolti non riguardano potenziali informazioni
sensibili:
29

CAPITOLO 6. ANALISI DEI DATI 30
• i memory reference sono gli indirizzi di memoria che legge la CPU, non il
suo contenuto. Non viene letto in nessun caso il contenuto della memoria
che, comunque, conterrebbe soltanto istruzioni e non dati;
• gli indicatori sull'utilizzo delle risorse sono informazioni già a disposizione
dei sistemisti attraverso la console del VMM.
Idealmente quindi l'utente dovrà essere quindi informato (non è necessario il
suo consenso) che il servizio acquistato (una o più macchine virtuali) prevede
la raccolta dei dati sopra citati per scopi statistici e ad uso interno riservato
ai sistemisti.
6.3 Memory References
Il VMM tramite le sue API è in grado di fornire informazioni riguardo allo
stato della macchina virtuale. Possiamo infatti leggere diversi registri della
CPU. Tra questi è stato scelto il registro IP. I valori di tale registro, che le
API forniscono, non sono puntuali ma sono campionati. Da studi compiuti
sull'API (si veda 5.3.1) possiamo ottenere un valore ogni 0, 5ms circa.
6.3.1 Caratterizzazione della sequenza dei memory
references
Con un tempo di campionamento così elevato rispetto al fenomeno di interesse,
si corre il rischio che i dati non rappresentino delle features utilizzabili per
gli scopi della tesi. Si rende pertanto necessaria un'approfondita analisi dei
dati. Saranno impiegate tecniche proprie dell'analisi dei segnali in quanto la
sequenza dei memory reference raccolta sarà trattata come un segnale. Come
si vede in gura 6.1 Tali valori possono essere caratterizzati come un segnale
discreto tempo variante. La tempo varianza è dovuta al fatto che i programmi
vengono caricati in porzioni diverse della memoria ad ogni esecuzione. Infatti
in gura 6.2 osserviamo la sequenza dei valori durante un'altra esecuzione dello
stesso programma.
Dall'osservazione dei graci si osserva che le proprietà fondamentali, ossia
località spaziale e temporale dei riferimenti alla memoria, vengono mantenute
anche dopo il campionamento.
6.3.2 Divisione in frame
La divisione in frame è necessaria per il successivo addestramento dei modelli
in quanto, a regime, il sistema che si vuole sviluppare deve permettere di

Figura 6.1: Sequenza di valori del registro IP assunti durante l'esecuzione
del programma PerlBench
Figura 6.2: Sequenza di valori del registro IP assunti durante un'altra
esecuzione del programma PerlBench
riconoscere il comportamento dell'utente raccogliendo informazioni per brevi
periodi di tempo. La sovrapposizione delle frame permette di coprire meglio la

casistica di un'acquisizione dati partendo da un qualsiasi istante dell'esecuzione
del programma. In gura 6.3 è rappresentato il processo di divisione in frame.
Figura 6.3: Operazione di framing del segnale
La dimensione ottimale delle frame, quanto sovrapporle e quanti campioni
scartare sono parametri da ricavare sperimentalmente. Da notare che, essendo
i dati di interesse campionati, specicare la lunghezza delle frame in unità
temporali, o in numero di campioni è equivalente.
6.3.3 Divisione in blocchi
Ogni frame viene divisa in un certo numero di blocchi 6.4. Questa suddivisione
in blocchi è giusticata dal fatto che le tecniche di machine learning usate
necessitano di un numero nito e noto a priori di input. Tale tecnica, ad
Figura 6.4: Operazione di divisione in blocchi di una frame del segnale
esempio, è impiegata con successo nel caso del riconoscimento vocale [FAE08]
. Il numero di blocchi in cui ogni frame viene divisa è un parametro da ricavare
sperimentalmente.

6.3.4 Analisi spettrale tramite DCT
Durante l'esecuzione di un programma, le proprietà di località spaziale e tem-
porale, fanno sì che esista una probabilità non nulla che la medesima istruzione
venga eseguita più volte. Nel dominio del tempo questo fenomeno si traduce
nel rilevare lo stesso valore del registro IP in istanti di tempo diversi. Ana-
lizzando il fenomeno nel dominio della frequenza avremo dei picchi di energia
in prossimità degli indirizzi ripetuti più frequentemente. Possiamo pertanto
considerare come feature i coecienti con maggiore energia della trasformata
del segnale. Il numero di questi coecienti è un parametro da determinare
sperimentalmente insieme con il fatto se sia opportuno o meno mantenere il
primo coeciente, che in perfetta analogia con la teoria dei segnali, rappre-
senta la componente continua. Viene scelta la trasformata discreta in coseno
(DCT) [Wik] in quanto già utilizzata con successo in letteratura per lo stesso
scopo [Pel11] Con questa tecnica, inoltre, viene premiata la località temporale
degli indirizzi. In gura 6.1 e in gura 6.5 si possono vedere il segnale originale
e il segnale trasformato rispettivamente. Si noti come i primi coecienti siano
quelli con l'energia maggiore.
Figura 6.5: DCT del segnale

6.4 Indicatori sull'utilizzo delle risorse
Altre tracce di esecuzione dei programmi sono gli indicatori sull'utilizzo delle
risorse. Attraverso le API di Virtual Box, possiamo acquisire i dati relativi a:
• percentuale di utilizzo CPU da parte dell'utente 6.6;
• percentuale di utilizzo CPU da parte del Kernel6.7;
• memoria libera6.8;
• spazio su disco utilizzato;
• I/O di rete istantaneo.
Tali dati risultano signicativi al ne di prolare l'utente in quanto permet-
tono di discriminare il programma in esecuzione. Come si vede nelle gure,
esecuzioni di programmi diversi hanno andamenti temporali visibilmente di-
versi, mentre lo stesso programma in diverse esecuzioni presenta un andamento
simile. La risoluzione di tali dati è molto minore rispetto a quella relativa
Figura 6.6: Percentuale utilizzo CPU User per 3 programmi in 2 esecuzioni
ciascuno.
ai memory reference in quanto le API aggiornano i loro valori ogni secondo.
Anche in questo caso è stata eettuata un'attenta analisi dei dati.

Figura 6.7: Percentuale utilizzo CPU Kernel per 3 programmi in 2 esecuzioni
ciascuno.
Figura 6.8: Ram libera per 3 programmi in 2 esecuzioni ciascuno.

6.4.1 Caratterizzazione della sequenza di indicatori
sull'utilizzo delle risorse
L'andamento temporale dei singoli indicatori può essere interpretato come un
segnale discreto tempo invariante. La tempo-invarianza è data dal fatto che le
percentuali di utilizzo delle varie risorse non dipendono dall'istante iniziale del-
l'esecuzione del singolo programma, ma dipendono solamente dall'evoluzione
del programma stesso. Questo a patto di considerare trascurabili gli eetti del
sistema operativo e di eventuali altri programmi che eseguono in backgroud.
Considerare il singolo indicatore separatamente dagli altri potrebbe non es-
sere signicativo ai ni della prolazione utente in quanto presenterebbe un
andamento temporale simile per programmi diversi. A tal proposito vedere
i programmi bzip2 e sjeng nella gura 6.6. Considerando tutti i vari indica-
tori nello stesso istante si ottiene un vettore N-dimensionale che rappresenta
il fenomeno in quell'istante. Questo procedimento di fusione dei dati, conte-
stualizzato nel framework applicativo di interesse, richiede che i dati siano il
più possibile omogenei come valori. Tutti gli indicatori fusi insieme verranno
pertanto normalizzati nell'intervallo [0,1]. Considerando tre indicatori pos-
siamo rappresentare la fusione gracamente. In gura 6.9 si osserva come i
programmi sono più facilmente isolabili nello spazio. Per quanto riguarda il
framing, la divisione in blocchi e l'analisi del dominio della frequenza, valgono
considerazioni analoghe a quelle fatte per i memory references. Si veda 6.3.2
6.3.3 6.3.4

Figura 6.9: Fusione degli indicatori.

Capitolo 7
Software realizzato
7.1 Introduzione
In questo capitolo verrà presentato il software sviluppato nell'ambito della
tesi. Verranno illustrati gli strumenti utilizzati e i vincoli di progetto. In
seguito verranno illustrati gli aspetti pratici e le scelte eettuate in fase di
implementazione.
7.2 Strumenti utilizzati
Vengono di seguito elencati i principali strumenti utilizzati durante questa fase
di progetto. L'hardware utilizzato viene omesso in quanto il software utilizzato
e realizzato è portabile su varie piattaforme.
• JDK 1.7;
• Eclipse IDE Juno;
• VirtualBox SDK versione 4.3.2;
• VirtualBox versione 4.3.2;
• sistema guest Linux debian 3.2.0-4-486;
• Benchmark Spec CPU 2006;
• Code::Blocks IDE versione 12.11;
• libreria OpenCv versione 2.4.6.1 [itS];
• sorgenti della libreria Fann versione 2.2 [Nis];
38

CAPITOLO 7. SOFTWARE REALIZZATO 39
• sorgenti libreria Dempster Shafer sviluppati da Thilo Michael e Jerey
Jedele [eJJ];
• sorgenti software hmmface [Pie11].
Il sistema è stato sviluppato su un host Linux Debian.
7.3 Sistema di acquisizione dati
Questo componente software è stato sviluppato interamente nell'ambito di
questa tesi. Come spiegato in dettaglio in 5.3.1 sono state impiegate le API
COM di VirtualBox La scelta di Java come linguaggio host per le chiamate
all'API è stata eettuata per i seguenti motivi:
• maggiore documentazione ed esempi di utilizzo dell'SDK rispetto ad altri
linguaggi;
• linguaggio orientato agli oggetti;
• gestione degli errori;
• portabile.
Obiettivo principale è realizzare un software che permetta di acquisire i dati
sulla sequenza di memory reference e delle statistiche sull'utilizzo delle risor-
se nella macchina virtuale e di persisterli su le. Il software realizzato deve
soddisfare i seguenti requisiti:
• introdurre basso overhead tra le varie chiamate dell'API;
• essere facilmente modicabile;
• essere robusto, in quanto deve essere eseguito per lunghi periodi di tempo
senza supervisione;
• essere essibile nel senso che deve essere possibile acquisire diversi dati
contemporaneamente;
• avere la possibilità di controllo automatico per l'avvio e l'arresto dell'ac-
quisizione dati.
Nel seguito viene descritto il software di acquisizione implementato. Vengono
anche descritte brevemente le soluzioni tecniche per soddisfare i requisiti.

7.3.1 Architettura
La gura 7.1 mostra l'architettura del software realizzato. Una volta acquisite
le informazioni tramite chiamate all'API è necessario persisterle su le. La
scrittura dei dati su le ad ogni chiamata introdurrebbe un overhead quan-
ticabile in 0.2 − 0.5ms. All'opposto tenere tutti i dati raccolti in memoria
potrebbe provocare errori di Out of Memory in quanto non è possibile stabili-
re a priori la mole di dati che si andranno ad acquisire. Una buona soluzione
di compromesso tra le due consiste nel leggere i dati a blocchi di dimensione
ssa (es. 1024) e persisterli tutti in una volta. Il progetto del software segue
il paradigma della programmazione ad oggetti. Ogni oggetto pertanto gode
delle proprietà di incapsulamento e disaccopiamento. Si è quindi proceduto al
test delle varie parti e solo in seguito ad unire tutte le componenti in un unico
programma. Il software per l'acquisizione deve essere in grado di gestire pos-
sibili anomalie di funzionamento. In particolare l'acqusizione dati in modalità
batch, in caso di errori, deve proseguire no alla ne del lotto programmato.
Figura 7.1: Architettura del software di acqusizione dati dalla VM.

7.3.2 Funzionamento
Il software sviluppato funziona in due modalità:
• online: l'acquisizione viene pilotata interamente dal sistema host;
• batch: l'acquisizione viene pilotata da un client installato sulla macchi-
na guest. Permette di eseguire le acquisizioni dati in corrispondenza a
determinati eventi.
Il programma necessita dei seguenti parametri:
• nome macchina virtuale: serve per agganciarsi alla macchina virtuale
desiderata;
• tipoAcquisizione: mr per i memory references, perf per gli indicatori
sull'utilizzo delle risorse;
• nomeFileOutput: solo per acquisizione online, indica il nome del le in
cui scrivere i dati. Per la modalità batch va indicato il percorso base
dove salvare i le generati. Il nome del le viene scelto dal client sulla
macchina virtuale.
L'output del programma è un le di testo in cui in ogni riga è presente uno o
più indicatori in funzione del tipo di acquisizione scelto:
• tipoAcquisizione mr: avremo un memory reference per ogni riga. Si veda
come esempio 7.1
• tipoAcquisizione perf: avremo una serie di indicatori sull'utilizzo delle
risorse. Si veda come esempio 7.2
Listing 7.1: Esempio di output nel caso di acquisizione di memory references
Timestamp,Indirizzo,
701892704123559, 0x0804a1be,
701892810391985, 0x0804e880,
701892913970180, 0x0804aa4f,
701893017903703, 0x0804ad8c,
701893121866733, 0x0804eed4,
701893224354769, 0x0804b11b,
701893329880761, 0x0804a878,
701893433875587, 0x0804af18,
701893535744118, 0x0804a3c8,
701893637910209, 0x0804f990,

701893741889815, 0x0804a884,
701893845900845, 0x0804a11d,
701893949900057, 0xc1005272,
701894051790540, 0x0804a989,
701894153906958, 0x0804a154,
701894257888280, 0x0804a8e5,
701894361898999, 0x0804ab68,
701894465900826, 0x0804a10b,
701894569877787, 0x0804a88c,
701894673902637, 0x0804a888,
Listing 7.2: Esempio di output nel caso di acquisizione di indicatori sull'utilizzo
delle risorse
Timestamp, Disco, NetIn, NetOut, CPUU, CPUK, RAM
701892704123559, 8740.0, 0.0, 0.0, 52.0, 45.0, 1135984.0,
701892810391985, 8740.0, 0.0, 0.0, 52.0, 45.0, 1135984.0,
701892913970180, 8740.0, 0.0, 0.0, 52.0, 45.0, 1135984.0,
701893017903703, 8740.0, 0.0, 0.0, 52.0, 45.0, 1135984.0,
701893121866733, 8740.0, 0.0, 0.0, 52.0, 45.0, 1135984.0,
701893224354769, 8740.0, 0.0, 0.0, 52.0, 45.0, 1135984.0,
701893329880761, 8740.0, 0.0, 0.0, 52.0, 45.0, 1135984.0,
701893433875587, 8740.0, 0.0, 0.0, 52.0, 45.0, 1135984.0,
701893535744118, 8740.0, 0.0, 0.0, 90.0, 10.0, 1016784.0,
701893637910209, 8740.0, 0.0, 0.0, 90.0, 10.0, 1016784.0,
701893741889815, 8740.0, 0.0, 0.0, 90.0, 10.0, 1016784.0,
701893845900845, 8740.0, 0.0, 0.0, 90.0, 10.0, 1016784.0,
701893949900057, 8740.0, 0.0, 0.0, 90.0, 10.0, 1016784.0,
701894051790540, 8740.0, 0.0, 0.0, 90.0, 10.0, 1016784.0,
701894153906958, 8740.0, 0.0, 0.0, 90.0, 10.0, 1016784.0,
701894257888280, 8740.0, 0.0, 0.0, 90.0, 10.0, 1016784.0,
701894361898999, 8740.0, 0.0, 0.0, 90.0, 10.0, 1016784.0,
701894465900826, 8740.0, 0.0, 0.0, 90.0, 10.0, 1016784.0,
701894569877787, 8740.0, 0.0, 0.0, 97.0, 2.0, 1016784.0,
701894673902637, 8740.0, 0.0, 0.0, 97.0, 2.0, 1016784.0,
7.3.3 Problemi riscontrati durante lo sviluppo
In questo paragrafo vengono presentati i problemi riscontrati durante lo svilup-
po del software. Il problema principale è stato la mancanza di esempi completi
all'interno dell'SDK per quanto riguarda l'acquisizione dati.

• L'acqusizione del valore dei registri della CPU non viene contemplato
in nessuno degli esempi forniti con l'SDK. È stato pertanto necessario
basarsi sulla scarna documentazione fornita, procedendo per tentativi,
no ad ottenere un sistema funzionante.
• Per quanto riguarda l'acqusizione degli indicatori sull'utilizzo delle risorse
è stato riscontrato un bug nell'implementazione della chiamata al meto-
do queryMetricsData della classe IPerformanceCollector dell'SDK di
Virtual Box, segnalato, tra l'altro, qui: [Smi] . Nel listato 7.3 è possibile
vedere la correzione eseguita derivando la classa e ridenendo il metodo.
• In una prima implementazione del software era presente un'unico pro-
gramma per la gestione dell'acqusizione dati batch. Da prove sul campo
è emerso che le API introducono una certa instabilità in caso di ese-
cuzioni protratte nel tempo. Per prevenire questi errori, che non sono
eccezioni gestibili all'interno della JVM, è stato necessario aggiungere
uno strato software (denominato factory in gura 7.1) per limitare gli
eetti di questi errori non gestibili solo all'acquisizione corrente e quindi
di poter proseguire con le restanti acquisizioni dati..
Listing 7.3: Correzione eseguita al codice dell'SDK
public ListInteger queryMetricsData(ListString paramList,
ListIUnknown paramList1, HolderListString paramHolder1,
HolderListIUnknown paramHolder, HolderListString
paramHolder2, HolderListLong paramHolder3, HolderListLong
paramHolder4, HolderListLong paramHolder5, HolderListLong
paramHolder6)
{
try {
String[][] arrayOfString1 =
(String[][])Array.newInstance([Ljava.lang.String.class, 1);
nsISupports[][] arrayOfnsISupports =
(nsISupports[][])Array.newInstance([Lorg.mozilla.interfaces.nsISupports.class
1);
String[][] arrayOfString2 =
(String[][])Array.newInstance([Ljava.lang.String.class, 1);
long[][] arrayOfLong1 = (long[][])Array.newInstance([J.class,
1);
1);

1);
1);
int[] arrayOfInt =
getTypedWrapped().queryMetricsData(paramList.size(),
Helper.unwrapStr(paramList), paramList1.size(),
(nsISupports[])Helper.unwrap2(IUnknown.class,
nsISupports.class, paramList1), null, arrayOfString1, null,
arrayOfnsISupports, null, arrayOfString2, null,
arrayOfLong1, null, arrayOfLong2, null, arrayOfLong3, null,
arrayOfLong4, null);
paramHolder1.value = Helper.wrap(arrayOfString1[0]);
//Produceva errore
//paramHolder.value = Helper.wrap2(IUnknown.class,
nsISupports.class, arrayOfnsISupports[0]);
//correzione:
paramHolder.value = new ArrayListIUnknown();
for(int i=0;iarrayOfnsISupports[0].length;i++){
IUnknown elm = new IUnknown(arrayOfnsISupports[0][i]);
paramHolder.value.add(elm);
}
//fine correzione
paramHolder2.value = Helper.wrap(arrayOfString2[0]);
paramHolder3.value = Helper.wrap(arrayOfLong1[0]);
return Helper.wrap(arrayOfInt);
}
catch (XPCOMException localXPCOMException)
{
throw new VBoxException(localXPCOMException.getMessage(),
localXPCOMException);
}
}

7.4 Creazione delle frame
Questo software è stato sviluppato interamente nell'ambito della tesi. Il soft-
ware è scritto in linguaggio c++. La scelta del linguaggio c++ è stato eet-
tuata perché:
• ben supportato come linguaggio dalla libreria openCV;
• introduce meno overhead nell'elaborazione rispetto a Java;
• nessun limite alla memoria allocabile (in Java occorre settare opportu-
namente la JVM).
Partendo dai le di testo prodotti dal software di acquisizione si vuole:
• portare i dati in un formato facilmente leggibile e facilmente utilizzabile;
• dividere le tracce in frame;
• normalizzare i valori.
La prima esigenza è stata risolta impiegando il formato YAML [Eva] per per-
sistere oggetti di tipo Mat della libreria OpenCV [odt]. La scelta è stata
eettuata per il fatto che YAML permette di serializzare gli oggetti in modo
che non sia più necessaria la conversione da testo a valore numerico. Inoltre la
libreria openCV supporta in modo nativo tale formato e nella documentazione
sono presenti numerosi esempi. La divisione in frame presuppone che vengano
forniti due parametri di ingresso:
• lunghezza della frame (espressa come numero di campioni);
• intervallo tra l'inizio di una frame e la successiva (sempre in numero di
campioni);
• numero di campioni iniziali da scartare.
Con questi due parametri il problema della divisione in frame viene demandato
completamente al chiamante. Per la normalizzazione dei valori è stato scelto:
• per i memory references, dato che si presentano come numeri interi di
valore molto elevato, di sostituirli con il loro logaritmo naturale. Que-
sta scelta permette di evitare problemi di arrotondamento nei successivi
calcoli;
• per gli indicatori sull'utilizzo delle risorse essi vengono normalizzati da
0 a 1. Questa scelta permette di uniformare le componenti del vettore
formato dai valori di questi indicatori.

Nei listati 7.4 e 7.5 si vedono degli esempi di output di questo programma.
Listing 7.4: Frame prodotto nel caso di memory reference
%YAML:1.0
frame: !!opencv-matrix
rows: 15040
cols: 1
dt: f
data: [ 2.18982315e+01, 2.18982315e+01, 2.18982315e+01,
2.18982315e+01, 2.18982315e+01, 2.18982315e+01, 2.18982315e+01,
2.18982315e+01, 2.18982315e+01, 2.18982315e+01, 2.18982315e+01,
2.18982315e+01, 2.18982315e+01, 2.18982315e+01, 2.18982315e+01,
2.18986187e+01, 2.21492462e+01, 2.18982315e+01, 2.18982315e+01,
2.18982315e+01, 2.18982315e+01, 2.18982315e+01, 2.18982315e+01,
Listing 7.5: Frame prodotto nel caso di indicatori sull'utilizzo dell risorse
%YAML:1.0
rows: 512
cols: 4
dt: f
data: [ 5.82666695e-01, 9.59999979e-01, 3.99999991e-02,
9.21773434e-01, 5.82666695e-01, 9.59999979e-01, 3.99999991e-02,
9.21773434e-01, 5.82666695e-01, 9.59999979e-01, 3.99999991e-02,
9.21773434e-01, 5.82666695e-01, 9.59999979e-01, 3.99999991e-02,
9.21773434e-01, 5.82666695e-01, 9.59999979e-01, 3.99999991e-02,
9.21773434e-01, 5.82666695e-01, 9.59999979e-01, 3.99999991e-02,
9.21773434e-01, 5.82666695e-01, 9.59999979e-01, 3.99999991e-02,
9.21773434e-01, 5.82666695e-01, 9.59999979e-01, 3.99999991e-02,
9.21773434e-01, 5.82666695e-01, 9.59999979e-01, 3.99999991e-02,
9.21773434e-01, 5.82666695e-01, 9.59999979e-01, 3.99999991e-02,
7.4.1 Funzionamento
Per semplicità di utilizzo il programma è stato diviso in due programmi distinti,
l'uno per gestire i memory reference e l'altro per gli indicatori sull'utilizzo delle
risorse. Entrambi vengono invocati con questi parametri:
• numero campioni totali;
• numero campioni iniziali da scartare;

• lunghezza (in numero di campioni) della frame;
• step, cioè distanza tra l'inizio di una frame e la successiva, (in numero
di campioni);
• percorso + presso per i le di output.
Durante l'esecuzione vengono create le varie frame. I le relativi si troveranno
lungo il path percorso/pressoXXX.yml, dove XXX rappresenta il numero di
frame generate a partire da una traccia in input. Per agevolare la creazione
delle frame è stato sviluppato uno script Bash. Tale script:
• seleziona le tracce per comporre gli insiemi di train e di test in modo
opportuno;
• eventualmente elimina i database creati in precedenza;
• crea la struttura di directory per i database;
• avvia il programma opportuno (memory reference o indicatori sull'uti-
lizzo delle risorse).
Alla ne del processo otteniamo due strutture di directory simili a quelle in
gura 7.2, una con l'insieme di train, l'altra con l'insieme di test.
Figura 7.2: Esempio di struttura del database delle frame.

Nello sviluppo di questo software non si sono riscontrati particolari problemi.
L'unico punto critico è stato trovare la corrispondenza tra tipi di dato in c++
e in openCV per poter valorizzare correttamente l'oggetto Mat con i campioni.
7.5 Divisione in blocchi e clustering
Questo software è stato sviluppato nel corso della tesi utilizzando come base il
software hmmface sviluppato nel corso di un'altra tesi. è stato completamente
svuotato delle logiche originali di addestramento, di gestione dei modelli e di
test. è stata modicata la parte di gestione del database delle frame in modo
da essere compatibile con il formato scelto (YAML). è stata aggiunta la logica
per la divisione in blocchi, il calcolo dei centroidi, la clusterizzazione. Partendo
da una frame (es. 7.4 o 7.5) il programma:
• suddivide in blocchi la frame;
• calcola la DCT di ciascun blocco;
• clusterizza i blocchi e ne salva le label (l'indice del vettore nell'insieme
dei centroidi).
La clusterizzazione dei blocchi avviene attraverso l'algoritmo kmeans, di cui
viene utilizzata l'implementazione presente nella libreria openCV.
7.5.1 Funzionamento
Si presuppone che esistano due set distinti del tipo in gura 7.2, uno per il
training, l'altro per il test. Esistono due programmi distinti:
• modalità di addestramento (train): con questo programma vengono crea-
ti i centroidi e calcolate le labels di tutti i blocchi generati dalle frame
presenti nel database di train;
• modalità di test: con questo programma vengono calcolate le labels di
ciascun blocco relativo alle frame del set di test utilizzando i centroidi
calcolati dal programma di train.
Il programma di train viene invocato con i seguenti parametri:
• path del database;
• numero di classi in cui clusterizzare i blocchi;

• numero di coecienti della DCT da utilizzare per rappresentare il blocco;
• ag per escludere o mantenere il primo coeciente della DCT (la conti-
nua);
• numero di blocchi per ciascuna frame.
I parametri devono soddisfare i seguenti vincoli:
• coecientiDCT lunghezzaFrame / numeroBlocchi;
• lunghezzaFrame / numeroBlocchi deve essere pari (vincolo imposto dalla
trasformata DCT).
L'output di questo programma sono dei le in formato YAML (uno per ogni
frame) in cui sono contenute le label associate a ciascun blocco della frame e un
altro le in formato YAML in cui sono contenuti i centroidi 7.6 Il programma
di test viene invocato con i seguenti parametri:
• frame da clusterizzare;
• database di train da cui caricare i centroidi;
• gli altri parametri sono gli stessi del programma train.
Per ogni frame data in input viene creato un le in formato YAML in cui sono
contenute le label associate a ciascun blocco della frame 7.7
Listing 7.6: Esempio di centroidi
%YAML:1.0
centroids: !!opencv-matrix
rows: 6
cols: 16
dt: f
data: [ -3.06569855e-04, -1.08161084e-01, -2.09528431e-02,
-5.95307760e-02, -2.05521379e-02, -8.53601918e-02,
-9.92437708e-04, -5.45172021e-02, 8.12677108e-03,
-4.59062643e-02,
7.90587452e-04, -3.55328433e-02, -9.75481141e-03,
-2.52794530e-02,
6.57281652e-03, -1.59176998e-02, 2.22821274e+01,
-1.48326406e+01,
5.79074383e+00, 4.98687476e-02, -2.06306362e+00, 1.31559050e+00,
-4.15854096e-01, -7.15919957e-02, -2.04606757e-01,
7.09409654e-01,

-7.57185757e-01, 3.13336998e-01, -7.22765252e-02,
1.39015466e-01,
-2.08173409e-01, 1.76923886e-01, 2.99389458e+01, 5.69996595e+00,
-9.68416309e+00, 1.26773369e+00, -5.63507862e-02,
1.43814385e-01,
-6.83244884e-01, 1.34673274e+00, -1.66306064e-01,
-5.58102012e-01,
2.12694108e-01, -5.43488264e-02, -1.42198861e-01,
-3.48987505e-02,
1.43358961e-01, 1.33434787e-01, -2.28228397e+01,
-1.41331720e+01,
-5.11468792e+00, 1.06525861e-01, 1.23515630e+00, 5.28854549e-01,
3.11504863e-02, 3.12583178e-01, 7.44129896e-01, 8.15373898e-01,
6.31796658e-01, 4.53701407e-01, 3.36565971e-01, 2.18720809e-01,
1.08863287e-01, 7.41523802e-02, -2.59945030e+01, 1.02532911e+01,
7.03120279e+00, 1.28860879e+00, 3.20311785e-01, 2.82335639e-01,
1.21425414e+00, 4.42285724e-02, -1.99875876e-01,
-2.27946430e-01,
2.32838050e-01, 2.54056633e-01, 1.60251167e-02, 4.10910621e-02,
8.58983025e-03, -5.37593924e-02, 7.34245396e+00, 2.20151386e+01,
7.92218506e-01, -1.02159679e+00, 4.77390513e-02, 2.03271937e-02,
-4.43136990e-01, -1.00596659e-02, 2.20206037e-01,
5.13941526e-01,
-3.60902429e-01, -2.19827801e-01, 2.17572227e-02,
-4.06459242e-01,
-1.55029118e-01, -3.82144004e-02 ]
Listing 7.7: Esempio di labels
%YAML:1.0
rows: 16
cols: 1
dt: i
data: [ 1, 1, 3, 1, 5, 1, 0, 0, 0, 1, 1, 2, 2, 2, 1, 3 ]
Durante lo sviluppo le dicoltà maggiori si hanno avute nella corretta suddi-
visione in blocchi, in quanto è stato necessario tener conto delle diversità nei
dati tra frame di memory references e indicatori sull'utilizzo delle risorse. Le

prime consistono in un dato primitivo per riga. Le altre sono composte da
righe con vettori di dati e vanno quindi gestite in modo opportuno.
7.6 Addestramento e test di rete neurale
Questo software, come il precedente, deriva da hmmface. È stata modicata
la parte di gestione del database delle frame in modo da essere compatibile
con il formato prescelto (YAML). Sono state modicate le parti relative alla
gestione (creazione, inizializzazione, caricamento) dei modelli e riscritte le parti
relative all'addestramento e al test dei modelli. L'implementazione scelta per
le reti neurali è quella eettuata nella libreria Fann (Fast Articial Neural
Network). La topologia di rete è il multilayer perceptron a tre layer (input,
hidden, output). L'input layer presenta tanti ingressi quanti sono i blocchi in
cui è stata divisa la frame. Gli ingressi sono i numeri delle label. L'output
layer presenta una sola uscita che indica la probabilità che la frame data in
input appartenga ad un programma.
7.6.1 Funzionamento
Si presuppone che esistano due set distinti del tipo in gura 7.2, uno per il
training, l'altro per il test, di cui è stata eseguita in precedenza la divisione in
blocchi e il clustering. Esistono due programmi distinti:
• modalità di addestramento (train): con questo programma vengono crea-
ti i modelli (uno per ogni programma) utilizzando come input le label
dei blocchi di tutte le frame presenti nel database di train;
• modalità di test: con questo programma vengono testate tutte le frame
presenti nel database di test. Viene scritto un le con i risultati del test.
Il programma di train viene invocato con i seguenti parametri:
• path del database;
• numero di input della rete neurale;
• numero di neuroni dello strato nascosto;
• numero massimo di epoche di addestramento.
L'algoritmo di addestramento segue i seguenti passi:
• censimento di tutte le frame, divise per programma in base alla struttura
del database;

• generazione dei modelli coerentemente con i programmi presenti nel
database e ai parametri in input;
• addestramento dei modelli, per ogni modello:
preparazione set di train con metà esempi di appartenenza al mo-
dello e metà esempi di non appartenenza. Questi ultimi scelti a caso
tra i rimanenti programmi;
avvio procedura di addestramento;
se raggiunto tasso di errore zero: stop;
altrimenti proseguo nché raggiunto numero massimo di epoche;
• salvataggio dei modelli addestrati.
L'output del programma di train sono i modelli relativi ai vari programmi
presenti nel database. Nel listato 7.8 è possibile vedere un esempio di mo-
dello generato, contenente la rete neurale addestrata per riconoscere frame
appartenenti al programma.
Listing 7.8: Rete neurale creata come modello di un programma
FANN_FLO_2.1
num_layers=3
learning_rate=0.700000
connection_rate=1.000000
network_type=0
learning_momentum=0.000000
training_algorithm=2
train_error_function=1
train_stop_function=0
cascade_output_change_fraction=0.010000
quickprop_decay=-0.000100
quickprop_mu=1.750000
rprop_increase_factor=1.200000
rprop_decrease_factor=0.500000
rprop_delta_min=0.000000
rprop_delta_max=50.000000
rprop_delta_zero=0.100000
cascade_output_stagnation_epochs=12
cascade_candidate_change_fraction=0.010000
cascade_candidate_stagnation_epochs=12
cascade_max_out_epochs=150
cascade_min_out_epochs=50
cascade_max_cand_epochs=150

cascade_min_cand_epochs=50
cascade_num_candidate_groups=2
bit_fail_limit=1.00000001490116119385e-01
cascade_candidate_limit=1.00000000000000000000e+03
cascade_weight_multiplier=4.00000005960464477539e-01
cascade_activation_functions_count=10
cascade_activation_functions=3 5 7 8 10 11 14 15 16 17
cascade_activation_steepnesses_count=4
cascade_activation_steepnesses=2.50000000000000000000e-01
5.00000000000000000000e-01 7.50000000000000000000e-01
1.00000000000000000000e+00
layer_sizes=21 64 2
scale_included=0
neurons (num_inputs, activation_function, activation_steepness)=(0,
0, 0.00000000000000000000e+00) (0, 0, 0.00000000000000000000e+00)
(0, 0, 0.00000000000000000000e+00)
connections (connected_to_neuron, weight)=(0,
4.04511094093322753906e-01) (1, 6.03508576750755310059e-03) (2,
-5.56600034236907958984e-01) (3, -4.46860194206237792969e-01)
Il programma di test viene invocato con i seguenti parametri:
• frame clusterizzata da testare;
• database di train che contiene i modelli.
Il programma carica tutti i modelli creati in fase di train e testa la frame passa-
ta in input con ogni modello. La frame viene riconosciuta come appartenente
al programma il cui modello risponde con un valore più alto in uscita. Per
agevolare la fase di test è stato creato uno script per richiamare il programma
di test con tutte le frame clusterizzate nel database di test. In uscita abbiamo
un le che contiene l'esito del riconoscimento, ovvero le probabilità che ha la
frame di appartenere a ciascun modello. Viene inoltre indicato il programma
a cui la frame appartiene. Nel listato 7.9 viene fornito un esempio di le di
output.
Listing 7.9: Output del programma per il test
pVero;pTrovato;sjeng;perlbench;omnetpp;libquantum;gcc;bzip2;
bzip2;bzip2;0.130548;0.22756;0.235933;0.163479;0;0.242481;
bzip2;bzip2;0.210586;0.231984;0.111663;0.200375;0;0.245393;
bzip2;bzip2;0.2579;0.248842;0;0.11131;0.107966;0.273981;
bzip2;bzip2;0.189267;0.214833;0;0.0901389;0.198654;0.307107;
bzip2;bzip2;0.181434;0.184786;0.18922;0;0.0662469;0.378313;

bzip2;bzip2;0.2516;0.249429;0.211497;0;0.0259506;0.261523;
bzip2;bzip2;0.241213;0.307921;0.069095;0;0.070553;0.311219;
bzip2;bzip2;0;0.325681;0.18369;0.147379;0.0112246;0.332026;
bzip2;bzip2;0.161043;0.25991;0;0.218057;0.0786933;0.282297;
bzip2;bzip2;0.14622;0.259191;0.118856;0.210021;0;0.265712;
bzip2;sjeng;0.227629;0.224094;0.187735;0.226305;0;0.134237;
bzip2;sjeng;0.231306;0.228582;0.151684;0.163513;0;0.224915;
bzip2;bzip2;0.268863;0.214774;0;0.0581869;0.178839;0.279338;
bzip2;bzip2;0.0639456;0.244768;0;0.215536;0.200423;0.275327;
bzip2;bzip2;0.251042;0;0.163536;0.24025;0.0796963;0.265476;
bzip2;bzip2;0.238174;0.220301;0;0.226525;0.0712822;0.243718;
bzip2;bzip2;0.213192;0.209801;0.153829;0.203002;0;0.220177;
bzip2;bzip2;0.272146;0.155566;0.237197;0.059243;0;0.275849;
bzip2;bzip2;0.150479;0.336761;0.0484909;0;0.0922978;0.371971.
Ogni riga rappresenta l'esito del test di una frame. La prima colonna rap-
presenta il programma vero da cui è stata estratta la frame. La seconda co-
lonna rappresenta il programma riconosciuto. Le restanti colonne indicano,
per ciascun modello nel database la probabilità della frame di appartenere al
modello.
7.7 Addestramento e test di HMM
È stato utilizzato il software sviluppato in un'altra tesi di laurea. Per maggiori
dettagli si veda [Pie11]. È stata modicata la logica di caricamento delle frame,
in quanto il programma originale lavora con immagini bitmap. Al loro posto
vengono impiegati le in formato YAML.
7.8 Software per la fusione con
Dempster-Shafer
Utilizzando come base gli esempi di utilizzo di una libreria c++ che implemen-
ta il metodo di Dempster-Shafer [eJJ] è stato sviluppato un programma che,
partendo dai risultati di più sistemi di riconoscimento (nel nostro caso memory
references e indicatori sull'utilizzo delle risorse), esegue la fusione delle infor-
mazioni al ne di migliorare il tasso di corretto riconoscimento delle frame. è
stato scritto un componente software che permette di leggere le in formato
csv come quello descritto qui 7.9. Inoltre è stata modicata la logica interna
per eettuare la fusione ne modo descritto in seguito. È possibile vedere la
struttura del programma in gura 7.3

Figura 7.3: Architettura del software di fusione con Dempster-Shafer a
partire dai riconoscitori di memory reference e dati sull' utilizzo delle risorse.
7.8.1 Funzionamento
Si presuppone che esistano due sistemi per il riconoscimento. I dati di input
devono essere del formato descritto in 7.9. I due sistemi di riconoscimento
devono lavorare con lo stesso numero di frame. Il programma viene invocato
con i seguenti parametri:
• le dei risultati del primo sistema;
• le dei risultati del secondo sistema.
In fase di inizializzazione il programma:
• esamina l'header del le csv per ricavare i programmi oggetto di ricono-
scimento;
• imposta come ipotesi dell'universo i programmi.
In seguito il programma esegue i seguenti passi per ogni frame dei due le di
input:
• per ogni sistema di riconoscimento:
per ogni programma:
∗ leggo la probabilità di appartenenza al programma della frame
dal le csv;
∗ crea un'attestazione con massa pari alla probabilità letta per il
programma in esame;

Profilazione utente in ambienti virtualizzati

Profilazione utente in ambienti virtualizzati

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (7)

Semelhante a Profilazione utente in ambienti virtualizzati

Semelhante a Profilazione utente in ambienti virtualizzati (20)

Último

Último (20)

Profilazione utente in ambienti virtualizzati