K8
O architektuře K8 bylo napsáno mnoho, zdůrazním tedy jen ty nejdůležitější věci. K8 disponuje devíti výpočetními jednotkami (tři celočíselné (ALU), tři pro výpočet adres (AGU), tři pro výpočty s plovoucí desetinou čárkou (FADD, FMUL, FMISC)), třemi dekodéry instrukcí, 64+64KiB L1 cache (data+kód) a 1024KiB L2 cache (512KiB ve variantě NewCastle).
K8 se může pracovat ve dvou základních režimech:
a) 32bit – v tomto režimu se chová jako běžný x86 kompatibilní procesor velmi podobný K7 (Duron, Athlon XP).
b) 64bit – režim s bohatší instrukční sadou, větším množstvím registrů a přepracovanou adresací. Dále se v článku budeme zabývat pouze tímto režimem.
Pokud programujete v assembleru x86, jistě víte, že tato architektura disponuje osmi 32bit „general purpose“ registry (EAX, EBX…, EDI). Můžeme rovněž pracovat pouze s dolní polovinou registru, pokud odtrhneme předponu E. Architektura K8 rozšiřuje registry na 64 bity. Pokud chceme pracovat s 64bit registrem jako s celkem, připojíme před název registru R. Je důležité si zapamatovat, že se implicitně pracujeme pouze se spodní 32bit polovinou registrů. Pokud chceme použít registr celý, musíme si to vynutit tzv. prefixem. Binární podoba takové instrukce je pak o jeden bajt delší. 32bit operand je tedy na AMD64 platformě implicitní. Od toho se volně odvíjí i to, že int zůstává 32bitový a 64bitový je long. Často v různých diskusích vídávám názor, že 64bit programy musí zabírat mnohem více paměti. Praxe ukazuje, že samotný kód je v průměru o 20 % větší a velikost dat se liší jen nepatrně (vlivem rozšíření ukazatelů do 64bit podoby). To ovšem není vše. K dispozici máme dalších 8 „general purpose“ registrů a 8 dodatečných 128bitových registrů pro SSE (SIMD instrukční sada). To je velmi důležité, protože se tím eliminuje nutnost prohazování dat mezi pamětí/zásobníkem a registry, ale také to umožňuje kompilátoru lépe rozptýlit v kódu použití stejného registru, a snížit tak množství závislostí instrukcí na výsledku předchozích instrukcí. Současné procesory mají více výpočetních jednotek, a můžou tedy provádět několik mikroinstrukcí současně. Pokud se ovšem vyskytne shluk několika instrukcí pracujících se stejným registrem, není možné další výpočetní jednotky využít, protože výsledek závisí na výsledcích všech předchozích instrukcí. V této situaci ostatní výpočetní jednotky zahálejí. Procesory disponují schopnostmi takové situace řešit (např. přejmenovávaní registrů). Pokud jim ovšem překladač pomůže vhodným uspořádáním instrukcí strojového kódu, efektivita využití výpočetních jednotek značně stoupne.
Fyzický adresní prostor je rozšířen na 40bitů (1TiB) a virtuální na 48bitů (256TiB). Pro použití paměti větší než 4GiB už tedy není potřeba použít zpomalovačů jako PAE. Padá rovněž limit paměti přidělené jednomu procesu. Management paměti se tím (z hlediska jádra) podstatně zjednodušuje.
Návrháři protected režimu i386 se rozhodli, že stránka určená pro čtení (read) a provádění (execute) bude v popisovači stránky označená stejným příznakem. Jinými slovy – nedá se rozlišit, zda byla stránka určená pro data, či pro kód. Z toho těžily exploity typu buffer overflow. K8 má v popisovači stránek dodatečný bit NX (no-execute), díky němuž je možné označit stránku, ze které se nesmí provádět kód. Jelikož některé programy využívají toho, že vykonávají kód i v datovém segmentu (např. kodeky – místo, aby se pořád program větvil podle toho, zda má aktuální procesor k dispozici SSE2, či ne, zda je vstupní formát barev v YUV, či jiném atd., učiní všechna tato rozhodnutí na začátku a poskládají optimalizovaný program v datovém segmentu a spouštějí ho tam), je implicitně podpora NX bitu vypnutá. Zapnout se dá předáním parametru noexec=on případně noexec32=on jádru.
Tímto jsme si shrnuli hlavní výhody, které nám K8 přináší – zvýšení výkonu, zvětšení adresovatelného prostoru a zvýšení bezpečnosti. Jak je to s výkonem v praxi, se podíváme v poslední části článku.
Hardware
Opět vás odkážu na kvalitní a často aktualizovanou dokumentaci, tentokráte na Gentoo/AMD64 Project Information. Naleznete tam především, které SATA a RAID řadiče jsou podporovány. Zdá se, že s deskami s chipsetem nForce3 je v Linuxu méně potíží než s VIA K8T800. S grafickými kartami nVidie rovněž není problém (s binárními ovladači funguje 2D i 3D akcelerace). S ATI je to horší, používá se radeon driver z xorg-x11 (xfree mimochodem není na AMD64 v Gentoo už podporováno), který akceleruje 2D, ale 3D nepodporuje. Má se to ale prý v dohledné době zlepšit. Se zvukovými kartami si hlavu lámat příliš nemusíte. Pokud vám pracovala ALSA na x86, máte téměř jistotu, že poběží i na AMD64. Podobné je to i s ostatními drivery obsaženými v jádru. Osobní zkušenost mám s IDE řadičem s chipem CMD649, síťovou kartou s chipem RTL8139 a zvukovou kartou Audigy.
BIOS
Před instalaci aktualizujte BIOS. Vývoj je v tomto směru pořád poměrně bouřlivý a nové verze většinou řeší řadu problémů s inicializací hardware a stabilitou. Doporučuji povypínat všechny integrované součásti, které nehodláte používat. Pokud patříte do skupiny šťastlivců, kterým funguje Cool'n'Quiet (umožňuje měnit frekvenci a napětí procesoru v závislosti na vytížení procesoru), můžete tuto volbu v BIOSu aktivovat a později při konfiguraci kernelu zapnout následující volby:
Power management options [*] Power Management support CPU Frequency scaling [*] CPU Frequency scaling <*> CPU frequency table helpers <*> AMD Opteron/Athlon64 PowerNow!
Mně bohužel C'n'Q nepracuje dobře, takže čerpám pouze z dokumentace.
Instalace
Zde budu předpokládat, že máte zkušenosti s instalací Gentoo na x86 nebo že máte nastudován Gentoo Handbook, případně český překlad.
Předně je třeba si uvědomit, že stage soubory pro AMD64 obsahují 64bit aplikace. Nemůžeme tedy provádět instalaci z prostředí 32bit Linuxu, protože se nám nezdaří chroot. Musíme tedy provádět instalaci z prostředí 64bit Linuxu. Nejvhodnějším kandidátem je Gentoo live CD (aktuálně ve verzi 2004.2). Poslední verze Live CD má bohužel několik chyb. Předně často nedetekuje IDE disky a je třeba provést příkaz
modprobe ide-disk
Podobně není detekována většina síťových karet. Zavedeme opět příkazem modprobe s názvem příslušného modulu, např.
modprobe 8139too
Doporučuji co nejdříve nainstalovat gcc 3.4.x a pomocí gcc-config přepnout, aby se začal používat (to není automatické). Po tomto kroku nezapomeňte na obligátní
env-update source /etc/profile
Podívejme se na chvíli na konfiguraci make.conf. Osvědčené CFLAGS jsou -march=k8 -pipe -O2 -fweb -frename-registers. Na jiných architekturách přínosný přepínač -ftracer zde přinesl spíše zpomalení. Do USE vložte multilib, budete-li chtít překládat aplikace do 32bit podoby.
Při konfiguraci kernelu nezapomeňte zahrnout volbu umožňující spouštět 32bit binárky – Executable File Formats/IA32 Emulation.
Jako zavaděč je nyní podporován pouze staticky linkovaný grub.
Kompatibilita
Většina běžně používaných programů pracuje v 64bit režimu bez zaváhání a v příslušných ebuildech figuruje architektura AMD64, případně ~AMD64. Můžete se sami přesvědčit nahlédnutím do online databáze balíčků. Pokud používáte nějaký exotický software, který nemá ebuild pro AMD64, nezoufejte – stále je poměrně velká šance, že půjde přeložit a bez problémů používat, akorát to prostě ještě nikdo nezkusil a nenahlásil funkčnost v Gentoo Bugzille. Pokud na takový program narazíte, nenechte si to pro sebe a dle návodu funkčnost nahlaste.
Další možností je spouštět aplikace v 32bitové podobě. Pokud nejsou k dispozici zdrojové kódy, často ani jinou možnost nebudete mít. Platí to především o komerčních programech jako Acrobat Reader, Oracle, a … Quake3 ;-) Často se takto podaří zprovoznit aplikace z RPM balíčků překládaných pro 32bitové distribuce a podobně. Velmi vhodné je i použít binární 32bit verzi OpenOffice.org. Kompilace tohoto balíku je velmi náročná. Abychom mohli spouštět 32bitové aplikace, musíme mít zapnutou podporu v jádře (výše zmiňovaná volba IA32 Emulation). Často je potřeba mít i 32bitové verze knihoven. Ty nainstalujeme příkazem
emerge emul-linux-x86-compat emul-linux-x86-glibc emul-linux-x86-sdl emul-linux-x86-baselibs emul-linux-x86-gtklibs emul-linux-x86-soundlibs
Jste-li majiteli grafické karty nVidia, oplatí se přiinstalovat navíc emul-linux-x86-nvidia.
Běh 32bit aplikací není emulován, jedná se o plně nativní režim procesoru. Zpomalení běhu 32bitových aplikací oproti 32bitovému systému způsobené přepínáním režimu z 32bit na 64bit a zpět během přepínání kontextu je malé. V některých případech je plně kompenzováno zvýšeným výkonem jádra, takže není nemožné, že 32bit aplikace poběží v 64bit Linuxu dokonce rychleji.
Samostatnou kapitolou si zaslouží Java. V současné době je podporována pouze 64bit verze VM Blackdown. SUN má podporu AMD64 teprve od verze 5, a ta je teprve ve fázi Release Candidate (a dle ohlasů je finální verze ještě poměrně daleko). Blackdown i SUN navíc obsahují pouze server verze virtuálního stroje (od klientské verze se liší zejména vyladěním JIT kompilátoru a garbage collectoru) což pro klientské aplikace není příliš dobré. Třeba vývojové prostředí Eclipse s těmito verzemi (eufemicky řečeno) nepracuje optimálně.
Zajímavou možností, jak si vytvořit prostředí pro kompilaci a spouštění 32bit aplikací, je vytvoření „chrootovaného x86 prostředí“. V podstatě provedeme kompletní instalaci (až na instalaci zavaděče, služeb a kompilaci jádra) do samostatného adresáře. Během instalace provedeme místo
chroot /mnt/gentoo /bin/bash
příkaz
linux32 chroot _adresář_s_rozbaleným_x86_stage_souborem_ /bin/bash
Příkaz linux32 přesvědčí všechny své potomky, že běží na platformě x86 (uname vrací i386). Díky tomu získáme kompletní 32bitové prostředí s 32bitovými knihovnami a programy. Zde je možno zkompilovat wine nebo třeba mplayer, který může spolupracovat s 32bitovými kodeky z Windows. Iluze x86 platformy je takřka dokonalá. Nevýhodou je velikost zabíraného místa na disku.
Jelikož platforma AMD64 není tak dokonale otestována jako x86, pravděpodobně narazíte i na problémy. Třeba můj oblíbený komunikační program sim odmítal v 64bitovém prostředí spolupráci. K3b se chová velmi nestabilně. 64bit plugin pro přehrávání flashe zatím neexistuje atd. To jsou ale všechno potíže, které se v dají v nejhorším případě vyřešit přes výše zmíněné chrootované prostředí.
Benchmarky
Zde si opět vypomůžu odkazem, tentokráte na testy Anandtechu. Dovolil bych si to pouze shrnout do jedné věty – zázraky nečekejte. Většinou je výkon mezi 64bit a 32bit verzemi srovnatelný. Citelného navýšení výkonu se dočkáte pouze při renderingu (POVRay) a u databázových aplikací (MySQL).
Jelikož mě zajímalo, jaké navýšení výkonu můžeme čekat u aplikací, které intenzivně pracují s 64bitovými čísly, a nemohl jsem najít výsledky testů ani žádný vhodný benchmark (není divu, 64bit čísla téměř žádný běžný program nevyužije), napsal jsem si svůj jednoduchý benchmark sestávající ze tří částí – třídění polí, násobení a sčítání matic. Velikosti dat jsem nastavil tak, aby se celý working set vešel do L2 cache, a výsledek tedy byl co nejméně ovlivněn tím, že při práci s 64bit integery zabírala data dvakrát tolik paměti. Překlad probíhal pomocí gcc 3.4.1 s použitím experimentálně zjištěných nejlepších flagů -march=k8 -O2 -funroll-all-loops.
Benchmark | verze | Velikost operandu | Tisíců operací za vteřinu |
---|---|---|---|
Třídění | Linux 64bit | 32 | 872 |
Třídění | Linux 64bit | 64 | 853 |
Třídění | Linux 32bit | 32 | 911 |
Třídění | Linux 32bit | 64 | 646 |
Třídění | Win 32bit | 32 | 522 |
Třídění | Win 32bit | 64 | 499 |
Sčítání | Linux 64bit | 32 | 2160 |
Sčítání | Linux 64bit | 64 | 2107 |
Sčítání | Linux 32bit | 32 | 2197 |
Sčítání | Linux 32bit | 64 | 1406 |
Sčítání | Win 32bit | 32 | 2952 |
Sčítání | Win 32bit | 64 | 1743 |
Násobení | Linux 64bit | 32 | 1976 |
Násobení | Linux 64bit | 64 | 1771 |
Násobení | Linux 32bit | 32 | 1924 |
Násobení | Linux 32bit | 64 | 245 |
Násobení | Win 32bit | 32 | 2663 |
Násobení | Win 32bit | 64 | 421 |
Bohužel nemám k dispozici 64bit překladač pro Windows (betaverze samotných 64bit je zdarma ke stažení ze stránek Microsoftu, pokud člověk souhlasí s poměrně volnými podmínkami). Pokles výkonu při provádění 64bit operací na 32bit platformě je citelný zejména při provádění násobení (emulace násobení pomocí 32bit instrukcí je poměrně náročná). Na 64bit platformě je pokles pochopitelně mnohem menší (nulový být nemůže – velká část operací nad 64bit registry je pomalejší než nad 32bit registry, nehledě na to, že pracujeme s daty dvojnásobné velikosti). Vidíme taktéž, že 32bit verze pracuje s 32bit operandy rychleji než 64bit verze (přestože ta má k dispozici více registrů), což je poměrně překvapivé. Dokážu si to vysvětlit jedině tím, že gcc neprodukuje prozatím pro AMD64 stejně kvalitní strojový kód jako pro x86. Překladač jazyka C z MS Visual Studia .NET 2003 generuje naopak velmi kvalitní výstup. Výsledek testu „Třídění“ je ovlivněn (pro běžné programy téměř nepoužitelným) parametrem -funroll-all-loops. Bez něho vede nad 32bit gcc na celé čáře. Jedná se samozřejmě o primitivní syntetický test a vyvozovat z těchto výsledků nějaké dalekosáhlé důsledky by bylo chybou.
Závěr
Vzhledem ke klesající ceně 64bitových Athlonů se z nich stává atraktivní volba i pro běžné uživatele. Nebudu vám nic nalhávat – je to oblast doposud ne zcela probádaná a bezproblémová. Vždy ale můžete zůstat v klidných vodách x86 a na 64 bitů s klidným svědomím zapomenout. Pokud ale rádi experimentujete, tak si s AMD64 užijete do sytosti.