Vyvíjet nové čipy bude složitější - druhá část

Dual-core (dva čipy v jednom)

Rostoucí statická spotřeba v podobě leakage a rostoucí hustota dynamické spotřeby nutí k novým pohledům při vývoji architektury čipů. Jak úspěšně zvýšit výkon a přitom redukovat spotřebu? Umístěním dvou čipů do jednoho!

Dual-core je něco, co by v dobách DOSu bylo zcela k ničemu. Dual-core potřebuje speciální aplikace. Dual-core neznamená vyšší výkon pro současné aplikace. Dual-core na současných frekvencích znamená obrovskou spotřebu. Samé nevýhody, že? Když se zeptáte některého z majitelů dvouprocesorového systému, zda jeho sestava poskytuje ve hrách vynikající výkon, řekne vám: "Ne.". Proč tedy chtít dva procesory v jednom? Když se toho samého člověka zeptáte, zda by svůj systém vyměnil za jednoprocesorový, odpověď je: "Ani náhodou!".

Klíčem úspěchu dvouprocesorových sestav jsou aplikace využívající více threadů a multitaskingové operační systémy (např. Windows). Operační systém Windows masově rozšířil objektové programování a s ním spojenou techniku "black-box". Dříve programátor hry dělal vše - komunikoval s grafickou kartou, programoval pro zvukovou kartu atd. atd. Dnes pouze zavolá funkce integrované v operačním systému (DirectX, Win32), které úkon provedou za něj. Samotné DirectX (či Win32) přitom zavolají funkce z ovladačů grafické / zvukové karty. Dříve naprogramování aplikace trvalo několik dní, dnes je možné toho samého v lepším kabátě docílit za hodinu např. v Borland Delphi. Komplexnost aplikací se zvětšuje, množství vykonaného kódu také, přitom samotné aplikace jsou pro programátory v mnoha ohledech jednodušší. Díky sdílení visualizace v operačním systému je možné dělat dříve nepředstavitelné.

Aby bylo sdílení funkcí v rámci DLL možné, musí existovat programová vlákna - thready. Zavoláním funkce DLL knihovny je zahájen nějaký výpočet, který modifikuje proměnné. Pokud by funkce DLL knihovny nevyužívala threadů, její zavolání v okamžiku výpočtu pro jiný program by způsobilo minimálně podivné chování (ty samé proměnné by byly modifikovány dvakrát). Funkce proto vytvoří nový thread, který pracuje nezávisle na prvním. Z jiného soudku - náš program vykonává nějaký kód. Víme, že určitá oblast je požadovanými daty zcela nezávislá na jiné oblasti - např. ve hře počítáme fyzikální model postav a jejich inteligenci, což jsou velmi nezávislé výpočty. V případě superskalárních procesorů je to ideální stav. Teoreticky bychom mohli počítat oboje najednou, vytížit jednotky a dosáhnout skvělého výkonu. Jenže v našem kódu jsou, kvůli přehlednosti, tyto výpočty velmi vzdáleny, nejdříve počítáme fyzikální model, pak inteligenci.

Problém je na světě. Procesor dokáže dopředu obhospodařovat, a využívat tak instrukčního paralelismu superskalárních procesorů, jen omezené množství OPs. V případě Pentia 4 je to jen 126 OPs, přičemž Pentium 4 má z dnešních procesorů najednou pod kontrolou asi nejvíce OPs (kvůli nejdelší pipeline). Protože výpočty pro hru jsou od sebe vzdáleny v řádu deseti tisíců OPs (stovek až tisíců řádek programu), je instrukční paralelismus vyloučen. Zde se dostává ke slovu více vláken - thread parallelism (vláknový paralelismus). Tím, že z fyzikálního modelu uděláme jedno vlákno, z inteligence druhé a každé svěříme jinému procesoru, získáme značné zrychlení.

Pokud se zrovna ptáte, proč se to tak dnes nedělá, mohu nabídnout dva důvody:

1. počítač s dvěma procesory má málokdo, je totiž podstatně dražší než jednoprocesorový.
2. tvorba threadů vyžaduje náročnou synchronizaci.

První problém je zřejmý, u druhého se zastavím. Co je synchronizace? Pokud vytvoříme další vlákno, které si počítá bez ohledu na původní kód, můžeme se dostat do situace, kdy vlákno dokončí svojí úlohu moc brzo nebo moc pozdě. Synchronizace spočívá v tom, že výsledek dostaneme ve správný okamžik tím, že vlákno nebo hlavní výpočet občas pozastavíme a následně opět spustíme. Toto je velmi náročné naprogramovat, protože jsou zde často neočekávatelné události typu "Něco spustilo další výpočet." nebo "Kam se mi ztratil výsledek?". Programovat s thready není tak jednoduché jako bez nich. Možnost chyb v programech proto roste.

Multithreading - výhody a nevýhody pro uživatele

Zásadní "vtip" threadů je tedy v tom, že musíme najít takové výpočty, které jsou na sobě nezávislé. Je již vcelku jedno, zda v rámci jednoho programu nebo více. Vzhledem k tomu, že většinou spouštíme jen jednu náročnou aplikaci, je důležitější klást důraz právě na jeden program. Jinými slovy můžeme mít perfektní výkon při spuštěném antiviru a současné kompresi videa, kolik z nás si kvůli tomu ale dnes kupuje dvouprocesorovou sestavu? Nikdo.

Dual-core zlepší rychlost odezvy systému a v některých případech značně zlepší výkon aplikace (místy klidně o 60 - 80 procent). Také výrazně zlepší použitelnost počítače v případě, kdy na jednom procesoru poběží výpočetně náročná operace (enkódování videa / audia). Budeme moct hrát hry, aniž by výkon druhé aplikace jakkoliv trpěl. Nezvýší se však výkon v aplikacích, které využívají jen jednoho vlákna - takových aplikací je dnes přitom odhadem 95 procent. Důležité je ale podotknout, že náročné výpočty jako již zmíněná komprese videa se často dají na thready upravit. Naopak třeba hry jsou dnes závislé především na grafické kartě, procesor nehraje až tak velikou roli. Výhody více procesorů se proto dočkáme především v případech, kde to je skutečně potřeba.

Ještě poznámka na závěr k tomuto tématu - tím, že aplikace využívá threadů, se automaticky stává pomalejší. Je to z toho důvodu, že threadů je využito i u jednoprocesorového systému, takže se synchronizaci nevyhneme. Synchronizace znamená další výpočty, tj. pokles celkového výkonu. A dále - tím, že operační systém obhospodařuje více procesorů, se stává pomalejším. Důvodem v tomto případě je to, že jádro musí být přizpůsobeno na více procesorů, mezi které musí distribuovat úlohy pokud možno rovnoměrně tak, aby každý procesor byl využit. To opět přináší další režii a snižuje celkový výkon.

Technická realizace

Technicky vzato není vytvoření dual-core čipu příliš složité. Stačí vzít jedno jádro a jednoduše ho okopírovat k druhému.

Horší je to se spotřebou. Přidáním dalšího jádra se maximální spotřeba rovná dvojnásobku spotřeby jednoho jádra (samozřejmě za předpokladu zdvojení všeho, tedy i cache). Pokud by se vzaly klasické čipy dneška, máme hned věc se spotřebou 200 - 300W. To už by byl problém uchladit i pro vodní chlazení (... do jehož vývoje Intel v poslední době údajně investoval). Typická spotřeba je samozřejmě menší než 2x typická spotřeba jednoho čipu, protože vytíženost jednoho procesoru bude ve většině případů nižší než u jednoprocesorové sestavy. Jenže typická není při konstrukci chlazení zajímavá, důležité je maximum. A to je v tomto případě problém.

Řešením je snížit frekvenci a napětí. Ano, slyšíte správně, snížit frekvenci oproti jednoprocesorovému řešení. AMD dnes prodává 35W a 55W Opterony... za vyšší ceny a s nižší frekvencí. Dual-core nebude nic jiného než dva tyto nízkospotřebové Opterony v jednom. Celková spotřeba bude na úrovni klasického čipu (tj. 95W), avšak s podstatně nižší frekvencí (údajně první dual-core od AMD poběží na 1.6 a 2.0 GHz). Důsledky jsou zřejmé - u aplikací nevyužívajících threadů bude výkon rapidně nižší než při jednoprocesorovém systému a u aplikací využívajících threadů lze čekat nárůst kolem 40 - 60 procent (dual-core bude mít zhruba o třetinu nižší frekvenci). Z hlediska techniky není dual-core pro AMD příliš problematický, protože návrh jádra K8 s touto variantou počítal. S rozcestníkem Crossbar tak budou komunikovat dvě jádra namísto jednoho, Crossbar samotný je bude spojovat s dalšími částmi - počet tří HyperTransport linků zůstane zachován a jeden řadič DDR400 pamětí také, jen nyní budou sdíleny.

Pokud jde o Intel a jeho čipy, je zde výhoda za předpokladu použití jádra Dothan z Pentia M. To je energeticky nenáročné, mohlo by si zachovat svojí frekvenci i při osazení dvou jader na jeden čip. Bohužel ale toto jádro nepodporuje instrukce AMD64 (a ani lehce redukovanou sadu EM64T), takže buďto bude muset projít radikálním redesignem nebo si jeho majitelé 64bit výpočtů neužijí. A co je pro výkon možná ještě horší, je absence integrovaného řadiče pamětí. Dual-core omezený pomalým paměťovým subsystémem s vysokými latencemi nebude podávat odpovídající výkon. Také je otázkou, nakolik se podaří Dothanu zvýšit frekvenci. V současnosti není jádro tak rychlé, aby mohlo porazit nejvýkonnější čipy. Intel je tak v situaci, kdy může vytvořit dual-core z jádra, které je sice velice dobré, ale ne nejrychlejší, a které nemá podporu pro v budoucnosti klíčovou instrukční sadu. Alternativně může vytvořit jádro na bázi architektury NetBurst s cílenou teplotou asi jako v centru výbuchu vodíkové bomby.

Budoucí směry v optimalizacích kódu

Hardwaroví giganti se uvedením dual-core procesorů aspoň prozatím zbaví problémů a přenesou je na vývojáře software. Jenže budou muset nějak vysvětlit, jak je možné, že současné aplikace běží na drahých dual-core podstatně pomaleji než na levných jednoprocesorových systémech. A i kdyby toto přežili, další problémy je čekají s dalšími generacemi transistorů, čili problém se jen odsune. Přitom efektivita přidávání dalších procesorů je v případě běžných aplikací od cca. třech čipů výše zhruba rovnoměrná - nulová.

Výrobci procesorů se budou snažit zákazníky přesvědčit, že chyba je na straně softwarových firem. A samotné softwarové firmy se budou snažit přesvědčit, že mají používat nové strategie při tvorbě aplikací.

Jednou z nich je asymetrický threading. Namísto současného způsobu (symetrického threadingu), kdy vytvoříme více vláken a operační systém pak tyto přiděluje jednotlivým procesorům, je myšlenka taková, že bude jedno hlavní vlákno doplněné dalšímu, podpůrnými vlákny. Ty budou provádět minoritní výpočty, které je rychlé spočítat takto paralelně. Hlavní vlákno, klíčové pro výkon, poběží na samostatném procesoru, zatímco podpůrné thready na jiném. Teoreticky se tak může zvýšit vytížení víceprocesorových systémů, tj. celkově zvýšit výkon i v minoritních úlohách. V současnosti například Intel C++ Compiler verze 8 může při zvoleném nastavení auto-paralelizace vytvářet separátní thready pro výpočty prováděné v cyklech. Kompilátor nejdříve analyzuje, zda se vyplatí vytvořit další thread (problém synchronizace), a pokud ano, vytvoří ho.

Druhým způsobem zvyšování výkonu je spekulativní předpočítávání.

V dnešních aplikacích výkon často vázne v situacích, kdy je nutné čekat na data z operační paměti - ta je v porovnání s rychlostí procesoru strašlivě pomalá. V případě situace, kdy procesor nenalezne data v cache (tzv. cache miss - v cca. pěti procentech případů), musí čekat. Dlouho. Idea spekulativního předpočítávání spočívá v tom, že kód obsahuje další thready, které dopředu prochází kód inicializují softwarový prefetch, který data načte do cache. Načítání probíhá v době, která není klíčová pro dosažení maximálního výkonu. Když pak hlavní thread dosáhne oblasti, kde tato data využívá, již je bude mít připravená v cache. Výpočet tak půjde plynuleji.

Závěrem

Budoucnost procesorů nevypadá nikterak růžově. Celý pokrok v minulosti spoléhal na menší, rychlejší a méně hřející transistory. S tím je teď konec. Bez inovací v designu více výkonu nebude. Nové procesory budou hřát více, nebude je možné tak dobře přetaktovat, patrně ani nebudou tak spolehlivé. Nároky na vývojáře software se dále zvýší. Menší transistory vytvořené budoucí 65nm technologií budou znamenat ještě větší problémy než transistory vyráběné v současnosti.

Uvedené problémy se samozřejmě netýkají jen procesorů, ale také čipsetů, grafických karet i jiných komplexních zařízení (včetně třeba 10Gbit síťovek). Například grafické karty dnes používají stále relativně bezproblémovou technologii 0.13 mikronu, přitom některé modely už spotřebují i více než 100W. Co nás čeká v budoucnu, to si netroufám odhadovat... pomalu se ale začínám smiřovat s nutností vodního chlazení.

Zdroje: IBM, Intel, EETimes, různé další dokumenty