Hlavní navigace

Low-end SMP (2) - jak rychle to běží

Miroslav Petříček 11. 2. 2000

Platí u víceprocesorového počítače, že 2 x 400 MHz = 800 MHz? Na tuto a další otázky odpovídá pokračování miniseriálu o SMP počítačích.

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.

Kompilace kernelu 2.3.34

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.

MP3 Komprimace

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.

Našli jste v článku chybu?

2. 3. 2000 10:38

Karel Panek (neregistrovaný)

Skutecne dva (ci vice) procesoru vyresi problem s
odezvou vnejsich zarizeni (zadne blokovani behem
operaci s CD, apod.). SMP je idealni
technologie pro provoz systemu, ktere musi
konzistentne reagovat v kteremkoliv case.
U kvalitnejsich SMP desek navic existuje specialni
podpora neprilis dokumentovane casti procesoru
Pentium PRO, ktera brani ryze hardwarovym
'blokovanim'.
Vyhoda SMP se samozrejme vztahuje i na vypalovani
CD-R. V linuxu neni zadny duvod proc 'nepracovat'
behem vypalovani media (a…










16. 2. 2000 11:00

Eva (neregistrovaný)

Problem moze byt aj v napalovanych CD. Niektore nekvalitnejsie media sa skutocne citaju dlhsie. Odporucam napalovat na Verbatimy.

Lupa.cz: Google měl výpadek, nejel Gmail ani YouTube

Google měl výpadek, nejel Gmail ani YouTube

Vitalia.cz: „Připluly“ z Německa a možná obsahují jed

„Připluly“ z Německa a možná obsahují jed

DigiZone.cz: Česká televize mění schéma ČT :D

Česká televize mění schéma ČT :D

Podnikatel.cz: Přehledná titulka, průvodci, responzivita

Přehledná titulka, průvodci, responzivita

Podnikatel.cz: Vládu obejde, kvůli EET rovnou do sněmovny

Vládu obejde, kvůli EET rovnou do sněmovny

Měšec.cz: Zdravotní a sociální pojištění 2017: Připlatíte

Zdravotní a sociální pojištění 2017: Připlatíte

Podnikatel.cz: Víme první výsledky doby odezvy #EET

Víme první výsledky doby odezvy #EET

Vitalia.cz: To není kašel! Správná diagnóza zachrání život

To není kašel! Správná diagnóza zachrání život

Lupa.cz: Babiš: E-shopů se EET možná nebude týkat

Babiš: E-shopů se EET možná nebude týkat

Měšec.cz: U levneELEKTRO.cz už reklamaci nevyřídíte

U levneELEKTRO.cz už reklamaci nevyřídíte

Měšec.cz: Finančním poradcům hrozí vracení provizí

Finančním poradcům hrozí vracení provizí

DigiZone.cz: NG natáčí v Praze seriál o Einsteinovi

NG natáčí v Praze seriál o Einsteinovi

Měšec.cz: Kdy vám stát dá na stěhování 50 000 Kč?

Kdy vám stát dá na stěhování 50 000 Kč?

Podnikatel.cz: EET zvládneme, budou horší zákony

EET zvládneme, budou horší zákony

Lupa.cz: Proč firmy málo chrání data? Chovají se logicky

Proč firmy málo chrání data? Chovají se logicky

Podnikatel.cz: EET: Totálně nezvládli metodologii projektu

EET: Totálně nezvládli metodologii projektu

120na80.cz: Pánové, pečujte o svoje přirození a prostatu

Pánové, pečujte o svoje přirození a prostatu

DigiZone.cz: ČT má dalšího zástupce v EBU

ČT má dalšího zástupce v EBU

Vitalia.cz: Paštiky plné masa ho zatím neuživí

Paštiky plné masa ho zatím neuživí

Lupa.cz: Avast po spojení s AVG propustí 700 lidí

Avast po spojení s AVG propustí 700 lidí