new distribuovaný výpo£et induktivních...

eské vysoké u£ení technické v PrazeFakulta elektrotechnická

Bakalá°ská práce

Distribuovaný výpo£et induktivních model·

Jakub pirk

Vedoucí práce: Ing. Pavel Kordík, Ph.D.

Studijní program: Elektrotechnika a informatika strukturovaný bakalá°ský

Obor: Informatika a výpo£etní technika

kv¥ten 2008

Pod¥kování

Rád bych na tomto míst¥ pod¥koval v²em, kte°í m¥ podporovali p°i psaní této práce.

v

Prohlá²ení

Prohla²uji, ºe jsem svou bakalá°skou práci vypracoval samostatn¥ a pouºil jsem pouze podkladyuvedené v p°iloºeném seznamu.Nemám závaºný d·vod proti uºití tohoto ²kolního díla ve smyslu 60 Zákona £. 121/2000 Sb.,o právu autorském, o právech souvisejících s právem autorským a o zm¥n¥ n¥kterých zákon·(autorský zákon).

V Praze dne 20.5. 2008 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

vii

Abstract

The goal of this thesis is to introduce inductive modelling, especially GAME method, as oneof the methods used in data mining process and compare this method with other methodsof data mining. In the next part I would like to present terms like parallelism and parallelprograming on Symmetric multiprocessing systems, explain the di�erence in basic approaches of�nding parallel solutions, discuss the posibilities and assets of parallelizing evolution of inductivemodels generated by GAME method and implement the chosen solution in JAVA programminglanguage. The goal is not to implement new natural evolution algorithms, the ones used inGAME method are to be preserved.

Abstrakt

Cílem práce je p°iblíºit metodu induktivních model·, zvlá²t¥ pak metodu GAME, jako jednu zmetod vyuºíván p°i procesu získávání v¥domostí a podat stru£né srovnání s ostatními metodamizískávání zku²ení. Následn¥ pak podat teoretický základ pro vysv¥tlení problému paralelizace aparalelního programování na víceprocesorových systémech se sdílenou pam¥tí, vysv¥tlit rozdílymezi základnímy p°ístupy k paralelním °e²ením, zváºit moºnosti a p°ínosy paralelizace procesuvýpo£tu induktivních model· generovaných metodou GAME a vybrané °e²ení implementovatv jazyku JAVA. Cílem práce není implementace nových výpo£etním algoritm· jako takových,jsou zachovány algoritmy pouºívané metodou GAME.

ix

Obsah

Seznam obrázk· xiii

1 Úvod 1

2 Proces dobývání znalostí - data mining 32.1 P°edstavení problému . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 Metodologie data miningu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2.1 Metodologie "5A" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2.2 Metodologie "SEMMA" . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2.3 Metodologie "CRISP-DM" . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.3 Podrobn¥j²í popis jednotlivých fází . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3.1 Porozum¥ní problematice . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3.2 Porozum¥ní dat·m . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3.3 P°íprava dat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3.4 Modelování . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3.5 Ohodnocení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3.6 Nasazení modelu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.4 Metody data miningu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.4.1 Rozhodovací stromy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4.2 Rozhodovací pravidla . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4.3 Asocia£ní pravidla . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.4.4 Statistické metody . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.4.5 Nejbliº²í soused . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.4.6 Neuronové sít¥ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.5 Shrnutí . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 Induktivní modelování 153.1 P°edstavení metody idnuktivního modelování . . . . . . . . . . . . . . . . . . . . 153.2 MIA GMDH a GAME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.3 Rozdílná topologie modelu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.4 Rozmanitost neuron· a u£ebních metod . . . . . . . . . . . . . . . . . . . . . . . 163.5 Niching genetický algoritmus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.6 Analýza vstupních parametr· . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.7 FAKE GAME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.8 Shrnutí . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4 Paralelismus a paralelní programování 194.1 Paralelismus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.2 Architektura paralelních systém· . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.2.1 Popis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.2.2 Flynnova taxonomie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.2.2.1 SISD model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.2.2.2 SIMD model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.2.2.3 MISD model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.2.2.4 MIMD model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.2.3 Pam¥´ové architektury . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.2.3.1 Sdílená pam¥´ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.2.3.2 Distribuovaná pam¥´ . . . . . . . . . . . . . . . . . . . . . . . . . 22

xi

4.2.4 Symetrické multiprocesory (SMP) . . . . . . . . . . . . . . . . . . . . . . . 224.3 Paralelní programování na SMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.3.1 Modely paralelního programování . . . . . . . . . . . . . . . . . . . . . . . 234.3.1.1 Procesový model . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.3.1.2 Vláknový model . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.3.2 Co je pot°eba vzít v úvahu p°i návrhu paralelního programu . . . . . . . . 244.3.2.1 Amdahlovo pravidlo . . . . . . . . . . . . . . . . . . . . . . . . . 244.3.2.2 Problematika Load Balancingu a Granularity . . . . . . . . . . . 244.3.2.3 Datová konzistence . . . . . . . . . . . . . . . . . . . . . . . . . . 254.3.2.4 Podmínky korektnosti paralelního programu . . . . . . . . . . . 26

4.3.3 Paralelní programování v jazyku JAVA . . . . . . . . . . . . . . . . . . . . 264.3.3.1 Vlastnosti vláken . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.3.3.2 Plánování vláken . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.3.3.3 Synchronizace vláken . . . . . . . . . . . . . . . . . . . . . . . . 28

5 Paralelizace aplikace GAME 315.1 Pr·zkum moºností . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.2 Výb¥r po£tu spou²t¥ných vláken . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.2.1 as pot°ebný na tvorbu vláken . . . . . . . . . . . . . . . . . . . . . . . . 325.2.2 as pot°ebný na synchronizaci . . . . . . . . . . . . . . . . . . . . . . . . 325.2.3 Zhodnocení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.3 Implenetace vybraného °e²ení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345.3.1 Metoda teachUnitsParallel a t°ída TeachThread . . . . . . . . . . . . . . . 345.3.2 Výb¥r optimaliza£ních metod . . . . . . . . . . . . . . . . . . . . . . . . . 355.3.3 Uchovávání výlsedk· optimalizací . . . . . . . . . . . . . . . . . . . . . . . 355.3.4 Výb¥r mezi paralelním a sekven£ním zpracováním . . . . . . . . . . . . . 365.3.5 Vizualizace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.4 Testování a zhodnocení zvoleného °e²ení . . . . . . . . . . . . . . . . . . . . . . . 365.4.1 HW speci�kace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365.4.2 M¥°ení doby b¥hu - metodika . . . . . . . . . . . . . . . . . . . . . . . . . 375.4.3 Testovací data a kon�gurace sít¥ GAME . . . . . . . . . . . . . . . . . . . 37

5.4.3.1 M¥°ení A: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385.4.3.2 M¥°ení B: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385.4.3.3 M¥°ení C: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385.4.3.4 M¥°ení D: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.4.4 Zm¥°ené výsledky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.4.5 Zhodnocení nam¥°ených údaj· . . . . . . . . . . . . . . . . . . . . . . . . 42

6 Záv¥r 436.1 Zhodnocení vybraného °e²ení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436.2 Moºná vylep²ení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

A Obsah p°iloºeného CD 45

B Literatura 47

xii

Seznam obrázk·

2.1 Metodologie SEMMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Metodologie CRISP-DM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3 Ukázková data pro p°íklad po£así . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.4 Rozhodovací strom pro p°íklad po£así . . . . . . . . . . . . . . . . . . . . . . . . 92.5 Ukázková data pro p°íklad £o£ky . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.6 Výsledná pravidla pro t°ídu recomendation=hard . . . . . . . . . . . . . . . . . . 102.7 Ukázka asocia£ních pravidel pro p°íklad po£así . . . . . . . . . . . . . . . . . . . 112.8 Nejbliº²í soused . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.9 Model um¥lého neuronu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1 Porovnání p·vodní MIA GMDH sít¥ a sit¥ GAME . . . . . . . . . . . . . . . . . 153.2 Porovnání b¥ºného genetického algoritmu a niching genetcikého algoritmu vyuºí-

vajícího metodu Deterministic Crowding . . . . . . . . . . . . . . . . . . . . . . . 17

4.1 Kategorie paralelních systém· dle Flynnovy taxonomie . . . . . . . . . . . . . . . 194.2 Model SISD architektury . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.3 Model SIMD architektury . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.4 Model MISD architektury . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.5 Model MIMD architektury . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.6 Model architektury se sdílenou pam¥tí . . . . . . . . . . . . . . . . . . . . . . . . 224.7 Model architektury s distribuovanou pam¥tí . . . . . . . . . . . . . . . . . . . . . 224.8 Architektura SMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.9 Amdahlovo pravidlo - ilustrace sniºování výhodnosti vyuºívání p°íli² vysokého

po£tu procesor· . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.1 Porovnání doby pot°ebné na tvorbu vláken . . . . . . . . . . . . . . . . . . . . . . 325.2 Porovnání synchroniza£ních metod . . . . . . . . . . . . . . . . . . . . . . . . . . 335.3 Ukázka vizualizace u£ebního procesu - sekven£ní . . . . . . . . . . . . . . . . . . . 375.4 Ukázka vizualizace u£ebního procesu - paralelní . . . . . . . . . . . . . . . . . . . 385.5 Porovnání nam¥°ených hodnot na Core 2 Due . . . . . . . . . . . . . . . . . . . . 395.6 Zrcyhlení pro jednotlivá m¥°ení na Core 2 Duo . . . . . . . . . . . . . . . . . . . 405.7 Porovnání nam¥°ených hodnot na 2x Quad Core Xeon . . . . . . . . . . . . . . . 405.8 Zrcyhlení pro jednotlivá m¥°ení na 2x Quad Core Xeon . . . . . . . . . . . . . . . 415.9 Pr·m¥rné £asy b¥hu aplikace pro jednotlivá m¥°ení na Core 2 Duo . . . . . . . . 415.10 Pr·m¥rné £asy b¥hu aplikace pro jednotlivá m¥°ení na 2x Quad Core XEON . . . 415.11 Varia£ní keo�cienty pro jednotlivá m¥°ení . . . . . . . . . . . . . . . . . . . . . . 42

xiii

KAPITOLA 1. ÚVOD 1

1 Úvod

Induktivní modelování je jednou z metod vyuºívaných p°i °e²ení problému dobývání znalostí(knowledge discovery, £i data mining). Proto budu první kapitolu této práce v¥novat práv¥problematice dobývání znalostí a r·znych metod uºívaných p°i tomto procesu.

V druhé kapitole se budu podrobn¥ji v¥novat metod¥ induktivního modelování, p°íblíºenímetody Group of Adaptive Models Evolution (GAME), jejím výhodám a úpravám oprotip·vodní modelovací metod¥ Group Method of Data Handling (GMDH).

Algoritmy pouºívané pro modelování induktivních model· jsou p°i obsáhlej²ím mnoºství vs-tupních dat výpo£etn¥ velmi náro£né, je proces paralelizace, vedle optimalizace pouºívanýchalgoritm·, dal²í moºností zrychlení výpo£tu a tím i získání modelu. Následující kapitolu budutedy v¥novat nástinu problematiky paralelního programování na distribuovaných systémech sesdílenou pam¥tí (SMP) se zam¥°ením na programovací jazyk JAVA.

Poté se zam¥°ím na rozbor moºností paralelizace aplikace GAME za pouºití stávajících algoritm·a popí²i implementace zvoleného zp·sobu.

V záv¥ru zhodnotím zvolená °e²ení a postupy.

2 KAPITOLA 1. ÚVOD

KAPITOLA 2. PROCES DOBÝVÁNÍ ZNALOSTÍ - DATA MINING 3

2 Proces dobývání znalostí - data mining

2.1 P°edstavení problému

"Proces dobývání znalostí je proces netriviální extrakce implicitních, d°íve neznámých a poten-

ciáln¥ uºite£ných informací z dat" [14].

Jedná se tedy o proces analyzování dat z r·zných perspektiv a jejich shrnutí do pro nás prosp¥²néinformace. Data mining je orientován na praktickou vyuºitelnost získaných výsledk·, hlavn¥o vytvo°ení modelu, který p°inese uºitek v podob¥ trefných prognóz a pouºitelných záver·a klasi�kací. Dnes má nejv¥t²í vyuºití ve v¥deckém výzkumu - nap°. p°i analýze genetickéinformace, p°edpov¥di po£así, geologické informace, £i v komer£ní sfé°e - nej£ast¥ji marketing.Se sou£asným rozvojem informa£ní techniky a databázových systém· ale data mining získávástále ²ir²í moºnosti praktického vyuºití - knihovní systémy, vyhledáva£e, plánování.

Podle [13] mezi nej£ast¥j²í úlohy °e²ené pomocí data miningu pat°í:

• Popis datVizualizace

Sumarizace

• Hledání "nuget·"Dominantní struktury, asocia£ní pravidla

Segmentace, shluková analýza, popis rozd¥lení dat

• PredikceKlasi�kace (predikce kategoriální prom¥nné)

Regrese (predikce spojité prom¥nné)

asové °ady (predikce závislé na £ase)

Poprvé se aktivity, které dnes ozna£ujeme jako data mining, za£ínají objevovat v 60. letechminulého století. lo nap°íklad o vyuºívání techniky regresní analýzi s automatickým výb¥remprom¥nných, £i rozhodovacími stromy, v¥t²inou v²ak o ojedin¥lé £i spí²e akademické záleºitosti.

S rozvojem statistických metod, um¥lé inteligence, masivním pouºíváním databázových aplikacía samoz°ejm¥ i technologickým rozvojem po£íta£· data miningové postupy zaznamenávájí prvnípraktické pouºití v pr·b¥hu sedmdesátých a osmdesátých let. Slovní spojení data mining tehdyov²em stále m¥lo spí²e hanlivý p°ídech: Ozna£ovalo "vyzobávání rozinek" z dat, hledání korelacíve velkých datových souborech, které � jak známo ze statistické teorie � je vystaveno obrovskémunebezpe£í, ºe "objeví" pouze nahodilé �uktuace v datech bez moºnosti zobecn¥ní a praktickéhovyuºití.

Výrazný rozvoj zaznamenává data mining po£átkem 90.let 20. století, p°i£emº první impulzyp°icházejí z konferencí o um¥lé inteligenci v USA. V té dob¥ jiº existují metody umoº¬ující sevý²e zmín¥nému problému vyhnout a navíc roste poptávka po nástrojích pro získávání pot°eb-ných informací ze stále se zv¥t²ujících objem· dat, p°edev²ím z komer£ní sféry, coº napomáhá kzavedení a uznání data miningu jako oboru aplikované v¥dy a k jeho ²irokému pouºití v komer£nípraxi. Nár·st mnoºství aplikací v oblasti data miningu má za následek vznik °ady specializo-vaných softwarových produkt· £i konzulta£ních �rem zabývajících se touto problematikou.

Vzhledem k sloºitosti a rozdílnosti proces· spjatých s data miningem se b¥hem 90. let objevilymetodologie snaºící se tento r·znorodý postup popsat.

4 KAPITOLA 2. PROCES DOBÝVÁNÍ ZNALOSTÍ - DATA MINING

2.2 Metodologie data miningu

V [12] si sice m·ºeme v p°edmluv¥ p°e£íst následující motto: "Máte-li ²patné údaje, ale dokon-alou logiku, pak jsou va²e záv¥ry zcela jist¥ mylné. Dop°ejete-li si tudíº sem tam n¥jakou trhlinuv logickém uvaºování, m·ºete díky náhod¥ dosp¥t ke správnému záv¥ru."

Práv¥ vý²e zmín¥né motto vystihuje pot°ebu vzniku n¥jaké ucelené metodologie. Ty vznikají vpr·b¥hu 90. let jednak jako produkt softwarových �rem - nap°. metody 5A �rmy SPSS, nebometoda SEMMA spole£nosti SAS, jednak jako spolupráce výzkumných £i komer£ních institucíjako "softwarov¥ nezávislé" - nap°. CRISP-DM.

2.2.1 Metodologie "5A"

Metodologii "5A" nabízí �rma SPSS jako sv·j pohled na proces dobývání znalostí:

• Assess � posouzení pot°eb projektu

• Access � shromáºd¥ní pot°ebných dat

• Analyze � provedení analýz

• Akt � p°em¥na znalostí na ak£ní znalosti

• Automate � p°evedení výsledk· analýzy do praxe.

2.2.2 Metodologie "SEMMA"

Softwarový produkt �rmy SAS, Enterprise Miner, vychází z vlastní metodologie "SEMMA" prodobývání znalostí:

• Sample - vybírání vhodných objekt·

• Explore - vizuální explorace a redukce dat

• Modify - seskupování objekt· a hodnot atribut·, datové transformace

• Model - analýza dat a vytvo°ení modelu

• Assess - porovnání model· a interpretace

2.2.3 Metodologie "CRISP-DM"

Dle [3] metodologie CRISP-DM (CRoss-Industry Standard Process for Data Mining) vzniklavrámci výzkumného projektu Evropské komise. Cílem projektu je navrhnout univerzální postup(tzv. standardní model procesu dobývání znalostí z databází), který bude pouºitelný v ne-jr·zn¥j²ích komer£ních aplikacích. Vytvo°ení takovéto metodologie umoºní °e²it rozsáhlé úlohydobývání znalostí rychleji, efektivn¥ji, spolehliv¥ji a s niº²ími náklady. Krom¥ návrhu standard-ního postupu má CRISP-DM nabízet "pr·vodce" potenciálními problémy a °e²eními, kterésemohou vyskytnout v reálných aplikacích. Na projektu spolupracují �rmy NCR (p°ední doda-vatel datových sklad·), Daimler Chrysler, ISL (tv·rce systému Clementine) a OHRA (velkáholandská poji²´ovna). V²echny tyto �rmy mají bohaté zku²enosti s reálnými úlohami dobýváníznalostí z databází. Metodika CRISP-DM uvádí následující kroky:


Obrázek 2.1: Metodologie SEMMA

• Business Understanding - porozum¥ní problematice

• Data Understanding - porozum¥ní dat·m

• Data Preparation - p°íprava dat

• Modeling - modelování

• Evaluation - vyhodnocení výsledk·

• Deployment - vyuºití výsledk·

Obrázek 2.2: Metodologie CRISP-DM

Lze také usuzovat, ºe terminologie uvád¥ná v rámci této metodiky jiº tvo°í standard v oboru.

2.3 Podrobn¥j²í popis jednotlivých fází

Jak je vid¥t v²echny metodologie popisují vpodstat¥ ten stejný proces, lze jej, podle [13] po-drobn¥ji popsat (v termínech metodologie CRISP-DM) jako:


2.3.1 Porozum¥ní problematice

Po£áte£ní fáze je zam¥°ena na porozum¥ní cíl· projektu z obchodního hlediska a poté nap°em¥nu t¥chto znalostí na de�nici data miningového problému:

• Cíle podnikání - porozum¥t pot°ebám klienta a identi�kovat cíle a jejich provázanost

• Pr·zkum situace - vyjasn¥ní terminologie, analýza návratnosti investic, analýza prost°edk·a poºadavk· na projekt, zváºit omezení

• Stanovení cíl· data mining projektu v technických pojmech - analýza obchodních poºa-davk· a návrh °e²ení jaký model vytvo°it

• Vytvo°ení plánu projektu - jednotlivé fáze, jejich délka, vstupy, výstupy, zdroje, nástroje

2.3.2 Porozum¥ní dat·m

Fáze porozum¥ní dat za£íná s p·vodní kolekcí dat a pokra£uje aktivitami sm¥°ujícími k sezná-mení se s daty, k identi�kaci problém· kvality dat a k detekování d·leºitých vazeb pro získánípot°ebných informací:

• Sb¥r dat - získání úvodní kolekce dat (z databáze, datového skladu, vstupu) a jejichp°edzpracování pro vyuºití analytickým softwarem

• Popis dat - mnoºství dat, formát

• Pr·zkum dat - popisné statistiky, identi�kace vztah· mezi atributy dat, významné sub-populace, odlehlé hodnoty

• Ov¥°ení dat - úplná data, chyb¥jící data, ²umy, neplatná data

• Eliminace chybných a odlehlých hodnot - nesmyslné hodnoty v datech - nap°. záporný£as, odlehlé hodnoty nejsou chybné, nicmén¥ statisticky málo významné

• Zpracování chyb¥jících dat - odstranit objekty s chyb¥jícími daty, pro tvorbu modelupouºít metody robustní v·£i chyb¥jícím dat·m, pop°. chyb¥jící data doplníme (mediánem,st°ední hodnotou ...)

2.3.3 P°íprava dat

Tato fáze spo£ívá ve vytvo°ení kone£ného souhrnu dat, který bude pouºit pro tvorbu modelu:

• Odvození nových prom¥nných - shrnutí pro nás relevantních údaj· a pop°ípad¥ transfor-mace mén¥ relevantních

• Normalizace dat - standardizace jednotek, optimalizace

• Selekce prom¥nných - výb¥r prom¥nných, které mají na modelovaný jev nejv¥t²í vliv,analytické metody jsou b¥ºn¥ výpo£etn¥ náro£né a pro zbyte£n¥ velká datová pole bybyly výpo£ty neúm¥rn¥ sloºité

• Extrakce prom¥nných - vytvo°ení men²ího po£tu prom¥nných, které nesou maximum in-formací z p·vodních dat


• Selekce relevantních objekt· - podobn¥ jako selekce a extrakce prom¥nných

• Formátování dat - úprava dat pro pot°eby pouºitého modelovacího nástroje

2.3.4 Modelování

Fáze modelování zahrnuje vytvo°ení °ady model· za pouºití r·zných modelovacích technik:

• Výb¥r typu modelu a modelovací techniky - s ohledem na data, budoucí pouºití, srozu-mitelnost, obvykle kombinace n¥kolika model·

• Stanovení testovacího plánu - testovací data, validace

• Tvorba modelu - lad¥ní parametr·, zpracování vygenerovaných výsledk·

• Hodnocení modelu - zváºení vypovídající hodnoty modelu z pohledu p°esnosti a obecnosti

2.3.5 Ohodnocení

V této fázi projektu máme hotový model, £i modely které by m¥li mít odpovídající kvalitu, akteré slibují relevantní podklady k analýze. P°ed posledním krokem je ale je²t¥ d·leºité znovud·kladn¥ zváºit vypovídací hodnotu modelu a jestli model skute£n¥ spl¬uje v²echny obchodnípoºadavky, které byli zadány. Zárov¥¬ zváºit dal²í kroky jako jsou moºnosti zlep²ení do bu-doucna.

2.3.6 Nasazení modelu

Vytvo°ením modelu projekt nekon£í, je pot°eba stále vy°e²it v¥ci jako je integrace modelu £ivyvinutého softwaru do podnikové infrastruktury, zajistit dosaºitelnost získaných informací azárove¬ model udrºovat a sledovat, pop°. obnovit £i p°estavit stávající model na model nový.

2.4 Metody data miningu

Výpo£etním jádrem celého procesu dobývání znalostí z databází je pouºití analytických metod.Vstupem do analytických procedur jsou p°edzpracovaná data, výstupem jsou znalosti. V²echnymetody pouºivané pro data mining vycházejí z p°edpokladu, ºe jednotlivé problémy (objekty)pat°ící k témuº konceptu (t°íd¥), lze popsat pomocí podobných charakteristik (atribut·), kteréjsou pro daný koncept podobné - tyto metody také bývají ozna£ovány jako metody u£ení nazáklad¥ podobností (similarity-based learning). Pokud jsou objekty takto popsatelné hodnotamiatribut·, je moºné je pak reprezentovat body v n-rozm¥rném prostoru, kde n je po£et atribut·.

£ení na základ¥ podobnosti pak vychází z úvahy, ºe objekty p°edstavující p°íklady téhoº kon-ceptu vytvá°ejí jakési shluky v tomto prostoru. Cílem modelování je tedy nalézt vhodnoureprezentaci t¥chto shluk·, pomocí procesu "u£ení" modelu. Proces u£ení lze rozd¥lit dle pouºití"trenéra" na metody s trenérema bez trenéra - neboli jestli trénovací mnoºina dat obsahujeohodnocené p°íklady, £i nikoliv, a cílem u£ení je pak nalézt popis jedotlivých t°íd.

Poºadavky na model p°i tomto procesu lze shrnout takto:

• Vyuºitelnost p°i predikci

• Schopnost generalizace - nalézat obecn¥ platné závislosti v datech


• Model nesmí být p°eu£ený - nesmí se nau£it "zdánlivé" závislosti v datech nebo ²um

Znalosti lze potom prezentovat r·znými zp·soby - nap°. jako reprezentativní p°íklady (vyuºí-vají analogické metody), funkce odpovídajícím jednotlivým shluk·m (jako u subsymbolickýchmetod) £i rozd¥lení prostoru atribut· na snadno popsatelné, pravidelné útvary. Dosti £astose lze ov²em setkat s tím, ºe mnoho lidí se snaºí zpracovávat data práv¥ jedním zp·sobem,a to nástrojem, který nejlépe ovládají. To m·ºe vést aº k pom¥rn¥ velkému ohýbání smysludat pouze pro moºnost vyuºít oblíbeného nástroje. Ve statistice tuto vlastnost ilustruje nap°.oblíbenost n¥kterých model· regresní analýzy, ov²em pokud vezmeme metody v potaz i dal²ímetody data miningu dostáváme jiº pom¥rn¥ velký rozsah prost°edk·, kde lze vyuºitím vhod-ného nástroje výrazn¥ zlep²it výsledky, pop°ípad¥ zefektivnit jednotlivé úlohy (pro£ vyuºívatneuronové sít¥ na n¥co, co jednodu²e zvládnou stromy, na£ hledat v asocia£ních pravidlech �ntypro práci s £asovými údaji, kdyº existují £asové °ady). Jednotlivé meotdy nejsou ur£eny pouzereprezentací hledaných znalostí, dle studie [11] a [12] je d¥líme podle následujícíh kriterií:

• pro jaký typ úlohy dobývání znalostí jsou vhodné (p°i deskrip£ních úlohách jde o nalezenísrozumitelných znalostí, které popisují základní nebo zajímavé souvislosti v datech, p°iklasi�ka£ních úlohách jde o nalezení znalostí, které lze pouºít pro klasi�kaci nových p°í-pad·),

• jak sloºité shluky dokáºí reprezentovat (nap°. otázka lineární separability),

• do jaké míry jsou nalezené znalosti srozumitelné pro uºivatele (symbolické vs. subsymbol-ické metody),

• jak jsou nalezené znalosti efektivní p°i klasi�kaci nových p°ípad·,

• pro jaký typ dat jsou vhodné (n¥které metody pracují pouze s kategoriálními daty, jinémetody umoº¬ují analyzovat kategoriální i numerické atributy).

2.4.1 Rozhodovací stromy

Jednou z nejpouºivan¥j²ích metod reprezentace znalostí je metoda rozhodovacích strom·. Smysltohoto uspo°ádání je velmi snadno pochopitelný a je znám z celé °ady oblastí. Smyslem kon-strukce stromu je rozd¥lování mnoºiny trénovacích dat na men²í pdomnoºiny tak, aby v kaºdépodmnoºin¥ p°evládaly prvky jedné t°ídy. Od ko°ene stromu se na základ¥ odpov¥dí na otázky(umíst¥né v nelistových uzlech) postupuje p°íslu²nou v¥tví stále hloub¥ji, aº do listového uzlu,který odpovídá za°azení p°íkladu do t°ídy. Podrobn¥j²í informace o konstrukci rozhodovacíchstrom· nap°. viz online p°edná²ka [7]. Následující informativní p°íklady jsou p°evzaty práv¥ zuvedené p°edná²ky, £i ze studie prof. Berky [11].

2.4.2 Rozhodovací pravidla

Podobn¥ jako rozhodovací stromy i tato metoda pat°í mezi nej£ast¥ji pouºívané. Konstrukce if-then jsou známé vpodstat¥ z kaºdého programovacího jazyka a metoda rozhodovacích pravidelpouºívá práv¥ tuto syntaxi jako reprezantaci znalostí. Jedním z nejznám¥j²ích algoritm· protvorbu rozhodovacích pravidel je algoritmus pokrývání mnoºin pracující metodou odd¥l a panuj(separate and conquer). Algoritmus snaºí nalézat pravidla, která pokrývají p°íklady téºe t°ídya odd¥lit je od p°íklad· ostatních t°íd. Na následujícím p°íkladu výb¥ru kontaktních £o£ek jez°ejmé jak tento algoritmus funguje. Sestrojíme rozhodovací pravidlo pro výb¥r tvrdých £o£ek.


Obrázek 2.3: Ukázková data pro p°íklad po£así

Obrázek 2.4: Rozhodovací strom pro p°íklad po£así

Nejprve ud¥láme test pro v²echny atributy a vybereme atribut, který vede na nejv¥r²í procentohledané t°ídy - v tomto p°ípad¥ astigmatismus, tak získáme první podmínku pravidla - obr. 2.5

Tímto zp·sobem pokra£ujeme stále dále, dokud nedostaneme hledanou t°ídu, tedy záznamy,které mají recomendation = hard. Tuto t°ídu záznam· z p·vodní mnoºiny odebereme a pokudstále máme n¥jaké záznamy s recomendation = hard celý postup opakujeme - tentokrát budeprvní zvoleny atribut v¥k. Tak dostaneme dv¥ pravidla, která pokrývají celou námi hledanout°ídu - obr. 2.6

2.4.3 Asocia£ní pravidla

V p°ípad¥ asocia£ních pravidel neni ºádný atribut (sloupec tabulky) vy£len¥n jako cíl klasi�kace.Asocia£ní pravidla hledají "v²echny zajímavé" asociace (implikace, ekvivalence) mezi hodnotamir·zných atribut·. Pro v¥t²í mnoºství dat m·ºe vzniknou p°íli² velké mnoºství pravidel, proto sezavádí pojmy minimal con�dence a support. Pro data o po£así z prvního p°íkladu tak vzniknounap°. pravidla - obr. 2.7


Obrázek 2.5: Ukázková data pro p°íklad £o£ky

Obrázek 2.6: Výsledná pravidla pro t°ídu recomendation=hard

2.4.4 Statistické metody

Statistika nabízí celou °adu teoreticky dob°e prozkoumaných a léty praxe ov¥°ených metod proanalýzu dat. Pro oblast dobývání znalostí z databází mají význam (a´ uº p°ímo jako pouºívanémetody nebo nep°ímo jako zdroj inspirace):

• kontingen£ní tabulky � pro zji²´ování vztahu mezi dv¥ma kategoriálními veli£inami,

• regresní analýza � pro zji²´ování funk£ní závislosti jedné numerické (spojité) veli£iny najiných numerických veli£inách,

• diskrimina£ní analýza � pro odli²ení p°íklad· (pozorování) pat°ících do r·zných t°íd,

• shluková analýza � pro nalezení skupin (shluk·) navzájem si podobných p°íklad·.

2.4.5 Nejbliº²í soused

V p°ípad¥ nejbliº²ího souseda jsou koncepty (t°ídy) reprezentovány svými typickými p°ed-staviteli. V procesu klasi�kace se pak nový p°íklad za°adí do t°ídy na základ¥ podobnosti (nej-men²í vzdálenosti k reprezentantovi n¥jaké t°ídy. Jde tedy o metodu která vychází ze shlukovéanalýzy. Klí£ovým pojmem je koncept podobnosti, resp. vzdálenosti dvou p°íklad·.


Obrázek 2.7: Ukázka asocia£ních pravidel pro p°íklad po£así

Obrázek 2.8: Nejbliº²í soused

2.4.6 Neuronové sít¥

První modely neuron· a neuronových sítí se zkoumaly v rámci um¥lé inteligence jiº v 50. letech.Um¥lé neuronové sít¥ vycházejí z analogie s lidským mozkem. Z toho vyplývá, ºe podstatounávrhu neuronových sítí je modelování struktury (topologie) a vlastní £innosti biologickýchneuronových sítí. Podobn¥ jako mozek jsou um¥lé neuronové sít¥ tvo°eny mnoºstvím navzájempropojených element· - neuron·, ur£itým zp·sobem seskupených a mezi sebou propojených.

V um¥lých neuronových sítích je neuron (obr. 2.9) chápán jako bu¬ka, která p°ijímá podn¥ty odjiných neuron·, které jsou k ní p°ipojeny "na vstupu". Pokud souhrnný ú£inek t¥chto vstupníchpodn¥t· p°ekro£í ur£itý práh, neuron se aktivuje a sám za£ne svým výstupem p·sobit na dal²íneurony.

Kaºdá neuronová sí´ jako celek realizuje ur£itou, pro ni typickou transforma£ní funkci � p°evádí(transformuje) hodnoty vstupních veli£in na hodnoty veli£in výstupních. P°i modelování a °ízenísloºitých, £asto siln¥ nelineárních soustav, býváme v¥t²inou postaveni p°ed problém, ºe danýproces není moºné s uspokojivou p°esností matematicky popsat, nebo exaktní matematickýmodel procesu je tak sloºitý, ºe jeho p°ípadná algoritmizace je bu¤ £asov¥ a programov¥ velmi


Obrázek 2.9: Model um¥lého neuronu

náro£ná nebo dokonce nemoºná. V tomto p°ípad¥ nám um¥lá neuronová sí´ poslouºí jako uni-verzální funk£ní aproximátor. To znamená, ºe navrºená a podle ur£itých matematických pravidel"nau£ená" neuronová sí´ je následn¥ schopná £innost výchozího procesu s ur£itou mírou p°es-nosti reprodukovat (simulovat) pro r·zné vstupní signály.

Obecný algoritmus u£eni neuronové sít¥ z p°edná²ky [15]

function NEURAL-NETWORK-LEARNING(examples) returns network

network a network with randomly assigned weights

repeat

for each e in examples do

O NEURAL-NETWORK-OUTPUT(network, e)

T the observed output values from e

update the weights in network based on e, O, and T

end

until all examples are correctly predicted or stopping criterion is reached

return network

Spole£ným rysem v²ech topologií um¥lých neuronových sítí je v¥t²inou jejich vrstevnatá struk-tura. V n¥kterých speciálních p°ípadech se m·ºeme setkat i s jinými typy struktur, jako jenap°. struktura m°íºková, tzv. mapa. To znamená, ºe jednotlivé neurony bývají organizoványdo ur£itých skupin � vrstev. Podle polohy vrstvy v neuronové síti tak rozeznáváme:

• vrstvu vstupní, v ní umíst¥né neurony zaji²´ují vstup signálu z okolí, lze ji chápat jakopasivní prvek a slouºí k p°íjmu signál· z okolí a jejich následné distribuce do neuron·vrstvy následující

• vrstvu nebo vrstvy skryté, jejich úkolem je zlep²it aproxima£ní vlastnosti sít¥ jako celku

• vrstvu výstupní, jejíº neurony p°edávají signál do okolí

Základní vlastností neuronových sítí je jejich schopnost u£ení se. Proces u£ení p°edstavuje dy-namický proces, p°i kterém dochá-zí k modi�kaci vhodných, tzv. nastavitelných, parametr·p°íslu²né neuronové sít¥ za ú£elem dosaºení poºadované shody mezi výstupy z modelovanésoustavy a výstupy z neuronové sít¥. V drtivé v¥t²in¥ p°ípad· se proces u£ení soust°e¤uje naadaptaci vah spojení mezi neurony. N¥kdy mohou být nastavitelnými parametry také strmostiaktiva£ních funkcí nebo postupná zm¥na struktury neuronové sít¥. Proces u£ení bývá charak-terizován ur£itými algoritmy u£ení.


U£ení sítí lze rozd¥lit na u£ení s u£itelem a bez u£itele, p°i£emº první metoda vyuºívá knalezení ideání transforma£ní funkce porovnávání skute£ného výstupu s ideálním výstupem prou£ební data. Proces u£ení tedy zahrnuje modi�kaci vah spojení jednotlivých neuron· k dosaºeníco moºná nejv¥t²í shody skute£ného výstupu s výstupem poºadovaným, dodaným u£itelem.Vlastn¥ tak hledáme minimum chybové funkce [8]:

E(s) =M∑i=1

ŷi(s, k)− yi(k)2 (2.1)

, kde s -po°adové £íslo epochy trénováníM -po£et vzor· trénovací mnoºinyk -po°adové £íslo trénovací mnoºinyy(k) -ºádané hodnoty na výstupu sít¥ŷ(s, k) -skute£né hodnosty na výstpu sít¥

Proces u£ení bez u£itele spo£ívá v schopnosti neuronových sítí rozeznat ve svých vstupech stejnénebo podobné vlastnosti a t°ídit tak p°edkládané vektory podle t¥chto vlastností. Podobné vek-tory se sdruºují do tzv. shluk· � map. P°itom algoritmus u£ení nemá informaci o poºadovanýchvýstupních hodnotách.

Neuronové sít¥ se pouºívají mimo jiné i pro rozpoznávání a kompresi obraz· nebo zvuk·, p°ed-vídání vývoje £asových °ad (nap°. burzovních index·), n¥kdy dokonce k �ltrování spamu. Vléka°ství slouºí k prohlubování znalostí o fungování nervových soustav ºivých organism·. Nap°ík-lad perceptronová sí´ vznikla p·vodn¥ jako simulace fyziologického modelu rozpoznávání vzor·na sítnici lidského oka.

2.5 Shrnutí

V této kapitole jsem se pokusil p°iblíºit problematiku data miningu, nejpouºívan¥j²í metodologiea jednotlivé metody k získávání informací, následující kapitolu budu podrobn¥ji v¥novat zatímnezmín¥né metod¥ - metod¥ induktivních model·.

KAPITOLA 3. INDUKTIVNÍ MODELOVÁNÍ 15

3 Induktivní modelování

3.1 P°edstavení metody idnuktivního modelování

Induktivní modelování vyuºívá techniky automatického u£ení pro tvorbu model· ze zadanýchdat. Je chápáno, podobn¥ jako neuronové sít¥, jako tzv. black box metoda automatické tvorbymodel·. Sí´ dop°edn¥ propojených jednotek (neuron·) se vytvá°í za pomoci procesu indukce.Nejv¥t²í výhodou induktivního modelování oproti tradi£ním neuronovým sítím je hlavn¥ jejichschopnost °e²it roznanité problémy s velkým mnoºstvím vlastností vstupních dat. Problém jerozd¥len na °adu men²ích podproblém· a informace z nejvýznamn¥j²ích vstupních dat jsouanalyzovány nejd°íve a poté se takto získané infromace kombinují a dále analyzují.

R. 1966 byla ukrajinským profesorem A. G. Ivahknenkem p°edstavena skupina metod pro in-duktivní modelování, známá jako Group Method of Data Handling (GMDH). V [10] je uvedeno,ºe metoda Group of Adaptive Models Evolution (GAME) vychází z jenoho z algoritm· pop-saných v GMDH a to sice algoritmu Multilayered Iterative Algorithm (MIA). Model systémuje zde reprezontován formou sít¥, algoritmus vytvá°í model sloºitého systému vrstvu po vrstv¥b¥hem procesu u£ení, p°i£emº u£ení - nastavování parametr· p°enosové sít¥, probíhá za pouºitídat popisujících modelovaný systém.

3.2 MIA GMDH a GAME

Základní my²lenka je pro oba algoritmy vpodstat¥ stejná, nicmén¥ v této £ásti se pokusímvysv¥tlit hlavní rozdíly. U MIA GMDH se nejprve vygeneruje p·vodní generace neuron· sezadanou polynomickou p°enosovou funkcí, v²echny neurony dal²ích vrstev mají práv¥ dva vstupya tudíº v²echny párovatelné kombinace vstupních prom¥nných jsou pouºity. Poté jsou spo£ítánykoe�cienty p°enosových funkcí neuron· za pomoci n¥jaké optimaliza£ní funkce - nap°. postupnéregrese a neurony jsou se°azeny podle výstupní chyby modelované prom¥nné. Nejlépe ohodno-cené neurony jsou vybrány jako vstupy pro dal²í vrstvu. Následující vrstvy jsou generoványtímto zp·sobem, dokud nedojde k získání poºadované p°esnosti modelované veli£iny.

Obrázek 3.1: Porovnání p·vodní MIA GMDH sít¥ a sit¥ GAME

16 KAPITOLA 3. INDUKTIVNÍ MODELOVÁNÍ

3.3 Rozdílná topologie modelu

Jak je vid¥t z obrázku 3.1 doznává algortimus GAME °ady výrazných zm¥n. Zatímco u algoritmuMIA GMDH je vºdy po£et vstp· neuron· v kaºdé vrstv¥ roven práv¥ dv¥ma v GAME má kaºdýneuron maximáln¥ tolik vstupních prom¥nných jako je hloubka vrstvy ve které se nachází, s tím,ºe první vrstva má pouze jeden vstupní parametr. V souladu s principem indukce je jednodu²²írozd¥lit problém na jednodimenzionální subproblémy a poté v dal²ích vrstvách kombinovat jiº°e²ení t¥chto subproblém·, neº za£ínat rovnou s vícerozm¥rnými problémy. Pro zvý²ení modelo-vací p°esnosti neuronových sítí, se £asto do mnoºiny vstupních dat, p°idávájí data syntetizovanámatematickými operacemi, to práv¥ d¥lá první vrstva v p°ípad¥ GAME algoritmu automaticky.Zárove¬ také GAME umoºnuje propojení neuron· mezi r·znými vrstvami.

3.4 Rozmanitost neuron· a u£ebních metod

Dal²ím z velkých vylep²ení je pouºití r·zných typ· neuron· - polynomické, lineární, expo-nenciální, gausovy apod. a pouºití rozdílných u£ebních metod -viz [9]. Hlavní výhodou pouºitíneuron· r·zných typ· v jednom modelu je, ºe se modely automaticky adaptují charakteru mod-elovaného systému a p°eºijí pouze neurony s nejlep²í p°enosovou funkcí. Hybridní modely takélépe aproximují vztahy, které lze vyjád°it superpozicí r·zných funkcí.

V p°ípad¥ modelovaní vícerozm¥rných systém· (20 a více vlastností) dochází u GMDH algo-ritmu, generujícímu v²echny párové kombinací vlastností k váºným výpo£etním problém·m.Proto GAME p°ichází s °e²ením ve form¥ tzv. niching genetického algoritmu.

3.5 Niching genetický algoritmus

Kaºdý neuron sít¥ GAME je v gnetickém algoritmu reprezentován "chromosomem", který neseinformaci o tom, které vstupy tohoto neuronu jsou p°ipojené k neuron·m v p°edchozí vrstv¥a je ur£ena biologická zdatnost (�tness) - f(p1). Po n¥kolika opakování genetického algoritmu(epochách dominují populaci jedinci s nejvy²²í hodnotou �tness funkce. Tím je nalezeno opti-mální °e²ení.

Niching genetický algoritmus ale umoº¬uje nalézt i dal²í, suboptimální, °e²ení - tedy druhýa dal²í nejvíce významné vstupní parametry. Tím lze získat více informací o modelovanémsystému, neº jen analýzou vlastností n¥kolika nejzdatn¥j²ích jedinc· závislých na jedné ne-jvýznam¥j²í vlastnosti - tyto závislosti bývají moc podobné. Niching algoritmus tak zaru£ujerozmanitost v populaci a tudíº i p°eºití neuron· spojených s mén¥ významnými vstupnímiparametry.

V GAME je proto vyuºíván algoritmus Deterministic Crowding. Ten ve stru£nosti pracuje násle-dovn¥. Nejd°íve rozd¥lí celou populaci na n/2 pár·. Ty poté sk°íºí a zmutuje v potomky. Kaºdýz potomk· potom sout¥ºí proti tomu z rodi£·, kterému je podobn¥j²í. Podobnost je ur£ena nanebo na základ¥ phenotypové rozdílnosti (k jakým vstup·m jsou jedinci p°ipojeni). Na obr. 3.2je pseudokód algoritmu Deterministic Crowding, jak ho uvádí [10].

Protoºe v první vrstv¥ mají v²echny neurony maximáln¥ jeden vstupní parametr jsou takvytvo°eny jakési t°ídy (niches) podle p°ipojení ke stejným vstupním parametr·m. Po n¥kolikaepochách genetického algoritmu tak z kaºdé t°ídy v dané vrstv¥ modelu zbydou ti nejchop-n¥j²í jedinci. Jak konstrukce modelu pokra£uje a v kaºdé vrstv¥ p°ibývá vstupních parametr·,vznikají nové t°ídy se shodnou mnoºinou vstupních parametr·.

KAPITOLA 3. INDUKTIVNÍ MODELOVÁNÍ 17

Obrázek 3.2: Porovnání b¥ºného genetického algoritmu a niching genetcikého algoritmu vyuºí-vajícího metodu Deterministic Crowding

3.6 Analýza vstupních parametr·

Dal²í z velkých p°edností metody GAME je, ºe nám dává moºnost analyzovat váhu vstupníchparametr· - jejich význam na výsledek modelované veli£iny v porovnání k ostatním. Po ukon£eníposlední etapy DC genetického algoritmu je spo£ítáno, kolik jedinc· je p°ipojeno ke které vs-tupní prom¥nné a po vyd¥lení celkovým po£tem jedinc· dostaneme váhu kaºdé vstupní veli£iny.Vlastnosti s nejv¥t²ím významem pro výstup jsou tedy tímto zp·sobem zji²t¥ny.

3.7 FAKE GAME

FAKE (Fully Automated Knowledge Extraction) je prost°edí pro metodu GAME umoº¬ujícízískávání uºite£ných informací z dat b¥ºného ºivota bez pot°eby asistence specialist· na statis-tiku £i data mining. Má za cíl zcela automatizovat proces získávání informací a nabízí rozhranípro °e²ení tohot problému. V²e o FAKE GAME lze zjistit z [9].

3.8 Shrnutí

Metoday GAME a FAKE GAME p°edstavují unikátní nástroje pro automatizovanou tvorbuinduktivních model· a to i pro velmi rozmanité systémy. DC genetický algoritmus umoº¬ujeefektivní vyhledání nejoptimáln¥j²í topologie modelu p°i zachování diverzity a navíc poskytujeprost°edky pro ur£ení významnosti jednotlivých vstupních vlastností na vlastnost modelovanou.

18 KAPITOLA 3. INDUKTIVNÍ MODELOVÁNÍ

KAPITOLA 4. PARALELISMUS A PARALELNÍ PROGRAMOVÁNÍ 19

4 Paralelismus a paralelní programování

4.1 Paralelismus

Paralelismus je model jak °e²it sloºité, obsáhlé úlohy rychleji. Vychází z my²lenky rozd¥lit zadanýproblém na men²í £ásti (subproblémy) a ty poté °e²it zárove¬, narozdíl od sekven£ního °e²eníproblému, kdy se problém °e²í krok za krokem. Základní schema tak m·ºe být:

• Rozd¥lení úlohy na subproblémy,

• P°id¥lení t¥chto problém· odli²ným "pracovník·m"

• Koordinování "pracovník·"

Paralelní metody °e²ení úloh jsou vid¥t v b¥ºném ºivot¥ na kaºdém kroku - v pr·myslu, p°i°ízení projekt·, p°i psaní bakalá°ské práce apod.

4.2 Architektura paralelních systém·

4.2.1 Popis

Po£íta£ové programy bývaly tradi£n¥ psány pro b¥h na sekven£ních po£íta£ích - na po£íta£íchs jedním procesorem (který u po£íta£· plní práv¥ funkci "pracovníka"). S tím jak stále rostesloºitost °e²ených úloh (problématika simulací, zpracování obrázk·, videa, data miningu, mode-lování) a tím i poºadavky na hardware, tento tradi£ní model po£íta£e a programovacích technikjiº p°estává být schopen dané úlohy °e²it. Vývoj stále rychlej²ích procesor· za£íná být neúm¥rn¥drahý oproti získanému zrychlení a lze hovo°it o p°iblíºení se k limitu technologických moºnostídnes pouºívaných metod konstrukce procesor·.

Paralelní po£íta£e tak p°iná²ejí relativn¥ levn¥j²í cestu k získávání poºadované výpo£etní ka-pacity a moºností a i osobní po£íta£e jsou dnes jiº standardn¥ dodávány s více procesory, nebos procesory vícejadernými. To samoz°ejm¥ vede k pot°eb¥ vytvá°et programy schopné t¥chtotechnologických prost°edk· vyuºít.

Obrázek 4.1: Kategorie paralelních systém· dle Flynnovy taxonomie

4.2.2 Flynnova taxonomie

Existuje n¥kolik metod jak popsat a rozd¥lit architekturu paralelních systém·. Jedna z ne-jpouºívan¥j²ích, Flynnova metoda, vyuºívá ke kategorizaci systém· vztah mezi instrukcemi datyprogramu. Na obr. 4.1 je rozd¥lení paralelních systém· práv¥ dle Flynnovy taxonomie [4].

20 KAPITOLA 4. PARALELISMUS A PARALELNÍ PROGRAMOVÁNÍ

4.2.2.1 SISD model

SISD - Single Instructions, Single Data stream p°edstavuje vlastn¥ sekven£ní po£íta£. Jednainstrukce je vykonávána kaºdý hodinový cyklus a kaºdá instrukce operuje nad jedním (resp.skalárním) datovým elementem. Výkon je tak limitován po£tem instrukcí, které lze v daném£asovém úseku zpracovat a je me°en v jednotkách MIPS (milios of instructions per second) nebopodle frekvence hodin v Hz (resp. GHz).

Obrázek 4.2: Model SISD architektury

4.2.2.2 SIMD model

U modelu Single Instructions, Multiple Data stream kaºdá instrukce m·ºe pracovat s více neºjedním datovým elementem - bu¤to v podob¥ vektoru (jedna instrukce tak upravuje více op-eradn·, sou°adnic vektoru) nebo rozdílných mnoºin dat (jedna instrukce se vykonává na v²echprocesorech, tkeré ale operují s r·znými mnoºinami dat). Práce procesor· je synchronní a tudíºsynchronizace program· nep°edstavuje váºn¥j²í problém. Výkon je m¥°en v jednotkách MFLPOS(milions of �oating point operations per second).

Obrázek 4.3: Model SIMD architektury


4.2.2.3 MISD model

Multiple Instructions, Single Data stream je velmi neobvyklá architektura, která je pouºívávpodstat¥ pouze k vylou£ení chyb. Rozdílné systémy pracují nad stejnými daty a musí se dobratstejného výsledku.

Obrázek 4.4: Model MISD architektury

4.2.2.4 MIMD model

Patrn¥ nejpouºívan¥j²í architektura, Multiple Indstructions, Multiple Data stream je vpodstat¥spojením zcela nezávislých procesor·, kdy kaºdý procesor zpracovává vlastní instrukce nezávisléna ostatních procesorech nad vlastními daty. Kaºdý procesor tak vykonává vlastní operace bezohledu na £innost ostatních procesor·. Klí£ovou otázkou b¥hu programu na této architektu°e jetedy synchronizace procesor· na konci paralelních £ástí programu.

Obrázek 4.5: Model MIMD architektury

4.2.3 Pam¥´ové architektury

Zp·soby jakými mezi sebou procesory komunikují jsou závislé na architektu°e pam¥ti. Lze takrozli²ovat:


4.2.3.1 Sdílená pam¥´

Jednotlivé procesory pracují nezávisle ale sdílenou spole£ný pam¥óvý prostor. Pouze jedenproces m·ºe v danou chvíli p°istupovat k dat·m ve sdílené pam¥ti. Problém synchronizacepak spo£ívá p°edev²ím v °ízení p°ístupu jednotlivých procesoru k t¥mto dat·m aby nedo²lo knekonzistenci dat £i k "uzamknutí programu". Klí£ovou otázkou pro výkon této architektury jepam¥óvá propustnost, a proto se tento model hodí k pouºití u niº²ího po£tu procesor· - °ádov¥desítky.

Obrázek 4.6: Model architektury se sdílenou pam¥tí

4.2.3.2 Distribuovaná pam¥´

U této architektury má kaºdý procesor vlastní pam¥óvý prostor a data jsou sdílena pomocízasílání zpráv po komunika£ní síti. Celkový výkon této architektury je odvislí od rychlostip°enosové sít¥.

Obrázek 4.7: Model architektury s distribuovanou pam¥tí

4.2.4 Symetrické multiprocesory (SMP)

Model systému se sdílenou pam¥tí schematicky zobrazuje obr. 4.8. Propojení mezi procesory amoduly pam¥ti, je realizováno pomocí multiprocesorovou sb¥rnice. Slovo symetrické vyjad°uje


skute£nost, ºe v²echny procesory jsou identické a mají identické moºnosti p°ístupu do pam¥ti.

Obrázek 4.8: Architektura SMP

Procesory u SMP jsou charakterizovány tím, ºe mohou p°istupovat p°ímo do libovolné bu¬kycelého pam¥óvého prostoru, p°i£emº doba p°ístupu nezávisí na pam¥óvé adrese a kon�iktnípoºadavky p°íistupu k téºe bu¬ce °e²í samotná pam¥´ £i propojovací sí´.

Z obrázku je také z°ejmé, ºe kaºdý procesor má vlastní cache (skrytou pam¥´). Práv¥ tatopam¥´ je kriticky d·leºitá pro výkonnost celé SMP, nebo´ umoº¬uje data z £asov¥ náro£nýchp°ístup· do hlavní pam¥ti kopírovat do pam¥ti skryté a vytvo°it si tak vlastní soukromé kopie,ke kterým je p°ístup samoz°ejm¥ výrazn¥ rychlej²í. Navíc se tím sniºuje po£et transakcí nasdílené pam¥óvé sb¥rnici a tím se zvy²uje její pr·chodnost a umoº¬uje tak více pam¥óvýchoperací.

4.3 Paralelní programování na SMP

V následujících £ástí práce, se budu v¥novat paralelnímu programování pouze na SMP architek-tu°e. Pokud program b¥zí na víceprocesorovém systému, hovo°íme o reálném paralelismu �kaºdý subprogram beºí na svém procesoru, pokud na jedoprocesorovém hovo°íme o tzv. pseudoparalelismu � subprogramy se na jednom procesoru st°ídají díky p°epínání kontextu, tzn. kaºdýsubprogram má p°id¥len procesor jen po ur£ité £asové kvantum, standardn¥ 10 � 100ms, díky £e-muº dochází k optimáln¥j²ímu vyuºívání dostupných systémových prost°edk· - zatímco procesor£eká na dokon£ené n¥jaké V/V operace, pot°ebné pro pokra£ování b¥hu jedné £ásti programu,lze jej zatím vyuºít k zpracování £ást dal²í.

Jak jiº bylo °e£eno, paralelní programování vychází z my²lenky rozd¥lit program na n¥kolik £ástí(subprogram·), které se dají °e²it nezávisle na sob¥ a ty pak °e²it najednou. Lze hovo°it o t°echmetodách rozd¥lení programu:

• Funk£ní rozd¥lení - rozd¥lení programu na nezávislé výpo£etní celky, které pak distribuovatjednotlivým procesor·m

• Datové rozd¥lení - rozd¥lení mnoºiny dat na men²í £ásti a ty pak distribuovat jednotlivýmprocesor·m k simultánímu zpracování

• Kombinace obou

4.3.1 Modely paralelního programování

Obecn¥ lze °íci, ºe existují dva modely paralelního programování, a to sice procesový model avláknový model.


4.3.1.1 Procesový model

V²echen b¥ºící software v systému je organizován jako mnoºina b¥ºících proces·. Proces jetedy vpodstat¥ b¥ºící instance programu. Kaºdý proces alokuje p°íslu²né prost°edky (adresovýprostor obsahující kód a data, otev°ené soubory, reakce na signály, ...), má vlastní identitu (PID,PPID, vlastníka, seznam potomku,. . . ). Implicitn¥ obsahuje jedno vlákno výpo£tu. Hierarchie,tvorba a parametry proces· jsou závislé na opera£ním systému.

4.3.1.2 Vláknový model

Vyuºívá odd¥lení alokace systémových prost°edk· od samotného výpo£tu, proces slouºí k alokaciprost°edk·, vlákna potom jako výpo£etní jednotky plánované pro spu²t¥ní na CPU. Vlákna vdaném procesu nejsou nezávislá tak, jako jednotlivé procesy. Vlákno má sv·j vlastní programcounter (pro uchování informace o výpo£tu), registry pro uchování aktuálních hodnot), zásobník(který obsahuje historii výpo£tu), lokální prom¥nné, ale ostatní prost°edky a venkovní identitaz pohledu vn¥ procesu jsou sdílené. Hlavní výhodou vláken je niº²í reºie na p°epínání kontextumezi vlákny a taktéº snadn¥j²í spolupráce.

4.3.2 Co je pot°eba vzít v úvahu p°i návrhu paralelního programu

4.3.2.1 Amdahlovo pravidlo

Amdahlovo pravidlo [1] de�nované systémovým architektem Gene Amdalhem je £asto pouºívánopro nalezení maximálního teoretického zrychlení výpo£tu p°i pouºití paralelních systém·.Pravidlo je modelem chování mezi p°edpokládaným zrychlením paralelizovaného algoritmuoproti jeho sekven£ní podob¥ za p°edpokladu, ºe rozsah prolém· je zachován. Pravidlo je de�-nováno takto. Pokud P je £ást programu, kterou lze paralelizovat, a 1−P £ást jeº paralelizovatnejde, potom je maximální moºné zrychlení p°i pouºití N procesor· rovno práv¥:

1(1− P ) + P/N

(4.1)

Jak se N limitn¥ blíºí nekone£nu, maximální dosaºitelné zrychlení je 1/(1 − P ). V praxi toznamená, ºe pom¥r výkon/cena strm¥ klesá (jak je vid¥t z obr. 4.9) jakmile existuje n¥jakáneparalelizovatelná £ást programu. Uve¤me si jednoduchý ilustrativní p°íklad. P°edstavme si,ºe máme se£íst 1000000000 prvk· vektoru a. Na£tení prvk· trvá 8% celkového výpo£tového£asu, vlastní výpo£et sou£tu trvá 90% celkového výpo£tového £asu a tisk trvá 2% celkovéhovýpo£tového £asu. Je z°ejmé, ºe jen výpo£et sou£tu lze paralelizovat t.j. P = 90% V p°ípad¥pouºití N = 10 procesor· dostaneme z Amdahlova pravidla ºe zrychlení výpo£tu paralelizací jep°ibliºn¥ 5, 2-krát. Z Amdahlova pravidla a uvedeného p°íkladu plynou dva záv¥ry:

• neplatí p°ímá úm¥ra mezi po£tem procesor· a urychlením výpo£tu (uºití 10 procesor·neznamená urychlení výpo£tu 10-krát) a

• pro limitní p°ípad N →∞ je urychlení výpo£tu kone£né a rovno 1/(1− P ).

4.3.2.2 Problematika Load Balancingu a Granularity

Balancování zát¥ºe (Load Balancing) znamená distribuci úkol· jednotlivým procesor·m prozaru£ení nejv¥t²í £asové efektivity. Pokud totiº nejsou úkoly distribuovány balancovan¥, m·ºe


Obrázek 4.9: Amdahlovo pravidlo - ilustrace sniºování výhodnosti vyuºívání p°íli² vysokéhopo£tu procesor·

dojít k zbyte£ným prodlevám, kdy se £eká na dokon£ení jednoho úkoly, zatímco ostatní úkolyneb¥ºí. O p°id¥lování jednotlivých úloh procesor·m se stará jádro opera£ního systému, resp.plánova£, vyuºívající dle opera£ního systému r·zné algoritmy pro vyváºené zatíºení procesor·,nap°. FCFS, SJF, RR, SRT, prioritního plánování a dal²í - více viz. p°edná²ky na [5].

Problematika granularity vzniká z pot°eby synchronizovat £innost r·zných procesor· pracujícíchna jednom problému. Synchronizace probíhá pomocí n¥jaké formy komunikace mezi procesorya práv¥ podíl mezi £asem v¥novaným výpo£tu a £asem pot°ebným pro synchronizaci se nazývágranularita. Je to dal²í z problém·, se kterým je pot°eba po£ítat p°i návrhu paralelních systém·a program·. P°íli² vysoká granularita totiº znamená p°íli² velkou spot°ebu £asu na synchro-nizaci výpo£tu a m·ºe vést aº k tomu, ºe sekven£ní °e²ení bude nakonec £asov¥ výhodn¥j²í neºparalelní.

4.3.2.3 Datová konzistence

V okamºiku kdy dochází k vícenásobnému uºití stejného pam¥´ového místa musíme se zabý-vat otázkou konzistence dat z této adresy. N¥kolik zárove¬ beºících proces· £i vláken pouºívá(£te/zapisuje) spole£né sdílené prost°edky (nap°. sdílená pam¥´, sdílené prom¥nné, sdílenésoubory,. . . ). Kv·li p°epínání kontextu m·ºe dojít nap°. k pozm¥n¥ní prom¥nné jedním pro-cesem d°íve neº ji stihne p°e£íst jiný proces který ji taktéº pot°eboval na£íst. V d·sledku je takvýsledek výpo£tu závislý na p°epínání kontextu jednotlivých proces· £i vláken, které pouºívajísdílené prost°edky. Tyto chyby se velmi ²patn¥ se detekují. ásti programu, kde procesy £i


vlákna pouºívají sdílené prost°edky, a kde tak m·ºe dojít k t¥mto chybám se nazývají kritickésekce.

4.3.2.4 Podmínky korektnosti paralelního programu

Aby byl paralelní program korektní, musí spl¬ovat tyto podmínky:

• Dva procesy se nesmí nacházet sou£asn¥ ve stejné sdruºené sekci.

• ádné p°edpoklady nesmí být kladeny na rychlost a po£et procesor·.

• Pokud proces b¥ºí mimo kritickou sekci nesmí být blokován ostatní procesy.

• ádný proces nesmí do nekone£na £ekat na vstup do kritické sekce.

Spln¥ní t¥chto podmínek lze pomocí ur£itých postup·, jako jsou aktivní £ekání, vzjámné vy-lou£ení pomocí blokování, zákazy p°eru²ení, a k zaji²t¥ní funk£nosti t¥chto metod v¥t²ina pro-gramovacích jazyk· nabízí nejr·zn¥j²í konstrukty synchroniza£ních prost°edk·, jako jsou mu-texy, semafory, bariéry apod. Pro více informací o synchroniza£ních prost°edcích jako celkudoporu£uji slidy z p°edná²ek na stránce [5].

4.3.3 Paralelní programování v jazyku JAVA

4.3.3.1 Vlastnosti vláken

Podobn¥ jako t°eba jazyk c++ umoº¬uje JAVA vyuºívat pro paralelizaci program· vlákna.Vlákna jsou v JAV vºdy instancí t°ídy java.lang.Thread nebo jejího potomka, p°i£emº t°ídaThread nabízí základní metody jako je spu²t¥ní vlákna, zastavení £i ukon£ení.

Vlákna lze v JAV vytvá°et dv¥ma zp·soby. Bu¤to odvozením potomka od t°ídy Thread neboimplenetací Runnable rozhraní. Vlastní kód vlákna je dán metodou run(), kterou musíme v na²ít°íd¥ implementovat a která je spou²t¥na pomocí volání metody start(). Jednoduché vláknotedy m·ºe vypadat nap°. takto (datová poloºka semaphore jsou uvedeny kv·li následujícímp°íklad·m):

class MyThread extends Thread {

Semaphore semaphore = new Semaphore;

public MyThread(sem, bar){

semaphore = sem;

}

public void run() {

//for semaphore synchronization -

//if semaphore counter > 0 lower the counter

//else this.wait()

try{

semaphore.acquire();

}

catch (InterruptedException ex) {

ex.printStackTrace();


}

//critical section

. . .

//increment semaphore counter,

//notify() threads waiting on this semaphore

semaphore.release();

}

A vytvo°ení instance této t°ídy pak:

MyThread mythread = new MyThread(actual, nerons);

mythread.start();

Vlákna v Jav¥ se nachází vºdy v jednom ze £ty° stav·, p°echody mezi nimi zaji²´ují metodyt°ídy Thread. Stavy vláken jak je popisuje [2]:

• Nové vlákno (new)Vlákno bylo vytvo°eno, ale dosud nebylo spu²t¥na metoda start().

• B¥huschopné (runnable) vláknoMetoda start() jiº prob¥hla, provádí se metoda run().

• Blokované vlákno (blocked)Vlákno je blokováno a £eká na n¥jakém "zámku".

• ekající vlákno (waiting)Vlákno £eká na danou operaci jiného vlákna.

• asov¥ omezené £ekání (timed_waiting)Vlákno £eká na operaci n¥jakého jiného vlákna, ale pouze po ur£ený £asový interval.

• Ukon£ené vlákno (terminated)Vlákno, jehº dokon£ilo sv·j výpo£et.

4.3.3.2 Plánování vláken

Jak jiº bylo °e£eno, na systémech s jedním procesorem, které nepodporují paralelní b¥h instrukcí,se multithreading simuluje tak, ºe se vlákna o procesor d¥lí, podle pravidel, která ur£uje pláno-va£.

Java pouºívá plánování podle priority: kaºdé vlákno má p°id¥leno £íslo, prioritu, v rozmezí kon-stant MIN_PRIORITY aº MAX_PRIORITY (de�nované ve t°íd¥ Thread), kde vy²²í hodnotaznamená vy²²í prioritu. Od priority se odvíjejí tato pravidla:

1. B¥ºící vlákno musí mít nejvy²²í prioritu.

2. Pokud je v b¥huschopném stavu vlákno s vy²²í prioritou neº má vlákno b¥ºící, je b¥ºícívlákno tímto okamºit¥ vyst°ídáno.

3. Vlákno s niº²í prioritou m·ºe b¥ºící vlákno vyst°ídat jen tehdy, pokud je b¥ºící vláknov neb¥huschopném stavu nebo je ukon£eno, a zárove¬ na p°id¥lení procesoru ne£eká jinévlákno s vy²²í prioritou.


4. Pokud na p°id¥lení procesoru £eká více vláken se stejnou prioritou, je dal²í vybráno tak,aby se postupn¥ vyst°ídala v²echna.

5. B¥ºící vlákno m·ºe navíc dobrovoln¥ poskytnout procesor jiným vlákn·m se stejnou pri-oritou zavoláním metody yield().

Z uvedených pravidel tedy vyplývá, ºe b¥ºící vlákno nem·ºe být "donuceno" k vyst°ídání jinýmvláknem se stejnou nebo niº²í prioritou, ale pouze s prioritou vy²²í.

Java je ov²em v tomto ohledu benevolentní a dovoluje na opera£ních systémech, které to pod-porují (Unix, Windows XP/NT), tzv. sdílení £asu (time slicing), kdy se vlákna se stejnou pri-oritou st°ídají po pevn¥ p°id¥lených £asových intervalech.

4.3.3.3 Synchronizace vláken

Pro synchronizaci vláken umoº¬uje JAVA pouºít velmi jednoduchý zp·sob pracující na principumonitoru. V Jav¥ má kaºdý objekt sv·j jedine£ný monitor. V n¥m jsou de�nována sdílená dataa £ást programu, kterou m·ºe v daném monitoru v jednu chvíli vykonávat pouze jeden proces.Monitor je inicializován klí£ovým slovem synchronized, kterým jsou ozna£eny metody a blokyde�nující kritickou sekci. Vlákno které vstoupí do této kritické sekce aktivuje monitor, který seuzamkne a je tak zaru£ena nep°eru²itelnost této metody aº do okamºiku, kdy vlákno monitoruvolní (vystoupí z kritické sekce).

Jinak je moºné vlákna synchronizovat p°ímo pomocí metod wait(), notify(), £i notifyAll(),které taktéº vyuºívají zmín¥né monitory. Metoda wait() zastaví vlákno aº do jeho probuzenímetodou notify() nebo metodou notifyAll(), kterou volá odli²né vlákno. Pokud m¥lo vláknozamknutý n¥jaký monitor, po zavolání metody wait() dojde k uvoln¥ní tohoto monitoru. Vý£etv²ech metod t°ídy Thread je uveden na stránkách [2].

Od uvedení J2SE 5.0 poskytuje JAVA °adu standardních synchroniza£ních prost°edk· nabíze-ných v balíku java.util.concurrent. Krom¥ monitor·, tak p°ibyly dalsí synchoniza£ní pro-st°edky známé nap°. z jazyka c++, jako jsou semafory, mutexy a bariéry, nebo fronty zpráv.V práci jsem p·vodn¥ zamý²lel pro synchronizaci vyuºít t°ídu Semaphore nicmén¥ na záv¥rjsem synchronizaci zajistil pomocí metody join(), která zaru£í po£kání programu na dokon£enívlákna které ji volá. Ukázka kódu synchronizace pomocí metody join() a pomocí t°ídySemaphore.

public static void main(String[] args){

//creating and starting array of threads

for (int i = 0; i < 30; i++){

threads[i] = new MyThread();

threads[i].start();

}

//synchronizing by waiting for all the threads from whole array to finish

for (int i = 0; i < 30; i++){

try {

threads[i].join();

}



}

}

}


public static void main(String[] args){

//maximal number of running threads at a time

int maxRunningThreads

//inicializing Semaphore

Semaphore semaphore = new Semaphore(maxRunningThreads, true)

//creating and starting array of threads

for (int i = 0; i < 30; i++){

threads[i] = new MyThread(i, Semaphore);

threads[i].start();

}

}

KAPITOLA 5. PARALELIZACE APLIKACE GAME 31

5 Paralelizace aplikace GAME

Jak jsem ukázal v kapitole 3 je induktivní modelování zna£n¥ výpo£etn¥ náro£né. V sou£asnédob¥ proces tvorby model· v aplikaci GAME probíha sekven£n¥ a tudíº se pro jeho zrychlenínabízí vyuºití princip· paralelního programování.

5.1 Pr·zkum moºností

Podle úvahy uvedené v p°edchozí kapitole jsem se snaºil identi�kovat, kterou £ást výpo£tuinduktivních model· paralelizovat. Jak je ukázáno v 4.3.2.1 nejv¥t²ího zrychlení lze dosáhnoutparalelizováním £ástí výpo£tu, které jsou £asov¥ nejnáro£n¥j²í. V p°ípad¥ aplikace GAME lzep°edpokládat, ºe se jedná samotný proces u£ení jednotlivých neuron·. Je tedy moºné bu¤toparalelizovat zvlá²´ kaºdý optimaliza£ní (u£ební) algoritmus, pokud v·bec paralelizovat p·jde,nebo vzhledem k faktu, ºe u£ení probíha po vrstvách sít¥ a neurony v rámci jedné vrstvy nejsouspolu propojeny, zajistit paralelizaci spou²t¥ním vláken pro kaºdý neuron v dané vrstv¥. Lze pakvyuºít stávající optimaliza£ní algoritmy. Je tedy pot°eba identi�kovat metoda, ve které docházík tvorb¥ vrstev sít¥, resp. k volání optimaliza£ních metod u neuron·.

V na²em p°ípad¥ se jedná o metod public double teachLayer(InputLayer iLayer) t°ídyGAMEnetwork která zaji²´uje u£ení jedné vrstvy sít¥ GAME. V té se provádí volání metodypublic void teachUnits(Neuron[] n, int inumber) jeº pak pro jednotlivé neurony vstup-ního pole Neuron[] n volá v cyklu metodu public void learnYourself(Unit me) která za-ji²´uje u£ení kaºdého jednotlivého neuronu. Pouºitá u£ební metoda je závislá na prom¥nnéboolean[] trainerAllowed t°ídy NetworkGAMEConfiguration.

public void teachUnits(Neuron[] n, int inumber) {

job = NEW_NEURON;

for (int act = 0; act < inumber; act++) {

actualNeuron = act;

n[act].learnYourself((Unit) n[act]);

}

}

Pro ov¥°ení této teorie jsem si vytvo°il jednoduchou t°ídu MyTimer, umoº¬ující zm¥°it délkutvorby vrstvy modelu a £ást, kterou z ní tvo°í proces u£ení. T°ída MyTimer vyuºívá metoducurrentTimeMillis() t°ídy java.lang.System k získání reálného £asu, tzv. wall clock timev milisekundách. Obdrºená doba tak m·ºe být ovlivn¥na jinými procesy sou£asn¥ b¥ºícími nadaném systému.

Po opakových m¥°ení jsem ur£il, ºe u£ení v závislosti na vybraném optimaliza£ním algoritmuzabírá 60%−99% celkové doby tvorby modelu. Teoretické maximální zrychlení aplikace GAMEtak m·ºe být v závislosti na po£tu procesor· dle 4.3.2.1 rovno N/(0.4N + 0.6) pro 60% aN/(0.1N + 0.9) pro 90%, kde N je po£et procesor·.

5.2 Výb¥r po£tu spou²t¥ných vláken

Po vybrání vý²e uvedeného zp·sobu paralelizace bylo pot°eba rozhodnout kolik vláken najednouspou²t¥t. Vzhledem k tomu, ºe vlákna mají vlastní program counter, registry i zásobník, jep°epínání kontextu mezi jednotlivými vlákny podstatn¥ rychlej²í neº u proces·.

32 KAPITOLA 5. PARALELIZACE APLIKACE GAME

5.2.1 as pot°ebný na tvorbu vláken

Teoreticky je ideální po£et b¥ºících vláken roven po£tu procesor· nicmén¥ JAVA API neu-moº¬uje zjistit po£et procesor· p°ímo. Proto jsem se, kv·li zachování nezávislosti aplikaceGAME na opera£ním systému a minimalizaci nebezpe£í granularity - viz 4.3.2.2, rozhodl po-mocí jednoduché aplikace experimentáln¥ zjistit, jaká je £asová náro£nost synchronizace vlákenpomocí r·zných synchroniza£ních prost°edk· a kolik £asu je spot°ebováno na vytvo°ení samot-ných vláken. as pot°ebný na tvorbu vláken je nejvíc závislý na velikosti datových poloºekvláken. Proto jsem testoval s r·znou velikostí dat a po£tem vláken. Tabulky 5.1 ukazují vºdyzpr·m¥rované hodnoty z dvaceti m¥°ení.

Obrázek 5.1: Porovnání doby pot°ebné na tvorbu vláken

5.2.2 as pot°ebný na synchronizaci

Výsledky m¥°ení £asu pot°ebného na synchronizace pomocí t°ídy Semaphore a pomocí metodyjoin() t°ídy java.lang.Thread uvádí následující tabulky. M¥°ení prob¥hlo po£íta£ích s dvoujádrovým procesorem na frekvenci 2,33GHz s 4GB hlavní pam¥ti a na po£íta£i s dv¥ma £ty°já-drovými procesory na frekvenci 2,66GHz a 8GB pam¥ti. Tabulky 5.2 op¥t ukazují pr·m¥rnéhodnoty z dvaceti m¥°ení, p°i£emº:

• Doba b¥hu - bez synchronizace znamená, ºe byla spu²t¥na v²echna vlákna a doba uvedenáv tabulce je £as od za£átku spou²t¥ní po skon£ení v²ech vláken.

• Doba b¥hu - synchronizace udává £as b¥hu testovací aplikace s tím, ºe vlákna jsou syn-chronizována aby v danou chvíli b¥ºelo tolik vláken, kolik je k dispozici jader

• a kone£n¥ Doba b¥hu - sekven£n¥ udává £as b¥hu aplikace, kdyº byla vlákna spou²t¥na pojednom. Nejedná se tedy p°esn¥ o £as pot°ebný pro sekven£ní chod aplikace, ale je v n¥mzahrnut i £as pot°ebný na vytvo°ení vláken, který je jednak v tabulkách taktéº uveden anavíc je ve srovnání s výslednými £asy zanedbatelný.

5.2.3 Zhodnocení

Jak je vid¥t z uvedených tabulek, nejvýhodn¥j²í z uvedených metod je pouºít synchronizacipomocí t°ídy Semaphore, p°i£emº ale rozdíly mezi v²emy m¥°enými zp·soby jsou naprosto


Obrázek 5.2: Porovnání synchroniza£ních metod

minimální. Je také vid¥t, ºe £as pot°ebný pro spu²t¥ní vláken je i p°i zna£ném objemu datovýchpoloºek jednoho vlákna zhruba 0, 1 ms na vlákno.

Ukázka t°ídy MyThread pouºité p°i m¥°ení délky b¥hu testovacího programu:

public class MyThread extends Thread {

Semaphore semaphore;

int neco;

int[] pole;

/** konstruktor MyThreadu, priradi threadu cislo a semafor a nejaka data*/

public MyThread(int n, Semaphore sem) {

this.setName("" +n);

neco = 16384;

pole = new int[neco];

semaphore = sem;

}

/** run metoda vlaken */

public void run() {

/** vnorene cykly */

try {

semaphore.acquire();

}



}

for (int i = 0; i


for (int j = 0; j


for (int i = count; i < n.size(); i++){

threads[i] = new TeachThread(i, (Neuron) n.get(i));

threads[i].start();

}

for (int i = count; i < n.size(); i++){

//synchronizing

try {

threads[i].join();

}



}

}

}

}

A kód t°ídy TeachThread:

class TeachThread extends Thread {

Neuron neuron;

public TeachThread(int i, Neuron n){

neuron = n;

}

public void run(){

neuron.learnYourself((Unit) neuron);

}

}

5.3.2 Výb¥r optimaliza£ních metod

ást optimaliza£ních algoritm· v sou£asné verzi aplikace GAME není "thread save", nap°. algo-ritmus PSO (Particle Swarm Optimization - genetický algoritmus inspirovaným chování davu,resp. hejna) vyuºívá p°i inicializaci jedinc· (t°ída Ptak) °ady statických prom¥nných, ke kterýmpak jednotlivé instance "pták·" p°istupují a m·ºe tak p°i paralelním zpracování dojít k nekonzis-tenci dat.

Výb¥r jaký optimaliza£ní algoritmus se má pouºít pro který neuron ur£uje prom¥nná typuTrainer v t°íd¥ Neuron. P°episování v²ech optimaliza£ních algoritm· je mimo rozsah tétopráce, proto jsem u kaºdého typu u£itele, t°ída Trainer a jejích potomk· zavedl metodupublic boolean isExecutableInParallelMode() která ur£uje, je -li daný algoritmus vyuºitel-ný pro mnou implementovaný zp·sob paralelizace.

5.3.3 Uchovávání výlsedk· optimalizací

Dále bylo zapot°ebí zajistit korektní uchovávání výsledk· optimalizací (u£ení). Ty bylo moºnév p·vodní, sekven£ní verzi aplikace moºné udrºovat jednu pro celou vrstvu sít¥, v prom¥nnéLayer.layerErr, typu RMSData. P°i paralelizaci by v²ak docházelo k nekorektním p°istup·mvláken k této prom¥nné. Jedním z moºných °e²ení bylo zajistit aby si kaºdý neuron uchovával


informace o svých mezivýpo£tech sám. Inicializaci a data prom¥nných typu RMSData jsem protop°esunul do t°ídy Neuron, pop°. do jejích potomk·.

5.3.4 Výb¥r mezi paralelním a sekven£ním zpracováním

Kv·li ²et°ení výkonu systému na b¥h dal²ích aplikací, jsem nabídl v menu Options moºnostzapnout £i vypnout paralelní b¥h programu. Struktura menu je udrºována v t°íd¥ GMDHtree.Pro výb¥r kterou metodu pouºít (paralelizovanou, £i sekven£ní) jsem proto upravil metodupublic void teachUnits(Neuron[] n, int inumber) tak, ºe na základ¥ kon�gura£ní pro-m¥nné GMDHtree.multiprocessor a samoz°ejm¥ meotdy isExecutableInParallelMode rozd¥lívstupní pole neuron· na dv¥ £ásti. První se zpracovává paraleln¥ a po ukon£ení b¥hu v²echvláken se druhá £ást zpracovává sekven£n¥. Pro sekven£ní zpracování se pouºívá metodapublic void teachUnitsSerial(ArrayList n).

Kód metody teachUnitsSerial(ArrayList n):

public void teachUnitsSerial(ArrayList n) {

Neuron neuron;

job = NEW_NEURON;

for (int act = 0; act < n.size(); act++) {

actualNeuron = act;

neuron = (Neuron) n.get(act);

neuron.learnYourself((Unit) neuron);

}

}

5.3.5 Vizualizace

Pro vizualici procesu u£ení slouºí t°íad RMSWindow která zaru£uje vykreslování progresu u£eníjednotlivých neuron· v dané vrstv¥ sít¥. V p°ípad¥ sekven£ního zpracování se tak vykreslujeprogres jednoho neuronu p°es celou k tomu ú£elu vyhrazenou plochu, v p°ípad¥ paralelníhozpracování je plocha okna rozd¥lena na malé £ásti podle po£tu neuron· v síti. Tento zp·sobvizualizace má spí²e prezenta£ní ú£el, v p°ípad¥ tvorby sloºitých model· na realných datech spouºitím vícero optimaliza£ních algoritm· vizualizace zbyte£n¥ prodluºuje výpo£et. Na to jepamatováno p°i pouºití FAKE GAME, které práv¥ umoº¬uje kontrolu procesu u£ení pomocícross-validace a tvorbu skupin model· a vizualizace je zna£n¥ omezena. Obrázky 5.3 a 5.4ukazují vizualizaci procesu u£ení. Je vid¥t výpo£et RMS p°i pouºití sekven£ního zpracování aparalelního p°i 15 neuronech v jedné vrstv¥ a tedy i 15-ti b¥ºících vláknech.

5.4 Testování a zhodnocení zvoleného °e²ení

5.4.1 HW speci�kace

Testování a m¥°ení prob¥hlo na po£íta£ích s procesory Intel Core 2 Duo E6550 na frekvenci2,33GHZ a 2x Intel Quad Core XEON E5430 na frekvenci 2,66GHZ, k dispoizi byly 4GB, resp.8GB hlavní pam¥ti a opera£ním systémem Microsoft Windows XP.

Verze JAVY byla v obou p°ípadech Standard Edition, Runtime Environment, Version 6.


Obrázek 5.3: Ukázka vizualizace u£ebního procesu - sekven£ní

5.4.2 M¥°ení doby b¥hu - metodika

Základní výkonostní charakteristika paralelního zpracování je jeho zrychlení oproti zpracovánísekven£nímu

S =TseqTpar

(5.1)

kde Tseq je délka b¥hu programu sekven£n¥ a Tpar je délka b¥hu paraleln¥. Zrychlení na jednojádro lze de�novat jako efektivitu

E =S

P(5.2)

kde P je po£et jader.

Provedl jsem 4 pokusy s r·zn¥ sloºitými vstupními daty a rozdílnými parametry sít¥ pro tvorbumodelu. Kaºdý pokus se skládal z 20 nezávislých m¥°ení doby optimalizace jedné vrstvy sít¥GAME. Pro °ímé m¥°ení doby b¥hu aplikace jsem op¥t vyuºil vlastní t°ídu MyTimer popsanouv kapitole 5.1. Kon�gurace sítí jsem volil co nejrozmanit¥ji, abych získal co nej²ir²í mnoºinum¥°ených £as·. B¥hem u£ení dochází k £astému zapisování mezivýsledk· u£ení, pouºívání vizual-izace apod. a lze tedy p°edpokládat, ºe se paralelizace u krat²ích optimalizací u jednoduchýchmodel· neprojeví tolik jako u t¥ch sloºitých.

5.4.3 Testovací data a kon�gurace sít¥ GAME

Jako testovací data jsem pouºíval sety realných dat, které jsou k dispozici na stránkách projektuFAKE GAME [6]. Testování probl¥hlo pomocí rozhraní FAKE GAME v aplikaci GAME, nebo´p°i plné vizualizaci by m¥°ení byla p°íli² £asov¥ náro£ná. Pouºíval jsem tato data a kon�guracesít¥ GAME:


Obrázek 5.4: Ukázka vizualizace u£ebního procesu - paralelní

5.4.3.1 M¥°ení A:

- data set soubor: ecoli-raw.txt- kon�gurace GAME: vlastní kon�gurace- cross validace: 5 folds- models in ensemble: 5

5.4.3.2 M¥°ení B:

- data set soubor: antro-age.txt- kon�gurace GAME: standart model dle FAKE GAME- cross validace: 10 folds- models in ensemble: 5

5.4.3.3 M¥°ení C:

- data set soubor: buildingraw.txt- kon�gurace GAME: quick model dle FAKE GAME- cross validace: 10 folds- models in ensemble: single model


5.4.3.4 M¥°ení D:

- data set soubor: motol-brain-pressure.txt- kon�gurace GAME: standart model dle FAKE GAME- cross validace: 10 folds- models in ensemble: 7

Zvolené kombinace nastavení sít¥ GAME by m¥ly pokrýt v¥t²inu funkcionalit které GAMEnabízí. Cross validaci jsem pouºíval kv·li zvý²ení náro£nosti a tím i prodlouºení výpo£tu. Uve-dené kon�gurace mi umoºnili provád¥t m¥°ení v rozsahu od 320 ms u kon�gurace C aº po 120000ms u kon�gurace A, aby výsledky m¥ly ²ir²í vypovídající hodnotu.

Pon¥vadº výpo£et modelu není deterministický generoval jsem vícero model· abych tak bylschopen lépe rozpoznat diferenci zp·sobenou paralelizací od vlivu náhody. Ze stejného d·vodujsem také z nam¥°ených hodnot vybíral náhodn¥ dvacet hodnot ke zpracování.

5.4.4 Zm¥°ené výsledky

Datové soubory i soubory s kon�gurací jsou na p°iloºeném CD v adresá°i \testing\data. Tab-ulka s nam¥°enými hodnotami je v adresá°i \testing. Následující grafy ukazují nam¥°ené hod-noty na obou testovacích po£íta£ích vºdy jako porovnání sekven£ního a paralelního zpracovánítestovacích dat. Grafy zobrazují maximální a minimální hodnoty, a hodnoty dolního kvartilu,mediánu a horního kvartilu.

Obrázek 5.5: Porovnání nam¥°ených hodnot na Core 2 Due

Graf 5.5 ukazuje souhrnné porovnání nam¥°ených hodnot délky b¥hu aplikace FAKE GAME prov²echna £ty°i m¥°ení na procesoru Core 2 Duo. Z grafu a následující tabulky je patrné zrychleníp°i vyuºití paralelního zpracování. V tabulce 5.6 jsou uvedeny vºdy pr·m¥rné hodnoty pro kaºdém¥°ení na tomto procesoru a pro kaºdé m¥°ení je spo£ítáno zrcyhlení podle rovnice 5.1. Je vid¥t,ºe zrychlení tady dosahuje hodnot mezi 1, 65 aº 1, 78 a tím pádem efektivita jader procesor· je


tedy od 0, 83 do 0, 89. Podle Amdahlova pravidla 4.1

1(1− P ) + P/N

(5.3)

odpovídají zm¥°eným zrychlením úsp¥²n¥ paralelizované £ásti výpo£tu rovné 83, 58%, 85, 1%,78, 84% resp. 87, 52%.

Obrázek 5.6: Zrcyhlení pro jednotlivá m¥°ení na Core 2 Duo

Na grafu 5.7 jsou podbn¥ jako na grafu 5.5 uvedeny hodnoty pro m¥°ení provád¥ná tentokrátena po£íta£i s dv¥ma procesory Quad Core XEON a v tabulce 5.8 jsou op¥t uvedeny pr·m¥rnéhodnoty £asu a zrychlení. U tohoto po£tu jader procesor· bylo dosaºeno zrychlení od 3, 36 do3, 62 s tím, ºe efektivita oproti dvoujádrovému procesoru rapidn¥ klesá - od 0, 42 po 0, 45. Op¥tpouºitím Amdahlova pravidla dostaneme velikosti paralelizové £ásti výpo£tu 82, 27%, 82, 23%,80, 29% a 82, 73%, coº jsou hodnoty velmi blízké hodnotám získaným z m¥°ení na dvoujádrovémprocesoru.

Obrázek 5.7: Porovnání nam¥°ených hodnot na 2x Quad Core Xeon

V záv¥ru m¥°ení je patrné, ºe my²lenka zmín¥ná v 5.4.2 tvrdící ºe u kratkých výpo£t· budezrcyhlení nejmen²í, byla oprávn¥ná. Nejmen²ího zrychlení bylo skute£n¥ dosaºeno u nejkrat²íchvýpo£t·, nicmén¥ obecn¥ neplatilo, ºe £ím del²í výpo£et, tím lep²í zrychlení. Na druhou stranurozdíl mezi nejlep²ím dosaºeným zrychlením u po£íta£e s dv¥ma £ty°jádrvými procesory upokusu D o hodnot¥ 3, 62 a nejmen²ím u pokusu C o hodnot¥ 3, 36 byl pouze 7, 7%.

Grafy 5.9 a 5.10 jsou jiº pouze ilustr£ní, je na nich vid¥t rozdíl v pr·m¥rných hodnotáchnam¥°eného £asu na uvedených procesorech.


Obrázek 5.8: Zrcyhlení pro jednotlivá m¥°ení na 2x Quad Core Xeon

Obrázek 5.9: Pr·m¥rné £asy b¥hu aplikace pro jednotlivá m¥°ení na Core 2 Duo

Obrázek 5.10: Pr·m¥rné £asy b¥hu aplikace pro jednotlivá m¥°ení na 2x Quad Core XEON


5.4.5 Zhodnocení nam¥°ených údaj·

Z provedených m¥°ení a Amdahlova zákona [1] vyplývá, ºe mnou uvedeným zp·sobem par-alelizace aplikace GAME dochází ke zrychlení výpo£tu odpovídající v pr·m¥ru

10, 1718 + 0,8282N

=N

0, 1718N + 0, 8282

kde N je po£et procesor·.

Grafy 5.5 a 5.7 napovídají, ºe p°i vyuºití paralelního zp·sobu zpracování dochází k sníºenívýskytu extrémních hodnot délky výpo£tu. Coº m·ºe být zp·sobeno omezením vlivu dal²íchaplikací na zatíºení procesoru a tím i prodlouºení doby výpo£tu.

Pro vyjád°ení "konzistence" zm¥°ených dat lze pouºít statistickou veli£inu varia£ní keo�cient,která je de�nována jako

V =σ

x(5.4)

kde σ je sm¥rodatná odchylka a x je pr·m¥rná hodnota. V tabulce 5.11 jsou uvedeny vºdymaximální a pr·m¥rné hodnoty pro kaºdé m¥°ení, jejich pom¥r, sm¥rodatná odchylka a varia£níkeo�cient.

Obrázek 5.11: Varia£ní keo�cienty pro jednotlivá m¥°ení

Z uvedené tabulky je z°ejmé, ºe p°i pouºívání více procesor· jsou varia£ní koe�cienty niº²í a lzetak °íci, ºe zm¥°ené £asy jsou mén¥ vystavovány náhodným vliv·m, a lze pak snadn¥ji p°edvídat£as pot°ebný na vytvo°ení modelu a s tím i odhadnout realné zrychlení.

KAPITOLA 6. ZÁVR 43

6 Záv¥r

Tato práce uvádí pot°ebný teoretický základ pro pochopení základ· problematiky induktivníhomodelování a paralelního programování v jazyku JAVA na distribuovaných systémech se sdílenoupam¥tí. Nabízí jednu z moºností paralelizace aplikace GAME a ukazuje její implementaci.

6.1 Zhodnocení vybraného °e²ení

Hlavním cíle paralelizace aplikace GAME bylo zrychlení výpo£tu model·. Jak je vid¥t z graf· nakonci p°edchozí kapitoly dochází nejen k výraznému zrychlení pr·m¥rné doby tvorby modelu, alei k sníºení výskytu extrémn¥ dlouhých výpo£t·, jeº mohou být u sekven£ního zpracování zb·-sobeny zatíºením procesoru dal²ími procesy, obzvlá²t¥ v p°ípad¥ opera£ního systému WindowsXP. Z tabulek u graf· s pr·m¥rnými hodnotami m¥°ených £as· vyplývá, ºe u dvoujádrovéhosystému bylo zrychlení mezi 1, 65−1, 78 a u po£íta£e s osmi jádry bylo zrychlení 3, 36−3, 62. Popouºití Amdahlova zákona jsme pro v²echna m¥°ení získlali zhruba stejnou hodnotu paraleli-zované £ásti výpo£tu odpovídající v pr·m¥ru 82, 82%, maximální teoreticky moºné zrychlenídosaºitelné mnou implementovaným zp·sobem paralelizace je tak

11− 0, 8282

= 5, 82

p°i po£tu pouºitých procesor· → ∞. Je také vid¥t, ºe efektivita u vyuºívání více procesor·prudce klesá a u systému s dv¥ma £ty°jádrovými procesory byla efektivita zhruba polovi£níoproti procesoru dvoujádrovému.

6.2 Moºná vylep²ení

Jako budoucí vylep²ení mnou nabízeného °e²ení je upravení v²ech optimaliza£ních algoritm·tak, aby je bylo moºno vyuºívat p°i paralelním zpracování modelu. Dal²í zlep²ení je implemen-tovat automatické rozpoznání po£tu procesor·, nebo spí²e dát uºivatel

new distribuovaný výpo£et induktivních...

Documents