Dvoujádrový procesor: mýtus silnější než realita

Když jsem před rokem a půl napsal článek s příhodným názvem „Dual-core: proč nemůže uspět“, byl jsem mnohými označen za skeptika. Nevěřil jsem tomu, že se dvoujádrové procesory dokážou v blízké budoucnosti významně prosadit. Od té doby už nějaký ten čas uplynul, změnilo se ale za tu dobu něco? Má už v dnešní době nákup dvoujádrového procesoru význam?
Kapitoly článku

Rambus, SSE – jak tlačili a nedotlačili

Myslíte si, že programátoři budou s příchodem vícejádrových procesorů nuceni začít programovat? To, že nucení není dobrý způsob, ukázala historie již několikrát. Stejně jako se ve 20. století mnohé státy vymanily z okupace světových mocností, i IT průmysl dokázal, že nebude akceptovat nic, co pro něj nebude výhodné. Kupříkladu Intel se v roce 1999 snažil prosadit paměti RDRAM od společnosti Rambus, což mu údajně mělo přinést nějaké ty provize. Trh ale na RDRAM nereagoval, snaha i tak velké společnosti byla úplně zbytečná, a tak aby vůbec zachoval prodeje svých procesorů, musel se chtě nechtě vrátit k SDRAM.

Podobný scénář se stal s instrukcemi MMX a SSE. První jmenované byly uvedeny v roce 1997, druhé pak v roce 1999. Kolik procent programů je dnes používá? Přiznejme si, příliš to není. Programátoři ani v tomto nechtěli ztrácet čas, mnohem jednodušší bylo vzkázat zákazníkům, že si mají koupit procesor s vyšší frekvencí. A co teprve HyperThreading! Uvedený už v roce 2002 jako snaha zvýšit výkon Pentia 4. Výsledek? Vždyť se podívejte, kolik dnešních aplikací je optimalizováno na vícejádrové procesory (a HyperThreading je v podstatě jakousi emulací dual-core, takže i on potřebuje multithreaded programy). Počet prodaných Pentií 4 s HTT pak svědčí o tom, že ani velké procentuální zastoupení na trhu nemusí být pro programátory dostatečným motivem.

Abychom jim nekřivdili...

Bylo by bláhové se domnívat, že za všechno jsou zodpovědní programátoři. Ani omylem. Pomiňme nyní to, že programátor se nechce zabývat problémem (nebo chcete-li neschopností) Intelu a AMD ve zvyšování výkonu jednovláknových aplikací a prozraďme, že jsou prostě situace, kdy nelze výpočty provádět paralelně. Kupříkladu u takové počítačové hry. Tu je obecně vzato možné rozdělit na výpočet fyziky, zpracování zvuku a zpracování scény. Až sem tedy multithreading provést lze. Je ale možné zpracovávat zvuk paralelně? Co když budu mít čtyři zvuky a budu z nich potřebovat jeden, který nakonec zvuková karta přehraje? Toto zjevně nemohou dělat dva procesory, neboť výsledek je jen jeden (onen cílový zvuk). Ve všech situacích, kdy existuje jen jeden vstupní údaj nebo jeden výstupní údaj, nelze paralelismus provést. U počítačové hry proto sotva kdy můžeme očekávat nárůst výkonu o potenciální maximum 100 %.

Dalším důvodem, proč dual-core sotva kdy přinese 100 %, je sdílení prostředků. Pro dvoujádrový procesor máte stále jednu paměť, jeden čipset, jeden pevný disk. Také se tyto dva procesory musí postarat o to, aby jeden druhému nezměnily data – používání cache a dalších urychlovacích algoritmů je u více než jednoho moderního out-of-order procesoru složitá záležitost, která ve výsledku stojí nějaký ten výkon.

Jsou ale i aplikace, které na vícevláknové převést nelze nebo je to neefektivní. Spuštění dalšího vlákna se provádí za chodu přímo v aplikaci prostřednictvím služeb operačního systému. Inicializace vlákna ale stojí nějaký výpočetní výkon, zabírá další místo v paměti, zvětšuje množství strojového kódu (následkem jsou větší spustitelné soubory EXE a DLL knihovny). Pokud by další vlákno provádělo jen krátkou sekvenci instrukcí (řádově pouze pár set), pak budou „náklady“ větší než přínosy.

Vícevláknová aplikace také potenciálně obsahuje více chyb, které se hůř odstraňují. Některé vícevláknové programy, které takto byly naprogramovány jen proto, že to bylo pro programátora jednodušší (tj. ne za účelem zvýšení výkonu), dokonce na dual-core nemusí fungovat korektně.

Dvoujádrový pomalejší než jednojádrový

Nic není ideální, a tak se může snadno stát, že dvoujádrový procesor bude pomalejší, než procesor jednojádrový. Jak je to možné? Důvody jsou hned dva.

Tím prvním je samotný operační systém a jeho plánovač úloh přidělující výpočetní výkon procesoru právě spuštěným aplikacím. U jednojádrového procesoru je tento plánovač poměrně jednoduchý, neboť obsluhuje pouze jedno jádro. V operačním systému Windows se tento jednoduchý plánovač projeví jako ACPI Uniprocessor PC (Jednoprocesorový osobní počítač s rozhraním ACPI).

Pokud ale máte procesory dva (což je i u dual-core), je plánovač složitější. Nyní totiž zařizuje, že aplikace mohou přistupovat k druhému jádru – samotné programy totiž přistupují k dalšímu výpočetnímu výkonu pomocí operačního systému a jím zprostředkovaných služeb. O co se dřív starat nemusel, to teď plánovač řešit musí. Protože i plánovač je pouhý software, odebírá tímto nějaký čas procesoru. Dalším faktorem působícím v jeho zesložitění je požadavek na monitorování výkonu. U jednoduchého plánovače tento nemusí sledovat, v jakém stavu jsou aktuálně obě jádra, neboť ví, že toto sledování (tj. zda jádro právě něco počítá či nikoli) je mu úplně k ničemu. U dvoujádrového modelu je tomu jinak. Tam je nutné vytížení sledovat, neboť základním úkolem je přidělovat programům to jádro, které je aktuálně nevytížené – bylo by k ničemu, kdyby všechny úlohy směřovaly na první jádro, přičemž druhé by zahálelo.

Toto zesložitění plánovače úloh vede k větším požadavkům na výkon. Na výkon obětovaný distribuci úloh mezi dvěma jádry, tedy takový, který uživateli nepřináší žádný užitek.

 

Přesuňme se nyní k problému číslo 2, mnohem závažnějšímu. Operační systém Windows, přesněji jeho plánovač úloh, má jednu takovou zvláštnost – přesouvá jednovláknové procesy z jednoho jádra na druhé. Proč? On totiž sleduje snahu dosáhnout maximálního možného výkonu. Pokud jednovláknová aplikace zcela okupuje jedno z jader a náhodou se na toto jádro nastaví i některá z dalších aplikací (např. nějaká systémová úloha s využitím procesorového času limitně se blížícím nule), plánovač zjistí, že oné jednovláknové aplikaci by se lépe dařilo na druhém jádře. A tak ho tam prostě přepne.


Teplota jader měřená pomocí přesného digitálního senzoru s časem 500 ms. Všimněte si, jak kolísá a že když u jednoho jádra roste, u druhého klesá. To je důsledek přepínání.

Problémem je, že přepnutí na druhé jádro stojí hodně výkonu. Aplikace totiž ke svému chodu obvykle vyžaduje poměrně velké objemy dat. Ty procesor uskladňuje v paměti cache, aby je nemusel neustále číst z paměti RAM (kdyby je musel pokaždé číst, výkon klesne odhadem na jednu setinu). Jenže v okamžiku, kdy plánovač proces přehodí na druhé jádro, toto nemá příslušná data v cache. Musí je tedy načíst z paměti RAM, přičemž ještě musí počkat, dokud se do RAM nezapíšou data nedávno změněná prvním jádrem. To trvá.

V testu na Core 2 Duo E6300 je vidět, že kvůli těmto dvěma faktorům probíhá kompilace projektu na dvoujádru o čtyři vteřiny déle (tj. výkon je nižší o necelá čtyři procenta). Core 2 Duo přitom obsahuje sdílenou L2 cache, tj. dopad na výkon u něj při přepnutí na druhé jádro není tak drastický. U procesorů s rozdělenou cache (Athlon 64 X2 a Pentium D) dochází k ještě většímu poklesu – rozdíl mezi jinak identickými jednojádrovým Athlonem 64 3200+ a dvoujádrovým Athlonem 64 X2 3800+ byl 121 vs. 127 vteřin ve prospěch prvního jmenovaného (tj. pokles výkonu o necelých 5 %). U Pentia D a u nadcházejícího čtyřjádrového „slepeného“ procesoru od Intelu, u nichž jsou jádra s nezávislou cache propojena pomocí pomalé sběrnice FSB, to bude s největší pravděpodobností ještě horší.

Přepínání jednovláknového procesu mezi dvěma jádry provádí plánovač úloh poměrně často. Ostatně můžete se přesvědčit na videu a na následujícím obrázku ze Správce úloh:



V této situaci je tedy nutné si uvědomit, že dvoujádrový procesor může podstatným způsobem zvýšit výkon, ale dojde k tomu jen za určitých podmínek. V některých případech ale může výkon mírně snížit a také mohou vzniknout problémy při spouštění některých programů. Naopak vyšší frekvence zvýší výkon vždy, byť v některých případech ne tak výrazně.

Témata článku: , , , , , , , , , , , , , , , , , , , , , , , , ,