Dual-core: proč nemůže uspět

HyperThreading - polovičatý dual-core

Technologie HyperThreading (HTT) byla Intelem uvedena na počátku roku 2002 v procesoru Xeon. O několik měsíců později - přesněji na podzim 2002 - Intel ohlásil i Pentium 4 3.06 GHz s její podporou. O co v HTT jde? Každý současný procesor má ve výpočetní části několik jednotek pro práci s celými čísly (integer výpočty v ALU jednotkách) a pro práci s čísly s desetinou čárkou (floating point výpočty v FPU jednotkách). Kdysi dávno, v dobách 486ky, měl každý procesor jen jednu ALU jednotku a FPU měl buďto jednu nebo jí neměl vůbec. Protože dnes už není tak drahé vyrábět procesory, jednotek ALU i FPU je v čipech podstatně víc - Pentium 4 má 3 ALU a 2 FPU, procesor Athlon 64 pak 3 ALU a 3 FPU.

Poznámka: Přesnější by bylo říkat "částečné ALU" a "částečné FPU", protože dost často bývají jednotky specializované jen na určitý typ instrukcí a neumí všechny operace.

Více jednotek umožňuje provádět některé výpočty zároveň. Pokud to charakter instrukcí umožňuje, je v jednom hodinovém cyklu zaměstnáno například více ALU jednotek naráz paralelním zpracováváním instrukcí, které jinak jdou v kódu po sobě. Tím je v rámci jednoho threadu. dosaženo vyššího výkonu (mimochodem, proto by Pentium 4 na stejné frekvenci bylo podstatně výkonnější než 486ka).

Bohužel ne všechny typy výpočtů lze provádět paralelně - jestliže jeden výpočet vyžaduje výsledek předchozího výpočtu, není zpracování současně možné a využití jednotek je mizivé. Jisté odhady hovoří o tom, že průměrné využití ALU a FPU je v dnešních procesorech na úrovni 30% potenciálu. To je opravdu slabé. Idea HyperThreadingu spočívá v tom, že procesor se bude navenek tvářit jako procesory dva, přijme na vstupu dva thready (z dvou různých programů či jednoho multithreaded programu) a oba bude zpracovávat současně. Pokud budou výpočty v jednotlivých threadech vyžadovat různé jednotky (např. jeden thread ALU a druhý FPU nebo každý z threadů jen jednu z dostupných ALU) a vytížení podpůrných jednotek před ALU / FPU nebude vysoké, pak dojde k výraznému zrychlení.

Idea HyperThreadingu ale naráží v okamžiku, kdy oba thready požadují stejné jednotky.
Protože procesor nemá dvojnásobný počet ALU a FPU jednotek, při stejných požadavcích obou threadů dochází k souboji o jednotky. Oba thready se uvnitř procesoru musí střídat. Výsledkem souboje je, že výkon nevzroste. Naopak, protože při zapnutí HyperThreadingu je řada z podpůrných částí procesoru nacházejících se ve výpočetní části před ALU a FPU jednotkami sdílena (např. L1 cache může být pro každý z threadů rozpůlena na dvě části), výkon dokonce poklesne. A co víc - plánovač úloh v operačním systému při zapnutém HyperThreadingu obsluhuje dva procesory, což je pro něj náročnější úloha než pouze jeden procesor - nezapomeňme, že i plánovač sám o sobě je thread, takže čím složitější bude, tím více výkonu je obětováno čistě jen tomu, aby přiděloval výkon ostatním aplikacím. V praxi tak může výkon se zapnutým HyperThreadingem vzrůst o desítky procent, o stejnou hodnotu může ale i poklesnout.

Ten největší problém HyperThreadingu ale není možný pokles výkonu v řádu pár procent, ale především jeho nepoužitelnost při multitaskingu. Myšlenka to byla velmi zajímavá, ale v laboratořích jí vůbec nedotáhli do zdárného konce. Problém leží v tom, jak plánovač operačního systému přiděluje čas procesoru jednotlivým úlohám.

Jak už bylo zmíněno, plánovač preferuje úlohy, které mají vysokou prioritu procesu. Naopak úlohám s nízkou prioritou přiděluje takový výkon, který "zbude". Když si na procesoru bez HyperThreadingu spustím SETI@home, tedy úlohu, která běží na pozadí a využívá pouze zbytkového strojového času, bude jí výkon přidělen jen tehdy, kdy ho ostatní programy nebudou potřebovat - tedy například v situaci, kdy píšu dokument ve Wordu. Když si ale pustím nějakou hru (... která vždy chce 100% výkonu procesoru), výpočet SETI se prakticky zastaví. To je žádoucí výsledek, protože hře chci přidělit maximum, aby chodila plynule.
Na procesoru s HyperThreadingem tomu bude jinak. Protože v takové situaci si plánovač myslí, že má k dispozici procesory dva, při spuštění hry tato poběží na procesoru č. 1. Co se stane se SETI@home ? Plánovač ho přesune na procesor č. 2, na kterém neběží žádný program, tj. jeho vytížení je nula. Výsledek? Hra poběží výrazně pomaleji a SETI@home si bude dál vesele počítat z výkonu ALU a FPU jednotek, které měly být dostupné hře. Proč? HyperThreading nejsou dva procesory, ale pouze jeden. Jednotky ALU a FPU jsou sdíleny. To ale plánovač neví, netuší, že zadáním SETI@home procesoru č. 2 si výpočet řekne o jednotky sdílené s procesorem č. 1. V podstatě tak HyperThreading obchází prioritu procesů - i když SETI@home má prioritu procesu minimální a hra vysokou, každý běží na vlastním procesoru, kde jsou sami. Každá úloha tudíž dostane 100% výkonu svého procesoru - v reálu jsou ale oba procesory jeden procesor, "sežerou" si jednotky... priority procesů - nízká a vysoká - se tak vyrovnají, plánovač selhává.

Zde je vidět, že HyperThreading postrádá jednu dost zásadní věc - prioritizování threadů. Problém by se dal snadno řešit tak, že by plánovač s každým threadem procesoru sdělil, jakou prioritu thread má, a procesor už by pak čas přiděloval sám. Jenže to HyperThreading neumí ! Jiná cesta, jak zabránit souboji o jednotky, neexistuje, žádná úprava v plánovači toto nedokáže ošetřit, protože plánovač netuší, jaké jednotky bude ta která aplikace vyžadovat (a ani to nemůže zjistit) a také netuší, jaké jednotky v procesoru jsou vytíženy a jaké ne. Celkově vzato je HyperThreading vhodný pro některé typy multithreadových aplikací (kde pokles výkonu jednoho threadu je kompenzován výkonem druhého threadu stejné aplikace), ale rozhodně ne pro multitasking. Někteří uživatelé přesto nabývají dojmu, že HyperThreading dělá práci plynulejší - ano, dělá, ale na úkor výkonu na pozadí běžících programů. Správným řešením zátěže v multitaskingovém operačním systému je pouze dual-core.

V souvislosti s dual-core se však také s HyperThreadingem setkáme - u Pentia eXtreme Edition. To je stejný dvoujádrový procesor jako Pentium D, jen má ještě pro každé jádro povolen HyperThreading. Díky tomu je schopen provádět až čtyři thready současně.

Pomiňme nyní, že v praxi se téměř nesetkáte se situací, kdy byste měli čtyři zátěžové thready (vyjma některých speciálních aplikací majících charakter plně multithreadových programů s neomezeným počtem možných threadů).

Zde se setkáváme se stejným problémem jako u Pentia 4 s HyperThreadingem. Zatímco u dual-core bez HTT vždy úloha běží na vlastním procesoru, tady může dojít k již zmíněnému souboji o jednotky. V nejhorší situaci plánovač přidělí dva thready stejnému jádru, zatímco druhé jádro zůstane nevytíženo - v takovém okamžiku bude výkon Pentia eXtreme Edition nižší než výkon mnohem levnějšího Pentia D či Athlonu 64 X2.