Nejčastějším důvodem proč si lidé dávají do svých domácích strojů více procesorů je touha po výkonu. Mnoho z nich si myslí, že „kupecké“ počty platí, a že například 2×400 MHz = 800 MHz. Přeneseno do reálných podmínek by to znamenalo, že např. úloha, která trvá 10 minut by na dvou procesorech trvala 5 minut. Bylo by to skvělé, ale jak je to doopravdy?
Měřit výkon na SMP počítači je složitější, než se zdá. Pokud například zkompilujete standardní Dhrystone test a spustíte jej na dvou či víceprocesorovém (SMP) počítači, získáte téměř stejný výsledek, jako když tak učiníte na stroji s jednou CPU (UP). Důvod je jednoduchý. Dva procesory se totiž ani nesnaží vykonávat tentýž programový kód. Logika programových instrukcí je dána jejich pořadím v programu. Kdyby tedy jeden procesor vykonával instrukce správně a druhý jakoby „napřed“, tak jeden nebo druhý by se dříve nebo později dostal do situace, kdy by nemohl pokračovat, neboť by neznal výsledek nějaké operace, která probíhá na druhém procesoru. Takový přístup by byl ovšem velmi neefektivní.
SMP počítače proto fungují na jiném principu. Víceúlohové operační systémy, jako je například Linux, umožňují, aby v daném okamžiku bylo aktivních více procesů. Základní úlohou jádra takového OS je přidělovat těmto procesům procesorový čas. Pokud má toto jádro k dispozici více procesorů, na které může úlohy rovnoměrně rozdělit, tak v souhrnu běží všechny rychleji. Podstatné je, že žádná s těchto dílčích úloh sama o sobě není na SMP počítači provedena rychleji, než na UP počítači.
Z toho plyne základní podmínka platná pro SMP systémy: Aby víceprocesorový počítač pracoval rychleji, musí na něm běžet více než jen jedna náročná úloha. Mnoho nezkušených uživatelů si myslí, že když je například Quake II hra náročná na výkon procesoru, tak že ji dramaticky urychlí přidání druhé CPU. Není tomu tak. Ačkoliv se běh hry možná o něco zrychlí (druhá CPU sejme z první zátěž v podobě ostatních běžících procesů), tak výsledek bude o mnoho méně výrazný, než třeba výměna procesoru za rychlejší. Naproti tomu značné zrychlení zaznamenáme, když spustíme dvě instance Quake II naráz :-0 (Všichni máme 256M paměti, že?).
Aby SMP nebylo příliš samoúčelné, tak samozřejmě existují metody, jak rozdělit i jednu úlohu na více procesorů. První metoda předpokládá, že daná aplikace je sama napsaná tak, že její jednotlivé funkce reprezentují dva nebo více nezávislých procesů. Tyto procesy pak vykonávají tytéž operace na různých částech společných dat. Jednotlivým „podprocesům“ takového programu se říká thready. Program sám se nazývá multithreadový a jako takový musí být napsán už v okamžiku překladu.
Druhá metoda má tu výhodu, že je jí možné použít i z úrovně uživatele – a na nezměněném programu. Řekněme, že máme úlohu – zkomprimovat určitý počet hudebních skladeb do formátu MP3. Komprimační program sám však multithreading nepoužívá. Pokud jej tedy normálně na SMP počítači spustíme, bude komprimovat postupně všechny skladby stejně rychle, jako na jednoprocesorovém počítači. Lepším řešením je spustit dvě instance programu naráz a každé určit jiná zdrojová data – jiné skladby. Výsledkem bude, že oba procesory budou pracovat na jedné úloze – převedení skladeb do MP3 – byť každý bude v daný okamžik komprimovat jinou skladbu. Samozřejmě tento způsob není možné použít tehdy, když je zapotřebí dodržet nějakou kontinuitu zpracovávaných dat, nebo třeba v případě zmíněného Quake II.
Konec teorie, podívejme se, jak to vypadá v praxi:
Jako testovací počítač byl použit vlastnoručně postavený kousek s touto konfigurací:
– Zákl. deska Abit BP6 (Intel 440BX)
– 2× CPU Intel Celeron 366, možno přetaktovat až na 550/100 MHz
– 64 MB RAM (PC100)
– pevný disk WDAC14300R (UDMA/66) na řadiči HPT366
– RedHat Linux 6.0 – kernel 2.3.34 s podporou SMP
Nejvděčnějším testem, na kterém se demonstruje výkon SMP, je doba potřebná ke kompilaci kernelu. Proto jsem čerstvě stáhl zdrojový kód kernelu 2.3.34 a napsal krátký skript, který jsem použil k měření času. Při sestavení jsem použil své oblíbené kompilační volby. Počet threadů při kompilaci se nastavuje ve skriptu příkazem make -jX. Při testování bylo X nastaveno jako počet procesorů + 1.
Z uvedeného grafu, kde je jeden procesor zanesen žlutě a dvojice procesorů modře, je patrné, že druhý procesor udělá s překládacím časem zázraky. Nárůst výkonu činí 87 – 89%. Pokud bychom uvažovali lineární trend růstu rychlosti procesoru v závislosti na jeho kmitočtu, tak by se dvojici procesorů Celeron 366 vyrovnal jeden procesor s frekvencí asi 700 MHz! Uvažujeme-li přetaktování, tak Duální 506 MHz kompiluje stejně rychle jako jeden 957 MHz. Tak rychlý procesor však v současné době není k dispozici.
V druhém testu bylo komprimováno celkem 22:14 minut audio dat, získaných z CD skupiny R.E.M.. Tato data byla postupně zkompilována na jednom a dvou procesorech, a s využitím paralelního spuštění enkodéru Bladeenc 0.91 v jedné, dvou, třech a šesti instancích.
Výsledky testu ukazují, že jeden procesor Celeron 506 MHz dokáže komprimovat audio do MP3 lépe než v reálném čase (22:14 za 21:59). Je dobré si všimnout, že pokud spustíme pouze jeden komprimační proces, ovlivní druhý procesor jeho výkon pouze zanedbatelně (asi 0,7%). Jiná situace je již u dvou instancí enkodéru. Pokud je spustíme současně, tak na dvou procesorech získáme výkon, umožňující komprimovat dvě skladby MP3 v reálném čase ! V tomto případě tedy dochází k faktickému zdvojnásobení výkonu. Nárůst výkonu při větším počtu instancí enkodéru než 2, již můžeme považovat za marginální, byť patrný. Zde by se vyšší mírou uplatnilo až přidání dalších procesorů.
Příště uvedu další benchmarkové testy a zároveň se zmíním detailněji o různých hardwarových alternativách pro SMP na Linuxu.
