Intel: máme 65nm! AMD: máme dual-core!

Dvoujádrový gigant ze stáje AMD

Nemožnost zvyšovat frekvence je důvod, proč všichni přechází na procesory s dvěma jádry. AMD není výjimkou a minulý týden se jako první výrobce firma pochlubila funkčním dual-core Opteronem.

Pro viceprezidenta AMD, Dirka Mayera (přezdívaného také Dark Mayor), je to další úspěch v řadě - ty předchozí byly například první 1 GHz x86 procesor a první 64bit procesor pro stolní počítače. Na fotografii výše pózuje vedle čtyřsocketového serveru HP ProLiant DL585 vybaveného celkem osmi procesory (čtyři dual-core). Zde je důležité zmínit, že sockety jsou dnes standardní 940 pinové, pouze musí být připraveny na proudový odběr cca. 65A na jeden procesor (v současnosti je potřeba asi 55A) - takové jsou totiž požadavky na 90nm čipy Opteron.
Přesně takto vypadá dual-core Opteron. Obě jádra jsou k sobě svisle zrcadlově symetrická podle středu, pouze u jednoho z nich byly odebrány HyperTransport linky a kontakt s paměťovým řadičem ("hluché" místo uprostřed v dolní polovině). Příslušné obvody byly přepojeny na stejné jednotky prvního jádra, které již k tomu vyžadovanou logiku obsahovalo od začátku výroby procesorů architektury AMD K8.

Velikost - zásadní problém

Dual-core procesory postavené na 90nm transistorech jsou jakousi předzvěstí toho, co přijde s 65nm. Tedy alespoň u AMD. V současnosti je procesor Opteron postaven na jádře SH7 s 1MB L2 cache, které měří 17.04 mm * 11.29 mm, tedy nějakých 192 mm2.

Budoucí Opteron s 1MB L2 cache s 90nm transistory (jádro SH8-D0) má měřit zhruba 110 mm2, tedy asi jako současný Intel Pentium 4 Prescott. Na fotografii výše vidíte, že jádro je jasně menší. Nejspodnější procesor je verze dual-core (revize E). Na první pohled je jasné, že je veliký.
Vzal jsem fotografii tohoto čipu a provedl měření velikosti. Hrany jsem "prodloužil" ke kraji pouzdra a poměřil podle počtu pixelů velikost s hranou, o které je známé, že měří 40 mm. Výslednou velikost čipu jsem takto odhadl na 15.63 mm * 13.03 mm, tedy cca. 204 mm2. A to je... hodně. Je to sice stále méně než dvojnásobek jednojádrového procesoru (ono zmenšení je dáno jen jediným řadičem pamětí, který obepíná vlastní jádro, viz. fotografie výše), no nicméně je to příliš mnoho, než aby si AMD mohlo dovolit tyto čipy vyrábět ve velkém. Velký čip "spolkne" velké místo na waferu, není jich tak možné vyrobit mnoho a při očekávaném množství 190 až 200 milionů transistorů je možnost poruchy opravdu veliká.

No ale protože se Opteronů prodalo do dnešního dne v desítkách tisíc kusů (a ne v milionech jako Intel Xeonů), neměla by větší velikost představovat pro AMD nepřekonatelný výrobní problém. Jak to ale bude u stolních verzí dual-core, není zatím jasné. Osobně se domnívám, že AMD nebude schopné při současných výrobních kapacitách uspokojit poptávku po Athlonech 64 FX postavených na takto velkém čipu. Je proto poměrně pravděpodobné, že firma sáhne u desktopových procesorů po redukci velikosti cache na 512kB na jedno jádro. Takový čip by mohl mít velikost kolem 160 mm2, což už je relativně přijatelné (současný NewCastle, jádro DH7, měří 150 mm2).

Sdílená nebo separátní cache?

Jednou ze zásadních otázek spojenou s dual-core procesory je, zda použít sdílenou nebo separátní L2 cache. Pro každou z variant hovoří jisté výhody, ale také nevýhody. AMD se rozhodlo jít cestou separátních cache, IBM cestou sdílené cache, stanovisko Intelu je zatím neznámé.

V procesoru Opteron je dual-core řešen tak, že každý procesor má svojí vlastní cache. Za řadičem L2 cache jsou obě jádra napojena na přepínač - Crossbar Switch - který je spojuje s řadičem pamětí a dalšími sockety prostřednictvím tří HyperTransport linků.
Z pohledu HT linků ani paměťového řadiče se tak proti současnému stavu v podstatě nic nemění, protože ty vystupují jen v pozici datových zprostředkovatelů a se samotnými výpočetními jádry nemají nic společného.

Výhodou tohoto řešení je, že souhrnný výkon L2 cache je velmi vysoký. Přístup do této cache (prostřednictvím SRAM řadiče) je limitován počtem simultárních přístupů a rychlostí vyřizování (latencí cache - ta činí u architektury AMD K8 kolem 12 až 15 hodinových cyklů). V případě více přístupů musí tyto počkat, což snižuje výkon a následně také počet přístupů do cache - mechanismus se tak vyrovnává do určitého průměrného počtu přístupů. Pakliže jsou k dispozici dva řadiče a cache není velká (čím větší cache, tím více dat uchovává a tím má nutně vyšší latence, je tedy pomalejší), je možné prohlásit, že celkový počet přístupů pro obě jádra je dvojnásobek počtu přístupů jednoho jádra, takže fakticky rychlost obou L2 cache dohromady je dvojnásobná oproti jedné cache.

Pokud bychom cache sloučili pro oba procesory, dojde jasně ke snížení jejího výkonu, protože:

1. Celou cache by obsluhoval pouze jeden SRAM řadič, který má limit v rychlosti, počet možných simultárních přístupů by tak klesl.

2. Větší cache by znamenala složitější vyhledávání, což ve výsledku znamená větší latence. Alternativně by musela, při stejné latenci, klesnout frekvence. Cache ale bývá u současných procesorů jedním z klíčových míst, které brzdí frekvenční nárůst, takže taková varianta není příliš pravděpodobná. Mimo jiné proto Intel u Prescottu zvýšil latenci L2 cache ze sedmi cyklů na 18.

Jaká je pak tedy výhoda sloučení L2 cache? Představme si situaci, kdy máme nějaký multi-treadový program, kde jednotlivá vlákna jsou na sobě relativně datově závislá. Kupříkladu napřed vypočteme nějaký výsledek a poté vytvoříme dvě vlákna. Jedno z nich (první) bude pracovat na zcela odlišných datech, druhé vezme výsledek předchozího výpočtu a dále s ním bude provádět nějaké jiné výpočty. Uvažujme o situaci v systému s pro každý procesor unikátní L2 cache. První jádro vypočetlo onen výsledek a uložilo ho ve své L2 cache pro pozdější zápis do paměti RAM (samotný zápis trvá kvůli pomalosti RAM příliš dlouho, jádro nečeká a počítá dále, výsledek se zapíše sám v okamžiku, kdy je paměť relativně nevytížená). Nyní operační systém přidělil prvnímu jádru druhý thread. Co se stane? Jádro požádá o data (o výsledek), který nalezne ve své L2 cache, je mu tedy rychle dostupný a výpočet probíhá perfektně. V tomto případě bude vynikající vytížení obou jader (druhé počítá nový - první - thread). Co se ale stane v případě, kdy operační systém přidělí druhý thread druhému jádru? To požádá o data (o výsledek) a zjistí, že je ve své cache nemá (jsou v cache prvního jádra)! Nejprve tedy bude nutné, aby první jádro dokončilo zápis výsledku do RAM, pak teprve bude možné ho načíst do jádra druhého. Paměť RAM tak zaznamená velké vytížení a druhé jádro bude celou dobu dlouhotrvajícího zápisu a následného čtení z RAM čekat. S trochou nadsázky se dá říct, že než se celá akce dokončí, uplyne pro procesor tolik, co pro člověka znamená rok života.

Je zcela zřejmé, že v případě sdílení L2 cache není takový scénář možný, protože data v této cache jsou dostupná oběma procesorům a není nutné si je vyměňovat přes pomalou paměť RAM. Druhé jádro by v takovém případě jen požádalo řadič o výsledek, který tam chviličku předtím nechalo první jádro. Zpomalení by bylo naprosto minimální.

Nejelegantnější řešení, pochopitelně, je schováno pod přístupy do L2 cache jednotlivých procesorů. Jinými slovy pokud by bylo možné, aby druhé jádro pro výsledek nečetlo z RAM, ale z L2 cache prvního jádra. Bohužel něco takového v současném návrhu procesoru Opteron není možné. Ostatně je to i logické - SRAM řadič obhospodařující obsah L2 cache je přímo napojen na konkrétní jádro a není řízen zvenčí, ale zevnitř - není tak například možné, aby si pevný disk zažádal o přesun dat přímo do cache, k této operaci musí dát příkaz jádro.

... a co na to Intel ?

Jak je názorně vidět, každé uspořádání má určité výhody i nevýhody. Osobně jsem velmi zvědavý, které řešení zvolí Intel. Systém se separátními cache je návrhem jednodušší, no na druhou stranu Intel již má zkušenosti se sdílením cache poměrně bohaté - v procesorech Pentium 4 s technologií HyperThreading je L1 cache sdílena mezi jednotlivými logickými procesory, popř. je adaptivně určována velikost připadající na logické jádro 1 a logické jádro 2. Jaké řešení nakonec zvolí pro dual-core, se dozvíme snad již brzy, řeč na toto téma by měla přijít na právě probíhajícím Intel Developer Forum.