tesi specialistica su parallelizzazione multithread di algoritmi per il datamining

1. `
UNIVERSITA CA’ FOSCARI – VENEZIA
Facolt` di Scienze Matematiche, Fisiche e Naturali
a
Corso di Laurea in Informatica (Specialistica)
Tesi di Laurea
11 Aprile 2008
Laureando: Fabio Pustetto
WekaSMP: Parallelizzazione Multi-Thread
di una libreria Java per il Data Mining
Relatore: Chiar.mo prof. Salvatore Orlando
Anno Accademico 2006 - 2007
Via Torino 155 – 30173 Mestre - Venezia

2. II

3. “Se aumentiamo gradualmente il carico di una nave,
possiamo anche cercare di distribuirlo in modo ottimale
ma ad un certo punto la nave affonder`,
a
anche se avremo la consolazione di un affondamento ottimale.”
Hermann Daly, economista della Sostenibilit`.
a
Questa tesi ` stampata su carta riciclata in adesione alla campagna
e
“Scrittori per le foreste”, lanciata da
III

4. IV

5. Indice
1 Introduzione 1
I Stato dell’arte 5
2 Data Mining 7
2.1 Regole Associative . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.1 Algoritmo Apriori . . . . . . . . . . . . . . . . . . . . 9
2.2 Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.1 Algoritmo K-Means . . . . . . . . . . . . . . . . . . . 15
2.3 Weka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.1 Algoritmo Apriori . . . . . . . . . . . . . . . . . . . . 20
2.3.2 Algoritmo K-Means . . . . . . . . . . . . . . . . . . . 22
3 Architetture e Programmazione Parallela 25
3.1 Definizioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2 Architetture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3 Gestione della memoria . . . . . . . . . . . . . . . . . . . . . 31
3.3.1 Memoria Cache . . . . . . . . . . . . . . . . . . . . . . 33
3.4 Sincronizzazione . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.5 Multi core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.5.1 Realizzazione . . . . . . . . . . . . . . . . . . . . . . . 39
3.6 Multithreading in Java . . . . . . . . . . . . . . . . . . . . . . 44
3.6.1 Processi . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.6.2 Thread . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.6.3 Sincronizzazione . . . . . . . . . . . . . . . . . . . . . 49
V

6. 4 Regole Associative e Clustering: algoritmi paralleli 57
4.1 Regole associative . . . . . . . . . . . . . . . . . . . . . . . . 60
4.1.1 Versioni parallele a memoria distribuita . . . . . . . . 62
4.1.2 Versioni parallele a memoria condivisa . . . . . . . . . 66
4.1.3 Risultati sperimentali . . . . . . . . . . . . . . . . . . 67
4.1.4 Problemi Aperti . . . . . . . . . . . . . . . . . . . . . 71
4.2 Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.2.1 Versioni parallele a memoria distribuita . . . . . . . . 74
4.2.2 Versioni parallele a memoria condivisa . . . . . . . . . 76
4.2.3 Risultati Sperimentali . . . . . . . . . . . . . . . . . . 76
II WekaSMP 79
5 Analisi degli algoritmi di WekaSMP 81
5.1 Regole Associative: AprioriSMP . . . . . . . . . . . . . . . . 82
5.2 Clustering: K-MeansSMP . . . . . . . . . . . . . . . . . . . . 83
6 Realizzazione del prototipo WekaSMP 87
6.1 Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.2 Regole Associative: AprioriSMP . . . . . . . . . . . . . . . . 89
6.3 Clustering: K-MeansSMP . . . . . . . . . . . . . . . . . . . . 96
7 Risultati Sperimentali 103
7.1 Preliminari . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
7.2 AprioriSMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
7.2.1 Dataset . . . . . . . . . . . . . . . . . . . . . . . . . . 107
7.2.2 Test contatori condivisi . . . . . . . . . . . . . . . . . 109
7.2.3 Test contatori privati . . . . . . . . . . . . . . . . . . . 113
7.2.4 Commenti . . . . . . . . . . . . . . . . . . . . . . . . . 120
7.3 K-MeansSMP . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
7.3.1 Dataset . . . . . . . . . . . . . . . . . . . . . . . . . . 125
7.3.2 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
7.3.3 Commenti . . . . . . . . . . . . . . . . . . . . . . . . . 131
8 Conclusioni 135
VI

7. III Allegati 141
A Script 143
B Core 147
B.1 Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
B.2 Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
C AprioriSMP 155
C.1 Apriori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
C.2 CountDistribution . . . . . . . . . . . . . . . . . . . . . . . . 163
D K-MeansSMP 165
D.1 SimpleKMeans . . . . . . . . . . . . . . . . . . . . . . . . . . 165
D.2 K-MeansSMP . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Bibliografia 181
VII

8. VIII

9. Elenco delle figure
2.1 Algoritmo Apriori [AS94] . . . . . . . . . . . . . . . . . . . . 10
2.2 Algoritmo Apriori, funzione apriori gen [AS94] . . . . . . . . 10
2.3 Algoritmo Apriori, eliminzione dei non frequenti (prune) [AS94] 11
2.4 Inserimento di candidati dalla radice dell’hash tree [HKK97] . 12
2.5 Inserimento di candidati dal sottoalbero sinistro dell’hash tree
[HKK97] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.6 Esempio di clusterizzazione gerarchica a dendrogramma . . . 14
2.7 Esempio di clusterizzazione partizionale . . . . . . . . . . . . 15
2.8 Algoritmo K-Means sequenziale [DM00] . . . . . . . . . . . . 17
2.9 Esempio di clusterizzazione di punti spaziali . . . . . . . . . . 18
2.10 Esempio di database in formato ARFF . . . . . . . . . . . . . 20
2.11 Output dell’algoritmo Apriori su Weka . . . . . . . . . . . . . 22
2.12 Output dell’algoritmo K-Means su Weka . . . . . . . . . . . . 24
3.1 Tassonomia di Flynn . . . . . . . . . . . . . . . . . . . . . . . 27
3.2 Architettura SIMD . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3 Architettura SIMD . . . . . . . . . . . . . . . . . . . . . . . . 28
3.4 Architettura MISD . . . . . . . . . . . . . . . . . . . . . . . . 29
3.5 Architettura MIMD . . . . . . . . . . . . . . . . . . . . . . . 29
3.6 Esempio di architettura quad core: AMD opteron [amd] . . . 30
3.7 Esempio di architettura della memoria UMA . . . . . . . . . 32
3.8 Esempio di architettura della memoria NUMA . . . . . . . . 33
3.9 Intel Pentium D Smithfield, primo dual core a die singolo [int] 39
3.10 Intel Pentium D Presler, primo dual core a die doppio [int] . 41
3.11 Intel Core 2 Duo, primo dual core a monolitico [int] . . . . . 42
3.12 Intel Xeon quad core [int] . . . . . . . . . . . . . . . . . . . . 43
3.13 Confronto tra l’architettura die singolo e monolitica [int] . . . 43
IX

10. 3.14 Esempio di processo multithreading su processore quad-core . 45
3.15 Grafo di transizione dei processi . . . . . . . . . . . . . . . . . 47
3.16 Sincronizzazione per l’accesso ad una risorsa . . . . . . . . . . 51
4.1 Struttura degli algoritmi di Data Mining pi` comuni [JA02] .
u 58
4.2 Utilizzo della memoria nei vari schemi di Locking [JA02] . . . 59
4.3 Compromessi tra le varie tecniche [JA02] . . . . . . . . . . . . 60
4.4 Algoritmi paralleli per la scoperta di Regole Associative [Zak99] 61
4.5 Algoritmo Count Distribution [HKK97] . . . . . . . . . . . . 63
4.6 Algoritmo Data Distribution [HKK97] . . . . . . . . . . . . . 64
4.7 Confronto scalabilit` algortimi paralleli [HKK97] . . . . . . .
a 67
4.8 Confronto speedup algortimi paralleli [HKK97] . . . . . . . . 68
4.9 Confronto tempi di risposta algortimi paralleli [HKK97] . . . 69
4.10 Propriet` del database per i test dell’algoritmo CCPD [ZOPL96] 70
a
4.11 Speedup dell’algoritmo CCPD senza e con lettura del data-
base [ZOPL96] . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.12 Tempi di lettura del database [ZOPL96] . . . . . . . . . . . . 71
4.13 Algoritmo K-Means sequenziale [DM00] . . . . . . . . . . . . 75
4.14 Scelta dei primi centroidi su algoritmo K-Means . . . . . . . . 76
4.15 Prestazioni K-Means parallelo con n = 221 , d = 8 e k = 8
[DM00] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.16 Prestazioni K-Means parallelo con n = 221 , d = 8 e k = 8
[JA02] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.1 Confronto Count Distribution SM e DM . . . . . . . . . . . . 90
6.2 Diagramma di flusso algoritmo AprioriSMP . . . . . . . . . . 91
6.3 Diagramma delle classi, algoritmo Apriori . . . . . . . . . . . 93
6.4 Diagramma di flusso kmeansSMP . . . . . . . . . . . . . . . . 98
6.5 Diagramma delle classi, algoritmo kMeansSMP . . . . . . . . 99
7.1 Esempio di rilevamento cache miss con VTune . . . . . . . . . 105
7.2 Esempio output AprioriSMP nei test . . . . . . . . . . . . . . 106
7.3 Esempio rilevamento tempi AprioriSMP nei test . . . . . . . 107
7.4 Struttura del dataset Mushroom . . . . . . . . . . . . . . . . 108
7.5 Descrizione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
X

11. 7.6 Tempi di risposta dell’algoritmo AprioriSMP con contatori
condivisi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
7.7 Speedup dell’algoritmo AprioriSMP con contatori condivisi . 115
7.8 Speedup del conteggio dei frequenti con contatori condivisi . 116
7.9 Tempi di risposta dell’algoritmo AprioriSMP con contatori
privati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
7.10 Speedup dell’algoritmo AprioriSMP con contatori privati . . . 120
7.11 Speedup del conteggio dei frequenti con contatori privati . . . 121
7.12 Confronto tempi di risposta versioni AprioriSMP . . . . . . . 122
7.13 Confronto speedup versioni AprioriSMP . . . . . . . . . . . . 123
7.14 Scalabilit` dell’algoritmo AprioriSMP . . . . . . . . . . . . . 124
a
7.15 Esempio rilevamento dei tempi test K-MeansSMP . . . . . . 125
7.16 Esempio output dei test K-MeansSMP . . . . . . . . . . . . . 126
7.17 Struttura del dataset Iris . . . . . . . . . . . . . . . . . . . . 127
7.18 Tempi di risposta K-MeansSMP variando il numero di pro-
cessori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
7.19 Tempi di risposta K-MeansSMP variando la dimensione del
database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
7.20 Scalabilit` K-MeansSMP . . . . . . . . . . . . . . . . . . . . . 133
a
7.21 Speedup K-MeansSMP . . . . . . . . . . . . . . . . . . . . . . 134
XI

12. XII

13. Elenco delle tabelle
2.1 Transazioni di un supermercato . . . . . . . . . . . . . . . . . 8
2.2 Simboli utilizzati per lo studio di K-Means . . . . . . . . . . . 16
2.3 Principali opzioni per l’algoritmo Apriori su Weka . . . . . . 21
2.4 Principali opzioni per l’algoritmo K-Means su Weka . . . . . 23
5.1 Simboli utilizzati nell’analisi teorica di Apriori . . . . . . . . 82
5.2 Simboli utilizzati nell’analisi teorica di K-Means . . . . . . . 83
6.1 Tipi pi` importanti nella classe Apriori
u . . . . . . . . . . . . 88
7.1 Parametri test AprioriSMP . . . . . . . . . . . . . . . . . . . 105
7.2 Tempi di risposta AprioriSMP, contatori condivisi, database
50 MByte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
7.3 Indici prestazionali AprioriSMP, contatori condivisi, database
50 MByte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
7.4 Tempi di risposta AprioriSMP, contatori condivisi, database
200 MByte . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
7.5 Indici prestazionali AprioriSMP, contatori condivisi, database
200 MByte . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
7.6 Tempi di risposta AprioriSMP, contatori condivisi, database
500 MByte . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
7.7 Speedup AprioriSMP, contatori condivisi, database 500 MByte113
7.8 Tempi di risposta AprioriSMP, contatori privati, database 50
MByte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
7.9 Indici prestazionali AprioriSMP, contatori privati, database
50 MByte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
7.10 Tempi di risposta AprioriSMP, contatori privati, database 200
MByte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
XIII

14. 7.11 Speedup AprioriSMP, contatori privati, database 200 MByte 117
7.12 Tempi di risposta AprioriSMP, contatori privati, database 500
MByte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
7.13 Indici prestazionali AprioriSMP, contatori privati, database
500 MByte . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
7.14 Cache Miss AprioriSMP . . . . . . . . . . . . . . . . . . . . . 123
7.15 Parametri test K-MeansSMP . . . . . . . . . . . . . . . . . . 124
7.16 Tempi di risposta K-MeansSMP, database 25 MByte . . . . . 128
7.17 Indici prestazionali K-MeansSMP, database 25 MByte . . . . 128
7.18 Tempi di risposta K-MeansSMP, database 50 MByte . . . . . 129
7.19 Indici prestazionali K-MeansSMP, database 50 MByte . . . . 129
7.20 Tempi di risposta K-MeansSMP, database 200 MByte . . . . 130
7.21 Indici prestazionali K-MeansSMP, database 200 MByte . . . 130
7.22 Cache Miss K-MeansSMP . . . . . . . . . . . . . . . . . . . . 133
XIV

15. Sommario
L’idea base delle architetture parallele ` che diversi processori cooperino
e
nella soluzione di un singolo problema. Il motivo che spinge ad occuparsi
di calcolo parallelo ` proprio il tentativo di velocizzare il processo di calco-
e
lo della soluzione dei problemi computazionali. In accordo con la legge di
Moore ` stato ormai raggiunto il limite fisico per l’aumento della frequenza
e
dei processori e vengono rilasciati i primi sistemi Multi-Core: pi` unit` di
u a
calcolo nello stesso processore che cooperano nel raggiungimento del risul-
tato e una sola memoria condivisa. Per far fronte all’esigenza di sfruttare il
patrimonio informativo contenuto nelle grandi raccolte di dati che abbiamo
a disposizione, si utilizzano algoritmi di Data Mining per estrarre infor-
mazione implicita da dati gi` strutturati, esplorare ed analizzare in modo
a
automatico grandi quantit` di dati allo scopo di scoprire regole o insiemi
a
significativi. Lo scopo di questa tesi ` studiare e fornire algoritmi di Data
e
Mining paralleli efficienti per questo nuovo tipo di architetture, basandosi
sulle librerie Java del progetto Weka. L’implementazione parallela da luogo
al prototipo WekaSMP, base di partenza per la parallelizzazione di tutti gli
algoritmi in essa contenuti. L’analisi dei risultati, infine, evidenzia come sia
possibile ridurre il tempo di computazione in modo sensibile sfruttando in
modo opportuno tutte le unit` di calcolo.
a

17. Capitolo 1
Introduzione
“Un giorno le macchine riusciranno a risolvere tutti i problemi,
ma mai nessuna di esse potr` porne uno”
a
Albert Einstein (1879-1955), fisico tedesco.
1

18. Con la disponibilit` di grandi basi di dati in molte aree applicative come
a
bioinformatica, medicina, analisi scientifiche e finanziarie, telecomunicazio-
ni, vendite al dettaglio e marketing, sta diventando sempre pi` necessario
u
eseguire applicazioni Data Mining in parallelo. Allo stesso tempo il progresso
tecnologico ha reso accessibile a tutti le macchine parallele a memoria con-
divisa, sia per l’industria che per il privato. Se da un lato la profonda inno-
vazione introdotta con queste architettura porta ad un effettivo incremento
delle prestazioni in ambienti multitasking, dall’altro obbliga i programma-
tori a sviluppare algoritmi paralleli su misura. In questo senso la velocit`
a
di sviluppo di queste nuove architetture non ` stata mantenuta anche dal-
e
l’implementazione di nuovi algoritmi. Ricordiamo una scomoda verit`: un
a
algoritmo sequenziale eseguito su un processore multi-core di nuova genera-
zione, basato su un’architettura parallela a memoria condivisa, non godr`
a
di nessun incremento di prestazioni.
In questo elaborato ci si focalizza sulla parallelizzazione ad hoc di alcu-
ne librerie Java per il Data Mining sviluppate in ambito accademico presso
la facolt` di informatica dell’universit` neozelandese di Waikato, conosciuto
a a
come progetto Weka. Lo sviluppo di questo nuovo tool deve essere parallelo
ed efficiente su macchine a memoria condivisa, tale da garantire un incre-
mento di prestazioni adeguato se confrontato con le versioni sequenziali o
parallele per macchine distribuite, esistenti.
Ecco come si presenta questo elaborato. Nel capitolo 2 si presentano
le basi teoriche delle discipline per la scoperta di regole associative e pro-
cessi di clustering sulle quali sono fondate le applicazioni di Data Mining
che stiamo esplorando e un’approfondimento sul progetto Weka alla relea-
se attuale. Nel capitolo 3 si presentano le innovazioni tecnologiche che ci
hanno spinto a sviluppare gli algoritmi qui presentati, in modo particolare
le nuove architetture parallele multi-core, mentre il capitolo 4 ` dedicato
e
ad un’ampia panoramica della letteratura allo stato dell’arte per quanto ri-
guarda gli algoritmi paralleli pi` famosi per la ricerca di regole associative e
u
di clustering, la maggior parte dei quali per sistemi a memoria distribuita,
dimostrazione del fatto che sono ancora pochi, o in stato embrionale, quelli
a memoria condivisa.
Nella seconda parte della tesi si presenta il lavoro effettivamente svolto,
dallo studio allo sviluppo ai test, per ottenere l’implementazione finale del
2

19. prototipo presentato con il nome di WekaSMP (Waikato Environment for
Knowledge Analysis on Shared Memory Processors). Nel capitolo 5 si stu-
diano formalmente gli algoritmi da sviluppare per stimarne la complessit`
a
temporale e gli incrementi di prestazioni mentre nel capitolo 6 si presen-
tano gli algoritmi, sviluppati in Java, includendo porzioni di pseudocodice
rappresentativi del codice sorgente delle funzioni pricipali sviluppate e de-
scrivendone il loro funzionamento. Gli algoritmi sviluppati vengono testati
su un computer composto da 2 processori quad-core, rilevati i tempi di ri-
sposta ed elaborati in indici e statistiche, presentate nel capitolo 7 sia in
forma tabellare che grafica. Il capitolo 8, in fine, contiene le conclusioni e
gli ultimi commenti sul lavoro.
L’ultima sezione ` dedicata alla stampa del codice sorgente delle funzioni
e
principali e di maggior interesse, elaborate in questo studio1 .
1
Tutti i diritti riservati. Marchi registrati e segni distintivi citati in questo elaborato
sono di propriet` dei rispettivi titolari, in particolare:
a
• Sun, Sun Microsystems, il logo Sun, Java, Java Virtual Machine, JavaServer Pages,
JavaScript, JDK, JRE, JSP, JVM, NetBeans, sono marchi o marchi registrati della
Sun Microsystems, Inc. negli Stati Uniti e in altri paesi.
• Intel, i386, i486, Pentium, Xeon e VTune sono marchi o marchi registrati della Intel
Corporation o delle sue sussidiarie negli Stati Uniti e in altri paesi.
• AMD, the AMD Arrow logo, 3DNow!, PowerNow!, Athlon, Opteron, logos and
combinations thereof, are trademarks of Advanced Micro Devices, Inc.
• Linux ` un marchio registrato di Linus Torvalds.
e
• Ubuntu e Canonical sono marchi registrati da Canonical Ltd.
3

20. 4

21. Parte I
Stato dell’arte
5

23. Capitolo 2
Data Mining
“Il segreto degli affari ` sapere qualcosa che nessun altro sa”
e
Aristotelis Sokratis Onassis (1906-1975), armatore e finanziere greco.
7

24. Il data mining o, come si preferisce chiamarlo di recente, la Knowledge
Discovery in Databases (KDD), ` una disciplina nata alla fine degli anni ’80.
e
Il motivo alla base dell’interesse per questa disciplina risiede nel fatto che
negli ultimi decenni la capacit` dell’uomo di generare e collezionare dati `
a e
incrementata notevolmente.
Nelle applicazioni reali spesso ` necessario estrarre dati da diversi dipar-
e
timenti. Per esempio in un’applicazione di marketing si pu` voler integrare
o
dati dall’ufficio vendite, dall’ufficio acquisti e dall’ufficio clienti ma ognuno
di essi probabilmente differisce nel modo di immagazzinare tali dati, oltre
che nelle convenzioni, stili, chiavi e regole. I dati devono essere assemblati,
integrati e puliti. Questa idea di ampia integrazione del database aziendale
` conosciuta come Data Warehousing [WF05]. Questa integrazione forni-
e
sce un unico punto di accesso ai dati aziendali ed essi verranno poi usati
per prendere decisioni di business, eventualmente integrati con dati esterni
(Overlay Data) che l’azienda non memorizza (ad esempio i dati meteo).
2.1 Regole Associative
Sia T l’insieme di transazioni, dove ognuna di esse ` un sottoinsieme dell’in-
e
sieme di articoli (item-set) I. Sia C un sottoinsieme di I allora si definisce
supporto di C rispetto a T
σ(C) = |{t|t ∈ T, C ⊆ t}|.
dove σ(C) ` il numero di transazioni che contengono C. Per esempio conside-
e
rare un insieme di transazioni di un supermercato come illustrato in tabella
2.1. L’insieme degli articoli I per questa transazione ` {Pane, Birra, Cola,
e
Tabella 2.1: Transazioni di un supermercato
TID Articoli
1 Pane, Cola, Latte
2 Birra, Pane
3 Birra, Cola, Pannolini, Latte
4 Birra, Pane, Pannolini, Latte
5 Cola, Pannolini, Latte
Pannolini, Latte} mentre il supporto di {Pannolini, Latte} ` σ(Pannolini,
e
8

25. Latte) = 3 ed il supporto di {Pannolini, Latte, Birra} ` σ(Pannolini, Latte,
e
Birra) = 2.
s,α
Una regola associativa ` un’espressione della forma X ⇒ Y , dove X ⊆ I
e
s,α
e Y ⊆ I. Il supporto s della regola X ⇒ Y ` definito come σ(X ∪ Y )/|T | e la
e
confidenza α ` definita come σ(X ∪ Y )/σ(X). Per esempio considerando la
e
regola {Pannolini, Latte} ⇒ {Birra}, la presenza di pannolini e latte nella
transazione tendono ad indicare, nella stessa transazione, la presenza di bir-
ra. Il supporto di questa transazione ` σ(P annolini, Latte, Birra)/5 = 40%
e
mentre la confidenza ` σ(P annolini, Latte, Birra)/σ(P annolini, Latte) =
e
66%. Ovviamente regole con alta confidenza sono molto importanti poi-
ch` forniscono spesso un’accurata previsione sull’associazione degli articoli
e
nella regola. Anche il supporto di una regola ` fondamentale, considera-
e
to che indica quanto frequente ` la regola in una transazione. Regole con
e
basso supporto non sono significative, motivo per cui alcuni algoritmi (tra
i quali Apriori) [AS94] tralasciano le regole che non soddisfino una condi-
zione di supporto minimo per ridurre le associazioni derivate, considerato
che il numero di regole possibili ` proporzionale al numero di sottoinsiemi
e
dell’insieme I degli articoli, come 2|I| .
La scoperta di regole associative consiste nel trovare tutte le regole
s,α
X ⇒ Y tali che s soddisfi una soglia di supporto minimo e α soddisfi una
soglia di confidenza minima. Questo processo ` suddiviso in due parti:
e
1. scoprire tutti i sottoinsiemi frequenti (insiemi candidati che hanno
supporto minimo superiore alla soglia stabilita);
2. generare le regole associative da questi sottoinsiemi.
La fase computazionalmente pi` costosa ` la prima e numerosi sono gli
u e
algoritmi sviluppati per risolverla, tra i quali uno dei pi` conosciuti ` Apriori.
u e
2.1.1 Algoritmo Apriori
L’algoritmo Apriori ` stato proposto nel 1994 da Rakesh Agrawal [AS94]. In
e
figura 2.1 sono riassunti i passi principali. Inizialmente L1 contiene tutti gli
oggetti (sottoinsiemi di dimensione 1) che soddisfano il supporto minimo: il
primo passo infatti conta semplicemente le occorrenze di ogni articolo nel
database ed elimina in L1 quelle che non soddisfano il supporto minimo. Il
9

26. Figura 2.1: Algoritmo Apriori [AS94]
passo successivo, detto k, consiste di due fasi: nella prima l’insieme frequente
Lk−1 , trovato al passo (k-1), viene usato per trovare l’insieme candidato Ck ,
usando la funzione apriori gen, descritta sotto. La seconda fase consiste nel
contare le occorrenze dei candidati in Ck nel database di transazioni per
trovarne il supporto. Infine, dall’insieme dei candidati Ck si eliminano le
occorrenze che non soddisfano il supporto minimo per trovare l’insieme dei
frequenti Lk . L’unione di tutti questi insiemi ` il risultato finale.
e
Per generare gli insiemi candidati, la funzione apriori gen richiede in
ingresso l’insieme degli articoli frequenti al passo (k-1). In uscita si ha un
superinsieme contenente gli oggetti frequenti di lunghezza k. La funzione si
divide in due fasi. Nella prima fase (join) si moltiplica per se stesso l’insieme
Lk−1 , ottenendo l’insieme candidato Ck , vedi figura 2.2 Nella seconda fase
Figura 2.2: Algoritmo Apriori, funzione apriori gen [AS94]
(prune), vedi figura 2.3, si eliminano tutte le occorrenze c ∈ Ck tali che qual-
´
siasi loro sottoinsieme di dimensione (k-1) non sia in Lk−1 . E importante
notare gi` a questo punto come l’operazione pi` pesante di tutto l’algorit-
a u
mo sia il conteggio dei supporti. L’algoritmo parallelo Count Distribution
10

27. Figura 2.3: Algoritmo Apriori, eliminzione dei non frequenti (prune) [AS94]
(vedi paragrafo 4.1.1) si propone proprio di suddividere tra i processori que-
sto compito. Un primo approccio naive per il contenggio dei supporti ` il
e
classico string-matching di ogni insieme di articoli nell’insieme dei candidati
nell’insieme delle transazioni ma trie [Bod03] ed hash tree [HKK97], usati
anche in Weka, garantiscono performance molto pi` veloci,
u
Hash Tree
La figura 2.4 mostra un esempio di hash tree contenente l’insieme candidato
di dimensione 3. I nodi interni hanno hash tables contenenti link ai nodi
figli, i nodi foglia contengono gli insiemi candidati.
La costruzione di un hash tree avviene come segue. Inizialmente l’hash
tree contiene solo il nodo root, che ` anche il nodo foglia ma che non con-
e
tiene insiemi candidati. Quando un insieme candidato viene generato, gli
oggetti dell’insieme vengono memorizzati in modo ordinato, cosa che per-
metter` una maggiore efficienza nel generare sia l’insieme dei frequenti che
a
il successivo insieme candidato. Ogni insieme candidato viene inserito nel-
l’albero codificando ogni oggetto successivo nei nodi interni e seguendo i
collegamenti delle tabelle hash. Quando si raggiunge una foglia l’insieme
candidato viene inserito come foglia anch’esso se il numero di foglie ` mi-
e
nore del massimo consentito, altrimenti il nodo foglia viene convertito in
nodo interno e vengono creati nodi figli per il nuovo nodo. Gli insiemi can-
didati vengono distribuiti nei nodi foglia secondo i valori hash degli oggetti
contenuti. Nell’esempio di figura 2.4, l’insieme candidato {1 2 4} ` inserito
e
codificando l’oggetto 1 nel nodo root per raggiungere il figlio sinistro; co-
dificando l’oggetto 2 su quel nodo si raggiunge il figlio centrale ed infine
codificando l’oggetto 4 si raggiunge il figlio sinistro, che ` una foglia.
e
L’operazione di subset attraversa l’albero a partire dalla radice e con
ogni oggetto di una transazione come possibile oggetto iniziale del candida-
11

28. Figura 2.4: Inserimento di candidati dalla radice dell’hash tree [HKK97]
to. Nel livello successivo, tutti gli oggetti che seguono quello iniziale della
transazione vengono codificati nella funzione hash. Questo ` fatto ricorsiva-
e
mente fino a che viene raggiunta una foglia. A questo punto tutti i candidati
inseriti nelle foglie vengono confrontati con la transazione ed i loro contatori
vengono aggiornati. Nell’esempio di figura 2.4 l’operazione viene effettuata
a partire dalla radice con la transazione {1 2 3 5 6}. L’oggetto 1 ` codifica-
e
to verso il figlio sinistro della radice e la transazione rimanente {2 3 5 6} `
e
applicata ricorsivamente a questo nodo. L’oggetto 2 ` codificato come figlio
e
centrale del nodo e cos` via, secondo la funzione di hash specifica.
ı
12

29. Figura 2.5: Inserimento di candidati dal sottoalbero sinistro dell’hash tree
[HKK97]
La figura 2.5 mostra la stessa operazione effettuata in precedenza, sul
sottoalbero sinistro. I figli 2 e 5 vengono codificati nei figli centrali del nodo
e quindi le rimanenti transazioni {3 5 6} e {6} vengono applicate ricorsiva-
mente a questo nodo centrale. L’oggetto 3, invece viene mappato nel figlio
destro del nodo e la rimanente transazione {5 6} ` applicata ricorsivamente
e
a questo figlio destro.
2.2 Clustering
Si definisce clustering il processo di partizionamento o raggruppamento di un
dato insieme di oggetti in sottoinsiemi disgiunti. Tutti gli oggetti apparte-
nenti allo stesso cluster avranno caratteristiche simili tra loro e il pi` diverse
u
possibile rispetto agli oggetti appartenenti alle altre partizioni (massimizzare
la similiarit` intra-cluster e minimizzare la similiarit` inter-cluster).
a a
Questo tipo di algoritmi ` usato spesso in applicazioni nei pi` svariati
e u
13

30. campi, dalla visualizzazione al pattern recognition, dalle applicazioni grafi-
che alle reti neurali passando per intelligenza artificiale e statistica. Appli-
cazioni pratiche comprendono anche classificazione unsupervised e genera-
zione di tassonomie, ricerche nearest neighbor, analisi time series, analisi e
navigazione di testi [Jos03].
La clusterizzazione di dati ` un ramo importante del Data Mining e molti
e
sono gli algoritmi che si occupano di questa scienza. Essi sono suddivisi in 2
categorie: algoritmi gerarchici (in figura 2.6 un esempio di rappresentazione
a dendrogramma) ed algoritmi partizionali (vedi esempio di figura 2.7). I
primi creano una decomposizione gerarchica del dataset in oggetto formando
un albero che divide ricorsivamente i dati in sottoalberi pi` piccoli; i secondi,
u
invece, creano un’unica partizione dei dati in insiemi disgiunti.
Figura 2.6: Esempio di clusterizzazione gerarchica a dendrogramma
14

31. Figura 2.7: Esempio di clusterizzazione partizionale
2.2.1 Algoritmo K-Means
K-means appartiene alla classe degli algoritmi di partizione non gerarchica.
Il suo obiettivo ` quello di trovare una partizione in k cluster di n oggetti
e
spaziali che minimizzi le differenze tra gli oggetti appartenenti alla stessa
classe e massimizzi le differenze tra gli oggetti di cluster diversi. Pi` formal-
u
mente, supporre di avere un insieme di n dati spaziali X1 , X2 , · · · , Xn tale
che ogni dato ` in Rd . La ricerca dei cluster con varianza minima di questo
e
insieme in k cluster ` definita come la ricerca di k punti {mj }k in Rd tale
e j=1
che
n
1
minj d2 (Xi , mj ) (2.1)
n
i=1
sia minimizzata, dove d(Xi , mj ) ` la distanza Euclidea tra Xi e mj . I punti
e
{mj }k sono i centroidi dei cluster. In modo equivalente si pu` dire che
j=1 o
l’obiettivo ` quello di minimizzare la varianza intra-cluster e massimizzare
e
quella inter-cluster
k
V ar = (Xi − mj )2 (2.2)
j=1 xi ∈Sj
dove k ` il numero di cluster raggruppati nell’insieme Sj , j = 1, 2, . . . , k e
e
mj sono i centroido dei punti xi ∈ Sj .
Informalmente il problema in 2.1 e 2.2 ` quello di ricercare k centroidi
e
dei cluster tali che minimizzino il quadrato della distanza Euclidea (cono-
sciuto anche come mean squared error, MSE ) tra ogni punto nello spazio e il
suo centroide pi` vicino. Sfortunatamente questo problema ` NP-completo
u e
[MRGW82].
Il classico algoritmo K-Means [Har75] fornisce una soluzione approssima-
ta, semplice da implementare, scalabile e veloce, che utilizza una euristica
15

32. Tabella 2.2: Simboli utilizzati per lo studio di K-Means
Simbolo Definizione
n numero transazioni
k numero di clusters
d dimensione del dominio (numero attributi)
P numero processi
numero di iterazioni di K-Means
iterativa di affinamento conosciuta come algoritmo di Lloyd’s, riassumibile
in 4 punti:
1. Inizializzazione: Seleziona un insieme di k punti di partenza {mj }k
j=1
in Rd come centroidi. La selezione pu` essere effettuata in modo
o
casuale o seguendo qualche euristica.
2. Calcolo della distanza: Per ogni punto Xi , 1 ≤ i ≤ n, calcola la sua
distanza Euclidea con ogni centroide mj , 1 ≤ j ≤ k e trova i centroidi
che minimizzano la 2.1.
3. Ricalcolo Centroidi: Per ogni 1 ≤ j ≤ k ricalcola i centroidi mj
come media dei punti assegnati ad essi.
4. Condizione di Convergenza Ripeti i passi 2 e 3 fino alla conver-
genza (M SE non cambia).
Questo algoritmo pu` essere considerato come una procedura a gradiente di-
o
scendente che comincia con dei centroidi casuali e li aggiorna iterativamente
ad ogni passo per minimizzare la funzione obiettivo 2.1. Tuttavia si sa che
K-Means converger` sempre in un minimo locale [BB95] che dipender` dai
a a
centroidi scelti all’inizio. Prima della convergenza, i passi 2 e 3 dovranno
essere ripetuti volte, valore non predicibile e dipendente anch’esso dai cen-
troidi iniziali. L’intero positivo ` detto numero di iterazioni di K-Means,
e
mentre un esempio di algoritmo ` presentato in figura 2.8.
e
In figura 2.9 si pu` intuire facilmente come opera l’algoritmo: si comin-
o
cia scegliendo casulamente dei centroidi (a); ogni punto verr` associato al
a
centroide pi` vicino (b) e successivamente si ricalcolano i centroidi relativa-
u
mente ad ogni cluster (c). I passi (b) e (c) si ripetono iterativamente fino
alla convergenza (i centroidi rimangono identici in due successive iterazioni).
16

33. Figura 2.8: Algoritmo K-Means sequenziale [DM00]
L’algoritmo K-Means ` conosciuto per la sua semplicit` di realizzazio-
e a
ne e per i buoni risultati che riesce a fornire tuttavia richiede un tempo
di computazione proporzionale al prodotto numero di oggetti e numero di
cluster per iterazione, tempo molto alto per database di grandi dimensio-
ni. Analizzando la complessit` computazionale si rileva che ogni iterazione
a
dell’algoritmo ` costante, composta dal calcolo delle distanze, e ricalcolo dei
e
centroidi. In particolare il calcolo delle distanze ` l’operazione pi` pesan-
e u
te e richiede (3nkd + nk + nd) operazioni in virgola mobile per iterazione
dove 3nkd si riferisce al calcolo delle distanze euclidee, nk alla ricerca del
centroide del cluster mentre n, k e d sono rispettivamente la cardinalit`
a
del database, il numero di cluster e il numero di dimensioni del dominio (il
numero di attributi). Anche il ricalcolo dei centroidi richiede approssima-
tivamente kd istruzioni floating point. Combinando le relazioni precedenti
17

34. Figura 2.9: Esempio di clusterizzazione di punti spaziali
possiamo ricavare la complessit` computazionale dell’algoritmo seriale come
a
O(3nkd + nk + nd + kd) · (2.3)
che pu` essere ridotto alla seguente relazione nel caso in cui il n >> k, d:
o
O(3nkd) · (2.4)
2.3 Weka
Il progetto Weka (Waikato Environment for Knowledge Analysis [wek]) `
e
una collezione di algoritmi autoapprendenti (machine learning) allo stato
18

35. dell’arte e di strumenti di analisi dei dati. Esso fornisce strumenti per l’in-
tero processo di “data mining” dalla preparazione dei dati in input alla
valutazione dei dati in output, anche in forma visuale, per verificare il risul-
tato della fase di learning, attraverso un’interfaccia grafica. Esso ` capace
e
di unire alla semplicit` della sua interfaccia un background potente ed af-
a
fidabile, cos` da fornire agli utenti uno strumento flessibile per lo sviluppo
ı
e l’utilizzo di tecniche machine learning per l’estrazione di conoscenze da
grossi database, impossibili da analizzare a mano.
Il sistema ` sviluppato in Java, linguaggio di programmazione orienta-
e
to agli oggetti disponibile per molte piattaforme, da Windows a Linux e
Macintosh e distribuito con licenza GNU General Public License [gnu], che
ci permette di scaricare, modificare e redistribuire il codice senza scopo di
lucro ed ` testato in Windows, Linux e Macintosh. Gli utenti di Weka non
e
sono solo ricercatori o professionisti, ma anche studenti per l’apprendimento
delle tecniche di Data Mining. Il suo utilizzo ` adatto a pi` livelli: forni-
e u
sce l’implementazione degli algoritmi allo stato dell’arte per questa scienza,
consentendo a chiunque di applicarli sul proprio database; in aggiunta sono
disponibili una grande variet` di procedure per la trasformazione dei dati
a
in input o l’analisi dei risultati degli algoritmi. Come tutti i pacchetti open
source Weka non solo consente di visionare, modificare e distribuire i sorgen-
ti ma mette anche a disposizone delle procedure che aiutano nello sviluppo
di nuovi metodi: ` possibile infatti, grazie all’uso delle interfacce comuni
e
sviluppare i propri algoritmi di associazione, clustering o associazione senza
doversi preoccupare di alcuni dettagli secondari, come per esempio leggere o
scrivere dal database, implementare filtri o tool di valutazione dei risultati;
Weka fornisce gi` tutte queste utilit`, oltre ad una nutrita documentazione
a a
online, cartacea e Javadoc.
Tutti gli algoritmi richiedono in input una tabella relazionale come in fi-
gura 2.10 nel formato ARFF (Attribute-Relational File Format, vedi [WF05],
che pu` esser generata da un file o da una query.
o
Un ultimo utilizzo di Weka consiste nell’applicare un metodo autoappren-
dente ad una serie di dati, utilizzando alcuni algoritmi di classificazione. Per
saperne di pi` si pu` visitare e scaricare Weka dal sito dell’universit` neo-
u o a
zelandese di Waikato [wek] mentre il libro di Witten e Frank [WF05] dedica
un intero capitolo a questo tool, alle sue caratteristiche e come sfruttarne a
19

36. Figura 2.10: Esempio di database in formato ARFF
pieno le potenzialit`.
a
Il nucleo centrale del progetto ` il package weka.core; qui vi sono definiti
e
i metodi per l’elaborazione primaria dei dati, a cominciare dalla lettura degli
oggetti nel database. Le classi principali in questo package sono Attribute,
Instance e Instances. Un oggetto della classe Attribute rappresenta un
attributo (identificato da nome, tipo e valore) ed il numero di istanze `
e
pari al numero di colonne del database. Un oggetto della classe Instance
contiene il valore dell’attributo di una particolare istanza; un insieme di
queste istanze (il dataset) ` rappresentato da un oggetto di tipo Instances.
e
2.3.1 Algoritmo Apriori
Weka include l’algoritmo Apriori per generare regole associative nella clas-
se weka.association.Apriori. Per testare l’algoritmo si pu` utilizzare
o
20

37. opzione funzione
-t <training file> Specifica il file di training
-N <numero di regole richieste> Specifica il numero di regole
richieste
-C <confidenza minima di una regola> Specifica la confidenza minima
di una regola
-D <delta per supporto minimo> Specifica il delta per decrescere
il supporto minimo
-M <limite minimo del supporto> Specifica il limite minimo
richiesto dal supporto
Tabella 2.3: Principali opzioni per l’algoritmo Apriori su Weka
l’interfaccia grafica o da terminale digitanto il comando
java weka.association.Apriori -t <<training file>>.arff
dove training file ` il nome del file contenente il database in formato
e
arff (Weka ne propone alcuni famosi in letteratura) con attributi nominali
(Apriori non pu` elaborare attributi numerici). L’output di questo comando
o
` rappresentato in figura 2.11.
e
Weka tenta di generare almeno 10 regole che rispettino il supporto mi-
nimo del 100%, decrescendo del 5% finch` non ci riesce o finch` raggiunge
e e
il 10%. La confidenza minima ` settata al 90%. Nell’esempio in figura il
e
supporto decresce fino al 20% prima di riuscire a generare le 10 regole e ci`
o
richiede 10 passaggi ma tutti questi parametri sono modificabili da parte
dell’utente con le opzioni di tabella 2.3.1.
La regole generate vengono rappresentate nella seconda parte dell’output
dell’algoritmo, numerate da 1 a 10. Il numero che precede il simbolo ==>
indica il supporto della regola, cio` il numero di insiemi di oggetti di quel
e
tipo trovati nel database. In modo analogo il numero nella conseguenza
della regola rappresenta quante volte questa regola ` verificata nel database
e
mentre tra parentesi c’` la confidenza della regola stessa.
e
Al di sopra delle regole si trovano il numero di insiemi trovati per ogni
lunghezza considerata; nell’esempio 6 insiemi di lunghezza 4, 39 di lunghezza
3, e cos` via.
ı
21

38. Figura 2.11: Output dell’algoritmo Apriori su Weka
2.3.2 Algoritmo K-Means
Nel package weka.clusterers sono presenti alcuni degli algoritmi di clu-
stering pi` conosciuti, tra i quali Cobweb, DBScan, EM e, naturalmente,
u
K-Means. Per il suo utilizzo si pu` utilizzare l’interfaccia grafica oppure il
o
22

39. opzione funzione
-t <training file> Specifica il file di training
-T <test file> Specifica il file di test
-x <numero di cicli> Specifica il numero di cicli per il cross-validation
-s <seme> Specifica il seme per i numero pseudo casuali
-l <file input> Specifica il file in input come modello
-d <file output> Specifica il file in output per il modello
-p Trova solo le previsioni in output
Tabella 2.4: Principali opzioni per l’algoritmo K-Means su Weka
comando
java weka.clusterers.SimpleKMeans -t <<training file>>.arff
dove training file ` il nome del file contenente il database in formato
e
arff con attributi numerici (K-Means non pu` elaborare attributi nominali),
o
eventualmente integrato con le opzioni di tabella 2.3.2. La bont` dell’output
a
` verificata con una funzione di verosimiglianza.
e
L’output di questo comando ` rappresentato in figura 2.12. Si possono
e
notare i cluster trovati, quante istanze sono state assegnate ad ognuno di
essi e statistiche dettagliate su media e la varianza dei dati.
Esistono 4 modi differenti affinch` Weka elabori i cluster, a scelta dell’u-
e
tente:
• Use training set: dopo aver generato i cluster, Weka classifica le istanze
di training nei cluster trovati e calcola la percentuale di istanze che
cadono in ogni cluster.
• Supplied test set e Percentage split: Weka clusterizza su un database
separato se la rappresentazione ` probabilistica (come in EM)
e
• Classes to clusters: in questa modalit` Weka ignora le classi degli
a
attributi e genera il cluster. Durante la fase di test assegna le classi
ai cluster, basando sul valore pi` grande degli attributi in ogni cluster
u
poi calcola l’errore di classificazione.
23

40. Figura 2.12: Output dell’algoritmo K-Means su Weka
Nell’esempio di figura 2.12 K-Means ha clusterizzato il dataset iris (vedi
dettagli nel capitolo 7) in 3 cluster, ognuno dei quali contenente 50 istanze.
Per ogni attributo viene calcolata la media e la deviazione standard.
24

41. Capitolo 3
Architetture e
Programmazione Parallela
“C’` vero progresso solo quando i vantaggi di una nuova tecnologia
e
diventano per tutti.”
Henry Ford (1863-1947), industriale americano.
25

42. 3.1 Definizioni
Uno dei principali metodi per aumentare le prestazioni di un sistema d’e-
laborazione dati, ` quello di aumentare il numero di processori che questo
e
prevede, distribuendo fra di essi il carico computazionale. Originariamente
questo problema ` stato affrontato in due modi diversi, che hanno portato
e
allo sviluppo di tecniche per la gestione di sistemi paralleli e sistemi di-
stribuiti. Un sistema parallelo ` un sistema in cui si hanno vari processori
e
strettamente collegati tra di loro e che condividono la maggior parte delle
risorse presenti. Un sistema distribuito ` invece un sistema in cui si hanno
e
varie unit` elaborative, indipendenti tra di loro ma collegate tramite una
a
qualche rete.
L’idea base dei computer paralleli, quindi, ` che diversi processori pos-
e
sano cooperare nella soluzione di un singolo problema. Il motivo che spinge
ad occuparsi di calcolo parallelo ` proprio il tentativo di velocizzare il calco-
e
lo della soluzione dei problemi computazionali. Intuitivamente si potrebbe
pensare che, se un processore impiega un tempo t per eseguire un compito,
allora n processori possono ultimare lo stesso in un tempo t/n. In realt`
a
soltanto in casi molto particolari questo incremento di velocita pu` essere
o
raggiunto e comunque ` compito del programmatore progettare l’algoritmo
e
in modo da ottenere il massimo beneficio da architetture multi processore.
Definiamo allora lo speedup come
tserial
S=
tparallel
rapporto tra il tempo di esecuzione seriale e parallelo; il valore ottentuto `
e
indice della bont` della parallelizzazione ottenuta, migliore quanto pi` vicino
a u
ad n, numero di processori. L’efficienza, invece, ` il rapporto tra speedup
e
parallelo e numero di processori
S
E=
n
e da una stima di quanto stiamo sfruttando il potenziale offerto dalla pa-
rallelizzazione. In pratica un’efficienza pari a 1, significa una riduzione dei
tempi di risposta dell’algoritmo parallelo di un fattore n.
Amdahl indic` il limite presente nello Speedup teorico, cio` nell’aumento
o e
26

43. di prestazioni dovuto al parallelismo, come:
1
S≤ .
α + (1 − α)/n
dove α ` la quota di codice non parallelizzabile e (1-α) ` parallelizzabile su
e e
n processori per cui, aumentando il numero n di processori, la percentuale α
di codice sequenziale ridurrebbe di molto l’aumento effetivo dello speedup.
Se ad esempio α = 0, 5, lo speedup massimo raggiungibile ` 2 anche con
e
1000 processori.
3.2 Architetture
Figura 3.1: Tassonomia di Flynn
La pi` famosa classificazione (tassonomia) delle architetture per i sistemi
u
paralleli ` quella proposta da Flynn in figura 3.1. Secondo questa tassonomia
e
le due pi` importanti caratteristiche di un elaboratore sono il numero di flussi
u
di istruzioni che esso pu` processare ad ogni istante ed il numero di flussi
o
di dati su cui esso pu` operare simultaneamente. Combinando queste due
o
caratteristiche ` possibile ottenere le seguenti quattro classi architetturali,
e
alle quali se ne aggregano altre due pi` recenti:
u
• SISD (Single Instruction stream - Single Data stream)
• SIMD (Single Instruction stream - Multiple Data stream)
27

44. • MISD (Multiple Instruction stream - Single Data stream)
• MIMD (Multiple Instruction stream - Multiple Data stream)
• SPMD (Single Program stream - Multiple Data stream)
• MPMD (Multiple Program stream - Multiple Data stream)
Figura 3.2: Architettura SIMD
La classe SISD, in figura 3.2, comprende l’architettura tradizionale di
Von Neumann che ` quella usata da tutti i calcolatori convenzionali, in cui
e
il singolo processore obbedisce ad un singolo flusso di istruzioni (programma
sequenziale) ed esegue queste istruzioni ogni volta su un singolo flusso di dati.
Figura 3.3: Architettura SIMD
Alla classe SIMD appartengono le architetture composte da molte unit`
a
di elaborazione che eseguono contemporaneamente la stessa istruzione ma
lavorano su insiemi di dati diversi. In genere, il modo di implementare le
architetture SIMD ` quello di avere un processore principale che invia le
e
istruzioni da eseguire contemporaneamente ad un insieme di elementi di
elaborazione che provvedono ad eseguirle. I sistemi SIMD sono utilizza-
ti principalmente per computazioni specializzate in parallelo, grafica CAD,
28

45. grafica vettoriale. Prima Intel con SSE poi AMD con 3DNow! hanno ag-
giunto estensioni SIMD ai propri processori, via via sempre pi` sofisticate
u
tanto che i pi` moderni processori di entrambe le case utilizzano l’ultima
u
versione denominata SSE3. La classe MISD (in figura 3.4), in cui pi` flussi
u
Figura 3.4: Architettura MISD
di istruzioni (processi) lavorano contemporaneamente su un unico flusso di
`
dati, non ` stata finora utilizzata praticamente. E da notare che, mentre nel-
e
la classe SIMD la granularit`, ovvero la dimensione delle attivit` eseguibili
a a
in parallelo, ` quella delle istruzioni, nella classe MISD e in quella MIMD la
e
granularit` ` quella dei processi, programmi composti da pi` istruzioni.
ae u
Figura 3.5: Architettura MIMD
Il modello rappresentato dalla classe MIMD di figura 3.5, in cui pi` pro-
u
29

46. cessi sono in esecuzione contemporaneamente su pi` processori ed utilizzano
u
dati propri o condivisi, rappresenta un’evoluzione della classe SISD. Infatti,
la realizzazione di queste architetture avviene attraverso l’interconnessione
di un numero elevato di elaboratori di tipo convenzionale. I sistemi con ar-
chitettura MIMD sono oggi fra quelli pi` studiati e si pu` presumere che essi
u o
rappresentino il punto di partenza per la costruzione di macchine parallele
di tipo general-purpose.
Spesso il modello SPMD utilizza il message passing tra i diversi nodi
di elaborazione ed ` supportato da specifiche librerie MPI Message Passing
e
Interface. Un solo programma con costrutti di controllo che scelgono parti
differenti del programma a seconda del nodo su cui viene lanciato. Questa
sar` l’architettura obbligata per la parallelizzazione degli algoritmi in Weka,
a
oggetto della tesi: un solo programma lanciato in parallelo su pi` proces-
u
sori a memoria condivisa che elaborano flussi di dati differenti. Il modello
MPMD ha i singoli nodi che eseguono programmi differenti (tipicamente
master/slave).
Figura 3.6: Esempio di architettura quad core: AMD opteron [amd]
Un’altra importante differenza nei computer paralleli riguarda il modello
di memoria utilizzato. Esso pu` essere di tipo condiviso (Shared Memory)
o
o distribuito (Distributed Memory). Un sistema a memoria condivisa ` mo-
e
strato in Fig 3.6. Qui, tutti i processori hanno accesso ad una memoria
comune. Ciascun processore pu` anche avere una propria memoria locale
o
30

47. per il codice del programma e dati temporanei, mentre la memoria comune
` utilizzata per dati e risultati necessari a pi` processori. Nel caso di AMD
e u
Opteron, nella foto, ogni core ha a disposizione memoria cache L1 ed L2
privata ed L3 da ben 2MB condivisa tra i 4 core all’interno del package;
a queste si aggiunge la memoria RAM, ovviamente condivisa e gestita dal-
lo stesso controller. Tutte le comunicazioni tra i processori sono compiute
attraverso la memoria comune. Il pi` grande vantaggio dei sistemi a me-
u
moria condivisa ` l’alta velocit` delle comunicazione tra processori, mentre
e a
il grande svantaggio ` che processori diversi possono desiderare di utilizza-
e
re la memoria comune nello stesso istante. In tal caso uno dei processori
deve attendere che sia liberata la memoria al fine di evitare conflitti (un
processore potrebbe alterare il dato proprio mentre l’altro li sta leggendo).
Questo ritardo pu` crescere al crescere del numero di processori. In genere
o
la memoria condivisa viene usata su sistemi con un numero di processori
basso.
3.3 Gestione della memoria
La gestione della memoria, nei sistemi a memoria condivisa non si discosta
di molto da come avviene nel caso di un sistema monoprocessore ma bisogna
porre particolare attenzione alla modalit` di accesso se si vogliono ottenere
a
consistenza e prestazioni. Alcune delle metodologie utilizzate per risolvere
questo problema sono:
• Condivisione. La richiesta di accesso in lettura pu` avvenire parallela-
o
mente per tutti i processi mentre in modo sequenziale se l’operazione `
e
di scrittura. In questo caso saranno necessari dei meccanismi di mutua
esclusione, per evitare la lettura di dati sporchi, che ne rallenteranno
le prestazioni
• Replicazione. Con questo sistema una stessa struttura dati pu` essere
o
presente contemporaneamente sullo stesso spazio di memoria associato
a processi diversi, disponibile sia in lettura che in scrittura. Dovendo
garantire la consistenza tra le varie copie richiede la presenza di op-
portuni algoritmi per la sua implementazione, simili a quelli che si uti-
lizzano per la realizzazione della consistenza delle cache nei processori
31

48. ed operazioni di riduzione per giungere al risultato finale dall’insieme
di risultati parziali ottenuti parallelamente
Dal punto di vista architetturale i sistemi multiprocessore possono esse-
re caratterizzati in base all’accoppiamento tra la memoria e i processori.
Nei sistemi multiprocessore a memoria condivisa, la memoria presente `
e
accessibile dai vari processori. Questi sistemi possono essere a loro volta
caratterizzati in base ai tempi di accesso alla memoria stessa.
• UMA (Uniform Memory Access): sistemi multiprocessore a tempi di
accesso uniforme per la memoria nei quali i tempi di accesso alla me-
moria sono uguali per tutti i processori. Questa architettura pu` esse-
o
re realizzata semplicemente collegando i vari processori e la memoria
presente nel sistema tramite un unico bus.
Figura 3.7: Esempio di architettura della memoria UMA
• NUMA (Non-Uniform Memory Access): sistemi multiprocessore a
tempi di accesso non uniforme per la memoria, i tempi di accesso a
ciascun elemento di memoria variano a seconda del processore. In que-
sta architettura ogni processore ha la sua memoria locale alla quale `
e
collegato direttamente. Per consentire l’accesso alla memoria apparte-
nente ad un altro processore, vi sar` un qualche collegamento, formato
a
ad esempio da un insieme di bus che unir` tra di loro i vari moduli
a
di memoria. Il tempo di accesso alla memoria di un altro processore
risulter` quindi essere maggiore di quello relativo alla memoria locale,
a
e varier` a seconda della distanza alla quale questa si trova. Sono si-
a
stemi che in termini di scalabilit` pongono meno problemi degli UMA.
a
32

49. Figura 3.8: Esempio di architettura della memoria NUMA
• NORMA (NO Remote Memory Access): sistemi multiprocessore sen-
za memoria condivisa, ogni processore ha la sua memoria locale, che
non pu` essere direttamente acceduta dagli altri. La comunicazione
o
avviene in questo caso tramite l’invio di messaggi su una qualche rete,
la cui topologia varia a seconda dei casi. Sono i pi` facili da realizza-
u
re, ma richiedono opportune tecniche per ottenere un elevato grado di
parallelismo senza avere effetti negativi sulle prestazioni.
3.3.1 Memoria Cache
La memoria cache ` un tipo di memoria piccola, ma molto veloce, che man-
e
tiene copie dei dati ai quali si fa pi` frequentemente accesso in memoria
u
principale. Finch´ la maggior parte degli accessi alla memoria avviene su
e
dati caricati nella cache, la latenza media dell’accesso alla memoria sar`
a
pi` vicina alla latenza della cache piuttosto che a quella della memoria
u
principale.
Ogni locazione di memoria ha un dato (una linea di cache) e un indice,
cio` un identificatore univoco utilizzato per riferirsi a quella specifica loca-
e
zione. L’indice di una locazione in memoria principale ` chiamato indirizzo
e
di memoria. Ogni locazione nella cache ha un’etichetta che contiene l’indice
in memoria principale del dato ivi caricato. Nelle cache dati, questi valori
sono chiamati blocchi di cache o linee di cache.
Quando il processore vuole leggere o scrivere in una data locazione in
memoria principale, inizialmente controlla se il contenuto di questa loca-
zione ` caricato in cache. Questa operazione viene effettuata confrontando
e
l’indirizzo della locazione di memoria con tutte le etichette nella cache che
33

50. potrebbero contenere quell’indirizzo. Se il processore trova che la locazione
di memoria ` in cache, si parla di cache hit (accesso avvenuto con successo),
e
altrimenti di cache miss (fallimento d’accesso). Nel caso di un cache hit,
il processore legge o scrive immediatamente il dato sulla linea di cache. Il
rapporto tra cache hit e accessi totali ` chiamato anche hit rate ed ` una
e e
misura dell’efficacia della cache stessa.
Nel caso di un cache miss, la maggior parte delle cache crea una nuova
entit`, che comprende l’etichetta appena richiesta dal processore ed una
a
copia del dato dalla memoria. Un fallimento del genere ` relativamente
e
lento, in quanto richiede il trasferimento del dato dalla memoria principale,
il cui tempo di risposta ` molto maggiore di quello della memoria cache.
e
Per poter fare spazio a nuovi dati nel caso di un cache miss, la cache
generalmente deve eliminare il contenuto di una delle linee. L’euristica che
utilizza per scegliere quale dato eliminare ` chiamata politica di rimpiazza-
e
mento. Il problema fondamentale di ogni politica di rimpiazzamento ` quello
e
di dover predire il dato della cache che verr` richiesto nel futuro con minor
a
probabilit`. Predire il futuro ` difficile, soprattutto per le cache hardware
a e
che devono sfruttare regole facilmente implementabili in circuiteria, perci`
o
esistono una serie di politiche di rimpiazzamento e nessuna di esse pu` es-
o
sere ritenuta perfetta. Una delle pi` popolari, la LRU (dall’inglese Least
u
Recently Used, cio` usato meno recentemente), rimpiazza, appunto, il dato
e
al quale si ` fatto accesso meno recentemente.
e
I dati in memoria principale, dei quali esiste una copia nella cache, po-
trebbero essere modificati da altre cause (evento non improbabile, ad esem-
pio, in un sistema multiprocessore), perci` i dati nella cache potrebbero
o
diventare obsoleti. I protocolli di comunicazione tra i sistemi di gestione
delle cache che conservano la consistenza dei dati sono chiamati protocolli
di coerenza.
Cache Miss
Con cache miss (fallimento della cache) ci si riferisce ad un intento fallito
nel leggere o scrivere un pezzo di dati nella cache, che ha come risultato
una latenza molto pi` lunga nell’accesso alla memoria principale. Per un
u
fallimento nella lettura dalla cache istruzioni, il processore deve aspettare
(stallo) finch´ l’istruzione non ` caricata dalla memoria principale. Un fal-
e e
34

51. limento della cache causato dal caricamento di un dato pu` invece essere
o
meno doloroso, perch´ le altre istruzioni non correlate ad esso possono co-
e
munque essere eseguite, finch´ l’operazione che richiede i dati da caricare
e
pu` essere eseguita. Comunque, i dati sono spesso usati immediatamente
o
dopo l’istruzione di caricamento. L’ultimo caso di cache miss, cio` un fal-
e
limento in scrittura, ` il meno preoccupante, perch´ di solito la scrittura `
e e e
bufferizzata. Il processore pu` continuare tranquillamente finch´ il buffer
o e
non ` pieno. (Non esiste un fallimento nella scrittura della cache istruzioni
e
perch´ esse sono di sola lettura).
e
Nei moderni processori multi-core la cache ` multilivello, talvolta fino a
e
3, con una cache L1 di dimensioni molto piccole (attorno ai 128 KByte) ed
una L2 di dimensioni maggiori, attorno ai 2 MByte. Le cache multilivello
generalmente operano controllando dapprima le cache a livello 1; se avvie-
ne un hit, il processore procede ad alta velocit`. Se la cache pi` piccola
a u
“fallisce”, allora viene controllata quella pi` grande e cos` via, fino ad dover
u ı
accedere alla memoria principale.
3.4 Sincronizzazione
La presenza di primitive di sincronizzazione tra processi che consentano la
mutua esclusione nella loro esecuzione, ` necessaria per proteggere le sezioni
e
critiche, e quindi la consistenza della memoria tra di loro condivisa, oltre
che per garantire una certa successione temporale nelle azioni realizzate. In
un sistema operativo multiprocessore possono essere implementate a livello
di sistema, tutte le primitive di sincronizzazione tra i processi normalmen-
te presenti anche nei sistemi operativi monoprocessore, quali ad esempio i
semafori e le variabili condition. In questo paragrafo affronteremo solo il
problema della sincronizzazione dei processi che si trovino su processori di-
versi: questa ` infatti la situazione che si verifica quando i vari kernel che si
e
trovano su processori diversi devono modificare le strutture dati tra di loro
condivise in sistemi UMA e NUMA.
Un lock ` una struttura dati condivisa utilizzata per realizzare la mutua
e
esclusione tra i processi, in quanto ciascun lock pu` essere posseduto da
o
un solo processo alla volta. Su di un lock possono essere realizzate due
operazioni, che chiameremo acquisisci lock (lock ) e rilascia lock (unlock ).
35

52. La prima cerca di trasferire il possesso del lock cui fa riferimento (ci possono
essere pi` lock per ogni processo, una per ogni risorsa) al processo che la
u
chiama, ponendolo in qualche modo in attesa se il lock ` in quel momento
e
posseduto da un altro processo. La seconda rilascia il possesso del lock cui
fa riferimento, consentendo l’avanzamento di uno dei processi in attesa su
di esso. Per realizzare una sezione critica, basta quindi racchiuderla tra le
due chiamate acquisisci lock e rilascia lock.
Uno dei modi per realizzare queste due chiamate ` esemplificato nelle
e
seguenti due funzioni, associando quindi ad esempio ad un lock il valore 1
se questo appartiene a qualcuno e 0 se ` libero.
e
void a c q u i s i s c i l o c k ( boolean l o c k ) {
while ( l o c k = 1 ) ;
l o c k := 1 ;
}
void r i l a s c i a l o c k ( char ∗ l o c k ) {
l o c k := 0 ;
}
Notiamo come l’operazione acquisisci lock si traduce in una sorta di at-
tesa attiva se il lock non ` libero: la richiesta di acquisizione ` ripetuta
e e
finch´ non viene soddisfatta. Ci` presuppone ovviamente che il possesso del
e o
lock sia di un processo che si trova su di un altro processore o almeno in
un altro thread. Nel caso in cui ci` non sia vero sono possibili altre solu-
o
zioni che a prima vista sembrerebbero in ogni caso pi` efficienti, come ad
u
esempio bloccare l’esecuzione del processo in attesa sul lock, schedulandone
`
un altro finch´ questo non sia stato rilasciato. E possibile eventualmente
e
aggiungere delle piccole pause tra due tentativi successivi, onde evitare che
la contesa sul bus che gli accessi al lock determina, causi un rallentamento
nell’esecuzione degli altri processi e quindi eventualmente del rilascio del
lock stesso.
Nel caso in cui sia possibile distinguere i processi in lettori e scrittori,
sono possibili altre ottimizzazioni a questo modello, consentendo ad esem-
pio a vari processi lettori di ottenere contemporaneamente il possesso di un
lock, fintanto che questo non appartenga a nessun processo scrittore. Un
altro modo per realizzare la sincronizzazione, ` tramite un evento. Questi
e
vengono utilizzati principalmente per garantire una certa successione tem-
porale: un processo blocca la sua esecuzione su di un evento finch´ questo
e
36

53. non si verifica. Il concetto di evento pu` essere utilizzato per la sincro-
o
nizzazione tra kernel che si trovino su processori diversi in sistemi UMA e
NUMA, collegati da un bus che consenta la propagazione delle interruzioni.
La routine di gestione delle interruzioni di un certo kernel sar` quindi in
a
attesa sull’evento interruzione generato da un altro kernel, e al suo arrivo
potr` prendere le opportune decisioni. In Java, presentato nel paragrafo 3.6,
a
sono disponibili molteplici soluzioni per la concorrenza e la sincronizzazione,
inclusa la gestione a eventi.
3.5 Multi core
Il termine multi core si usa per descrivere una CPU composta da pi` core,
u
ovvero da pi` “cuori” di processori fisici indipendenti, le rispettive Cache e i
u
cache controller in un singolo package. Questo tipo di architettura consente
di aumentare la potenza di calcolo senza aumentare la frequenza di lavoro,
a tutto vantaggio del calore dissipato.
I primi processori dual core prodotti sono gli IBM PowerPC del 2003 ma
il concetto ha assunto risonanza mondiale nel 2005, anno in cui i due mag-
giori produttori di CPU al mondo, Intel e AMD, hanno messo in commercio
i primi esemplari di una nuova generazione di microprocessori, basati sui
rispettivi prodotti esistenti, e contenenti due core.
Aumentare ulteriormente la frequenza di clock di una CPU single core `
e
stato giudicato dai progettisti una via molto onerosa e complicata, dato che i
consumi dei processori hanno superato i 100 W e si presenta un conseguente
problema di raffreddamento dei circuiti. Si ` deciso quindi di puntare sul pa-
e
rallelismo in modo da poter aumentare il numero di operazioni eseguibili in
un unico ciclo di clock. Tale approccio comporta anche alcuni svantaggi, in
quanto i programmi devono essere ottimizzati per un utilizzo multi-thread
per poter sfruttare appieno le caratteristiche di questi processori, in caso
contrario impegneranno solo uno dei core presenti, lasciando gli altri presso-
ch´ inutilizzati. Potrebbe addirittura verificarsi che un’applicazione risulti
e
di pi` lenta esecuzione su un processore dual core e, al momento del lancio,
u
erano veramente pochi i software gi` pronti per queste nuove architetture.
a
Diversi analisti prevedono che se il software pensato per un utilizzo pa-
rallelo in ambito dual core venisse realizzato in maniera oculata, tenendo
37

54. conto non del funzionamento su un sistema dual core, ma su un sistema a
pi` core, non richiederebbe poi grosse modifiche per essere utilizzato su un
u
dual core o su un quad core. Secondo altri invece, gli sforzi necessari per
realizzare software multi processore che funzioni in maniera ottimale satu-
rando tutti i core e non occupandoli in modo disomogeneo saranno esagerati
in relazione con i reali vantaggi, soprattutto di impatto di costi.
I primi processori dual core commerciali sono sostanzialmente quelli della
precedente generazione di processori di Intel e AMD montati su un unico
package, tuttavia esistono differenti approcci attraverso i quali si possono
realizzare chip dual core sulla realizzazione fisica di queste CPU e Dual
core (gestione della cache), per considerazioni sulla fruizione della cache da
parte di ciascun core). Al momento del lancio dei primi processori della
nuova generazione dedicati al settore desktop, vale a dire gli Intel Pentium
D (basati sul progetto Smithfield ), le frequenze dei processori erano minori
rispetto a quelle dei rispettivi processori monoprocessore AMD.
I primi Pentium D erano formati appunto da 2 core Prescott montati
sullo stesso package; successivamente sono arrivati anche quelli basati su
core Presler, divenuti la seconda generazione di processore Pentium D (in
cui erano sempre presenti due core uguali affiancati, anche se non sullo
stesso package per poter cos` aumentare le rese produttive), con processo
ı
produttivo a 65 nm. Dopo Presler ` stata la volta del Core 2 Duo Conroe
e
arrivato sul mercato a luglio 2006.
Intel ha inoltre progressivamente esteso l’utilizzo di questa tecnologia a
tutti i segmenti di mercato, inclusi quello mobile, di cui il primo esponente
` stato il Core Duo Yonah e successivamente Merom, entrambi evoluzioni
e
del Pentium M, e ovviamente al settore server. In questa categoria i primi
dual core sono Montecito evoluzione del processore a 64 bit Itanium 2 con
cache L3 che raggiunge in alcune versioni i 24 MB di capacit`, mentre per i
a
server di fascia bassa basati sul processore Xeon hanno visto la luce Dempsey
(formato da due core Irwindale), e Paxville, nomi in codice di queste CPU,
costruite con processo produttivo a 65 nm e destinate, rispettivamente, a
sistemi workstation e server a 2 e 4 processori. Da Conroe ` derivato anche
e
lo Xeon Woodcrest, per sistemi server di fascia entry level dotati di due
socket.
Se Intel ha avuto il merito di rendere questi processori disponibili pra-
38

55. ticamente a tutti, i primi processori multi core presentati sul mercato sono
stati, verso la fine del 2005, il Cell, CPU sviluppata congiuntamente da IBM,
Sony e Toshiba per il mercato console/blade server e composto da 8 core
non omogenei, e l’UltraSPARC T1, processore a 8 core omogenei sviluppato
da Sun Microsystems per il mercato server (In particolare per Web server
con numerosi accessi) capace di gestire 32 thread simultanei.
Intel ha stimato che nel corso del 2007 la percentuale di processori do-
tati di architettura quad core in commercio sia pari al 3% della produzione
complessiva. Una percentuale di questo tipo pu` sembrare limitata, ma al-
o
la luce del totale di processori commercializzati nel 2007 (stimato in circa
230 milioni) e della quota di mercato del 75% circa detenuta da Intel, se ne
ricava un totale di almeno 3 milioni di processori quad core [Cor].
3.5.1 Realizzazione
Al momento, esistono 3 metodi differenti per creare un chip dual core: Die
Singolo, Die Doppio e Die Monolitico. Il Die ` il blocco di silicio al centro
e
di un processore che contiene il cuore elaborativo della CPU, il core.
Die singolo
Figura 3.9: Intel Pentium D Smithfield, primo dual core a die singolo [int]
L’unico processore ad utilizzare tale approccio ` stato il Pentium D Smi-
e
`
thfield e consiste nel combinare 2 core su un singolo die. E l’approccio sen-
z’altro pi` semplice, e quindi pi` economico rispetto agli altri, per realizzare
u u
un chip dual core, ma ovviamente ` anche pi` limitante per quanto riguarda
e u
39

56. le prestazioni e la resa produttiva. Infatti, prendendo ad esempio proprio il
caso di Smithfield, che ` sostanzialmente formato da 2 core Prescott (sin-
e
gle core), ` possibile osservare, ovviamente in maniera molto semplicistica,
e
come per realizzarlo sia sufficiente utilizzare la stessa maschera litografica
disegnata per il processore Prescott, e “stamparla” 2 volte sul wafer di silicio
interconnettendo i due core cos` realizzati. Rimane comunque il problema
ı
che se anche solo uno dei 2 core stampati ` difettoso, tutto il chip diventa
e
inutilizzabile, ovvero non potr` essere un Pentium D, e potrebbe quindi es-
a
sere rivenduto come semplice Pentium 4 Prescott dopo aver disabilitato uno
dei due core.
L’evoluzione delle tecniche produttive probabilmente ha gi` decretato la
a
“morte” di tale approccio, che sebbene semplice da realizzare pu` risultare
o
indirettamente costoso per la probabilit` di non avere molti core attigui sul
a
wafer perfettamente funzionanti. Intel stessa infatti ha realizzato tutti gli
altri progetti dual e multi core utilizzando gli altri approcci e AMD invece
non ha mai utilizzato tale approccio. La tecnica pi` sofisticata attualmente
u
in uso, il die monolitico, pur risolvendo altri problemi, di fatto soffre anch’es-
sa dello stesso problema: si devono avere i due core vicini funzionanti. Da
parte sua per` si avvantaggia del fatto di essere progettato tenendo conto
o
di questi fattori, mentre i core utilizzati nel die singolo non erano progettati
per essere multi core.
Ognuno dei due core comunque, manteneva la propria indipendenza e
quindi anche le cache L2 erano sdoppiate e ogni core aveva la “propria” cache
L2, quindi solo con questa poteva avere una sorta di accesso privilegiato.
Proprio per questo motivo, per Smithfield, non si parlava di una cache L2 da
2 MB ma di 2x1MB. Affinch´ un core potesse accedere ai dati memorizzati
e
nella cache dell’altro era necessario trasferire i dati attraverso il BUS di
sistema, con il rischio di saturarlo. La scelta di questa implementazione in
Smithfield, penalizzante dal punto di vista delle prestazioni, era giustificata
proprio dalla sua relativa semplicit` realizzativa e progettuale. Solo con
a
l’avvento del die monolitico si riuscir` a porre rimedio a questo collo di
a
bottiglia, condividendo l’intera cache L2 tra i core in modo da liberare il
bus di sistema e consentire la condivisione dei dati in memoria a libello di
cache.
40

57. Die doppio
Figura 3.10: Intel Pentium D Presler, primo dual core a die doppio [int]
Tale metodo consiste nel posizionare 2 die, fisicamente separati, su un
unico package e collegarli successivamente con collegamenti esterni. Il primo
progetto Intel ad avvantaggiarsi di questo approccio ` stato il Pentium D
e
Presler. Tale metodo, seppure leggermente pi` complesso nella realizzazione
u
di quello a Die singolo, in quanto collegare i core solo in un secondo tempo
richiede maggiore tempo che realizzare i collegamenti direttamente sul silicio,
risulta per` complessivamente il metodo pi` economico dal punto di vista
o u
del produttore, infatti ` possibile “scegliere” quali devono essere i due core
e
che andranno poi collegati insieme, facendo cadere la necessit` dei due core
a
affiancati e massimizzando la resa produttiva.
Soprattutto agli albori dell’utilizzo di quest’approccio i chip che supe-
ravano i test, venivano valutati sui margini di clock e tensioni; i modelli
che tolleravano frequenze di clock elevate potevano essere marchiati come
veloci Pentium 4 single core, mentre gli altri potevano essere accoppiati per
realizzare i modelli dual core Pentium D che generalmente funzionavano a
clock inferiori.
C’` tuttavia un grande svantaggio nell’inserire due core indipendenti in
e
un solo package. Quando un core accede ai dati, anche l’altro far` lo stesso,
a
utilizzando risorse non necessarie. La separazione fisica dei core compor-
ta due inconvenienti: la necessit` di collegamenti esterni e, ovviamente la
a
separazione della cache che non ` pi` una scelta progettuale ma uno scot-
e u
to da pagare. Il primo inconveniente in realt` ` comunque relativamente
a e
economico da superare, mentre il secondo rappresenta comunque un limite
intrinseco di questo approccio.
41

58. Die monolitico
Figura 3.11: Intel Core 2 Duo, primo dual core a monolitico [int]
L’approccio a die monolitico ` certamente quello pi` sofisticato da rea-
e u
lizzare ma ovviamente ` anche quello che garantisce le migliori prestazioni
e
di una CPU multi core. Tale approccio deve essere preventivato fin dalle
prime fasi della progettazione del processore ed ` stato utilizzato per la pri-
e
ma volta da Intel per i Core Duo Yonah e gli Itanium 2 Montecito. Il suo
pi` grande pregio consiste nell’offrire ai progettisti l’opportunit` di condivi-
u a
dere alcune unit` del processore; nel caso pi` semplice, tale condivisione si
a u
limita alla cache che viene realizzata in un unico blocco condiviso tra tutti
i core (in processori che utilizzano gli altri approcci costruttivi, la cache `
e
necessariamente equamente divisa tra i core e l’accesso diretto a ciascuna
cache ` riservato esclusivamente al rispettivo core, il quale per accedere alle
e
altre deve far transitare i dati sul BUS). In casi pi` complessi le unit` con-
u a
divise possono essere anche altre, come il memory controller della RAM (al
momento solo nei processori AMD) gli scheduler che ripartiscono il carico
tra i vari core, ecc.
A questo punto ` infatti ormai chiaro che la pi` grossa lacuna delle prime
e u
versioni di processori dual core risiedeva proprio nella esclusivit` della cache
a
L2 e la necessit` di far transitare i dati sul gi` trafficato BUS di sistema.
a a
Il primo processore a colmare questa lacuna ` stato il Core Duo Yonah una
e
CPU mobile dual core in cui la cache L2 era condivisa tra i 2 core. Ogni
core quindi poteva accedere alla totalit` della cache lasciando libero il BUS
a
di sistema che poteva quindi limitarsi a far transitare solo i dati da, e per,
la memoria RAM.
42

59. Figura 3.12: Intel Xeon quad core [int]
Appare quindi evidente come tutti i pi` recenti progetti di processo-
u
ri multi core puntino soprattutto all’utilizzo di quest’ultimo approccio co-
struttivo, riservando gli altri (soprattutto quello a Die Doppio), per risolvere
specifiche esigenze.
Figura 3.13: Confronto tra l’architettura die singolo e monolitica [int]
In figura 3.13, di propriet` di Intel R , un confronto tra due architetture
a
dual core: la prima immagine rappresenta la prima serie a die singolo mentre
la a destra a die monolitico. Appare evidente subito il diverso utilizzo della
cache di secondo livello che nel primo caso ` separata per ogni core mentre nel
e
nei monolitici ` condivisa. Quest’ultimo approccio velocizza le performance
e
dei processori che consentono di accedere indistintamente ai dati di ogni
singolo core.
43

60. 3.6 Multithreading in Java
Con l’avvento delle nuove architetture parallele la semplice programmazio-
ne sequenziale a singolo processo non era adeguata per sfruttare le risorse a
disposizione. La necessit` di poter eseguire pi` programmi contemporanea-
a u
mente ` antecedente all’avvento dei multiprocessori, gia Windows 3.0 (che
e
pochi di noi si ricorderanno) era multi-tasking, anche se i job non erano ef-
fettivamente paralleli ma si suddividevano il tempo di calcolo della cpu per
poter simulare le architetture recenti.
Oggi i programmi pi` sofisticati suddividono i loro job in unit` pi` pic-
u a u
cole, processi o thread, che possono avanzare nel tempo parallelamente in
modo reale (se ci sono pi` cpu che processi) o simulato (suddividento il tem-
u
po di cpu tra i thread se necessario). I thread multipli hanno origine dallo
stesso processo e condividono lo spazio di memoria, il codice eseguibile e i
dati globali, potendo in questo modo suddividere il lavoro a pi` processori
u
in modo efficiente. Il costo da pagare ` una notevole complessit` che pu`
e a o
essere spesso difficile da gestire. Il problema maggiore ` la sincronizzazione:
e
spesso un thread ha bisogno dei risultati di un altro, oppure deve sovra-
scrivere i dati di un altro ma non prima di un dato momento che possono
causare inconsistenza dei dati o stalli, risolvibili con vari approcci di mutua
esclusione.
I moderni processori multi-core aumentano le loro prestazioni all’aumen-
tare del grado di parallelismo proprio perch` raggiungono il risultato in modo
e
cooperativo rispetto al singolo flusso di dati. Dal punto di vista del sistema
operativo una cpu di questo tipo si avvantaggia dal fatto di poter dedicare
unit` di calcolo separate per pi` programmi in esecuzione, ma dal punto
a u
di vista algoritmico (di interesse in questa tesi), lo stesso algoritmo svilup-
pato per processori a core singolo non si avvantaggeranno dell’uso dei core
multipli. Essi infatti utilizzeranno un solo core per tutti i calcoli, lasciando
gli altri potenzialmente inutilizzati, ecco perch` ` necessario riprogettare e
ee
riscrivere interamente gli algoritmi in modo parallelo, in modo diverso ovvia-
mente dagli algoritmi per sitemi distribuiti, potendo contare sulla memoria
condivisa.
Java ` nato da subito con l’ambizione di poter essere facilmente utiliz-
e
zato con la programmazione multi-thread, grazie all’implementazione della
44

61. Figura 3.14: Esempio di processo multithreading su processore quad-core
sua Virtual Machine, e si sposa particolarmente bene con le nuove archi-
tetture multiprocessore poich`, come in figura 3.14, ` possibile generare pi`
e e u
processi che condividono lo stesso spazio di memoria, cos` come pi` core la
ı u
condividono nello stesso processore multi-core. Generalmente, le classi de-
finite in Java sono “multi-threaded”, ovvero sono potenzialmente in grado
di gestire l’invocazione dei propri metodi da parte di pi` thread in contem-
u
poranea (fanno eccezione tutti i metodi caratterizzati dalla parola riservata
synchronized che rende tali metodi accessibili solo in maniera sequenziale);
se cos` non fosse, thread paralleli potrebbero accodarsi per accedere allo
ı
stesso metodo, inficiando i benefici dei flussi di istruzioni paralleli. Ecco
perch` Weka, sviluppato in Java, si ` prestato in modo naturale al lavoro di
e e
parallelizzazione proposto in questa tesi.
Se gi` prima dell’avvento dei multi-core si riteneva necessario ricorrere
a
all’uso dei thread, magari per poter avviare pi` task contemporaneamen-
u
te, oppure pi` istanze dello stesso algoritmo con dati diversi, oggi il multi-
u
threading ` d’obbligo: senza di esso infatti la ridondanza di processori sareb-
e
be inutile. A ci` si aggiunga il beneficio di poter contare su un parallelismo
o
reale in modo che due thread paralleli possano contare sull’uso esclusivo di
due unit` di calcolo concorrenti (un dual core che elabora un programma
a
con due thread produttore-consumatore ne ` un esempio).
e
45