Program testující výkon procesoru. Jakub Levý. ƒeské vysoké u ení technické v Praze Fakulta elektrotechnická Katedra po íta

eské vysoké u£ení technické v Praze Fakulta elektrotechnická Katedra po£íta£·

Bakalá°ská práce

Program testující výkon procesoru Jakub Levý

Vedoucí práce:

Ing. Ivan ime£ek, Ph.D.

Studijní program: Elektrotechnika a informatika, dobíhající, Bakalá°ský

Obor: Výpo£etní technika

25. kv¥tna 2011

iv

v

Pod¥kování Rád bych tímto pod¥koval p°edev²ím Ing. Ivanu ime£ekovi, Ph.D. za jeho £asté a cenné rady.

vi

vii

Prohlá²ení Prohla²uji, ºe jsem práci vypracoval samostatn¥ a pouºil jsem pouze podklady uvedené 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 25. 5. 2011

.............................................................

viii

Abstract In our daily life we come across/deal with various types of computers with various performance levels. Above all, we can denitely consider the processor as the most important feature the computer performance. The aim of my thesis is to implement a program which enables to test the processor performance and to evaluate it so that it is possible to compare the performances of particular types of processors.

Abstrakt V kaºdodenním ºivot¥ se setkáváme s r·znými druhy po£íta£·, které mají také r·zný výkon. Nejd·leºit¥j²ím prvkem ur£ujícím výkon jist¥ m·ºeme ozna£it procesor. Cílem práce je proto naimplementovat program, který umoºní otestovat výkon procesoru a ohodnotit ho takovým zp·sobem, abychom byli schopni pomocí t¥chto výsledk· srovnávat výkon jednotlivých druh· procesor·.

ix

x

Obsah 1

Úvod

1

2

Teoretický úvod

3

2.1

2.2

2.3 3

Procesor . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Architektura . . . . . . . . . . . . . . . . . . 2.1.2 Frekvence . . . . . . . . . . . . . . . . . . . . 2.1.3 Po£et jader . . . . . . . . . . . . . . . . . . . 2.1.4 HyperThreading . . . . . . . . . . . . . . . . 2.1.5 Komunikace mezi procesorem a hlavní pam¥tí 2.1.6 Cache pam¥´ . . . . . . . . . . . . . . . . . . 2.1.7 Instruk£ní sady . . . . . . . . . . . . . . . . . 2.1.8 ízení spot°eby . . . . . . . . . . . . . . . . . Opera£ní pam¥´ . . . . . . . . . . . . . . . . . . . . . 2.2.1 Základní informace . . . . . . . . . . . . . . . 2.2.2 Frekvence a latence . . . . . . . . . . . . . . . 2.2.3 Dual channel . . . . . . . . . . . . . . . . . . 2.2.4 Dal²í technologie . . . . . . . . . . . . . . . . Teorie výkonu procesoru . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

Analýza a návrh °e²ení

3.1 3.2

3.3

3.4

3 3 3 3 4 4 4 5 5 5 5 6 6 6 7 9

Úvod . . . . . . . . . . . . . . . . . . . Problematika výkonu procesoru . . . . 3.2.1 ídicí hazardy . . . . . . . . . 3.2.2 Datové hazardy . . . . . . . . . 3.2.3 Strukturní hazardy . . . . . . . Testy s podporou jednoho vlákna . . . 3.3.1 Výpo£et posloupnosti . . . . . 3.3.2 MMX instrukce . . . . . . . . . 3.3.3 adicí algoritmus . . . . . . . . 3.3.4 Práce s pam¥tí . . . . . . . . . Testy s podporou více vláken . . . . . 3.4.1 Výpo£ty aritmetických operací 3.4.2 Vyhledávání v textu . . . . . . 3.4.3 Ztrátová komprese dat . . . . . 3.4.4 Bezztrátová komprese dat . . . xi

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

9 10 11 11 11 12 12 12 12 12 13 13 13 13 14

xii

OBSAH

3.4.5 3.4.6 4

Implementace

4.1 4.2

4.3

5

P°epínání vláken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 ifrování dat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Programovací prost°edí . . . . . . . . . . Testy s podporou jednoho vlákna . . . . 4.2.1 Fibonacciho posloupnost . . . . . 4.2.2 MMX instrukce . . . . . . . . . . 4.2.3 adicí algoritmus . . . . . . . . . 4.2.4 Práce s pam¥tí . . . . . . . . . . Testy s podporou více vláken . . . . . . 4.3.1 Výpo£ty aritmetických operací . 4.3.2 Vyhledávání v textu . . . . . . . 4.3.3 Ztrátová komprese dat . . . . . . 4.3.4 Bezztrátová komprese dat . . . . 4.3.5 P°epínání vláken . . . . . . . . . 4.3.6 ifrování dat . . . . . . . . . . . 4.3.7 Gracké rozhraní . . . . . . . . . 4.3.8 Ostatní problémy s implementací

Testování

5.1 5.2

5.3 5.4 5.5 5.6 5.7

Úvod . . . . . . . . . . . . . . . . . . . . Lad¥ní . . . . . . . . . . . . . . . . . . . 5.2.1 Inicializace prom¥nných . . . . . 5.2.2 Gracké prost°edí . . . . . . . . . 5.2.3 Odlad¥ní test· . . . . . . . . . . Nastavování test· . . . . . . . . . . . . . 5.3.1 Základní problematika . . . . . . 5.3.2 Prvotní testování . . . . . . . . . P°epo£et skóre . . . . . . . . . . . . . . Výsledky testu procesoru . . . . . . . . P°enositelnost mezi opera£ními systémy Doporu£ená hardwarová kongurace . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

17

17 18 18 18 18 18 19 19 19 19 20 20 21 21 21

23

23 23 23 23 24 24 24 25 28 28 29 30

6

Záv¥r

31

7

Návrh na budoucí moºné roz²í°ení aplikace

33

A Seznam pouºitých zkratek

39

B Instala£ní a uºivatelská p°íru£ka

41

C Instala£ní manuál pro programátora

43

D Obsah p°iloºeného DVD

47

Seznam obrázk· 2.1

Rozdíl mezi relativní výkonností pam¥ti DRAM a CPU [7] . . . . . . . . . . .

3.1 3.2

K10 pipelining [10] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Jednotaktový, vícetaktový a pipeline procesor [7] . . . . . . . . . . . . . . . . 11

5.1 5.2 5.3 5.4 5.5

Výsledky test· pro procesor AMD Athlon X2 3,0 GHz Výsledky test· pro procesor Intel Core2Duo 2,2 GHz . Srovnání výsledk· test· AMD a Intel procesor· . . . . Tabulka srovnání 4 po£íta£ových systém· . . . . . . . Finální verze programu . . . . . . . . . . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

7

25 26 27 29 30

B.1 Po£áte£ní okno aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 C.1 Nastavení kolekce nástroj· . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 C.2 Nastavení cesty knihovny pthreadGC2 . . . . . . . . . . . . . . . . . . . . . . 45 C.3 Nastavení parametru kompilátoru GCC a G++ . . . . . . . . . . . . . . . . . 46 D.1 Seznam p°iloºeného DVD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

xiii

xiv

SEZNAM OBRÁZK

Kapitola 1

Úvod Mezi nejd·leºit¥j²í prvky z pohledu na celkový výkon hardwaru po£íta£e rozhodn¥ pat°í výkon procesoru. I p°es jeho neustálý a pom¥rn¥ zna£ný vývoj není stále pro mnoho operací zcela vyhovující, a to p°edev²ím z d·vodu neustálého zvy²ování nárok· pouºívaného softwaru. Také trend zvy²ování kvality multimédii (nap°. rozli²ení videozáznamu) vede k pot°eb¥ výkonn¥j²ího hardwaru. V poslední dob¥ navíc díky rychlému roz²í°ení p°enosných notebook· £i netbook· jsme sv¥dky omezování výkonu hardwaru z d·vodu sníºení ztrátového tepla. V tomto p°ípad¥ je ov²em vhodné sledovat pom¥r mezi spot°ebou a poskytnutým výkonem. Zam¥°it se pouze na zji²tování výkonu procesoru by ov²em nemuselo mít reálné vypovídací hodnoty, z tohoto d·vodu se v této práci zabývám i hardwarem úzce souvisejícím s procesorem. Zam¥°ím se tedy nejen na rychlost procesoru, ale i na opera£ní pam¥´ a p°enos mezi opera£ní pam¥tí a procesorem. Jako cíl práce jsem si stanovil nalezení a naimplementování takových typ· algoritm·, které dokáºí co nejlépe otestovat výkon procesoru pot°ebný pro aplikace, které b¥ºn¥ p°i práci s po£íta£em vyuºíváme. Soust°edit se p°itom budu na otestování výkonu p°edev²ím moderních po£íta£ových systém·.

1

2

KAPITOLA 1.

ÚVOD

Kapitola 2

Teoretický úvod 2.1 Procesor 2.1.1 Architektura Architektura moderních procesor· poºívaných v moderních osobních a p°enosných po£íta£ích je velice sloºitá. Jiº dávno p°estalo platit klasické rozd¥lení na procesory typu CISC a RISC. V dne²ní dob¥ se vlastnosti t¥chto základních typ· kombinují. Mnohem zajímav¥j²í je rozli²ení 32 a 64 bitových procesor·. Dnes umí v¥t²ina procesor· pracovat s 64 bitovými instrukcemi. 64 bitové aplikace pracující pod opera£ním systémem Microsoft Windows se bohuºel p°íli² nevyskytují. I p°esto, ºe lze díky p°izp·sobení na 64 bit· získat teoreticky aº dvojnásobný výkon, v praxi bývá nár·st výkonu daleko niº²í. Nejv¥t²í výhodou tak prozatím z·stává schopnost adresovat pam¥´ v¥t²í neº pouhé 4 GB. [7] Nadále se ale jiº nebudu zabývat technologickými detaily procesor·, zam¥°ím se p°edev²ím na d·leºité prvky a parametry, které zna£n¥ ovliv¬ují (£i mohou ovliv¬ovat) celkový výkon systému.

2.1.2 Frekvence Frekvence zajisté pat°í mezi klí£ové parametry procesoru. Zpravidla se volí jako násobek frekvence systémové sb¥rnice. V dne²ní dob¥ se na trhu vyskytují procesory s taktem 1,2 - 3,6 GHz a dle dosavadního vývoje lze p°edpokládat, ºe se tato hranice v dohledné dob¥ výrazn¥ji m¥nit nebude. Sou£asná technologie totiº v podstat¥ narazila na sv·j frekven£ní limit vzhledem k nízkému nár·stu výkonu a sou£asnému neúm¥rnému navý²ení spot°eby (spolu s frekvencí je zárove¬ nutné zvy²ovat i nap¥tí CPU) se výrobci rozhodli zvolit jinou cestu pro vylep²ení výkonu svých procesor·. Mimo to dochází k regulaci vyza°ování odpadního tepla pomocí sniºovaní nap¥tí a taktu CPU v závislosti na aktuálním zatíºení (vysoce ²etrné Intel Atom sniºují frekvenci aº na 100 MHz).

2.1.3 Po£et jader Zvy²ování po£tu jader se ukázalo jako nejsch·dn¥j²í cesta ke zna£n¥ vy²²ímu výkonu. Systém s více procesory je daleko draº²í neº platformy s vícejádrovým procesorem, ov²em navý²ení 3

4

KAPITOLA 2.

TEORETICKÝ ÚVOD

výkonu tomu neodpovídá. Z tohoto d·vodu se víceprocesorové po£íta£e pouºívají výhradn¥ pro serverové £i v¥decké ú£ely. V dne²ní dob¥ nalezneme na trhu 1-12 jádrové CPU a o£ekává se dal²í zvy²ování po£tu jader.

2.1.4 HyperThreading HyperThreading je technologie, která díky zdvojení °ídicích registr· jádra navenek budí dojem, ºe se jedná o dv¥ výpo£etní jednotky. Díky tomu se rychlost dle r·zných test· zvý²í aº o 30 procent. Intel tuto technologii poprvé pouºil ve svých Pentium 4 jako odezvu na v té dob¥ vysp¥lé AMD Athlon XP, které dokázaly zpracovat aº 3 instrukce b¥hem jednoho taktu (oproti Intel Pentium 4 se svojí 1 instrukcí za jeden takt). Kv·li vysoké spot°eb¥ se ov²em nakonec u Pentium 4 od této technologie upustilo a Intel se rozhodl ji znovu pouºít teprve u úsporných model· °ady Atom a nejnov¥j²ích procesor· °ady Core i. [15]

2.1.5 Komunikace mezi procesorem a hlavní pam¥tí Komunikace mezi procesorem a hlavní pam¥tí probíhá (p°edev²ím) dv¥ma r·znými cestami. Komunikaci zaji²úje pam¥óvý °adi£, který je bu¤ integrován v £ipsetu, konkrétn¥ northbridge (severním m·stku), anebo p°ímo na desce mikroprocesoru. Pam¥óvý °adi£ umíst¥ný v £ipsetu se pouºívá u star²ích procesor· spole£nosti AMD (°ada K7 a niº²í) a u procesor· spole£nosti Intel se s ním setkáváme dodnes, krom¥ systém· zaloºených na n¥jnov¥j²ích procesorech (nap°. Core i3, i5, i7 £i mobilní verze Pentium DualCore P6xxx). Pokud není pam¥óvý °adi£ umíst¥n v procesoru, ale v £ipsetu, komunikuje procesor s °adi£em p°es systémovou sb¥rnici. adi£ je poté dále propojen p°ímo s pam¥óvými moduly. Díky tomuto uzp·sobení je výkon celého systému závislý jak na pouºitém £ipsetu, tak i na rychlosti systémové sb¥rnice. V n¥kterých p°ípadech dokonce není moºné vyuºívat maximální propustnost, kterou by nám umoº¬ovala opera£ní pam¥´, jelikoº propustnost sb¥rnice je niº²í. Samoz°ejm¥ se tím sniºuje i vybavovací rychlost dat. adi£ integrovaný v procesoru se zdá být vhodným °e²ením a p°edpokládá se, ºe procesory se i nadále budou ubírat touto cestou. N¥které nov¥j²í procesory mají dokonce více °adi£·, kdy kaºdý obsluhuje jeden pár pam¥óvých modul· (pokud jsou nainstalovány) a umoºnuje tak vyuºít technologii dual-channel pro více pam¥óvých modul·. U technologie dual-channel máme zpravidla na výb¥r ze dvou r·zných mód· Ganded a Unganged, o kterých budu dále mluvit v £ásti. Dual Channel [30] [31] [32]

2.1.6 Cache pam¥´ D·leºitým faktorem p°i výb¥ru procesoru je velikost, rychlost a struktura pam¥ti Cache. Pam¥´ Cache v moderních procesorech mívá 2 nebo 3 úrovn¥. Cache L1 (1. úrovn¥) je velmi rychlá, s vybavovací rychlostí okolo 1 ns a velikostí °ádov¥ v desítkách kB na jádro procesoru. Výrobci procesor· ji umisújí co moºná nejblíºe k samotnému jádru procesoru. Velikost Cache L1 ov²em samoz°ejm¥ není dostate£ná pro v¥t²inu aplikací, proto v²echny moderní CPU obsahují i Cache L2, která není tak drahá, ale bohuºel ani tak rychlá jako L1. Typická velikost Cache L2 bývá okolo 128 kB - 2 MB na jádro procesoru. M·ºe být bu¤

2.2.

OPERANÍ PAM

5

privátní pro kaºdé jádro (procesory AMD), £i sdílená v²em jádr·m procesoru (Intel Core 2 Duo a nov¥j²í). V poslední dob¥ se také objevují CPU s Cache L3, s rychlostí niº²í neº L2, ov²em s velikostí aº 12 MB. Tato Cache pam¥´ se jiº pouºívá výhradn¥ jako sdílená pro v²echna jádra. Cache pam¥´ nezvy²uje kapacitu celkové pam¥ti v po£íta£i, jelikoº data se duplikují ve v²ech úrovních Cache i hlavní pam¥ti. Vyuºívá se tedy pro rychlej²í získání jiº pouºitých dat. Pro °ízení dat v Cache pam¥ti se pouºívají r·zné technologie a práv¥ i na t¥chto technologiích záleºí výkon celého systému.

2.1.7 Instruk£ní sady Pro zvý²ení výkonu v ur£ité skupin¥ aplikací se pouºívají p°ídavné instruk£ní sady. První známou sadou bylo roz²í°ení MMX (Intel Pentium MMX), která obsahovala instrukce vyuºitelné p°edev²ím pro multimediální výpo£ty. Nevýhoda této sady je p°edev²ím umoºn¥ní práce pouze s celými £ísly. Tento nedostatek vy°e²ila technologie 3D Now! konkuren£ní spole£nosti AMD. Intel poté implementoval vlastní roz²í°ení SSE (verze SSE 1, 2, 3S, 4 a 5). [17] [35]

2.1.8 ízení spot°eby Snaha o co energeticky nej²etrn¥j²í procesory donutila výrobce implemetovat technologie umoºnující zm¥nu frekvence a nap¥tí v závislosti na aktuálním zatíºení. Procesor·m Intel umoº¬uje °ídit nap¥tí a frekvenci technologie SpeedStep, konkuren£ní spole£nost AMD ji nazývá PowerNow! u °ady Opteron, u ostatních °ad poté Cool and Quiet. Nejnov¥j²í procesory Intel st°ední a vy²²í t°ídy (Core i5, i7) nov¥ pouºívají také funkci TurboBoast, která v p°ípad¥ nevyuºití v²ech jader procesoru (a v p°ípad¥ pot°eby) zvý²í frekvenci pouºívaných jader (tím vyuºívá maximální hodnotu TDP). Nové °ady Core i5 a i7 (SandyBridge) dokonce umoº¬ují do£asn¥ procesory p°etíºit a vyuºít tak tepelnou absorbci pouºitého chladi£e. [36] [6]

2.2 Opera£ní pam¥´ 2.2.1 Základní informace Rychlost a struktura opera£ní pam¥ti je d·leºitým faktorem ovliv¬ujícím výkon celého systému. Procesor v reálných aplikacích £asto pom¥rn¥ dlouhou dobu £eká, neº získá poºadovaná data v p°ípad¥, ºe je nenalezne v pam¥ti Cache. P°ed samotným popisem opera£ní pam¥ti povaºuji za vhodné uvést základní parametry:

• Frekvence pam¥ti - b¥ºn¥ udávanou frekvencí je p°edev²ím efektivní hodnota frekvence, na které pracuje vnit°ní sb¥rnice pam¥ti. • CAS latency (CL) - zpoºd¥ní mezi p°ijmutím poºadavku (pam¥tí) o p°e£tení sloupce pam¥ti a moºného p°e£tení poºadovaných dat (bloku dat) . • RAS to CAS (tRCD) - zpoºd¥ní mezi p°echodem °ádkové a sloupcové identikace

6

KAPITOLA 2.

TEORETICKÝ ÚVOD

• Row Precharge Delay (tRP, tRCP) - doba, po kterou se udrºuje adresovaný blok pam¥ti, neº je povoleno na£íst dal²í blok dat. • Row to Active Delay (tRA, tRD, tRAS) - doba, která p°edstavuje celkový £as vybavení bloku dat. • Command Rate (CMD, tCMD) - minimální doba mezi aktivováním pam¥óvé bu¬ky a vysláním p°íkazu. [2] [22] [8]

2.2.2 Frekvence a latence Frekvenci m·ºeme (mimo kapacity) ozna£it za nejd·leºit¥j²í parametr hlavní pam¥ti. Rychlost vybavení dat a propustnost p°ímo souvisí s touto hodnotou. Na druhé stran¥ se zvy²ující se frekvencí obvykle dostáváme i vy²²í dobu vybavení dat (latence). Z toho d·vodu zvý²ení frekvence hlavní pam¥ti nemusí nutn¥ znamenat zlep²ení výkonu ve v²ech aplikacích. Vybavovací doba se totiº p°íli² nem¥ní, pouze propustnost pam¥ti je díky prokládání poºadavk· na data tém¥° p°ímo úm¥rná frekvenci. [14] Pokud pam¥óvý °adi£ za²le poºadavek na ur£itá data, provede se nejd°íve na£tení °ádku pam¥ti, tato operace samoz°ejm¥ n¥jakou dobu trvá, poté se p°epne °ádková na sloupcovou identikaci (tRCD), po které musíme op¥t po£kat, neº se poºadovaná data na£tou. U opera£ní pam¥ti musíme také po£ítat s dal²ími zpoºd¥ními, jako jsou nap°. tRP (Row Precharge Delay) a CMD (Command Rate). Pokud bychom museli pokaºdé £ekat, aº se data tímto zp·sobem na£tou, znamenalo by to neúm¥rné (a zbyte£né) zpomalení. Proto se v moderních po£íta£ích pouºívá jiº zmi¬ované prokládání, kdy p°istupujeme k více pam¥óvým bankám rychle po sob¥ a tím pádem eliminujeme vliv dlouhé vybavovací doby. Ke zrychlení pomáhá i prefetch buer, o kterém se zmi¬uji v sekci Dal²í

technologie

2.2.3 Dual channel Technologie dual channel umoº¬uje procesoru získávat data paraleln¥ z více pam¥óvých modul·. Nap°íklad v p°ípad¥ pouºítí dual channelu u moderních DDR3 modul· získáme místo 64 bit· dat dvojnásobek (128 bit·). Nov¥j²í systémy navíc umoº¬ují zvolit si reºim této technologie, a to bu¤ Ganged nebo Unganged mód. [24] Rozdíl mezi nimi je ve zp·sobu získávání a ukládání dat do pam¥ti. P°i zvolení Ganged módu se rozhraní pam¥ti jednoho kanálu chová jako jeden celek (nap°íklad 1x128 bit·), zatímco v módu Unganged k nim m·ºeme p°istupovat odd¥len¥ (simuluje se rozhraní nap°. 2x64 bit·), tím pádem je nám umoºn¥no £íst a zapisovat do pam¥ti zárove¬. V praxi je daleko výhodn¥j²í mód Unganged. Ganged mód v n¥kterých p°ípadech dokonce daný systém zpomaluje, jelikoº se vºdy zpracovává celých 128 bit·, a to i v p°ípad¥, ºe je nepot°ebujeme.

2.2.4 Dal²í technologie Nezáleºí samoz°ejm¥ pouze na frekvenci a latenci opera£ní pam¥ti. V minulosti se nap°íklad pouºívaly opera£ní pam¥ti RDRAM (Rambus DRAM) s daleko vy²²í frekvencí neº tehdej²í

2.3.

TEORIE VÝKONU PROCESORU

7

DDR (DDR SDRAM), ov²em díky jejich vysoké cen¥, nep°esved£ivé doby vybavení a pouze 16bitovému rozhraní modulu se DDR staly v podstat¥ jedinými pouºívanými (v osobních i p°enosných po£íta£ích) moduly. RDRAM se tak instalují pouze do speciálních za°ízení (nap°. Sony PlayStation). Zatímco u grackých karet se b¥ºn¥ pouºívají GDDR (Graphics DDR) verze 4 a 5, jako systémová pam¥´ p°evaºuje zatím pouze DDR 2 a 3. Jednotlivé verze se neli²í pouze svými frekvencemi a latencemi, jak DDR 2, tak i DDR 3 získaly inovaci v podob¥ propracovan¥j²ího tzv. Prefetch Bueru. Prefetch Buer umoº¬uje na£tení n¥kolika datových slov (v jednom °ádku) rychle za sebou, DDR umoº¬uje na£íst 2 slova, DDR 2 £ty°i slova a DDR 3 poté 8 slov a tím i samoz°ejm¥ zrychlit na£tení dat z opera£ní pam¥ti. Dal²í d·leºitou (a jiº zmi¬ovanou) technologií je tzv. prokládání (Interleaving). Ta umoº¬uje na£ítání dat st°ídav¥ z n¥kolika pam¥óvých bun¥k najednou a tím výrazn¥ zvý²it propustnost. Nedochází tedy k razantnímu zpomalení z d·vodu dlouhé vybavovací doby. [24] [37]

2.3 Teorie výkonu procesoru Pokud nebereme v úvahu £ekání na V/V, m·ºeme vypo£ítat dobu b¥hu programu jednoduchým vzorcem

Tcpu (prg) = IC(prg) ∗ CP I(prg) ∗ Tclk , kde Tcpu (prg) je doba pr·b¥hu programu, IC(prg) po£et instrukcí daného programu prg, CPI(prg) po£et hodinových cykl· na jednu instrukci daného programu prg a Tclk doba periody hodin procesoru. Po zhlédnutí následujícího grafu je ov²em z°ejmé, ºe takový výpo£et nemá reálnou vypovídací hodnotu.

Obrázek 2.1: Rozdíl mezi relativní výkonností pam¥ti DRAM a CPU [7] Proto musíme do výpo£tu zanést i £ekání na V/V, £ímº se vzorec zm¥ní na následující

Tcpu = (Cyccpu + Cycmem ) ∗ Tclk = IC ∗ (CP I + M AP I ∗ M R ∗ M P ) ∗ Tclk ,

8

KAPITOLA 2.

TEORETICKÝ ÚVOD

kde MAPI je po£et pam¥óvých p°ístup· na instrukci programu, MP pr·m¥rný £as získání dat z pam¥ti niº²í úrovn¥ a MR pr·m¥rný výskyt pam¥óvých výpadk·. Díky t¥mto zm¥nám se m·ºe £as prodlouºit i n¥kolikanásobn¥. Zanesení zpoºd¥ní zp·sobené výpadky dat v pam¥ti Cache je teda nutné pro správné ohodnocení výkonu.

Kapitola 3

Analýza a návrh °e²ení 3.1 Úvod Testovat výkon procesoru m·ºeme r·znými zp·soby. Osobn¥ bych moºnosti rozd¥lil do dvou základních typ·. První a jednodu²²í je pouºití algoritm·, které se zam¥°ují p°ímo na jednu konkrétní výpo£etní £ást procesoru (stejný typ operací), £i hardwarovou £ást po£íta£e úzce související s procesorem. V tomto p°ípad¥ se snaºíme eliminovat v²echny vn¥j²í faktory, které by mohly zp·sobovat zpomalení pr·b¥hu algoritmu (nap°. pouºití pouze takového objemu dat, který m·ºe být uloºen v Cache pam¥ti 1. úrovn¥). Tím otestujeme tzv. hrubý výkon námi ur£ené hardwarové £ásti po£íta£e. Hodnotu získanou z takového testu bychom mohli téº ozna£ovat jako teoretický výkon dané £ásti po£íta£e. Jako druhou moºnost bych ozna£il vyuºití benchmark· simulujících reálný chod aplikací. Nesnaºíme se tedy izolovat výkon ur£ité £ásti, ale testujeme výkon v¥t²ího celku. Výrazn¥ se v t¥chto testech odrazí nap°íklad £ekání na pot°ebná data (pokud nejsou nalezena v Cache pam¥ti) a o£ekáváme i v¥t²í vliv pouºitého opera£ního systému a jeho momentálního stavu. Pro otestování procesoru jsem se nakonec rozhodl vyuºít jak prvního typu t¥chto algoritm·, tak i kombinaci obou t¥chto typ·. Mimo test· izolovaných £ástí tedy budu testovat i v¥t²í celky po£íta£e, a to pomocí algoritm·, které se pouºívají v reálných programech, £i algoritm·, se kterými se moºná nev¥dom¥ setkáváme v podstat¥ kaºdý den. Vzhledem k trendu zvy²ování po£tu jader procesoru a zam¥°ení se na co nejefektivn¥j²í a nejrychlej²í rozd¥lení práce jednotlivým jádr·m procesoru jsem testy rozd¥lil do kategorií:

• testy zji²újící výkon jednoho jádra • testy zji²újící výkon více jader N¥které mnou vybrané algoritmy proto vyuºívají pouze jedno vlákno, n¥které více vláken a n¥které aplikace jsou schopny b¥ºet na jednom i více vláknech (v závislosti na vstupním argumentu). 9

10

KAPITOLA 3.

ANALÝZA A NÁVRH EENÍ

3.2 Problematika výkonu procesoru Vyuºít stoprocentn¥ potenciál procesoru je velmi obtíºné, £i dokonce p°ímo nemoºné. Existuje n¥kolik oblastí, které musíme brát v úvahu za p°edpokladu, ºe chceme co nejvíce vyuºít schopností procesoru. Pro pochopení následující problematiky je nutné znát funkcionalitu technologie pipelining. První verze procesor· byly tzv. jednotaktové, které zpracovávaly kaºdou instrukci v jednom hodinovém taktu. Tento zp·sob °e²í sice mnoºství problém·, které musíme brát v potaz u moderních CPU, na druhou stranu frekvence, na které procesor pracoval, musela být velice nízká, jelikoº bylo nutné v²echny fáze procesoru provést najednou. Pro zvý²ení frekvence odd¥líme jednotlivé fáze (vloºíme mezi n¥ registr), £ímº vznikne tzv. vícetaktový procesor. Zpravidla mluvíme o t¥chto fázích:

• Instruction Fetch - na£tení instrukce • Operand Fetch - na£tení operand· • Execute - provedení instrukce • Memory Access - práce s pam¥tí (£tení/zápis) • Result Store/Write Back - uloºení výsledku Jedná se ov²em pouze o obecné schéma, jednotlivé typy procesor· mohou mít fáze rozd¥lené na n¥kolik men²ích, £i naopak mohou být sjednocené. Rozd¥lením jsme sice zvý²ili hranici maximální frekvence procesoru, kaºdá instrukce ale trvá více takt·, reálné zvý²ení výkonu proto nenastává. Jiná situace ov²em nastane v p°ípad¥, ºe pouºijeme jiº zmi¬ovaný pipelining.

Obrázek 3.1: K10 pipelining [10] Na obrázku vidíme rozd¥lení pipeliningu p°i zpracování celo£íselných operací u procesoru AMD °ady K10 (p°i operaci s plovoucí £árkou má 17 fází). Pipelining vyuºívá rozd¥lení instrukce na jednotlivé fáze a umoº¬uje nám, aby kaºdá fáze zpracovávala jinou instrukci. Nemusíme tedy £ekat, aº práv¥ probíhající instrukce skon£í, sta£í pouze, kdyº dokon£í ur£itou fázi. Tím docílíme zpracovávání více instrukcí najednou.

3.2.

PROBLEMATIKA VÝKONU PROCESORU

11

Obrázek 3.2: Jednotaktový, vícetaktový a pipeline procesor [7] Jak je vid¥t, díky pipeliningu se zpracování instrukcí m·ºe velice urychlit. Problém nastává, pokud se instrukce zastaví z d·vodu hazardu (ang. Stall).

3.2.1 ídicí hazardy V této £ásti budu mluvit p°edev²ím o tzv. Branch Stallu, který nastává v p°ípad¥, ºe je plynulý tok instrukcí p°eru²en z d·vodu skoku na jiné místo v programu. Pokud budeme brát v úvahu jazyk C, Branch Stall nastává nap°. p°i instrukcích if, while, for a case. V krajním p°ípad¥ Branch Stall znamená zru²ení v²ech instukcí, které jsou jiº rozpracované. Snaºíme se proto tento Stall eliminovat, a to jak hardwarovým p°izp·sobením, tak i softwarovým (nap°. optimalizátory p°edklada£·). Schopnost procesoru eliminovat Branch Stall tedy m·ºe v n¥kterých p°ípadech zna£n¥ ovliv¬ovat pr·b¥h programu.

3.2.2 Datové hazardy Stejn¥ jako °ídicí, jsou datové hazardy d·sledkem koniktu mezi sémantikou programu a pipeliningem. Dochází k nim v p°ípadech, kdy následující instrukce pot°ebuje ke svému vykonání výsledek instrukce p°edchozí (která je²t¥ nebyla dokon£ena). V tomto p°ípad¥ se musí následující instrukce pozastavit, p°ípadn¥ m·ºe být tento problém zredukován tzv. forwardingem, kdy následující instrukce pracuje zprvu se starými daty, a teprve v jejím pr·b¥hu dostane správná data k dispozici (fáze, ve které jiº musí mít následující instrukce data správná, závisí na zp·sobu implementace forwardingu).

3.2.3 Strukturní hazardy Oproti °ídicím a datovým, strukturní hazardy jsou d·sledkem nedokonalého pipeliningu. V reálných systémech to p°edstavuje p°edev²ím £ekání na data ve sdílené pam¥ti Cache (£i hlavní pam¥ti, pop°ípad¥ v pevném disku). Op¥t nám m·ºe pomoci optimalizace zdrojového

12

KAPITOLA 3.


kódu programu; na rychlost a velikost Cache pam¥ti se ov²em zam¥°ují i sami výrobci procesor·, jelikoº napsat program, který ke svému b¥hu nepot°ebuje Cache pam¥´, je v dne²ní dob¥ v podstat¥ nemoºné.

3.3 Testy s podporou jednoho vlákna 3.3.1 Výpo£et posloupnosti Mezi nejznám¥j²í a nejpouºívan¥j²í posloupnosti dozajisté pat°í i Fibonacciho posloupnost. Mimo jiné se pomocí této posloupnosti ur£uje tzv. zlatý °ez, který je ozna£ován za ideální pom¥r stran. V testu pouºívám velmi neefektivní rekurzivní implementaci Fibonacciho posloupnosti s exponenciální sloºitostí (otestujeme tak p°edev²ím hrubý výkon procesoru) i implementaci metodou postupného výpo£tu se sloºitostí lineární. [33] [3]

3.3.2 MMX instrukce Podporu roz²í°ené instruk£ní sady MMX dnes nalezneme v kaºdém moderním procesoru. Zprost°edkovává nám rychlej²í výpo£ty instrukcí vyuºívaných p°edev²ím v multimédiích, a to pomocí zvlá²tní výpo£etní jednotky. Pracuje s 64 bitovými £ísly (jejich vektory). Umoº¬uje nám provád¥t aritmetické a logické výpo£ty, posuny nebo komparace.

3.3.3 adicí algoritmus Nejroz²í°en¥j²í °adicí algoritmus QuickSort pat°í mezi nejrychlej²í algoritmy i p°esto, ºe byl vyvinut jiº p°ed n¥kolika desítkami let. Stal se natolik oblíbený, ºe ho n¥které programovací jazyky integrují do své standardní knihovny. Má sice sloºitost v nejhor²ím p°ípad¥ O(n2 ), ve v¥t²in¥ p°ípad· ov²em pracuje se sloºitostí Ω(n*log(n)). Samoz°ejm¥ ne pro v²echny typy vstupních dat QuickSort vykazuje nejlep²í výsledky, ale pr·m¥rná doba se°azení dat je na velice dobré úrovni. QuickSort pracuje na principu porovnávání prvk·. Základní my²lenkou je rozd¥lení pole £ísel na dv¥ p°ibliºn¥ stejné £ásti (práv¥ na tom, jak dob°e se pole poda°í rozd¥lit, závisí sloºitost algoritmu), kde v levé £ásti jsou prvky men²í neº libovoln¥ zvolená hodnota, naopak v pravé £ásti jsou prvky v¥t²í. Po rozd¥lení pole £ísel na pole men²í probíhá dal²í rozd¥lení. Takto algoritmus pokra£uje aº do doby, kdy je pole rozd¥leno na jednotlivé prvky. Algoritmus tedy pracuje na principu rozd¥l a panuj. [25]

3.3.4 Práce s pam¥tí Rychlost opera£ní pam¥ti a vyuºití technologií, které urychlují práci s ní, jsou d·leºitými faktory výkonu po£íta£ového systému. Pokud totiº procesor nenalezne poºadovaná data v pam¥ti Cache, musí £ekat pom¥rn¥ dlouhou dobu, neº se na£tou z hlavní pam¥ti (pokud nejsou ani v hlavní pam¥ti, dochází je²t¥ k daleko v¥t²ímu zpoºd¥ní). V tomto testu se tedy snaºíme simulovat rychlost na£tení dat v p°ípadech:

• Sekven£ní £tení - rychlost na£ítání dat souvislého bloku. Data jsou v¥t²inou nalezena v pam¥ti Cache, ale ob£as je nutné £ekat na p°ísun dat z hlavní pam¥ti.

3.4.

13

TESTY S PODPOROU VÍCE VLÁKEN

• tení dat z r·zných míst hlavní pam¥ti - procesor musí neustále £ekat na data (na£tení z hlavní pam¥ti), jelikoº jen z°ídkakdy nalezne data v pam¥ti Cache. [21]

3.4 Testy s podporou více vláken Tyto testy mohou pracovat v reºimu práce s jedním i více vlákny.

3.4.1 Výpo£ty aritmetických operací Tento test pat°í mezi nejjednodu²²í testy v mém programu. Jedná se pouze o m¥°ení rychlosti výpo£tu aritmetických operací (+, -, *, /). Vzhledem k nízké pam¥óvé náro£nosti by se v¥t²inu doby b¥hu algoritmu m¥la data uchovávat v pam¥ti Cache L1, díky £emuº nedochází k £ekání na vstup/výstup. P°i vícevláknovém pr·b¥hu se poté rozd¥lí mnoºství operací jednotlivým vlákn·m. Vzhledem k podstat¥ testu p°edpokládám, ºe zrychlení bude tém¥° k-násobné (kde k se rovná po£et jader).

3.4.2 Vyhledávání v textu Mezi velmi £asto vyuºívané funkce jist¥ pat°í vyhledávání slov v textu. Ze ²kály r·zných algoritm· jsem si vybral práv¥ Boyer-Moore. Oproti naivnímu postupu p°i vyhledávání totiº srovnává strukturu hledaného slova a prohledávaného °et¥zce odzadu a tím umoº¬uje zrychlení pr·chodu aº k-krát (kde k se rovná velikosti hledaného °et¥zce) v p°ípadech, kdy nenalezne ºádnou shodu. V nejhor²ím p°ípad¥ poté pracuje se sloºitostí O(n). V testu volím pom¥rn¥ dlouhý hledaný °et¥zec i vstupní text, tím pádem by se do doby vyhledávání m¥la odrazit i rychlost vyrovnávací pam¥ti Cache, p°ípadn¥ i hlavní pam¥ti. [16] Pro testování vícejádrových procesor· se text rozd¥lí na n¥kolik £ástí a jednotlivé £ásti se p°i°adí vytvo°eným vlákn·m. Tím se docílí paralelní zpracování dat.

3.4.3 Ztrátová komprese dat Ztrátová komprese dat se stala velice roz²í°enou p°edev²ím kv·li nár·stu pouºívání multimédií a rozvoji Internetu, kde se snaºíme, aby p°ená²ená data m¥la co nejmen²í velikost a zárove¬ zachovávala ur£itou kvalitu. Asi nej£ast¥ji uºivatelem vyuºívanou kompresí je komprese bitmapových obrázk·. Vzhledem k tomu jsem pro test zvolil kompresi JPEG, konkrétn¥ první z jeho £ástí - diskrétní kosinovou transformaci. Diskrétní kosinová transformace se nepouºívá jen u obrazového formátu JPEG, ale i p°i konverzi videozáznam· (MJPEG, MPEG, DV) a její modikaci nalezneme i u zvukových multimédií (AAC, MP3, Vorbis). Analyzuje sloºení dat a ur£uje nám p°evládající sloºku. Získáme tak p°esné ur£ení intenzity jednotlivých sloºek. Jedná se o bezztrátový proces, jehoº data se p°ípadn¥ v dal²ím kroku zaokrouhlí, a tím dochází ke ztrátovosti. V mém p°ípad¥ volím typ DCT-II, která má vzorec:

Xk =

N −1 X k=1

[29] [19]

xn cos[

π 1 (n + )k] N 2

(3.1)

14

KAPITOLA 3.


3.4.4 Bezztrátová komprese dat Bezztrátové kompresní algoritmy se pouºívají jak pro bezztrátovou kompresi, tak i jako dopln¥k ke ztrátovým algoritm·m. V praxi se pouºívá n¥kolik typ· t¥chto algoritm·:

• Triviální - metody hledající opakující se znaky za sebou (nap°. RLE), jejich ú£innost siln¥ závisí na vstupních datech. • Slovníkové algoritmy - nejú£inn¥j²í p°i kompresi textu. Hledají stejné posloupnosti znak· a subtituují je za speciální kódy (nap°. LZMA). • Statické algoritmy - zanalyzují vstupní data a dle statistiky po£tu jednotlivých znak· vygenerují kódy znak·, které se poté zam¥ní za p·vodní (Humanovo kódování). [28] [18] Z vý²e uvedených moºností jsem vybral Humanovo kódování, které se pouºívá jak u bezztrátových kompresí (Deoy, GIF, PNG), tak i jako dopln¥k ke ztrátovým kompresím (nap°. JPEG). Pr·b¥h kódování je navíc z £ásti podobný i slovníkovým algoritm·m, tudíº dob°e simuluje pouºití komplexních kompresních metod.

3.4.5 P°epínání vláken Aktuální vývoj na poli výpo£etní techniky jasn¥ ukazuje, ºe budoucnost pat°í p°edev²ím aplikacím podporujícím vícevláknové zpracování. Obecn¥, pokud je to vzhledem k pot°ebám aplikace moºné, dává se p°ednost vyuºití vytvá°ení vláken p°ed procesy, a to p°edev²ím z d·vodu daleko niº²í reºie systémových prost°edk· p°i vytvá°ení £i p°epínání vláken, neº jakých dosahujeme u proces·. Rychlost p°epínání závisí nejen na pouºitém procesoru, ale i na zvoleném opera£ním systému, který se díky tomu promítne do výsledku. ádným standardním zp·sobem bohuºel nejde systému p°ikázat, aby daná vlákna p°epínal, dokonce ani za pouºití mutex·. Reºii vlákna lze ale zjistit pomocí vypo£tení rozdílu doby zpracování stejných dat p°i r·zném po£tu spu²t¥ných vláken.

3.4.6 ifrování dat Dal²í skupinou £asto pouºívaných algoritm· jsou algoritmy ²ifrovací. V n¥kterých p°ípadech jsou realizované hardwarov¥ (hardwarové ²ifrování USB ash disk·), ale nap°. p°i odesílání hesel £i d·leºitých dat p°es webové aplikace, £i pro ²ifrování dat na pevném disku stále vyuºíváme výpo£etní výkon procesoru. Z celé ²kály r·zných ²ifrovacích metod jsem vybral vít¥ze sout¥ºe o AES, metodu Rijn-Dael, která se stala tzv. ²ifrovacím algoritmem 3. tisíciletí. Mimo vytvo°ení klí£e má ²ifrování 4 hlavní kroky:

• SubBytes - nelineární bytová substituce, kaºdý byt nahradíme jiným dle p°edem daného klí£e, £ímº zajistíme nelineárnost ²ifry. Zabraníme tak útok·m zaloºeným na jednoduchých algebraických vlastnostech. [39] • ShiftRows - rotace bytu v matici. 1. °ádek z·stává nezm¥nen, u 2. °ádku prob¥hne rotace o 1 doprava, u 3. °ádku o 2, atd.

3.4.


15

• MixColumns - vynásobení sloupc· matice polynomem c(x) = 3x3 + x2 + x + 2, £ímº docílíme promíchání sloupc·. • AddRoundKey - nad kaºdým bytem matice vykonáme operaci xor s maticí subklí£·, které získáme z p·vodního klí£e pomocí tzv. Rijndaelovy tabulky. [1] [9] Pro testování rychlosti pr·b¥hu ²ifrovacích algoritm· je tedy vhodné simulovat tyto 4 práv¥ zmín¥né kroky.

16

KAPITOLA 3.


Kapitola 4

Implementace 4.1 Programovací prost°edí Výb¥r programovacího jazyka byl pom¥rn¥ jednoduchý a rychlý proces. Vzhledem ke svým zku²enostem se mi nabízely p°edev²ím dv¥ varianty - Java nebo C/C++. Java, jakoºto vy²²í programovcí jazyk, umoº¬uje jednodu²²í a rychlej²í implementaci, na druhou stranu to znamená, ºe máme omezený prostor ke kontrole, jak doopravdy námi napsaný program probíhá (jakým zp·sobem jsou implementovány jednotlivé funkce). Kv·li této vlastnosti jsem si vybral jazyk C, ve kterém ob£as pouºiji s výhodou jazyk C++. [11] [12] P°i rozhodování, jaké programovací prost°edí a nástroje pro jazyk C/C++ pouºít, jsem se snaºil zohlednit moºnost spu²t¥ní aplikace ve více druzích opera£ního systému. Po prozkoumání n¥kolika alternativ mi zbyly v podstat¥ dv¥ moºnosti pro MS Windows. Pouºít prost°edí MinGW nebo CygWin. MinGW m·ºeme povaºovat za úsporn¥j²í verzi CygWinu, pouºívá ov²em WIN32 API místo unixové verze tohoto rozhraní. Tím pádem jsou drobné rozdíly v pouºívání funkcí z knihovny pthread. N¥které funkce úpln¥ chybí, nap°íklad funkce pro vytvá°ení nových proces· fork(). [34] [4] Naproti tomu CygWin umoº¬uje pouºití t¥chto funkcí, ov²em za cenu sníºení výkonu z d·vodu emulace unixového prost°edí. I p°es pohodlnost CygWinu jsem se rozhodl pro prost°edí MinGW, jelikoº mi nep°i²lo vhodné, aby program testující výkon procesoru m¥l zkreslené výsledky touto emulací. Odli²nost volání vláken jsem ve Windows vy°e²il odkazováním na knihovnu pthreadGC2, která spolupracuje s Win32API. P·vodní plán pouºít funkci fork() jsem musel zm¥nit a nahradit ji funkcí popen(). Z d·vod·, které uvedu dále v sekci "Uºivatelské rozhraní", nakonec ale nebyla pouºita ani jedna z nich. [4] Mimo metody fork() se vyskytl problém s konverzí datového typu integeer na °et¥zec znak· pomocí itoa((int), pocetZnaku, (char*)). Mnou pouºité GNU (integrované v Ubuntu 10.04) tuto funkci nepodporuje, a tak byla nutná zám¥na za multiplatformní sprintf((char*), "%d", (int)). B¥hem implementace se objevily i dal²í podobné problémy, které se mi nakonec poda°ily vy°e²it, a tak nebylo nutné pouºít podmín¥ný p°eklad z d·vodu multiplatformosti. [27] 17

18

KAPITOLA 4.

IMPLEMENTACE

4.2 Testy s podporou jednoho vlákna 4.2.1 Fibonacciho posloupnost Fibonacciho posloupnost m·ºeme implementovat standardním zp·sobem, pomocí dynamického programování £i postupným výpo£tem. Standardní zp·sob má ov²em obrovskou pam¥óvou a £asovou sloºitost (exponenciální), proto se v praxi s tímto stylem implementace Fibonacciho posloupnosti tém¥° nesetkáváme. Pro ú£ely otestování výkonu procesoru ale vysoká sloºitost není p°ekáºkou. Implementací postupným výpo£tem Fibonacciho posloupnosti získávame algoritmus se sloºitosti Ω(n). V programu jsem pouºil ob¥ tyto verze výpo£tu Fibonacciho posloupnosti. Vzhledem k velmi rozdílné sloºitosti jsem ov²em stanovil po£et prvk· °ady pro standardní rekurzivní výpo£et na hodnotu 40, zatímco pro výpo£et °ady dynamickým zp·sobem na 10 milión·. Poté trvá výpo£et °ádov¥ zhruba stejn¥ dlouhou dobu.

4.2.2 MMX instrukce Rychlost výpo£tu instrukcí z roz²í°ené sady MMX jsem otestoval pomocí operací s£ítání, od£ítání, násobení, logického posunu vpravo, logického posunu vlevo, testu ekvivalence a testu neekvivalence. [35] Pro vyuºítí t¥chto instrukcí bylo zapot°ebí 64 bitového datového typu m64 (vektor na celo£íselný datový typ) a zmín¥ných funkcí z knihovny mmintrin.h. [20]

4.2.3 adicí algoritmus Jak jiº bylo v této práci °e£eno, °adicí algoritmus QuickSort pat°í mezi nejoblíben¥j²í °adicí metody, a proto bývá implementován i ve standardních knihovnách n¥kterých jazyk·. Jazyk C/C++ není výjimkou. I p°es tento fakt rad¥ji v programu pouºívám vlastní implementaci, jelikoº kaºdá verze vývojového prost°edí m·ºe mít mírn¥ modikovanou verzi QuickSortu, coº by mohlo výrazn¥ ovlivnit výsledky test·, pokud bychom program p°ekládali r·znými verzemi p°eklada£·. Pro testování jsem zvolil standardní rekurzivní verzi tohoto °adícího algoritmu. [38]

4.2.4 Práce s pam¥tí Cílem testu rychlosti práce s pam¥tí bylo vytvo°ení algoritmu, který by zji²toval rychlost na£ítaní dat sekven£n¥ a naopak st°ídav¥ z velkého po£tu míst v pam¥ti. K tomu nám posta£í alokování prostoru daleko v¥t²ího, neº je standardní velikost pam¥ti Cache a pom¥rn¥ jednoduchý cyklus: for( i = 0; i < vyska; i ++) { for ( j = 0; j < sirka; j++) pom += pole[i][j]; } Tím simulujeme sekven£ní £tení dat. Jednoduchá zám¥na prom¥nné i za j ov²em zp·sobí na£ítání dat se st°ídou. P°i dostate£n¥ velké st°íd¥ je pot°eba data na£ítat z pam¥ti DRAM daleko £ast¥ji, a tak se její rychlost promítne do výsledku testu (mimo rychlost pam¥ti Cache).

4.3.


19

4.3 Testy s podporou více vláken 4.3.1 Výpo£ty aritmetických operací Test rychlosti výpo£tu aritmetických operací byl proveden podobným zp·sobem jako u instrukcí MMX. Procesor m¥l nap°eská£ku zpracovat velké mnoºství aritmetických výpo£t· (+, -, *, /). Oproti testu MMX je v této £ásti umoºn¥no rozd¥lení práce více jádr·m procesoru. K vícevláknovému zpracování jsem pouºil knihovnu OpenMP. Knihovna OpenMP nám umoº¬uje (mimo jiné) rozd¥lit nap°. cyklus for a jednotlivé £ásti p°edat ke zpracování nov¥ vytvo°eným vlákn·m (o samotný vznik vlákna se knihovna také postará). Po skon£ení cyklu se vlákna op¥t ukon£í a tím se defakto program op¥t za£ne zpracovávat jednovláknov¥. Vzhledem k faktu, ºe v dne²ní dob¥ je snaha pokud moºno co nejvíce £ástí programu zpracovávat paraleln¥, lze p°edpokládat, ºe tato knihovna bude p°edev²ím v budoucnosti hojn¥ vyuºívána. P°íklad pouºití:

# pragma omp parallel for private (i); for (i = 0; i < pocet; i++) vypo£ti(i); [13] Tímto p°íkazem se vytvo°í n¥kolik vláken, p°i£emº kaºdé vlákno provede metodu vypo£ti(i) s ur£itým rozp¥tím hodnot prom¥nné i. Takto postupuji ve v²ech £ástech programu, kde pot°ebuji rozd¥lit práci do n¥kolika vláken vyjma testu P°epínání vláken.

4.3.2 Vyhledávání v textu Vyhledávání slova (vzoru v textu) je pom¥rn¥ rychlý proces. Pokud je vstupní prohledávaný text v opera£ní pam¥ti, m·ºeme v jistých p°ípadech prohledávat rychlostí aº GB/s. Vzhledem k tomu, ºe pro zji²t¥ní výkonu procesoru je d·leºité, aby se data neustále nena£ítala z disku, vytvá°ím v programu pouze zhruba 180 MB dat, a tato data n¥kolikrát prohledávám. P°i vícevláknovém zpracování tedy nerozd¥luji soubor na n¥kolik £ástí, které analyzuji, ale kaºdé vlákno provádí ty samé operace (vyhledává vzor ve stejném vstupním °et¥zci). V programu je vygenerován vstupní °et¥zec náhodných znak·, v n¥mº je vyhledávána sekvence zzzzzzzzzzzzzzz, £ímº docílíme rychlý pr·b¥h algoritmu, a tak se nám do £asu pot°ebného k naleznutí patternu zohlední i rychlost Cache L2, p°ípadn¥ opera£ní pam¥ti.

4.3.3 Ztrátová komprese dat Implementace simuluje algoritmus DCT-II. Velikost vstupu se ale oproti DCT-II pro kompresi (nap°. JPEGu) li²í, je totiº upravena vzhledem k £asové sloºitosti tak, aby algoritmus trval dobu ideální pro tento test. Hodnoty vstupních dat kopírují funkci kosinus, na které jsou um¥le vyrobené odchylky pomocí random funkce. Získáme tak vstup, ve kterém lze nalézt harmonickou sloºku, na druhou stranu obsahuje i prvky, které by m¥ly být neharmonické (náhodné hodnoty). Ve vícevláknové verzi implementace p°i°adíme jednotlivým vlákn·m £ást vstupních dat, s nimiº nadále pracují. [28]

20

KAPITOLA 4.

IMPLEMENTACE

4.3.4 Bezztrátová komprese dat Human·v kód, který jsem zvolil jako zástupce algoritm· bezztrátov¥ komprimujících data, probíhá ve dvou základních fázích. Nejprve musíme vstupní data zanalyzovat a dle nich sestrojit p°íslu²ný tzv. Human·v strom, který sestavujeme na základ¥ £etnosti jednotlivých znak· ve vstupním °et¥zci. Dle tohoto stromu poté vygenerujeme kódy, kterými subtituujeme p·vodní znaky. Tyto kódy mají prom¥nnou (bitovou) velikost. Bohuºel struktura pam¥ti po£íta£e není na bitové operace p°íli² p°izp·sobena, a tak je sloºit¥j²í manipulace s nimi pom¥rn¥ obtíºná. V druhé fázi procházíme postupn¥ vstupní data a nahrazujeme p·vodní znaky p°íslu²ným vygenerovaným kódem. P·vodním zam¥rem bylo zaloºit test práv¥ na sestavování Humanova stromu. Vzhledem k upozorn¥ní na nevhodnost pouºití této £ásti kompresní metody v programu testující výkon procesoru (kv·li nízké výpo£etní náro£nosti) jsem se nakonec zam¥°il na dobu b¥hu nahrazování p·vodních dat vygenerovaným kódem. Dále jsem se rozhodoval, jakým zp·sobem nahrazovat p·vodní znaky nov¥ vygenerovaným kódem. V potaz p°ipadaly dv¥ moºnosti:

• Do£asné ukládání bit· do pole typu char - za pouºítí string bueru (pro rychlej²í ukládání) uloºit kaºdý bit jako znak do °et¥zce a po ur£ité velikosti dat (nap°. 4096 byt·) p°ekonvertovat kaºdý byte (char) na bit a uloºit ho do výstupní datové struktury. Tém¥° tím eliminujeme problémy s uloºením n-bitového kódu, pokud musí být rozd¥len do dvou datových bun¥k. • P°ímé ukládání výstupu pomocí maskování - p°i kaºdé substituci p·vodního bytu za nový kód dochází k maskování a logickému posunu dat. V p°ípad¥, ºe je kód del²í neº volný po£et bit· ve zvolené struktu°e (datovém typu), musí být kód rozd¥len do více t¥chto struktur (datového typu). Bylo tedy nutné zabývat se otázkou, zda je lep²í up°ednostnit v¥t²í mnoºství stejných, pom¥rn¥ jednoduchých operací (1. p°ípad), anebo zvolit sloºit¥j²í implementaci, která ov²em ukládá celý kód najednou a nikoliv po bitech (2. p°ípad). Po zji²tení, ºe logický posun o jakýkoliv po£et bit· trvá p°ibliºn¥ stejn¥, jsem se nakonec rozhodl pro maskování. Výstupní data tedy ukládám p°ímo, a to do pole typu integer, které je z d·vodu v¥t²í velikosti (oproti datové struktu°e typu char) vhodn¥j²í (nedochází tak £asto k nutnosti rozd¥lení kódu do dvou datových bun¥k).

4.3.5 P°epínání vláken Spou²t¥ní vláken pomocí knihovny OpenMP, kterou pouºívám v ostatních £ástech programu, kde pot°ebuji vícevláknové zpracování, by z°ejm¥ bylo nevhodné z d·vodu niº²í ú£asti programátora na vytvá°ení nových vláken. Proto jsem rad¥ji pouºil funkci pthread_create(pthread_t*, pthread_attr_t*, funkce, void*). V testu rychlosti p°epínání vláken provádím p°i£ítání konstanty k jednotlivým prvk·m matic. Jedná se o velice jednoduchý proces, který procesoru nezabere tém¥° ºádný £as. Tento proces nechávám zpracovat r·zným po£tem vláken a sleduji, jak se m¥ní doba b¥hu procesu p°i jejich vzr·stajícím po£tu. B¥hem implementace jsem narazil na problém s tvo°ením vláken. V n¥kterých p°ípadech se totiº stávalo, ºe program odmítl vytvo°it tolik vláken, kolik jsem od n¥j poºadoval (p·vodní ideální po£et vláken pro

4.3.


21

testovaní byl aº 6144), proto kontroluji, jestli se dané vlákno poda°í vytvo°it, a pokud ne, sníºím poºadovaný po£et vláken na polovinu a celý cyklus opakuji, coº by v praxi m¥lo znamenat pouze znep°esn¥ní informace o rychlosti p°epínání a vytvá°ení vláken. [13]

4.3.6 ifrování dat V testu ²ifrování dat simuluji pr·b¥h ²ifrování pomocí Rijn-Dael algoritmu ve 128 bitové verzi, pouºívám data uloºená do matic 4x4 byty. Jak jiº bylo °e£eno v analýze, ²ifrovací klí£ pro SubBytes negeneruji, pouºívám pro tyto ú£ely pouze staticky uloºenou matici. Operace SubBytes a ShiftRows probíhá pomocí dat uloºených v datových prom¥nných typu char (velikost 1 byte), pro dal²í operace (MixColumns, AddRoundKey) p°evádím hodnoty do datového typu integer (kaºdy °ádek matice je uloºen v jednom integeru). Implementace se skládá p°edev²ím z operací bitového posuvu a maskování. Jako vstupní data nepouºívám ºádný generovaný vstup, coº znamená, ºe program by nem¥l být znateln¥ zpomalován £ekáním na V/V.

4.3.7 Gracké rozhraní Vhodným prost°edkem pro zobrazení výsledk· test· je gracké rozhraní. K dispozici máme velké mnoºství moºných alternativ, které m·ºeme k tomuto ú£elu vyuºít. Po prozkoumání n¥kolika moºností jsem se rozhodl pro pouºití knihovny Qt, a to hned z n¥kolika d·vod·. Vzhledem k multiplatformosti celé aplikace bylo zapot°ebí, aby i pouºité gracké rozhraní bylo multiplatformní. To samoz°ejm¥ Qt spl¬uje. Dal²ím benetem pro m¥ byla p°ímá podpora vývojového programu NetBeans, ve kterém jsem celý projekt implementoval a odla¤oval. Jako poslední, nemén¥ d·leºitý faktor, bych ozna£il obrovské moºnosti knihovny Qt. Její rozsáhlosti bohuºel rozhodn¥ nevyuºívám, ale v budoucnu, pokud by bylo zapot°ebí n¥jakým zp·sobem gracké rozhranní roz²í°it, nem¥lo by nastat omezení ze strany knihovny Qt. [23] [5]

4.3.8 Ostatní problémy s implementací Pokud pouze simulujeme pr·b¥h algoritm·, není nutné implementovat program takovým zp·sobem, aby vytvá°el n¥jaký smysluplný výstup. V tom p°ípad¥ si ov²em musíme dávat pozor na funkce kompilátoru a optimalizátoru, p°edev²ím pokud vyuºíváme vy²²í stupe¬ optimalizace. V po£áte£ních fázích vývoje programu jsem si totiº tento fakt neuv¥domoval a díky tomu docházelo k jev·m, kdy, i p°es teoretickou zvy²ující se výpo£etní sloºitost algoritmu, se nezvy²ovala reálná doba b¥hu dané £ásti. Po p°evedení programu do assembleru jsem zjistil, ºe kompilátor na dané zm¥ny nereaguje, jelikoº vyhodnotil, ºe daná operace nevede k ºádnému vedlej²ímu efektu, tudíº je zbyte£né ji provád¥t. Tato vlastnost kompilátoru je jist¥ ºádaná v reálných aplikacích, ale pouze pro ohodnocení výkonu procesoru nikoliv. Proto se v n¥kterých £ástech programu objevují na první pohled zbyte£né podmínky, které mají pouze °e²it tuto vlastnost kompilátoru (optimalizátoru). Druhým problémem bylo generování náhodné posloupnosti. Abychom výsledky test· mohli srovnávat mezi jednotlivými po£íta£i (a zejména jejich procesory), je pot°eba, aby pr·b¥h programu nebyl odli²ný. Funkce rand(), generování náhodných prvk·, integrovaná ve

22

KAPITOLA 4.

IMPLEMENTACE

standardní knihovn¥ jazyka C/C++ sice umoº¬uje vygenerování identické pseudonáhodné posloupnosti, tento fakt platí ov²em pouze v p°ípad¥, ºe verze programu jsou zkompilovány pomocí stejného p°eklada£e (se stejnými knihovnami). Jelikoº ov²em tato funkce m·ºe být implementována r·znými zp·soby, generuji data v programu sám, a to pomocí statického vstupu (£ítajícího zhruba 12 tisíc náhodných £ísel), která dále kopíruji dle poºadavk· jednotlivých úloh. Pouze v p°ípad¥, kde mírn¥ rozdílný vstup nehraje roli, pouºívám ke generování funkci rand(). Zpo£átku jsem plánoval implementovat program jako modulovatelný. Skládat se m¥l z £ásti gracké a n¥kolika program·, konkrétních test·. Gracká £ást obstarávala GUI a zárove¬ spou²t¥la dal²í programy. Zde v²ak nastal problém. Spou²t¥ní dal²ích proces· pomocí multiplatformních funkcí popen() £i system() totiº znamenalo zárove¬ spu²t¥ní p°íkazové °ádky (ve Windows cmd.exe, v Linuxu Shell). Tím pádem byly testy ovlivn¥ny spot°ebou prost°edk· ke spou²t¥ní p°íkazové °ádky, navíc p·sobilo opakované otevírání t¥chto oken velice nep°íjemn¥. Proto jsem nakonec vytvo°il pouze jediný program v Qt, i kdyº jsou v n¥m n¥které moºnosti omezené £i h·°e p°ístupné (nap°íklad parametry kompilátoru).

Kapitola 5

Testování 5.1 Úvod Aplikaci není pot°eba testovat standardním zp·sobem (unit testy atd.), jelikoº výstupní hodnoty nejsou nikterak vázané na správný chod aplikace. P°eváºná £ást testování aplikace tedy souvisela s jejím lad¥ním a nastavováním vstupních parametr· testu tak, aby pr·b¥h testu trval p°im¥°en¥ dlouho a vykazoval výsledky co nejvíce se p°ibliºující reálné hodnot¥.

5.2 Lad¥ní 5.2.1 Inicializace prom¥nných A£koliv jsem b¥hem testování aplikace nenarazil na ºádné velké problémy, musel jsem °e²it n¥které nep°íjemné situace. První rozsáhlej²í problém nastal p°i inicializaci polí. Jazyk C totiº neumoº¬uje inicializovat libovoln¥ velké pole, p°i nadm¥rn¥ velkých polích p°estává program pracovat. Je tedy nutné nahradit klasickou inicializaci alokací pole ur£ité velikosti a p°i°adit ukazateli adresu pole. P°i této zám¥n¥ ov²em musíme dávat velký pozor na správnou dealokaci pam¥óvého prostoru, který jiº nepot°ebujeme, jinak riskujeme práci s jiº neaktuálními daty, necht¥né p°episování dat £i zahlcení pam¥ti. B¥hem lad¥ní jsem nevhodnou dealokaci v mém programu musel °e²it. Vzhledem k tomu, ºe program správn¥ pracoval na n¥kterých po£íta£ových systémech, a na jiných nikoliv, bylo hledání této chyby pom¥rn¥ obtíºné.

5.2.2 Gracké prost°edí O n¥co v¥t²í problém vzniká kv·li vlastnosti opera£ního systému Windows. Ten totiº kontroluje, jestli se gracké rozhraní programu n¥jakým zp·sobem m¥ní. Pokud tedy okno programu nereaguje del²í dobu z toho d·vodu, ºe na pozadí b¥ºí výpo£ty, ozna£í systém program jako nekomunikující (do doby neº program okno op¥t obnoví). Snaºil jsem se tento nedostatek vy°e²it pravidelným obnovováním grackého rozhraní aplikace. Bohuºel se mi nepovedlo zjistit, jakým zp·sobem by toto ²lo zajistit. Qt totiº neumoº¬uje, aby aplikaci obnovovalo (p°íkazem processEvents()) jiné vlákno neº to, které Qt p°ímo vytvo°ilo. Pokud jsem tedy vytvo°il jiné 23

24

KAPITOLA 5.

TESTOVÁNÍ

vlákno pomocí knihovny pthread a v n¥m zavolal funkci processEvents(), poºadovaný p°íkaz nem¥l ºádný efekt. Dále jsem se pokusil testovací úlohy p°esunout do zvlá²tního vlákna a vlákno vytvo°ené knihovnou Qt vyuºít k obnovování grackého rozhraní, bohuºel, pokud jsem spustil testovací úlohy, které vyuºívaly knihovnu openmp, program p°estal pracovat a systém musel aplikaci ukon£it. Vzhledem k tomu, ºe se jedná pouze o kosmetickou vadu, která by nem¥la mít na pr·b¥h test· vliv, rozhodl jsem se aplikaci nakonec neobnovovat (obnovuje se pouze po dokon£ení jednotlivých £ástí aplikace).

5.2.3 Odlad¥ní test· Pom¥rn¥ dlouhou dobu mi zabralo odlad¥ní jednotlivých test·. Bez tohoto procesu hodnoty získané z test· naprosto neodpovídaly p°edpoklad·m a velmi £asto naopak vykazovaly výsledky oproti p°edpoklad·m protich·dné. Mimo o²et°ení funkce optimalizátoru (popsané v £ásti Ostatní problémy s implementací - 4.3.8 ) jsem musel °e²it p°edev²ím správné nastavení inicializa£ních hodnot. Zvý²enou pozornost bylo pot°eba v¥novat p°edev²ím t¥mto problematikám:

• Reºie p°epínání a vytvá°ení vláken - I p°esto, ºe k p°epínání vláken pot°ebujeme daleko mén¥ £asu neº k p°epínání proces·, musíme s touto dobou v programu po£ítat. P°i nevhodném rozd¥lení práce mi u n¥kterých algoritm· vícevláknové zpracování trvalo déle, neº p°i vyuºití pouze jednoho vlákna. • Sdílení prost°edk· - Tato problematika úzce souvisí s p°edchozím bodem. Je pot°eba co nejlépe o²et°it zápis dvou £i více vláken na stejné místo v pam¥ti, jinak dochází k výraznému zpomalování algoritmu. • P°ekro£ení hranice velikosti pam¥ti - Testy jsou konstruovány tak, aby vyuºívaly bu¤ pouze Cache L1 £i i dal²í úrovn¥ Cache, p°ípadn¥ i pam¥´ DRAM. P°i vícevláknovém zpracování ov²em v n¥kterých p°ípadech pot°ebujeme více pam¥ti najednou, musíme proto ohlídat, aby nedocházelo k p°ekro£ení plánované hranice (nap°. 32 kB pro L1 Cache).

5.3 Nastavování test· 5.3.1 Základní problematika Po dokon£ení implementace bylo nutné nastavit vstupní a inicializa£ní hodnoty tak, aby výsledné testy spl¬ovaly následující kritéria:

• Reálné vypovídací hodnoty - Testy musí vykazovat takové výsledky, které se co nejvíce blíºí reálné skute£nosti a jsou ovlivn¥ny co nejvíce faktory (nezam¥°it se nap°. jen na rychlost pam¥ti Cache). • Rozumná doba pr·b¥hu testu - ím déle bude program testovat daný po£íta£ový systém, tím p°esn¥j²í výsledky m·ºe poskytnout. Od ur£ité £asové hranice se ov²em p°esnost výsledk· p°íli² nem¥ní. Cílem je najít tuto hranici.

5.3.

NASTAVOVÁNÍ TEST

25

B¥hem lad¥ní jsem se potýkal p°edev²ím s problémy, jak správn¥ nastavit testy, aby nedocházelo ke znevýhod¬ování n¥kterých typ· procesor·. Nap°íklad u testu aritmetických operací jsem dosahoval s procesory AMD aº n¥kolikanásobn¥ hor²í výsledky neº u procesoru Intel. Po detailn¥j²ím rozboru obou procesor· a po r·zných nastavováních aplikace jsem zjistil, ºe tento rozdíl vzniká p°edev²ím z d·vodu men²í Cache L2 u procesoru AMD.

5.3.2 Prvotní testování Odlad¥ním vývoj aplikace nekon£í, je t°eba n¥jakým zp·sobem ohodnotit výkon procesoru dle dosaºených výsledk· test·.

Obrázek 5.1: Výsledky test· pro procesor AMD Athlon X2 3,0 GHz

26

KAPITOLA 5.

TESTOVÁNÍ

Obrázek 5.1. ukazuje výsledky (uvedené hodnoty je doba trvání algoritmu) stolního po£íta£e s procesorem AMD Athlon X2 b¥ºícím na frekvenci 3 GHz (jádro Brisbane) s opera£ní pam¥tí DDR2 - 800 MHz (CL5) zapojenou v dual channelu (Ganged mód). Jedná se jiº o pom¥rn¥ starý typ procesoru s pomalou pam¥tí Cache (L1 s propustností 24,7 GB/s, L2 - 4,6 GB/s) o velikosti 2x64 kB L1 a 2x512 kB L2. Základní deska pouºívá £ipset AMD 790X, ten by se ov²em do výsledk· nem¥l p°íli² promítnout (vzhledem k pam¥óvému °adi£i integrovaném na desce procesoru).

Obrázek 5.2: Výsledky test· pro procesor Intel Core2Duo 2,2 GHz Obrázek 5.2. zobrazuje výsledky mobilního Intel Core2Duo T6670 2,2 GHz (jádro Penryn) s opera£ní pam¥tí DDR3, pracující na frekvenci 800 MHz v reºimu dual channel. Maximální propustnost pam¥tí ov²em není vyuºitá vzhledem k systémové sb¥rnici o frekvenci 1066 MHz. Oproti AMD má o poznání rychlej²í pam¥´ Cache (propustnost L1 - 30,9 GB/s, L2 poté 14,3 GB/s) a poskytuje Cache L2 s dvojnásobnou velikostí (2x1 MB). V následujícím srovnání budu ozna£ovat tyto procesory zkrácen¥ procesor Intel a AMD, mluvím ov²em stále o t¥chto konkrétních dvou modelech. Oba tyto procesory jsou dvoujádrové, li²í se p°edev²ím svojí frekvencí, pam¥óvým °adi£em (Intel Core2Duo má pam¥óvý °adi£ integrovaný v £ipsetu) a velikostí a rychlostí Cache pam¥ti. Intel sice v na²em p°ípad¥ pouºívá modern¥j²í opera£ní pam¥´ DDR3, vzhledem k pam¥óvému °adi£i ov²em této výhody v podstat¥ nevyuºije. Dle test· provedených programem Lavalys Everest v2.20.405 je pr·m¥rná latence pam¥ti u AMD v na²em p°ípad¥ zhruba polovi£ní oproti Intelu. P°i srovnání výsledk· by se samoz°ejm¥ tyto vlastnosti procesor· m¥ly projevit. Porovnat výsledky procesor· m·ºeme v následující tabulce.

5.3.

NASTAVOVÁNÍ TEST

27

Obrázek 5.3: Srovnání výsledk· test· AMD a Intel procesor· Z tabulky je z°ejmé, ºe u n¥kterých test· jsou rozdíly velmi zna£né. U prvního z vyjmenovaných, testu rychlosti výpo£tu aritmetických operací (Arithmetic), AMD dosahuje o 94% hor²ího výsledku (u single-core testu) neº Intel. Algoritmus provádí aritmetické výpo£ty nad polem celo£íselného datového typu (integer). Kv·li po£tu prvk· pole (100 000) a velikosti datového typu integer (4B) pot°ebuje ke svému b¥hu zhruba 400 kB pam¥ti, coº znamená, ºe by algoritmu m¥la sta£it pro data velikost Cache L2 u v¥t²iny moderních procesor·. Vzhledem k tomu, ºe rychlost pam¥ti Cache L2 je u AMD zhruba t°etinová (oproti Intelu), nelze povaºovat výsledek testu aritmetických operací za nereálný. U testu prohledávání textu metodou Boyer-Moore (Text searching) je rozdíl mezi procesory zhruba 50%, tentokrát ve prosp¥ch AMD. B¥hem testu se 24 krát na£ítá 180 MB vstup (tzn. celkem více jak 4,7 GB dat), projevuje se zde tedy niº²í rychlost vybavení dat u procesoru Intel. Dal²í algoritmus, který AMD zvládlo znateln¥ rychleji, je Rijn-Dael (Encryption). Data pot°ebná k pr·b¥hu tohoto algoritmu mají pouze n¥kolik desítek aº stovek byt·. Pracuje tedy v podstat¥ pouze s daty uloºenými v Cache pam¥ti 1. úrovn¥. Doba trvání tohoto algoritmu tedy závisí p°edev²ím na kmito£tu procesoru, který má AMD o zhruba 36% vy²²í. Test rychlosti £tení z pam¥ti (MMR) prob¥hl daleko rychleji u procesoru Intel. V testu se totiº neprojeví pouze rychlost opera£ní pam¥ti, ale i rychlost a velikost pam¥ti Cache (v²ech úrovní). Posledním algoritmem, v n¥mº nalezneme mezi ob¥ma procesory znatelný rozdíl, je rychlost p°epínání vláken (Threads). Z tabulky m·ºeme vypozorovat lep²í výsledky procesoru Intel o zhruba 49% (°ádka Threads (2N threads)). Vzhledem ke struktu°e algoritmu by výsledek nem¥l být p°íli² ovlivn¥n nap°. £ekáním na vybavení dat z pam¥ti, a proto p°edpokládám, ºe Intel opravdu dokáºe rychleji zpracovávat poºadavky na vytvo°ení a p°epínání vláken.

28

KAPITOLA 5.

TESTOVÁNÍ

5.4 P°epo£et skóre Jak jiº bylo °e£eno, v minulé £ásti (Prvotní testování ) jsem porovnával pouze dobu trvání jednotlivých test·. Uºivatelsky p°íjemn¥j²í je ov²em uvád¥ní výsledku ve form¥ dosaºených bod· (skóre). Jako referen£ní po£íta£ jsem uváºil mobilní po£íta£ s procesorem Intel Core2 Duo T6670 (taktéº z minulé £ásti dokumentu). Tém¥° u v²ech test· jsem pouºil následující p°epo£et:

Skorei = 1000/(Ref erencniDobai /DobaT estui ),

(5.1)

kde Ref erencniDobai je £as pot°ebný ke zpracování úlohy i na referen£ním po£íta£ovém systému a DobaT estui £as pot°ebný pro zpracování úlohy na konkrétním systému. Trochu jiná situace nastává u testu Memory read, kdy dostáváme hned dva výsledky, proto je skóre se£teno z t¥chto dvou hodnot:

Skorei = 500/(Ref erencniDoba1i /DobaT estu1i ) + +500/(Ref erencniDoba2i /DobaT estu2i ),

(5.2)

kde Ref erencniDoba1i je doba zpracování první £ásti testu na referen£ním po£íta£i, DobaT estu1i doba zpracování na konkrétním systému, Ref erencniDoba2i a DobaT estu2i poté platí pro 2. £ást testu. K vypo£tení skóre u testu Threads - p°epínání vláken jsem pouºil o n¥co sloºit¥j²í výpo£et. Je totiº pot°eba zjistit, jaký je nár·st pot°ebného £asu p°i zpracování stejného mnoºství aritmetických operací p°i r·zném po£tu pouºitých vláken:

Skorei = 1000 ∗ ((Ref erencniDoba2Ni − Ref erencniDobaNi )/ /(N )i )/((Doba2Ni − DobaNi )/(N )i ),

(5.3)

kde DobaNi je doba pot°ebná ke zpracování úlohy N vlákny (N = po£et pouºitých vláken), Doba2Ni doba pot°ebná ke zpracování úlohy 2N vlákny, Ref erencniDobaNi a Ref erencniDoba2Ni jsou poté hodnoty referen£ního po£íta£e. Po vypo£tení skóre jednotlivých test· se provede pr·m¥r t¥chto hodnot, samostatn¥ pro single-core i multi-core testy. Pokud se výsledné skóre blíºí hodnot¥ 1000, znamená to tedy, ºe má p°ibliºn¥ stejný výkon jako mnou zvolený referen£ní procesor.

5.5 Výsledky testu procesoru Program jsem otestoval na n¥kolika po£íta£ových systémech. Pro ukázku jsem zvolil 4 r·zné systémy.

5.6.

PENOSITELNOST MEZI OPERANÍMI SYSTÉMY

29

Obrázek 5.4: Tabulka srovnání 4 po£íta£ových systém· Výsledné skóre referen£ního po£íta£e se samoz°ejm¥ velice blíºí hodnot¥ 1000. Pokud srovnáváme po£íta£ové systémy vyuºívající procesory od spole£nosti AMD, výsledky zhruba odpovídají jejich frekvenci a po£tu jader. Výrazný rozdíl poté nalezneme u testu aritmetických výpo£t· mezi Athlonem a Phenomem, kde (jak jiº bylo °e£eno) rychlej²í Cache a zvý²ení po£tu úrovní (AMD Phenom má i Cache L3) urychlily znateln¥ tyto výpo£ty, coº znamená zvý²ení skóre o zhruba 46%.

5.6 P°enositelnost mezi opera£ními systémy Po dokon£ení nastavování skóre jsem projekt uzp·sobil systému Linux (Ubuntu verze 10.04, 64bit) a program zkompiloval. Po spu²t¥ní testu jsem ov²em zjistil, ºe získané hodnoty neodpovídají hodnotám získaným testováním pod systémem MS Windows. Op¥t nastává stejný problém, jaký jsem m¥l p°ed odlad¥ním aplikace pod MS Windows (nap°. zpomalení algoritm· p°i vyuºití vícevláknového zpracování). Pro kaºdý opera£ní systém musíme tedy jednotlivé testy odladit a nastavit správný p°epo£et skóre. Pokud bereme v úvahu MS Windows a Linux, musíme po£ítat nap°. s t¥mito rozdíly:

• Aplika£ní programové rozhraní (API) - MS Windows pouºívá jiné API neº linuxové systémy. Kv·li tomu musíme po£ítat s rozdílným chováním program· nap°. v rychlosti p°epínání vláken. [26]

30

KAPITOLA 5.

TESTOVÁNÍ

• Prost°edí (kompilátor) - Z°ejm¥ nejv¥t²í zm¥nou je pouºití jiného prost°edí (kompilátoru), který samoz°ejm¥ jednotlivé funkce m·ºe implementovat r·znými zp·soby. S tím souvisí i optimalizátor, který °e²í nedostatky v programu jinými metodami. • Správa opera£ní pam¥ti - OS Linux pouºívá pro správu a p°id¥lování pam¥ti odli²né prost°edky. Oproti vý²e uvedeným bod·m by ov²em nem¥la správa pam¥ti mít tak velký vliv na dobu b¥hu algoritm·. Vzhledem k náro£nosti procesu lad¥ní jsem tento proces provedl pouze u opera£ního systému MS Windows (testováno na verzích XP, Vista a 7).

5.7 Doporu£ená hardwarová kongurace Program lze samoz°ejm¥ spustit na v¥t²in¥ po£íta£·, jejichº procesor podporuje alespo¬ instrukce MMX, vzhledem k tomu, ºe program k testování vyºaduje zhruba 250 MB opera£ní pam¥ti, je pro správný chod aplikace d·leºité, aby disponoval alespo¬ 768 MB DRAM (£ást systémových prost°edk· spot°ebuje opera£ní systém a ostatní spu²t¥né procesy). N¥které algoritmy jsou navíc konstruovány tak, aby algoritmus nemusel data neustále na£ítat z hlavní pam¥ti, ale pouze z pam¥ti Cache. P°edpoklad velikosti pam¥ti Cache L2 je alespo¬ 512 kB. Pokud ov²em bereme v úvahu moderní po£íta£ové systémy, tyto podmínky spl¬uje naprostá v¥t²ina z nich.

Obrázek 5.5: Finální verze programu

Kapitola 6

Záv¥r Cílem této práce bylo naimplementovat program, který je schopný otestovat výkon procesoru takovým zp·sobem, aby bylo moºné pomocí výsledku tohoto testu porovnávat výkon procesoru v r·zných po£íta£ových systémech. V první fázi bylo pot°eba vybrat soubor typ· algoritm·, který dokáºe co moºná nejlépe simulovat reálný chod dnes b¥ºn¥ pouºívaných aplikací. Mezi takové algoritmy bezesporu pat°í °azení dat, vyhledávání vzoru v textovém °et¥zci, komprese £i ²ifrování dat. Mimo n¥ jsem do programu integroval i testy zam¥°ující se na ur£itý problém procesoru (na£ítání dat z pam¥ti, rychlost p°epínání vláken). Ve fázi druhé jsem prostudoval jednotlivé typy a na²el vhodný algoritmus reprezentující daný typ. V n¥kterých p°ípadech jsem pouºil modikovanou verzi kompletního algoritmu (p°. QuickSort), v ostatních sloºit¥j²ích jsem vybral pouze ur£itou £ást (nap°. diskrétní kosinovou transformaci u ztrátové kompresní metody). Poslední £ástí poté bylo záv¥re£né lad¥ní a úprava algoritm· takovým zp·sobem, aby výsledek aplikace byl co moºná nejp°esn¥j²í. Ani tato £ást se neobe²la bez jistých problém·. V n¥kterých p°ípadech se objevily ve zpracování algoritmu p°íli² velké £asové rozdíly kv·li velké závislosti na ur£itých £ástech procesoru (velikost pam¥ti Cache), proto bylo nutné algoritmy upravit, aby rozdíly v dob¥ jejich zpracování odpovídaly realit¥. P°edev²ím t¥mto problém·m ov²em vd¥£ím za hlub²í pochopení problematiky implementace algoritm·, které co nejlépe dokáºí vyuºít výkon procesoru. Výsledná aplikace je uzp·sobena moderním po£íta£·m. Bylo samoz°ejm¥ moºné ji naprogramovat takovým zp·sobem, aby byla pouºitelná jak pro moderní, tak i pro zastaralé po£íta£ové systémy, znamenalo by to ov²em silné zkreslení výsledk· test·. Nejv¥t²ím problémem pro vytvo°ení test· univerzálních pro nové i star²í systémy je neustále se zvy²ující velikost opera£ní a Cache pam¥ti. B¥hem implementace jsem narazil na velké mnoºství problém· týkajících se p°edev²ím grackého uºivatelského prost°edí, které mi neumoº¬ovalo implementovat n¥které metody poºadovaným zp·sobem, p°edev²ím v p°ípadech, kdy jsem pot°eboval vyuºít vícevláknového zpracování, a tak jsem byl n¥kolikrát nucen pozm¥¬ovat strukturu aplikace. Kone£ný zdrojový kód programu pouºívá pouze multiplatformní funkce, a je tedy moºné ho vyuºít v n¥kolika r·zných opera£ních systémech. Program nelze rozumn¥ pouºít pro srovnávání výkonu procesoru mezi po£íta£i s rozdílnými typy opera£ního systému, kv·li jejich 31

32

KAPITOLA 6.

ZÁVR

odli²ným vlastnostem. Pro kaºdý opera£ní systém je t°eba aplikaci zvlá²´ odladit, jinak získáme zkreslené výsledky test·. Ve své práci jsem se zam¥°il na opera£ní systém MS Windows, pro n¥jº jsem také aplikaci odladil. Po celkovém dokon£ení aplikace a následovném otestování na n¥kolika po£íta£ích s r·znými procesory jsem získal ohodnocení výkonu procesoru, která se tém¥° shodují s p°edpokládanými hodnotami, £ímº se mi poda°ilo dosáhnout spln¥ní zám¥ru této práce.

Kapitola 7

Návrh na budoucí moºné roz²í°ení aplikace M·j návrh na budoucí potenciální rozvoj aplikace bych rozd¥lil do dvou fází. V prvé °ad¥ by bylo vhodné mimo stávající fukcionality zji²tovat parametry aktuáln¥ testovaného po£íta£ového systému, p°edev²ím typ procesoru, velikost a druh opera£ní pam¥ti a informace o základní desce. Tyto informace by poté poslouºily k uloºení dosaºeného skóre systému a následovného porovnání s dal²ími otestovanými po£íta£i, nejlépe ve form¥ r·zných graf·. Získané hodnoty by bylo ideální synchronizovat s databází uloºenou na vzdáleném serveru (Internetu), £ímº by se docílilo aktuálnosti databáze. Prostor k rozvoji aplikace také vidím v implementaci dal²ích algoritm· soust°e¤ujících se nejen na výkon procesoru, ale i na dal²í hardwarové komponenty, jakými jsou nap°íklad pevný disk £i gracká karta. U metod testujících gracký výkon bych nedoporu£oval zam¥°ovat se na herní výkon gracké karty, ale p°edev²ím na výkon pot°ebný pro b¥ºné multimediální vyuºití (nap°. výpo£ty pouºívané pro p°ehrávání £i konverzi video/audio záznam·, které se p°edev²ím v poslední dob¥ vyuºívají pro uleh£ení práce procesoru), z d·vodu niº²í implementa£ní náro£nosti. Pokud bychom se rozhodovali pro ur£itý zp·sob rozvoje aplikace, musíme vzít v úvahu moºnou ztrátu multiplatformosti aplikace. Nap°. pokud bychom cht¥li zji²óvat rychlost pevného disku, je tém¥° nemoºné toto provád¥t bez instrukcí, které jsou p°ímo vázané na opera£ní systém. M·ºeme sice vyuºít technologie podmín¥ného p°ekladu aplikace a vytvo°it tak n¥kolik verzí testovacího programu (pro kaºdý systém zvlá²´), ale £ím více £ástí vázaných na pouºitý opera£ní systém bude v programu integrováno, tím sloºit¥j²í samoz°ejm¥ bude i vytvo°ení více verzí tohoto programu a následovné odla¤ování. Vzhledem k t¥mto fakt·m bych doporu£oval bu¤ zvolit si jeden druh opera£ního systému a sm¥°ovat budoucí vývoj k n¥mu, anebo rozvíjet dále program takovým zp·sobem, aby z·stávala i nadále zachována multiplatformost v co nejv¥t²í moºné mí°e. Pokud bychom cht¥li zachovat multiplatformost, týkal by se budoucí vývoj p°edev²ím test· výkonu procesoru, rychlosti pam¥ti Cache a pam¥ti DRAM a p°ípadn¥ vylep²ení grackého rozhraní aplikace. Ostatní £ásti jsou, jak jiº bylo °e£eno, z tohoto pohledu velmi problematické.

33

34

KAPITOLA 7.

NÁVRH NA BUDOUCÍ MONÉ ROZÍENÍ APLIKACE

Literatura [1] AES. [online], Naposledy £erpal: 18. 4. 2011. Dostupné z: . [2] DRAM. [online], 16. 3. 1999. Dostupné z: . [3] Fibonacciho posloupnost - implementace. [online], Naposledy £erpal: 17. 4. 2011. Dostupné z: . [4] Pthread - Win32API. [online], 5. 11. 2010. Dostupné z: . [5] Qt. [online], 2008. Dostupné z: . [6] SpeedStep. [online], 25. 1. 2011. SpeedStep>.

Dostupné z:
[7] BE£Vá°, I. M. ING. RóBERT LóRENCZ, C. DSA. [online], 2010. Dostupné z: . [8] DOC. ING. ZDEN¥K KOTáSEK, C. Pam¥ti SDRAM. [online], 2006. Dostupné z: . [9] DOLEºAL, P. AES - 2. [online], Naposledy £erpal: 18. 4. 2011. Dostupné z: . [10] DRNDARSKI, F. K10 pipeline. [online], 12. 5. 2008. Dostupné z: . [11] HEROUT, P. U£ebnice jazyka C - 1. díl. Kopp, eské Bud¥jovice, 5th edition, 2008. In Czech. [12] HEROUT, P. U£ebnice jazyka C - 2. díl. Kopp, eské Bud¥jovice, 5th edition, 2008. In Czech. [13] PHD., I. I. MI-PAP/>.

MI-PAP.

[online], 2011.

Dostupné z:
[14] JAKUB LOHNINSKý, J. K. Jak zvý²it výkon PC. Computer Press s.r.o, Brno, 1st edition, 2001. In Czech. 35

36

LITERATURA

[15] KER²LáGER, M. Hyper-threading. [online], 27. 3. 2011. Dostupné z: . [16] KOST¥NEC, M. Vyhledávání v textu. [online], Naposledy £erpal: 5. 5. 2011. Dostupné z: . [17] KOU°IL, M. Diplomová práce - Efektivní implementace genetického algoritmu s vyuºitím vícejádrových cpu. [online], 2010. Dostupné z: . [18] M. HUBI£KA, J. R. D. m. L. M. Human·v kód. [online], Naposledy £erpal: 15. 4. 2011. Dostupné z: . [19] MAUTNER. Kompresní algoritmy. [online], 1. 4. 2011. Dostupné z: . [20] MICROSOFT. MSDN MMX. [online], Naposledy £erpal: 2. 5. 2011. Dostupné z: . [21] MUSUMECI, G. P. LOUKIDES, M. System Performance Tuning. OReilly, Sebastopol, 2nd edition, 2002. In English. [22] OBERMAIER, Z. asování pam¥tí a Skew. [online], 28. 9. 2009. Dostupné z: . [23] Pí²A, P. GUI. [online], 22. 3. 2011. Dostupné z: . [24] PET°í£EK, L. Módy Dual-channelu. [online], 9. 7. 2008. Dostupné z: . [25] ING. PAVEL TVRDíK CSC. RNDR. JOSEF KOLá° CSC. DSA. [online], 2009. Dostupné z: . [26] UMBERA, I. P. P°epínání vláken v r·zných OS. [online], Naposledy £erpal: 20. 5. 2011. Dostupné z: . [27] VAMBERG, M. Tutoriál LaTeXu. [online], Naposledy £erpal: 25. 5. 2011. Dostupné z: . [28] WIKIPEDIE, P. Bezztrátová komprese dat. [online], Naposledy £erpal: 15. 4. 2011. Dostupné z: . [29] WIKIPEDIE, P. Diskrétní kosinová transformace. [online], 11. 3. 2011. Dostupné z: . [30] WIKIPEDIE, P. DDR. [online], Naposledy £erpal: 1. 3. 2011. Dostupné z: .

LITERATURA

37

[31] WIKIPEDIE, P. DDR2. [online], Naposledy £erpal: 1. 3. 2011. Dostupné z: . [32] WIKIPEDIE, P. DDR3. [online], Naposledy £erpal: 1. 3. 2011. Dostupné z: . [33] WIKIPEDIE, P. Fibonacciho posloupnost. [online], Naposledy £erpal: 17. 4. 2011. Dostupné z: . [34] WIKIPEDIE, P. GCC pro Windows. [online], 5. 11. 2010. Dostupné z: . [35] WIKIPEDIE, P. MMX. [online], 26. 3. 2011. Dostupné z: . [36] WIKIPEDIE, P. PowerNow. [online], 7. 6. 2010. Dostupné z: [37] WIKIPEDIE, P. Prefetch Buer. [online], Naposledy £erpal: 12. 4. 2011. Dostupné z: . [38] WIKIPEDIE, P. QuickSort. [online], 9. 2. 2011. Dostupné z: . [39] WIKIPEDIE, P. S-BOX. [online], Naposledy £erpal: 18. 4. 2011. Dostupné z: .

38

LITERATURA

P°íloha A

Seznam pouºitých zkratek DRAM Dynamic Random Access Memoryl SDRAM synchronous dynamic random access memory DDR SDRAM double-data-rate synchronous dynamic random access memory RDRAM Rambus DRAM CPU Central Processing Unit CISC Complex Instruction Set Computer RISC Reduced Instruction Set Computer TDP Thermal Design Power JPEG Joint Photographic Experts Group MJPEG Motion Joint Photographic Experts Group MPEG Motion Picture Experts Group DV Digital Video AAC Advanced Audio Coding RLE Run-length encoding LZMA Lempel-Ziv-Markov-Chain Algorithm GIF Graphics Interchange Format PNG Portable Network Graphics USB Universal Serial Bus AES Advanced Encryption Standard MinGW Minimalist GNU for Windows

39

40

PÍLOHA A.

API Application Programming Interface DCT discrete cosine transform SC single-core MC multi-core OS opera£ní systém AMD Advanced Micro Devices MAPI Memory Accesses Per Instruction MR Miss Rate MP Miss Penalty IC Instruction Count CPI Cycles per Instruction

SEZNAM POUITÝCH ZKRATEK

P°íloha B

Instala£ní a uºivatelská p°íru£ka Program nemá ºádný instalátor, ke spu²t¥ní sta£í rozbalit komprimovaný archiv na libovolné místo na disku a ve sloºce Test procesoru spustit soubor testProcesoru.exe.

Obrázek B.1: Po£áte£ní okno aplikace Tím se nám otev°e okno grackého rozhraní programu, na kterém nalezneme následující tla£ítka a informa£ní pole:

• Information - Tla£ítko slouºící k vypsání základních informací o programu, p°edev²ím potom o jeho testech. • Start - Tla£ítko, po jehoº stisku se spustí test výkonu procesoru. Po skon£ení testu se zobrazí informa£ní okno s výsledky testu. 41

42

PÍLOHA B.

INSTALANÍ A UIVATELSKÁ PÍRUKA

• Popisky sloupce Singlecore tests - Popisky, které pr·b¥ºn¥ zobrazují dosaºené skóre jednotlivých algoritm· testujících jedno jádro procesoru. Label Total Score poté zobrazuje pr·m¥r dosaºených skóre t¥chto test·. • Popisky sloupce Multicore tests - Stejné jako v p°edchozím bodu (Popisky sloupce Singlecore Tests), pouze uvedené hodnoty zobrazují výsledky test· s podporou více jader. • STATUS - Ukazuje aktuální stav aplikace, READY v p°ípad¥, ºe je aplikace p°ipravená ke spu²t¥ní testu (£i test jiº dob¥hl), a RUNNING, pokud test práv¥ probíhá. Vypnutí aplikace docílíme stisknutím k°íºku v pravém horní rohu okna aplikace (v p°ípad¥ pouºití MS Windows, n¥které systémy jej mají vlevo naho°e).

P°íloha C

Instala£ní manuál pro programátora Pro vývoj aplikace jsem zvolil vývojové prost°edí NetBeans (verze 7.0 £i vy²²í), které je voln¥ ke staºení na stránkách http://netbeans.org/downloads/, kde zvolíme verzi C/C++ a poºadovaný opera£ní systém. Pro NetBeans je pot°eba zárove¬ nainstalovat i Java Development Kit, instala£ní soubor nalezneme op¥t na stránkách http://netbeans.org/. NetBeans a JDK do po£íta£e nainstalujeme. Dále pot°ebujeme p°eklada£ a dal²í nástroje pot°ebné pro p°eklad programu v jazyku C:

• V opera£ních systémech na bázi Linux bývá tato kolekce nástroj· jejich sou£ástí, v takovém p°ípad¥ sta£í stáhnout a nainstalovat Qt SDK (knihovnu grackého rozhraní) poºadované verze ze stránek http://qt.nokia.com/downloads/ a nainstalovat ji do systému. • Pro OS Windows doporu£uji kolekci MinGW, pro kterou je aplikace odlad¥na. Instalátor MinGW nalezneme na stránkách http://sourceforge.net/projects/mingw/les/. Osobn¥ doporu£uji pouºít Qt SDK i s integrovaným MinGW, které je k dispozici na p°iloºeném médiu. V p°ípad¥, ºe se rozhodneme instalovat MinGW zvlá²´, zvolíme v pr·b¥hu k instalaci nejen defaultn¥ nastavený kompilátor C, ale navíc i p°eklada£e pro jazyk C++. Pokud pouºijeme MinGW, pot°ebuje dále Minimalist SYStem, který nalezneme na p°iloºeném médiu (MSYS-1.0.10.exe). Po dokon£ení instalace Minimalist SYStem se spustí konzole, v níº dle pokyn· musíme nastavit cestu k MinGW (nap°íklad: G:/Qt/2010.05/mingw). Poslední £ástí pot°ebnou pro zkompilování aplikace je knihovna pthread. V Linuxu bývá op¥t integrována standardn¥, pro Windows je nutné stáhnout verzi upravenou pro Win32API (pthreadGC2) ze stránek http://sources.redhat.com/pthreads-win32/ £i jej nalezneme na p°iloºeném DVD. Po instalaci v²ech £ástí spustíme program NetBeans. Nainstalovanou kolekci nástroj· je nutné nastavit p°ímo v NetBeans. Do nabídky kolekce nástroj· se dostaneme pomocí hlavní nabídky Tools/Option, kde zvolíme záloºku C/C++. V levém dolním rohu stiskneme tla£ítko Add a zadáme cestu k nástroj·m nainstalovaného prost°edí (nap°. G:/Qt/2010.05/mingw/bin). Pokud zvolíme sloºku s poºadovanými nástroji, m¥ly by se vyplnit kolonky v pravé £ásti aplikace (Base Directory, C Compiler atd.).

43

44

PÍLOHA C.

INSTALANÍ MANUÁL PRO PROGRAMÁTORA

Obrázek C.1: Nastavení kolekce nástroj· V p°ípad¥, ºe se nám automaticky nevyplní Make Command, zadáme manuáln¥ cestu k souboru make.exe vyskytující se v cílové sloºce nainstalovaného Mimimalist System, p°ípadn¥ vyplníme cestu i pro qmake (nap°: Q:/Qt/2010.05/qt/bin/qmake.exe). Dále otev°eme poºadovaný projekt volbou File/Open Project.

45

Obrázek C.2: Nastavení cesty knihovny pthreadGC2 Ve²keré parametry p°eklada£· a linker· jsou nastaveny p°ímo v projektu. Pouze parametr pro knihovnu pthread musíme modikovat dle konkrétního rozhraní:

• P°i vyuºití POSIX knihovny pthread je parametrem pro linker i kompilátor -lpthread a nem¥lo by být pot°eba odkazovat na tuto knihovnu (sta£í pouze parametry), • p°i vyuºítí Win32API s knihovnou pthreadGC2 musíme nastavit parametry na -lpthreadGC2 a soubor (knihovnu) libpthreadGC2.a, který nalezneme mezi soubory v balí£ku pthread Win32API (získaný instalací souboru p°iloºeném na dvd: pthreads-w32-2-8-0-release.exe), zkopírujeme k ostatním knihovnám MinGW (v mém p°ípad¥ do sloºky Q:/Qt/2010.05/ mingw/lib/gcc/mingw32/4.4.0) a v NetBeans nastavíme cestu k této knihovn¥ (viz obr. 9.2.). Pro nastavení cesty ke knihovn¥ pthreadGC2 klikneme na poºadovaný projekt (testProcesoru), rozev°eme nabídku projektu (pravým tla£ítkem my²í) a zvolíme Properties. Otev°e se nám okno Project Properties s moºnostmi projektu. V levé £ásti Categories zvolíme Linker a poté v právé £ásti Libraries kliknutím na poloºku Libraries otev°eme okno Debug Libraries. V £ásti Item odstraníme stávající poloºku pthreadGC2 (£i pthread) a nahradíme ji poºadovanou, stiskem tla£ítka Add Library, kde zadáne cestu ke knihovn¥ lpthreadGC2. V této £ásti také p°ípadn¥ nastavujeme parametr pro linker (nap°. -lpthread) volbou Add Option/Other Option.

46

PÍLOHA C.

INSTALANÍ MANUÁL PRO PROGRAMÁTORA

Obrázek C.3: Nastavení parametru kompilátoru GCC a G++ V p°ípad¥, ºe pot°ebujeme zm¥nit parametry u kompilátor· (nap°. -lpthread/lpthreadGC2), musíme je zm¥nit v parametrech QMAKE. Ve stejném okn¥ (Project Properties ) vybereme v lévé £ásti Build/Qt. V pravé £ásti (dole) poté nalezneme uzel Expert, po jehoº rozkliknutí se nám objeví °ádek Custom Denition. Kliknutím na n¥j se nám zobrazí aktuáln¥ pouºívané parametry (QMAKE_CXXFLAGS pro G++, QMAKE_CFLAGS pro GCC), které m·ºeme libovoln¥ m¥nit. Samoz°ejm¥ musíme také projektu p°i°adit p°íslu²nou kolekci nástroj·. To nastavíme op¥t ve stejném okn¥ Project Properties, pokud v levé £ásti zvolíme moºnost Build. V pravé £ásti poté vybereme poºadovanou kolekci nástroj· kliknutím na °ádek Tool Collection. Vyskytnou-li se problémy s nainstalováním vývojového prost°edí NetBeans s Qt, doporu£uji nav²tívit stránky http://netbeans.org/kb/docs/cnd/qt-applications.html.

P°íloha D

Obsah p°iloºeného DVD

Obrázek D.1: Seznam p°iloºeného DVD

47

Program testující výkon procesoru. Jakub Levý. ƒeské vysoké u ení technické v Praze Fakulta elektrotechnická Katedra po íta

Recommend Documents