Tesi Specialistica - Weka SMP

2,351 views

Published on

tesi specialistica su parallelizzazione multithread di algoritmi per il datamining

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,351
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Tesi Specialistica - Weka SMP

  1. 1. `UNIVERSITA CA’ FOSCARI – VENEZIAFacolt` di Scienze Matematiche, Fisiche e Naturali a Corso di Laurea in Informatica (Specialistica) Tesi di Laurea 11 Aprile 2008 Laureando: Fabio PustettoWekaSMP: Parallelizzazione Multi-Thread di una libreria Java per il Data MiningRelatore: Chiar.mo prof. Salvatore Orlando Anno Accademico 2006 - 2007 Via Torino 155 – 30173 Mestre - Venezia
  2. 2. II
  3. 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`. aQuesta tesi ` stampata su carta riciclata in adesione alla campagna e “Scrittori per le foreste”, lanciata da III
  4. 4. IV
  5. 5. Indice1 Introduzione 1I Stato dell’arte 52 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 . . . . . . . . . . . . . . . . . . . 223 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. 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 . . . . . . . . . . . . . . . . . . 76II WekaSMP 795 Analisi degli algoritmi di WekaSMP 81 5.1 Regole Associative: AprioriSMP . . . . . . . . . . . . . . . . 82 5.2 Clustering: K-MeansSMP . . . . . . . . . . . . . . . . . . . . 836 Realizzazione del prototipo WekaSMP 87 6.1 Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 6.2 Regole Associative: AprioriSMP . . . . . . . . . . . . . . . . 89 6.3 Clustering: K-MeansSMP . . . . . . . . . . . . . . . . . . . . 967 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 . . . . . . . . . . . . . . . . . . . . . . . . . 1318 Conclusioni 135 VI
  7. 7. III Allegati 141A Script 143B Core 147 B.1 Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 B.2 Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152C AprioriSMP 155 C.1 Apriori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 C.2 CountDistribution . . . . . . . . . . . . . . . . . . . . . . . . 163D K-MeansSMP 165 D.1 SimpleKMeans . . . . . . . . . . . . . . . . . . . . . . . . . . 165 D.2 K-MeansSMP . . . . . . . . . . . . . . . . . . . . . . . . . . . 174Bibliografia 181 VII
  8. 8. VIII
  9. 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. 10. 3.14 Esempio di processo multithreading su processore quad-core . 453.15 Grafo di transizione dei processi . . . . . . . . . . . . . . . . . 473.16 Sincronizzazione per l’accesso ad una risorsa . . . . . . . . . . 514.1 Struttura degli algoritmi di Data Mining pi` comuni [JA02] . u 584.2 Utilizzo della memoria nei vari schemi di Locking [JA02] . . . 594.3 Compromessi tra le varie tecniche [JA02] . . . . . . . . . . . . 604.4 Algoritmi paralleli per la scoperta di Regole Associative [Zak99] 614.5 Algoritmo Count Distribution [HKK97] . . . . . . . . . . . . 634.6 Algoritmo Data Distribution [HKK97] . . . . . . . . . . . . . 644.7 Confronto scalabilit` algortimi paralleli [HKK97] . . . . . . . a 674.8 Confronto speedup algortimi paralleli [HKK97] . . . . . . . . 684.9 Confronto tempi di risposta algortimi paralleli [HKK97] . . . 694.10 Propriet` del database per i test dell’algoritmo CCPD [ZOPL96] 70 a4.11 Speedup dell’algoritmo CCPD senza e con lettura del data- base [ZOPL96] . . . . . . . . . . . . . . . . . . . . . . . . . . 704.12 Tempi di lettura del database [ZOPL96] . . . . . . . . . . . . 714.13 Algoritmo K-Means sequenziale [DM00] . . . . . . . . . . . . 754.14 Scelta dei primi centroidi su algoritmo K-Means . . . . . . . . 764.15 Prestazioni K-Means parallelo con n = 221 , d = 8 e k = 8 [DM00] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774.16 Prestazioni K-Means parallelo con n = 221 , d = 8 e k = 8 [JA02] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776.1 Confronto Count Distribution SM e DM . . . . . . . . . . . . 906.2 Diagramma di flusso algoritmo AprioriSMP . . . . . . . . . . 916.3 Diagramma delle classi, algoritmo Apriori . . . . . . . . . . . 936.4 Diagramma di flusso kmeansSMP . . . . . . . . . . . . . . . . 986.5 Diagramma delle classi, algoritmo kMeansSMP . . . . . . . . 997.1 Esempio di rilevamento cache miss con VTune . . . . . . . . . 1057.2 Esempio output AprioriSMP nei test . . . . . . . . . . . . . . 1067.3 Esempio rilevamento tempi AprioriSMP nei test . . . . . . . 1077.4 Struttura del dataset Mushroom . . . . . . . . . . . . . . . . 1087.5 Descrizione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 X
  11. 11. 7.6 Tempi di risposta dell’algoritmo AprioriSMP con contatori condivisi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1147.7 Speedup dell’algoritmo AprioriSMP con contatori condivisi . 1157.8 Speedup del conteggio dei frequenti con contatori condivisi . 1167.9 Tempi di risposta dell’algoritmo AprioriSMP con contatori privati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1197.10 Speedup dell’algoritmo AprioriSMP con contatori privati . . . 1207.11 Speedup del conteggio dei frequenti con contatori privati . . . 1217.12 Confronto tempi di risposta versioni AprioriSMP . . . . . . . 1227.13 Confronto speedup versioni AprioriSMP . . . . . . . . . . . . 1237.14 Scalabilit` dell’algoritmo AprioriSMP . . . . . . . . . . . . . 124 a7.15 Esempio rilevamento dei tempi test K-MeansSMP . . . . . . 1257.16 Esempio output dei test K-MeansSMP . . . . . . . . . . . . . 1267.17 Struttura del dataset Iris . . . . . . . . . . . . . . . . . . . . 1277.18 Tempi di risposta K-MeansSMP variando il numero di pro- cessori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1317.19 Tempi di risposta K-MeansSMP variando la dimensione del database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1327.20 Scalabilit` K-MeansSMP . . . . . . . . . . . . . . . . . . . . . 133 a7.21 Speedup K-MeansSMP . . . . . . . . . . . . . . . . . . . . . . 134 XI
  12. 12. XII
  13. 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. 14. 7.11 Speedup AprioriSMP, contatori privati, database 200 MByte 1177.12 Tempi di risposta AprioriSMP, contatori privati, database 500 MByte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1187.13 Indici prestazionali AprioriSMP, contatori privati, database 500 MByte . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1187.14 Cache Miss AprioriSMP . . . . . . . . . . . . . . . . . . . . . 1237.15 Parametri test K-MeansSMP . . . . . . . . . . . . . . . . . . 1247.16 Tempi di risposta K-MeansSMP, database 25 MByte . . . . . 1287.17 Indici prestazionali K-MeansSMP, database 25 MByte . . . . 1287.18 Tempi di risposta K-MeansSMP, database 50 MByte . . . . . 1297.19 Indici prestazionali K-MeansSMP, database 50 MByte . . . . 1297.20 Tempi di risposta K-MeansSMP, database 200 MByte . . . . 1307.21 Indici prestazionali K-MeansSMP, database 200 MByte . . . 1307.22 Cache Miss K-MeansSMP . . . . . . . . . . . . . . . . . . . . 133 XIV
  15. 15. SommarioL’idea base delle architetture parallele ` che diversi processori cooperino enella soluzione di un singolo problema. Il motivo che spinge ad occuparsidi calcolo parallelo ` proprio il tentativo di velocizzare il processo di calco- elo della soluzione dei problemi computazionali. In accordo con la legge diMoore ` stato ormai raggiunto il limite fisico per l’aumento della frequenza edei processori e vengono rilasciati i primi sistemi Multi-Core: pi` unit` di u acalcolo nello stesso processore che cooperano nel raggiungimento del risul-tato e una sola memoria condivisa. Per far fronte all’esigenza di sfruttare ilpatrimonio informativo contenuto nelle grandi raccolte di dati che abbiamoa disposizione, si utilizzano algoritmi di Data Mining per estrarre infor-mazione implicita da dati gi` strutturati, esplorare ed analizzare in modo aautomatico grandi quantit` di dati allo scopo di scoprire regole o insiemi asignificativi. Lo scopo di questa tesi ` studiare e fornire algoritmi di Data eMining paralleli efficienti per questo nuovo tipo di architetture, basandosisulle librerie Java del progetto Weka. L’implementazione parallela da luogoal prototipo WekaSMP, base di partenza per la parallelizzazione di tutti glialgoritmi in essa contenuti. L’analisi dei risultati, infine, evidenzia come siapossibile ridurre il tempo di computazione in modo sensibile sfruttando inmodo opportuno tutte le unit` di calcolo. a
  16. 16. Capitolo 1Introduzione “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
  17. 17. Con la disponibilit` di grandi basi di dati in molte aree applicative come abioinformatica, medicina, analisi scientifiche e finanziarie, telecomunicazio-ni, vendite al dettaglio e marketing, sta diventando sempre pi` necessario ueseguire applicazioni Data Mining in parallelo. Allo stesso tempo il progressotecnologico 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 incrementodelle prestazioni in ambienti multitasking, dall’altro obbliga i programma-tori a sviluppare algoritmi paralleli su misura. In questo senso la velocit` adi sviluppo di queste nuove architetture non ` stata mantenuta anche dal- el’implementazione di nuovi algoritmi. Ricordiamo una scomoda verit`: un aalgoritmo sequenziale eseguito su un processore multi-core di nuova genera-zione, basato su un’architettura parallela a memoria condivisa, non godr` adi 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 pressola facolt` di informatica dell’universit` neozelandese di Waikato, conosciuto a acome progetto Weka. Lo sviluppo di questo nuovo tool deve essere paralleloed efficiente su macchine a memoria condivisa, tale da garantire un incre-mento di prestazioni adeguato se confrontato con le versioni sequenziali oparallele per macchine distribuite, esistenti. Ecco come si presenta questo elaborato. Nel capitolo 2 si presentanole basi teoriche delle discipline per la scoperta di regole associative e pro-cessi di clustering sulle quali sono fondate le applicazioni di Data Miningche stiamo esplorando e un’approfondimento sul progetto Weka alla relea-se attuale. Nel capitolo 3 si presentano le innovazioni tecnologiche che cihanno spinto a sviluppare gli algoritmi qui presentati, in modo particolarele nuove architetture parallele multi-core, mentre il capitolo 4 ` dedicato ead 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 udi clustering, la maggior parte dei quali per sistemi a memoria distribuita,dimostrazione del fatto che sono ancora pochi, o in stato embrionale, quellia 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
  18. 18. prototipo presentato con il nome di WekaSMP (Waikato Environment forKnowledge Analysis on Shared Memory Processors). Nel capitolo 5 si stu-diano formalmente gli algoritmi da sviluppare per stimarne la complessit` atemporale e gli incrementi di prestazioni mentre nel capitolo 6 si presen-tano gli algoritmi, sviluppati in Java, includendo porzioni di pseudocodicerappresentativi del codice sorgente delle funzioni pricipali sviluppate e de-scrivendone il loro funzionamento. Gli algoritmi sviluppati vengono testatisu 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 informa tabellare che grafica. Il capitolo 8, in fine, contiene le conclusioni egli ultimi commenti sul lavoro. L’ultima sezione ` dedicata alla stampa del codice sorgente delle funzioni eprincipali e di maggior interesse, elaborate in questo studio1 . 1 Tutti i diritti riservati. Marchi registrati e segni distintivi citati in questo elaboratosono 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
  19. 19. 4
  20. 20. Parte IStato dell’arte 5
  21. 21. Capitolo 2Data Mining “Il segreto degli affari ` sapere qualcosa che nessun altro sa” e Aristotelis Sokratis Onassis (1906-1975), armatore e finanziere greco. 7
  22. 22. Il data mining o, come si preferisce chiamarlo di recente, la KnowledgeDiscovery in Databases (KDD), ` una disciplina nata alla fine degli anni ’80. eIl motivo alla base dell’interesse per questa disciplina risiede nel fatto chenegli ultimi decenni la capacit` dell’uomo di generare e collezionare dati ` a eincrementata notevolmente. Nelle applicazioni reali spesso ` necessario estrarre dati da diversi dipar- etimenti. Per esempio in un’applicazione di marketing si pu` voler integrare odati dall’ufficio vendite, dall’ufficio acquisti e dall’ufficio clienti ma ognunodi essi probabilmente differisce nel modo di immagazzinare tali dati, oltreche 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-esce un unico punto di accesso ai dati aziendali ed essi verranno poi usatiper prendere decisioni di business, eventualmente integrati con dati esterni(Overlay Data) che l’azienda non memorizza (ad esempio i dati meteo).2.1 Regole AssociativeSia T l’insieme di transazioni, dove ognuna di esse ` un sottoinsieme dell’in- esieme di articoli (item-set) I. Sia C un sottoinsieme di I allora si definiscesupporto di C rispetto a T σ(C) = |{t|t ∈ T, C ⊆ t}|.dove σ(C) ` il numero di transazioni che contengono C. Per esempio conside- erare un insieme di transazioni di un supermercato come illustrato in tabella2.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, LattePannolini, Latte} mentre il supporto di {Pannolini, Latte} ` σ(Pannolini, e 8
  23. 23. Latte) = 3 ed il supporto di {Pannolini, Latte, Birra} ` σ(Pannolini, Latte, eBirra) = 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 econfidenza α ` definita come σ(X ∪ Y )/σ(X). Per esempio considerando la eregola {Pannolini, Latte} ⇒ {Birra}, la presenza di pannolini e latte nellatransazione tendono ad indicare, nella stessa transazione, la presenza di bir-ra. Il supporto di questa transazione ` σ(P annolini, Latte, Birra)/5 = 40% ementre la confidenza ` σ(P annolini, Latte, Birra)/σ(P annolini, Latte) = e66%. Ovviamente regole con alta confidenza sono molto importanti poi-ch` forniscono spesso un’accurata previsione sull’associazione degli articoli enella regola. Anche il supporto di una regola ` fondamentale, considera- eto che indica quanto frequente ` la regola in una transazione. Regole con ebasso supporto non sono significative, motivo per cui alcuni algoritmi (trai quali Apriori) [AS94] tralasciano le regole che non soddisfino una condi-zione di supporto minimo per ridurre le associazioni derivate, consideratoche il numero di regole possibili ` proporzionale al numero di sottoinsiemi edell’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 unasoglia 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 ealgoritmi sviluppati per risolverla, tra i quali uno dei pi` conosciuti ` Apriori. u e2.1.1 Algoritmo AprioriL’algoritmo Apriori ` stato proposto nel 1994 da Rakesh Agrawal [AS94]. In efigura 2.1 sono riassunti i passi principali. Inizialmente L1 contiene tutti glioggetti (sottoinsiemi di dimensione 1) che soddisfano il supporto minimo: ilprimo passo infatti conta semplicemente le occorrenze di ogni articolo neldatabase ed elimina in L1 quelle che non soddisfano il supporto minimo. Il 9
  24. 24. Figura 2.1: Algoritmo Apriori [AS94]passo successivo, detto k, consiste di due fasi: nella prima l’insieme frequenteLk−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 nelcontare le occorrenze dei candidati in Ck nel database di transazioni pertrovarne il supporto. Infine, dall’insieme dei candidati Ck si eliminano leoccorrenze che non soddisfano il supporto minimo per trovare l’insieme deifrequenti Lk . L’unione di tutti questi insiemi ` il risultato finale. e Per generare gli insiemi candidati, la funzione apriori gen richiede iningresso l’insieme degli articoli frequenti al passo (k-1). In uscita si ha unsuperinsieme contenente gli oggetti frequenti di lunghezza k. La funzione sidivide in due fasi. Nella prima fase (join) si moltiplica per se stesso l’insiemeLk−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 importantenotare gi` a questo punto come l’operazione pi` pesante di tutto l’algorit- a umo sia il conteggio dei supporti. L’algoritmo parallelo Count Distribution 10
  25. 25. 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 eclassico string-matching di ogni insieme di articoli nell’insieme dei candidatinell’insieme delle transazioni ma trie [Bod03] ed hash tree [HKK97], usatianche in Weka, garantiscono performance molto pi` veloci, uHash TreeLa figura 2.4 mostra un esempio di hash tree contenente l’insieme candidatodi dimensione 3. I nodi interni hanno hash tables contenenti link ai nodifigli, i nodi foglia contengono gli insiemi candidati. La costruzione di un hash tree avviene come segue. Inizialmente l’hashtree contiene solo il nodo root, che ` anche il nodo foglia ma che non con- etiene insiemi candidati. Quando un insieme candidato viene generato, glioggetti dell’insieme vengono memorizzati in modo ordinato, cosa che per-metter` una maggiore efficienza nel generare sia l’insieme dei frequenti che ail successivo insieme candidato. Ogni insieme candidato viene inserito nel-l’albero codificando ogni oggetto successivo nei nodi interni e seguendo icollegamenti delle tabelle hash. Quando si raggiunge una foglia l’insiemecandidato viene inserito come foglia anch’esso se il numero di foglie ` mi- enore del massimo consentito, altrimenti il nodo foglia viene convertito innodo interno e vengono creati nodi figli per il nuovo nodo. Gli insiemi can-didati vengono distribuiti nei nodi foglia secondo i valori hash degli oggetticontenuti. Nell’esempio di figura 2.4, l’insieme candidato {1 2 4} ` inserito ecodificando 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 infinecodificando l’oggetto 4 si raggiunge il figlio sinistro, che ` una foglia. e L’operazione di subset attraversa l’albero a partire dalla radice e conogni oggetto di una transazione come possibile oggetto iniziale del candida- 11
  26. 26. Figura 2.4: Inserimento di candidati dalla radice dell’hash tree [HKK97]to. Nel livello successivo, tutti gli oggetti che seguono quello iniziale dellatransazione vengono codificati nella funzione hash. Questo ` fatto ricorsiva- emente fino a che viene raggiunta una foglia. A questo punto tutti i candidatiinseriti nelle foglie vengono confrontati con la transazione ed i loro contatorivengono aggiornati. Nell’esempio di figura 2.4 l’operazione viene effettuataa partire dalla radice con la transazione {1 2 3 5 6}. L’oggetto 1 ` codifica- eto verso il figlio sinistro della radice e la transazione rimanente {2 3 5 6} ` eapplicata ricorsivamente a questo nodo. L’oggetto 2 ` codificato come figlio ecentrale del nodo e cos` via, secondo la funzione di hash specifica. ı 12
  27. 27. Figura 2.5: Inserimento di candidati dal sottoalbero sinistro dell’hash tree[HKK97] La figura 2.5 mostra la stessa operazione effettuata in precedenza, sulsottoalbero sinistro. I figli 2 e 5 vengono codificati nei figli centrali del nodoe quindi le rimanenti transazioni {3 5 6} e {6} vengono applicate ricorsiva-mente a questo nodo centrale. L’oggetto 3, invece viene mappato nel figliodestro del nodo e la rimanente transazione {5 6} ` applicata ricorsivamente ea questo figlio destro.2.2 ClusteringSi definisce clustering il processo di partizionamento o raggruppamento di undato insieme di oggetti in sottoinsiemi disgiunti. Tutti gli oggetti apparte-nenti allo stesso cluster avranno caratteristiche simili tra loro e il pi` diverse upossibile rispetto agli oggetti appartenenti alle altre partizioni (massimizzarela 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
  28. 28. 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 enavigazione di testi [Jos03]. La clusterizzazione di dati ` un ramo importante del Data Mining e molti esono gli algoritmi che si occupano di questa scienza. Essi sono suddivisi in 2categorie: algoritmi gerarchici (in figura 2.6 un esempio di rappresentazionea dendrogramma) ed algoritmi partizionali (vedi esempio di figura 2.7). Iprimi creano una decomposizione gerarchica del dataset in oggetto formandoun albero che divide ricorsivamente i dati in sottoalberi pi` piccoli; i secondi, uinvece, creano un’unica partizione dei dati in insiemi disgiunti. Figura 2.6: Esempio di clusterizzazione gerarchica a dendrogramma 14
  29. 29. Figura 2.7: Esempio di clusterizzazione partizionale2.2.1 Algoritmo K-MeansK-means appartiene alla classe degli algoritmi di partizione non gerarchica.Il suo obiettivo ` quello di trovare una partizione in k cluster di n oggetti espaziali che minimizzi le differenze tra gli oggetti appartenenti alla stessaclasse e massimizzi le differenze tra gli oggetti di cluster diversi. Pi` formal- umente, supporre di avere un insieme di n dati spaziali X1 , X2 , · · · , Xn taleche ogni dato ` in Rd . La ricerca dei cluster con varianza minima di questo einsieme in k cluster ` definita come la ricerca di k punti {mj }k in Rd tale e j=1che n 1 minj d2 (Xi , mj ) (2.1) n i=1sia 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 ol’obiettivo ` quello di minimizzare la varianza intra-cluster e massimizzare equella inter-cluster k V ar = (Xi − mj )2 (2.2) j=1 xi ∈Sjdove k ` il numero di cluster raggruppati nell’insieme Sj , j = 1, 2, . . . , k e emj sono i centroido dei punti xi ∈ Sj . Informalmente il problema in 2.1 e 2.2 ` quello di ricercare k centroidi edei cluster tali che minimizzino il quadrato della distanza Euclidea (cono-sciuto anche come mean squared error, MSE ) tra ogni punto nello spazio e ilsuo 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
  30. 30. 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-Meansiterativa di affinamento conosciuta come algoritmo di Lloyd’s, riassumibilein 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- oscendente che comincia con dei centroidi casuali e li aggiorna iterativamentead ogni passo per minimizzare la funzione obiettivo 2.1. Tuttavia si sa cheK-Means converger` sempre in un minimo locale [BB95] che dipender` dai a acentroidi scelti all’inizio. Prima della convergenza, i passi 2 e 3 dovrannoessere ripetuti volte, valore non predicibile e dipendente anch’esso dai cen-troidi iniziali. L’intero positivo ` detto numero di iterazioni di K-Means, ementre un esempio di algoritmo ` presentato in figura 2.8. e In figura 2.9 si pu` intuire facilmente come opera l’algoritmo: si comin- ocia scegliendo casulamente dei centroidi (a); ogni punto verr` associato al acentroide pi` vicino (b) e successivamente si ricalcolano i centroidi relativa- umente ad ogni cluster (c). I passi (b) e (c) si ripetono iterativamente finoalla convergenza (i centroidi rimangono identici in due successive iterazioni). 16
  31. 31. Figura 2.8: Algoritmo K-Means sequenziale [DM00] L’algoritmo K-Means ` conosciuto per la sua semplicit` di realizzazio- e ane e per i buoni risultati che riesce a fornire tuttavia richiede un tempodi computazione proporzionale al prodotto numero di oggetti e numero dicluster per iterazione, tempo molto alto per database di grandi dimensio-ni. Analizzando la complessit` computazionale si rileva che ogni iterazione adell’algoritmo ` costante, composta dal calcolo delle distanze, e ricalcolo dei ecentroidi. In particolare il calcolo delle distanze ` l’operazione pi` pesan- e ute e richiede (3nkd + nk + nd) operazioni in virgola mobile per iterazionedove 3nkd si riferisce al calcolo delle distanze euclidee, nk alla ricerca delcentroide del cluster mentre n, k e d sono rispettivamente la cardinalit` adel database, il numero di cluster e il numero di dimensioni del dominio (ilnumero di attributi). Anche il ricalcolo dei centroidi richiede approssima-tivamente kd istruzioni floating point. Combinando le relazioni precedenti 17
  32. 32. Figura 2.9: Esempio di clusterizzazione di punti spazialipossiamo 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 WekaIl progetto Weka (Waikato Environment for Knowledge Analysis [wek]) ` euna collezione di algoritmi autoapprendenti (machine learning) allo stato 18
  33. 33. 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 allavalutazione dei dati in output, anche in forma visuale, per verificare il risul-tato della fase di learning, attraverso un’interfaccia grafica. Esso ` capace edi unire alla semplicit` della sua interfaccia un background potente ed af- afidabile, cos` da fornire agli utenti uno strumento flessibile per lo sviluppo ıe l’utilizzo di tecniche machine learning per l’estrazione di conoscenze dagrossi database, impossibili da analizzare a mano. Il sistema ` sviluppato in Java, linguaggio di programmazione orienta- eto agli oggetti disponibile per molte piattaforme, da Windows a Linux eMacintosh e distribuito con licenza GNU General Public License [gnu], checi permette di scaricare, modificare e redistribuire il codice senza scopo dilucro ed ` testato in Windows, Linux e Macintosh. Gli utenti di Weka non esono solo ricercatori o professionisti, ma anche studenti per l’apprendimentodelle tecniche di Data Mining. Il suo utilizzo ` adatto a pi` livelli: forni- e usce l’implementazione degli algoritmi allo stato dell’arte per questa scienza,consentendo a chiunque di applicarli sul proprio database; in aggiunta sonodisponibili una grande variet` di procedure per la trasformazione dei dati ain input o l’analisi dei risultati degli algoritmi. Come tutti i pacchetti opensource Weka non solo consente di visionare, modificare e distribuire i sorgen-ti ma mette anche a disposizone delle procedure che aiutano nello sviluppodi nuovi metodi: ` possibile infatti, grazie all’uso delle interfacce comuni esviluppare i propri algoritmi di associazione, clustering o associazione senzadoversi preoccupare di alcuni dettagli secondari, come per esempio leggere oscrivere dal database, implementare filtri o tool di valutazione dei risultati;Weka fornisce gi` tutte queste utilit`, oltre ad una nutrita documentazione a aonline, 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. Persaperne di pi` si pu` visitare e scaricare Weka dal sito dell’universit` neo- u o azelandese di Waikato [wek] mentre il libro di Witten e Frank [WF05] dedicaun intero capitolo a questo tool, alle sue caratteristiche e come sfruttarne a 19
  34. 34. Figura 2.10: Esempio di database in formato ARFFpieno le potenzialit`. a Il nucleo centrale del progetto ` il package weka.core; qui vi sono definiti ei metodi per l’elaborazione primaria dei dati, a cominciare dalla lettura deglioggetti nel database. Le classi principali in questo package sono Attribute,Instance e Instances. Un oggetto della classe Attribute rappresenta unattributo (identificato da nome, tipo e valore) ed il numero di istanze ` epari al numero di colonne del database. Un oggetto della classe Instancecontiene il valore dell’attributo di una particolare istanza; un insieme diqueste istanze (il dataset) ` rappresentato da un oggetto di tipo Instances. e2.3.1 Algoritmo AprioriWeka include l’algoritmo Apriori per generare regole associative nella clas-se weka.association.Apriori. Per testare l’algoritmo si pu` utilizzare o 20
  35. 35. 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 Wekal’interfaccia grafica o da terminale digitanto il comando java weka.association.Apriori -t <<training file>>.arffdove training file ` il nome del file contenente il database in formato earff (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 eil 10%. La confidenza minima ` settata al 90%. Nell’esempio in figura il esupporto decresce fino al 20% prima di riuscire a generare le 10 regole e ci` orichiede 10 passaggi ma tutti questi parametri sono modificabili da partedell’utente con le opzioni di tabella 2.3.1. La regole generate vengono rappresentate nella seconda parte dell’outputdell’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 etipo trovati nel database. In modo analogo il numero nella conseguenzadella regola rappresenta quante volte questa regola ` verificata nel database ementre tra parentesi c’` la confidenza della regola stessa. eAl di sopra delle regole si trovano il numero di insiemi trovati per ognilunghezza considerata; nell’esempio 6 insiemi di lunghezza 4, 39 di lunghezza3, e cos` via. ı 21
  36. 36. Figura 2.11: Output dell’algoritmo Apriori su Weka2.3.2 Algoritmo K-MeansNel package weka.clusterers sono presenti alcuni degli algoritmi di clu-stering pi` conosciuti, tra i quali Cobweb, DBScan, EM e, naturalmente, uK-Means. Per il suo utilizzo si pu` utilizzare l’interfaccia grafica oppure il o 22
  37. 37. 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 Wekacomando java weka.clusterers.SimpleKMeans -t <<training file>>.arffdove training file ` il nome del file contenente il database in formato earff con attributi numerici (K-Means non pu` elaborare attributi nominali), oeventualmente 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 enotare i cluster trovati, quante istanze sono state assegnate ad ognuno diessi e statistiche dettagliate su media e la varianza dei dati. Esistono 4 modi differenti affinch` Weka elabori i cluster, a scelta dell’u- etente: • 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
  38. 38. Figura 2.12: Output dell’algoritmo K-Means su Weka Nell’esempio di figura 2.12 K-Means ha clusterizzato il dataset iris (vedidettagli nel capitolo 7) in 3 cluster, ognuno dei quali contenente 50 istanze.Per ogni attributo viene calcolata la media e la deviazione standard. 24
  39. 39. Capitolo 3Architetture eProgrammazione Parallela “C’` vero progresso solo quando i vantaggi di una nuova tecnologia e diventano per tutti.” Henry Ford (1863-1947), industriale americano. 25
  40. 40. 3.1 DefinizioniUno dei principali metodi per aumentare le prestazioni di un sistema d’e-laborazione dati, ` quello di aumentare il numero di processori che questo eprevede, distribuendo fra di essi il carico computazionale. Originariamentequesto problema ` stato affrontato in due modi diversi, che hanno portato eallo sviluppo di tecniche per la gestione di sistemi paralleli e sistemi di-stribuiti. Un sistema parallelo ` un sistema in cui si hanno vari processori estrettamente collegati tra di loro e che condividono la maggior parte dellerisorse presenti. Un sistema distribuito ` invece un sistema in cui si hanno evarie unit` elaborative, indipendenti tra di loro ma collegate tramite una aqualche rete. L’idea base dei computer paralleli, quindi, ` che diversi processori pos- esano cooperare nella soluzione di un singolo problema. Il motivo che spingead occuparsi di calcolo parallelo ` proprio il tentativo di velocizzare il calco- elo della soluzione dei problemi computazionali. Intuitivamente si potrebbepensare 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` asoltanto in casi molto particolari questo incremento di velocita pu` essere oraggiunto e comunque ` compito del programmatore progettare l’algoritmo ein modo da ottenere il massimo beneficio da architetture multi processore. Definiamo allora lo speedup come tserial S= tparallelrapporto tra il tempo di esecuzione seriale e parallelo; il valore ottentuto ` eindice della bont` della parallelizzazione ottenuta, migliore quanto pi` vicino a uad n, numero di processori. L’efficienza, invece, ` il rapporto tra speedup eparallelo e numero di processori S E= ne da una stima di quanto stiamo sfruttando il potenziale offerto dalla pa-rallelizzazione. In pratica un’efficienza pari a 1, significa una riduzione deitempi di risposta dell’algoritmo parallelo di un fattore n. Amdahl indic` il limite presente nello Speedup teorico, cio` nell’aumento o e 26
  41. 41. di prestazioni dovuto al parallelismo, come: 1 S≤ . α + (1 − α)/ndove α ` la quota di codice non parallelizzabile e (1-α) ` parallelizzabile su e en 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 e1000 processori.3.2 Architetture Figura 3.1: Tassonomia di Flynn La pi` famosa classificazione (tassonomia) delle architetture per i sistemi uparalleli ` quella proposta da Flynn in figura 3.1. Secondo questa tassonomia ele due pi` importanti caratteristiche di un elaboratore sono il numero di flussi udi istruzioni che esso pu` processare ad ogni istante ed il numero di flussi odi dati su cui esso pu` operare simultaneamente. Combinando queste due ocaratteristiche ` possibile ottenere le seguenti quattro classi architetturali, ealle quali se ne aggregano altre due pi` recenti: u • SISD (Single Instruction stream - Single Data stream) • SIMD (Single Instruction stream - Multiple Data stream) 27
  42. 42. • 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 diVon Neumann che ` quella usata da tutti i calcolatori convenzionali, in cui eil singolo processore obbedisce ad un singolo flusso di istruzioni (programmasequenziale) 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` adi elaborazione che eseguono contemporaneamente la stessa istruzione malavorano su insiemi di dati diversi. In genere, il modo di implementare learchitetture SIMD ` quello di avere un processore principale che invia le eistruzioni da eseguire contemporaneamente ad un insieme di elementi dielaborazione che provvedono ad eseguirle. I sistemi SIMD sono utilizza-ti principalmente per computazioni specializzate in parallelo, grafica CAD, 28
  43. 43. grafica vettoriale. Prima Intel con SSE poi AMD con 3DNow! hanno ag-giunto estensioni SIMD ai propri processori, via via sempre pi` sofisticate utanto che i pi` moderni processori di entrambe le case utilizzano l’ultima uversione denominata SSE3. La classe MISD (in figura 3.4), in cui pi` flussi u Figura 3.4: Architettura MISDdi istruzioni (processi) lavorano contemporaneamente su un unico flusso di `dati, non ` stata finora utilizzata praticamente. E da notare che, mentre nel- ela classe SIMD la granularit`, ovvero la dimensione delle attivit` eseguibili a ain parallelo, ` quella delle istruzioni, nella classe MISD e in quella MIMD la egranularit` ` 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
  44. 44. cessi sono in esecuzione contemporaneamente su pi` processori ed utilizzano udati propri o condivisi, rappresenta un’evoluzione della classe SISD. Infatti,la realizzazione di queste architetture avviene attraverso l’interconnessionedi 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 orappresentino il punto di partenza per la costruzione di macchine paralleledi tipo general-purpose. Spesso il modello SPMD utilizza il message passing tra i diversi nodidi elaborazione ed ` supportato da specifiche librerie MPI Message Passing eInterface. Un solo programma con costrutti di controllo che scelgono partidifferenti del programma a seconda del nodo su cui viene lanciato. Questasar` l’architettura obbligata per la parallelizzazione degli algoritmi in Weka, aoggetto della tesi: un solo programma lanciato in parallelo su pi` proces- usori a memoria condivisa che elaborano flussi di dati differenti. Il modelloMPMD ha i singoli nodi che eseguono programmi differenti (tipicamentemaster/slave). Figura 3.6: Esempio di architettura quad core: AMD opteron [amd] Un’altra importante differenza nei computer paralleli riguarda il modellodi memoria utilizzato. Esso pu` essere di tipo condiviso (Shared Memory) oo distribuito (Distributed Memory). Un sistema a memoria condivisa ` mo- estrato in Fig 3.6. Qui, tutti i processori hanno accesso ad una memoriacomune. Ciascun processore pu` anche avere una propria memoria locale o 30
  45. 45. per il codice del programma e dati temporanei, mentre la memoria comune` utilizzata per dati e risultati necessari a pi` processori. Nel caso di AMDe uOpteron, nella foto, ogni core ha a disposizione memoria cache L1 ed L2privata 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 compiuteattraverso la memoria comune. Il pi` grande vantaggio dei sistemi a me- umoria condivisa ` l’alta velocit` delle comunicazione tra processori, mentre e ail grande svantaggio ` che processori diversi possono desiderare di utilizza- ere la memoria comune nello stesso istante. In tal caso uno dei processorideve attendere che sia liberata la memoria al fine di evitare conflitti (unprocessore potrebbe alterare il dato proprio mentre l’altro li sta leggendo).Questo ritardo pu` crescere al crescere del numero di processori. In genere ola memoria condivisa viene usata su sistemi con un numero di processoribasso.3.3 Gestione della memoriaLa gestione della memoria, nei sistemi a memoria condivisa non si discostadi molto da come avviene nel caso di un sistema monoprocessore ma bisognaporre particolare attenzione alla modalit` di accesso se si vogliono ottenere aconsistenza e prestazioni. Alcune delle metodologie utilizzate per risolverequesto 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
  46. 46. ed operazioni di riduzione per giungere al risultato finale dall’insieme di risultati parziali ottenuti parallelamenteDal 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 ` eaccessibile dai vari processori. Questi sistemi possono essere a loro voltacaratterizzati 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
  47. 47. 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 CacheLa memoria cache ` un tipo di memoria piccola, ma molto veloce, che man- etiene copie dei dati ai quali si fa pi` frequentemente accesso in memoria uprincipale. Finch´ la maggior parte degli accessi alla memoria avviene su edati caricati nella cache, la latenza media dell’accesso alla memoria sar` api` vicina alla latenza della cache piuttosto che a quella della memoria uprincipale. 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- ezione. L’indice di una locazione in memoria principale ` chiamato indirizzo edi memoria. Ogni locazione nella cache ha un’etichetta che contiene l’indicein memoria principale del dato ivi caricato. Nelle cache dati, questi valorisono chiamati blocchi di cache o linee di cache. Quando il processore vuole leggere o scrivere in una data locazione inmemoria principale, inizialmente controlla se il contenuto di questa loca-zione ` caricato in cache. Questa operazione viene effettuata confrontando el’indirizzo della locazione di memoria con tutte le etichette nella cache che 33
  48. 48. potrebbero contenere quell’indirizzo. Se il processore trova che la locazionedi memoria ` in cache, si parla di cache hit (accesso avvenuto con successo), ealtrimenti di cache miss (fallimento d’accesso). Nel caso di un cache hit,il processore legge o scrive immediatamente il dato sulla linea di cache. Ilrapporto tra cache hit e accessi totali ` chiamato anche hit rate ed ` una e emisura dell’efficacia della cache stessa. Nel caso di un cache miss, la maggior parte delle cache crea una nuovaentit`, che comprende l’etichetta appena richiesta dal processore ed una acopia del dato dalla memoria. Un fallimento del genere ` relativamente elento, 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 cachegeneralmente deve eliminare il contenuto di una delle linee. L’euristica cheutilizza per scegliere quale dato eliminare ` chiamata politica di rimpiazza- emento. Il problema fondamentale di ogni politica di rimpiazzamento ` quello edi dover predire il dato della cache che verr` richiesto nel futuro con minor aprobabilit`. Predire il futuro ` difficile, soprattutto per le cache hardware a eche devono sfruttare regole facilmente implementabili in circuiteria, perci` oesistono una serie di politiche di rimpiazzamento e nessuna di esse pu` es- osere ritenuta perfetta. Una delle pi` popolari, la LRU (dall’inglese Least uRecently Used, cio` usato meno recentemente), rimpiazza, appunto, il dato eal 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 odiventare obsoleti. I protocolli di comunicazione tra i sistemi di gestionedelle cache che conservano la consistenza dei dati sono chiamati protocollidi coerenza.Cache MissCon cache miss (fallimento della cache) ci si riferisce ad un intento fallitonel leggere o scrivere un pezzo di dati nella cache, che ha come risultatouna latenza molto pi` lunga nell’accesso alla memoria principale. Per un ufallimento nella lettura dalla cache istruzioni, il processore deve aspettare(stallo) finch´ l’istruzione non ` caricata dalla memoria principale. Un fal- e e 34
  49. 49. limento della cache causato dal caricamento di un dato pu` invece essere omeno doloroso, perch´ le altre istruzioni non correlate ad esso possono co- emunque essere eseguite, finch´ l’operazione che richiede i dati da caricare epu` essere eseguita. Comunque, i dati sono spesso usati immediatamente odopo l’istruzione di caricamento. L’ultimo caso di cache miss, cio` un fal- elimento in scrittura, ` il meno preoccupante, perch´ di solito la scrittura ` e e ebufferizzata. Il processore pu` continuare tranquillamente finch´ il buffer o enon ` pieno. (Non esiste un fallimento nella scrittura della cache istruzioni eperch´ esse sono di sola lettura). e Nei moderni processori multi-core la cache ` multilivello, talvolta fino a e3, con una cache L1 di dimensioni molto piccole (attorno ai 128 KByte) eduna L2 di dimensioni maggiori, attorno ai 2 MByte. Le cache multilivellogeneralmente 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 SincronizzazioneLa presenza di primitive di sincronizzazione tra processi che consentano lamutua esclusione nella loro esecuzione, ` necessaria per proteggere le sezioni ecritiche, e quindi la consistenza della memoria tra di loro condivisa, oltreche per garantire una certa successione temporale nelle azioni realizzate. Inun sistema operativo multiprocessore possono essere implementate a livellodi sistema, tutte le primitive di sincronizzazione tra i processi normalmen-te presenti anche nei sistemi operativi monoprocessore, quali ad esempio isemafori e le variabili condition. In questo paragrafo affronteremo solo ilproblema della sincronizzazione dei processi che si trovino su processori di-versi: questa ` infatti la situazione che si verifica quando i vari kernel che si etrovano su processori diversi devono modificare le strutture dati tra di lorocondivise in sistemi UMA e NUMA. Un lock ` una struttura dati condivisa utilizzata per realizzare la mutua eesclusione tra i processi, in quanto ciascun lock pu` essere posseduto da oun solo processo alla volta. Su di un lock possono essere realizzate dueoperazioni, che chiameremo acquisisci lock (lock ) e rilascia lock (unlock ). 35
  50. 50. La prima cerca di trasferire il possesso del lock cui fa riferimento (ci possonoessere pi` lock per ogni processo, una per ogni risorsa) al processo che la uchiama, ponendolo in qualche modo in attesa se il lock ` in quel momento eposseduto da un altro processo. La seconda rilascia il possesso del lock cuifa riferimento, consentendo l’avanzamento di uno dei processi in attesa sudi esso. Per realizzare una sezione critica, basta quindi racchiuderla tra ledue chiamate acquisisci lock e rilascia lock. Uno dei modi per realizzare queste due chiamate ` esemplificato nelle eseguenti due funzioni, associando quindi ad esempio ad un lock il valore 1se questo appartiene a qualcuno e 0 se ` libero. evoid 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 efinch´ non viene soddisfatta. Ci` presuppone ovviamente che il possesso del e olock sia di un processo che si trova su di un altro processore o almeno inun altro thread. Nel caso in cui ci` non sia vero sono possibili altre solu- ozioni che a prima vista sembrerebbero in ogni caso pi` efficienti, come ad uesempio bloccare l’esecuzione del processo in attesa sul lock, schedulandone `un altro finch´ questo non sia stato rilasciato. E possibile eventualmente eaggiungere delle piccole pause tra due tentativi successivi, onde evitare chela contesa sul bus che gli accessi al lock determina, causi un rallentamentonell’esecuzione degli altri processi e quindi eventualmente del rilascio dellock 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 unlock, fintanto che questo non appartenga a nessun processo scrittore. Unaltro modo per realizzare la sincronizzazione, ` tramite un evento. Questi evengono utilizzati principalmente per garantire una certa successione tem-porale: un processo blocca la sua esecuzione su di un evento finch´ questo e 36
  51. 51. non si verifica. Il concetto di evento pu` essere utilizzato per la sincro- onizzazione tra kernel che si trovino su processori diversi in sistemi UMA eNUMA, collegati da un bus che consenta la propagazione delle interruzioni.La routine di gestione delle interruzioni di un certo kernel sar` quindi in aattesa sull’evento interruzione generato da un altro kernel, e al suo arrivopotr` prendere le opportune decisioni. In Java, presentato nel paragrafo 3.6, asono disponibili molteplici soluzioni per la concorrenza e la sincronizzazione,inclusa la gestione a eventi.3.5 Multi coreIl termine multi core si usa per descrivere una CPU composta da pi` core, uovvero da pi` “cuori” di processori fisici indipendenti, le rispettive Cache e i ucache controller in un singolo package. Questo tipo di architettura consentedi 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 mail 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 commercioi primi esemplari di una nuova generazione di microprocessori, basati suirispettivi prodotti esistenti, e contenenti due core. Aumentare ulteriormente la frequenza di clock di una CPU single core ` estato giudicato dai progettisti una via molto onerosa e complicata, dato che iconsumi dei processori hanno superato i 100 W e si presenta un conseguenteproblema di raffreddamento dei circuiti. Si ` deciso quindi di puntare sul pa- erallelismo in modo da poter aumentare il numero di operazioni eseguibili inun unico ciclo di clock. Tale approccio comporta anche alcuni svantaggi, inquanto i programmi devono essere ottimizzati per un utilizzo multi-threadper poter sfruttare appieno le caratteristiche di questi processori, in casocontrario impegneranno solo uno dei core presenti, lasciando gli altri presso-ch´ inutilizzati. Potrebbe addirittura verificarsi che un’applicazione risulti edi pi` lenta esecuzione su un processore dual core e, al momento del lancio, uerano 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
  52. 52. conto non del funzionamento su un sistema dual core, ma su un sistema api` core, non richiederebbe poi grosse modifiche per essere utilizzato su un udual core o su un quad core. Secondo altri invece, gli sforzi necessari perrealizzare software multi processore che funzioni in maniera ottimale satu-rando tutti i core e non occupandoli in modo disomogeneo saranno esageratiin relazione con i reali vantaggi, soprattutto di impatto di costi. I primi processori dual core commerciali sono sostanzialmente quelli dellaprecedente generazione di processori di Intel e AMD montati su un unicopackage, tuttavia esistono differenti approcci attraverso i quali si possonorealizzare chip dual core sulla realizzazione fisica di queste CPU e Dualcore (gestione della cache), per considerazioni sulla fruizione della cache daparte di ciascun core). Al momento del lancio dei primi processori dellanuova generazione dedicati al settore desktop, vale a dire gli Intel PentiumD (basati sul progetto Smithfield ), le frequenze dei processori erano minoririspetto a quelle dei rispettivi processori monoprocessore AMD. I primi Pentium D erano formati appunto da 2 core Prescott montatisullo stesso package; successivamente sono arrivati anche quelli basati sucore Presler, divenuti la seconda generazione di processore Pentium D (incui erano sempre presenti due core uguali affiancati, anche se non sullostesso package per poter cos` aumentare le rese produttive), con processo ıproduttivo a 65 nm. Dopo Presler ` stata la volta del Core 2 Duo Conroe earrivato sul mercato a luglio 2006. Intel ha inoltre progressivamente esteso l’utilizzo di questa tecnologia atutti i segmenti di mercato, inclusi quello mobile, di cui il primo esponente` stato il Core Duo Yonah e successivamente Merom, entrambi evoluzioniedel Pentium M, e ovviamente al settore server. In questa categoria i primidual core sono Montecito evoluzione del processore a 64 bit Itanium 2 concache L3 che raggiunge in alcune versioni i 24 MB di capacit`, mentre per i aserver 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, asistemi workstation e server a 2 e 4 processori. Da Conroe ` derivato anche elo Xeon Woodcrest, per sistemi server di fascia entry level dotati di duesocket. Se Intel ha avuto il merito di rendere questi processori disponibili pra- 38
  53. 53. ticamente a tutti, i primi processori multi core presentati sul mercato sonostati, 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 corenon omogenei, e l’UltraSPARC T1, processore a 8 core omogenei sviluppatoda Sun Microsystems per il mercato server (In particolare per Web servercon 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 produzionecomplessiva. Una percentuale di questo tipo pu` sembrare limitata, ma al- ola luce del totale di processori commercializzati nel 2007 (stimato in circa230 milioni) e della quota di mercato del 75% circa detenuta da Intel, se nericava un totale di almeno 3 milioni di processori quad core [Cor].3.5.1 RealizzazioneAl momento, esistono 3 metodi differenti per creare un chip dual core: DieSingolo, Die Doppio e Die Monolitico. Il Die ` il blocco di silicio al centro edi un processore che contiene il cuore elaborativo della CPU, il core.Die singoloFigura 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 uun chip dual core, ma ovviamente ` anche pi` limitante per quanto riguarda e u 39
  54. 54. le prestazioni e la resa produttiva. Infatti, prendendo ad esempio proprio ilcaso di Smithfield, che ` sostanzialmente formato da 2 core Prescott (sin- egle core), ` possibile osservare, ovviamente in maniera molto semplicistica, ecome per realizzarlo sia sufficiente utilizzare la stessa maschera litograficadisegnata per il processore Prescott, e “stamparla” 2 volte sul wafer di siliciointerconnettendo i due core cos` realizzati. Rimane comunque il problema ıche se anche solo uno dei 2 core stampati ` difettoso, tutto il chip diventa einutilizzabile, ovvero non potr` essere un Pentium D, e potrebbe quindi es- asere rivenduto come semplice Pentium 4 Prescott dopo aver disabilitato unodei due core. L’evoluzione delle tecniche produttive probabilmente ha gi` decretato la a“morte” di tale approccio, che sebbene semplice da realizzare pu` risultare oindirettamente costoso per la probabilit` di non avere molti core attigui sul awafer perfettamente funzionanti. Intel stessa infatti ha realizzato tutti glialtri progetti dual e multi core utilizzando gli altri approcci e AMD invecenon ha mai utilizzato tale approccio. La tecnica pi` sofisticata attualmente uin 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. Daparte sua per` si avvantaggia del fatto di essere progettato tenendo conto odi questi fattori, mentre i core utilizzati nel die singolo non erano progettatiper essere multi core. Ognuno dei due core comunque, manteneva la propria indipendenza equindi anche le cache L2 erano sdoppiate e ogni core aveva la “propria” cacheL2, quindi solo con questa poteva avere una sorta di accesso privilegiato.Proprio per questo motivo, per Smithfield, non si parlava di una cache L2 da2 MB ma di 2x1MB. Affinch´ un core potesse accedere ai dati memorizzati enella cache dell’altro era necessario trasferire i dati attraverso il BUS disistema, con il rischio di saturarlo. La scelta di questa implementazione inSmithfield, penalizzante dal punto di vista delle prestazioni, era giustificataproprio dalla sua relativa semplicit` realizzativa e progettuale. Solo con al’avvento del die monolitico si riuscir` a porre rimedio a questo collo di abottiglia, condividendo l’intera cache L2 tra i core in modo da liberare ilbus di sistema e consentire la condivisione dei dati in memoria a libello dicache. 40
  55. 55. 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 ununico package e collegarli successivamente con collegamenti esterni. Il primoprogetto Intel ad avvantaggiarsi di questo approccio ` stato il Pentium D ePresler. Tale metodo, seppure leggermente pi` complesso nella realizzazione udi quello a Die singolo, in quanto collegare i core solo in un secondo temporichiede maggiore tempo che realizzare i collegamenti direttamente sul silicio,risulta per` complessivamente il metodo pi` economico dal punto di vista o udel produttore, infatti ` possibile “scegliere” quali devono essere i due core eche andranno poi collegati insieme, facendo cadere la necessit` dei due core aaffiancati 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 modelliche tolleravano frequenze di clock elevate potevano essere marchiati comeveloci Pentium 4 single core, mentre gli altri potevano essere accoppiati perrealizzare i modelli dual core Pentium D che generalmente funzionavano aclock inferiori. C’` tuttavia un grande svantaggio nell’inserire due core indipendenti in eun solo package. Quando un core accede ai dati, anche l’altro far` lo stesso, autilizzando risorse non necessarie. La separazione fisica dei core compor-ta due inconvenienti: la necessit` di collegamenti esterni e, ovviamente la aseparazione della cache che non ` pi` una scelta progettuale ma uno scot- e uto da pagare. Il primo inconveniente in realt` ` comunque relativamente a eeconomico da superare, mentre il secondo rappresenta comunque un limiteintrinseco di questo approccio. 41
  56. 56. 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 ulizzare ma ovviamente ` anche quello che garantisce le migliori prestazioni edi una CPU multi core. Tale approccio deve essere preventivato fin dalleprime fasi della progettazione del processore ed ` stato utilizzato per la pri- ema volta da Intel per i Core Duo Yonah e gli Itanium 2 Montecito. Il suopi` grande pregio consiste nell’offrire ai progettisti l’opportunit` di condivi- u adere alcune unit` del processore; nel caso pi` semplice, tale condivisione si a ulimita alla cache che viene realizzata in un unico blocco condiviso tra tuttii core (in processori che utilizzano gli altri approcci costruttivi, la cache ` enecessariamente equamente divisa tra i core e l’accesso diretto a ciascunacache ` riservato esclusivamente al rispettivo core, il quale per accedere alle ealtre deve far transitare i dati sul BUS). In casi pi` complessi le unit` con- u adivise possono essere anche altre, come il memory controller della RAM (almomento solo nei processori AMD) gli scheduler che ripartiscono il caricotra i vari core, ecc. A questo punto ` infatti ormai chiaro che la pi` grossa lacuna delle prime e uversioni di processori dual core risiedeva proprio nella esclusivit` della cache aL2 e la necessit` di far transitare i dati sul gi` trafficato BUS di sistema. a aIl primo processore a colmare questa lacuna ` stato il Core Duo Yonah una eCPU mobile dual core in cui la cache L2 era condivisa tra i 2 core. Ognicore quindi poteva accedere alla totalit` della cache lasciando libero il BUS adi sistema che poteva quindi limitarsi a far transitare solo i dati da, e per,la memoria RAM. 42
  57. 57. Figura 3.12: Intel Xeon quad core [int] Appare quindi evidente come tutti i pi` recenti progetti di processo- uri multi core puntino soprattutto all’utilizzo di quest’ultimo approccio co-struttivo, riservando gli altri (soprattutto quello a Die Doppio), per risolverespecifiche 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 adual core: la prima immagine rappresenta la prima serie a die singolo mentrela a destra a die monolitico. Appare evidente subito il diverso utilizzo dellacache di secondo livello che nel primo caso ` separata per ogni core mentre nel enei monolitici ` condivisa. Quest’ultimo approccio velocizza le performance edei processori che consentono di accedere indistintamente ai dati di ognisingolo core. 43
  58. 58. 3.6 Multithreading in JavaCon l’avvento delle nuove architetture parallele la semplice programmazio-ne sequenziale a singolo processo non era adeguata per sfruttare le risorse adisposizione. La necessit` di poter eseguire pi` programmi contemporanea- a umente ` antecedente all’avvento dei multiprocessori, gia Windows 3.0 (che epochi 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 perpoter simulare le architetture recenti. Oggi i programmi pi` sofisticati suddividono i loro job in unit` pi` pic- u a ucole, processi o thread, che possono avanzare nel tempo parallelamente inmodo reale (se ci sono pi` cpu che processi) o simulato (suddividento il tem- upo di cpu tra i thread se necessario). I thread multipli hanno origine dallostesso processo e condividono lo spazio di memoria, il codice eseguibile e idati globali, potendo in questo modo suddividere il lavoro a pi` processori uin modo efficiente. Il costo da pagare ` una notevole complessit` che pu` e a oessere spesso difficile da gestire. Il problema maggiore ` la sincronizzazione: espesso 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 possonocausare inconsistenza dei dati o stalli, risolvibili con vari approcci di mutuaesclusione. I moderni processori multi-core aumentano le loro prestazioni all’aumen-tare del grado di parallelismo proprio perch` raggiungono il risultato in modo ecooperativo rispetto al singolo flusso di dati. Dal punto di vista del sistemaoperativo una cpu di questo tipo si avvantaggia dal fatto di poter dedicareunit` di calcolo separate per pi` programmi in esecuzione, ma dal punto a udi vista algoritmico (di interesse in questa tesi), lo stesso algoritmo svilup-pato per processori a core singolo non si avvantaggeranno dell’uso dei coremultipli. Essi infatti utilizzeranno un solo core per tutti i calcoli, lasciandogli altri potenzialmente inutilizzati, ecco perch` ` necessario riprogettare e eeriscrivere interamente gli algoritmi in modo parallelo, in modo diverso ovvia-mente dagli algoritmi per sitemi distribuiti, potendo contare sulla memoriacondivisa. Java ` nato da subito con l’ambizione di poter essere facilmente utiliz- ezato con la programmazione multi-thread, grazie all’implementazione della 44

×