Porovnání výkonu mezi x86 a amd64 na Ubuntu

Phoronix porovnává rozdíl ve výkonu Ubuntu pro x86 a pro amd64. Výkon byl měřen na UT2004, LAME, gzipu, kompilaci jádra a dalších operacích.

30.12.2006 12:13 | Luboš Doležel (Doli) | Zajímavý článek

Komentáře

[David Ježek]

tak nejak asi neprekvapuje, ze 7.04 zatim dostava vicemen na zadek.

[Lukas]

Tak nějak se ani nevyplatí 64-bit instalovat... ZATÍM

[Michal Kubeček]

Jen další příklad toho, že šikovně zvoleným benchmarkem podložíte jakékoli tvrzení…

[hwsoft]

No tady asi chteli ukazat, ze na desktop, je lepsi 32bit, aspon zatim.

[Michal Kubeček]

Zjevně ano. Ale o tom, zda je skutečně vhodnější, jeden účelově vybraný benchmark vypovídá pramálo. To bych na druhou stranu mohl argumentovat tímhle:

                  sign    verify    sign/s verify/s
rsa  512 bits 0.000506s 0.000040s   1977.1  25163.1
rsa 1024 bits 0.002250s 0.000107s    444.5   9318.9
rsa 2048 bits 0.012400s 0.000343s     80.6   2915.8
rsa 4096 bits 0.079840s 0.001175s     12.5    850.8

                  sign    verify    sign/s verify/s
rsa  512 bits 0.000262s 0.000018s   3822.1  54325.7
rsa 1024 bits 0.000856s 0.000044s   1168.9  22574.3
rsa 2048 bits 0.004398s 0.000125s    227.4   7988.9
rsa 4096 bits 0.026530s 0.000392s     37.7   2550.0

jenže to by byl asi tak stejný nesmysl jako ten jejich "test"…

[Käyttäjä 11133]

Kryptografie a většinové využití desktopu? Pochybuju že většina zdejšího osazenstva má alespoň šifrovaný /home.

[Chloop]

Já jo.

[Käyttäjä 11133]

Nj, 2 (respektive 3 i se mnou) nejsou většina.

[zde]

Pánové, fakt vás to dětský porno bere?

[Käyttäjä 11133]

Nevím jestli děstké porno, ale rád ukládám do prohlížeče hesla, mám v počítači spoustu kontaktů a nějaké ty lechtivé materiály tam jsou taky. A co teprve klíče k ssh přístupu na pár serverů.

[Michal Vyskočil]

Aha, takže namísto silné passfráze pro klíč šifruješ rovnou celý disk?

[Luboš Doležel (Doli)]

Taky šifruju taky jsem na amd64.

[Käyttäjä 11133]

Nj, 2 (respektive 3 i se mnou) nejsou většina.

[Michal Kubeček]

Asi tak stejně většinové jako encoding videa nebo překlad jádra…

[Ritchie]

Přesně tak, stačí se poohlédnout po internetu a najde se test, který ukazuje pravý opak.

[Luboš Doležel (Doli)]

Nemá LAME nějaké x86 optimalizace, že je i zde rychlejší na x86?

[Michal Kubeček]

Nebo spíš nemá optimalizace pro x86_64…

[michich]

Ano, pro i386 má kusy psané v assembleru.

[David Jaša]

Ty CPU jsou zatím optimalizovány pro běh ve 32 bitech, změnit by to měla příští generace (u Intelu i AMD). Četl jsem to nejspíš na SHW, ale teď to nemůžu najít.

[Ritchie]

Ty CPU nejsou optimalizovány pro běh ve 32 bitech. Naopak v long-mode (64 bitů) má aplikace k dispozici dvojnásobný počet general purpose registrů a xmm registrů, což je nejčastější důvod, proč se běh některých aplikací zrychlí i po pouhé rekompilaci.

K vašemu tvrzení vás mohlo snad vést to, že aritmetika s 64bitovými celými čísly trvá déle než s 32bitovými. (Snad si to pamatuji správně.) Nikdo vás ale nenutí používat 64bitovou aritmetiku, pokud máte jen 32bitová čísla.

[Michal Kubeček]

K vašemu tvrzení vás mohlo snad vést to, že aritmetika s 64bitovými celými čísly trvá déle než s 32bitovými.

Určitě to platí i na 64-bitovém procesoru?

[Ritchie]

Platí a týká se to třeba operace násobení. Na architektuře K8 trvá ALU vynásobení dvou 32bitových celých čísel 3 takty, dvou 64bitových 5 taktů. Na druhou stranu operace jako sčítání, bitový posun, bitová rotace trvají jak pro 32bitová, tak pro 64bitová celá čísla shodně jeden takt.

[Luděk]

Jak je to s velikostí int pro x64? Aby se pak rychlost získaná větším počtem registrů neztratila při přenosu CPU-RAM...

[Ritchie]

1. Označovat instrukční sadu (architekturu) jako x64 je nesmyslný patvar používaný firmou Microsoft. Logické pojmenování je x86-64 či v Linuxu obvykle x86_64.

2. GCC používá i pro target x86_64 32bitový int, viz volby -m32 a -m64 v manuálové stránce.

[deda.jabko]

ja jsem si zvykl oznacovat architekturu jako amd64 analogicky k i386, podle toho, kdo s danou architekturou prisel prvni. (navic to v textu vypada lip nez x86_64)

[Luboš Doležel (Doli)]

To rozhodně nevypadá líp. Proč nepoužíváte i x32?

[deda.jabko]

prominte, ale asi jste to necetl spravne -- ja preferuji oznaceni amd64 a i386, ne x64!

btw. rozdil mezi tim co vypada lip je znacne subjektivni. kazdopadne podtrzitka uz nejsou tak trendy, jak byvaly. v beznem textu je nikdo nepouziva a i v programech se zacinaji omezovat.... ;-]

[Michal Kubeček]

To bych ani neřekl, IMHO je to spíš záležitost jazyka. U céčkařů pořád převládá tradiční_způsob, VelbloudíZápis je spíš doména C++-istů (já ovšem preferuji klasiku i v C++). Ale když pořád lepší než javoidní velbloudBezHlavy…

[Kyosuke]

Nene, to je smalltalkoidní velBloud.

[Luboš Doležel (Doli)]

Pravda, omlouvám se, nepodíval jsem se, kdo to napsal původně.

[T]

Ale houby patvar...

Wikipedia:

Similarly, Microsoft began using "x64" as a vendor-neutral way to refer to products that support both AMD64 and EM64T. Other companies, such as Sun Microsystems, have also adopted this convention.

[David Jaša]

1. na citace je tag <blockqoute>

2. x64 je skutečně patvar, když už nemůžete být bez toho x, tak použijte x86_64.

[Kyosuke]

Asi mi něco uniklo. Podle AMD Optimization Guide má IMUL reg16/32/64, mreg16/32/64 latenci 3/3/4 takty. Dále tam stojí: „The processor is capable of performing a 64-bit addition each clock cycle and a 64-bit multiplication every other clock cycle.“ Předpokládám (== hádám ), že to je kvůli paralelizaci.

[Ctirad Feřtr]

Trefa. Pánové by se měli ujistit, jestli náhodou nesrovávají dva různé programy (u kodeků bývá na x86 brutálně optimalizovaný kód využivající MMX/SSE(2/3)) nebo dokonce dva různé programy produkující dva různé výstupy (kompilace jádra).

[Ritchie]

Zrovna lame na floating point aritmetiku pomocí SSE silně spoléhá. Zkuste si lame zkompilovat poprvé s -mfpmath=387 a podruhé s -mfpmath=sse. Nárůst výkonu se počítá v desítkách procent. Na okraj podotýkám, že v gcc je pro x86 (386 a výše) výchozí volba 387 a pro x86-64 sse.

[Kyosuke]

Nedělá -mfpmath=sse jen to, že SSE jednotku používá ve skalárním režimu? Na vektory člověk pořád ještě potřebuje assembler…nebo ten nový autovektorizér, který ale musí ještě pořádně vyrůst. (Aneb vivat Cčko, které je z tohohle pohledu hnusně nízkoúrovňové a obtížně optimaliovatelné.)

[Ivanhoej]

Skor by bolo dobre porovnat poriadne distro gentoo32<->64 alebo archlinux32<->64, co to je to ubuntu???? :)

[.....]

Ubuntu? Linuxová distribuce, ovšem divím se, že zrovna velký pan archista gentooista to neví.

[Petr Ježek]

"Pan archista gentooista" chtěl asi sdělit, že na Gentoo nebo Archu by bylo jaksi lépe co srovnávat - jde už tak o rychlé a čisté distribuce (pokud gentooisté nejsou patlalisté)... Já jsem Archa64 nahradil 32bitem jen pro neexistenci MM Flashe v 64bit verzi, longchain verze se jinak jevila jako viditelně rychlejší.

[Radek Hladik]

Když už tady o tom jde řeč, nevíte někdo o:

1) nějakém článku/shrnutí/benchmarku, které popíše pro které aplikace je vhodnější 64-bitů a pro které 32-bitů? Jako například: pro kryptografii je 64-bitů rozhodně super, pro unreal tournament je o prdíček lepší 32-bitů,....

2) nějakém benchmarkovacím programu, který by uměl změřit hodně věcí, syntetických benchmarků třeba pro procesor jsem našel jak šafránu a nejlepší to srovnával s AMD K2 450MHz . Kompilaci jádra používám, ale kdyby třeba bylo něco obdobnýho na databáze, web, javu,... Prostě něco, co stáhnu, spustím, za dvě hodiny přijdu a budu mít hafo výsledků...

Radek

[Lukáš Zapletal]

Je to snadný, už jsem to tu někde psal. Na desktop 64 bitů v zásadě člověk nepotřebuje, rozhodně se to nevyplatí v tom smyslu, že by nárůst výkonu (který je vlastně téměř nulový) nahradil nestabilitu (či jen nahradil aplikace které na 64bit systému vůbec nejdou (flash..). Navíc na 64 bitech systém i aplikace žerou o něco více paměti, na druhou stranu můžete využít daleko větší paměťový prostor (to se týká spíše serverů).

Takže můj verdikt: 64 bitů se zatím hodí spíše pro servery (a to jen někdy), a nebo desktopy, kde se často dělá určitá výpočetně náročná činnost, kde je prokazatelné, že použitím 64 bitového systému se zvýší výkon (šachy, kódování, šifrování, databáze...)

[Ritchie]

S částí vašeho příspěvku, kde se zaobíráte výkonem a stabilitou 64bitového desktopu, ostře nesouhlasím. Jakou máte zkušenost s provozováním 64bitového systému na desktopu?

Nárůst výkonu rozhodně není „téměř nulový“, jak píšete, ale v řadě výpočetně náročnějších aplikacích dobře postřehnutelný (desítky procent). Namátkou mě napadá třeba oggenc. Tvrzení o nestabilitě je bohapustý FUD. Nebo jej snad můžete podložit nějakým tvrzením?

[Michal Kubeček]

O jaké nestabilitě to pořád FUDujete? Buď uveďte konkrétní příklady té nestability nebo mlčte.

[Radek Hladik]

Ok, tohle je mi tak ňák víceméně jasný. 64bitová architektura umí počítat s většími čísly v jedné instrukci, má víc registrů (takže vhodná optimalizace může "namapovat" více proměnných na registry a ušetřit tak hodně zdlouhavých přístupů do paměti) a může uadresovat více paměti. Na druhou stranu při ukládání registrů na zásobník se více nadře. Taky je možné mít víc paměti než 4GB a více bez použití PAE (když už zmiňuju PAE, víte někdo, jakej má vliv na výkon a stabilitu?).

Problém je v komplikovanějších aplikacích typu databáze, webserver, různé aplikační servery, php, kde nejsem schopen jen tak od stolu říct: tohle bude rychlejší. Například taková databáze: hodně pracuje s diskem (zrychlí to nějak 64bitový kernel?) potom provádí nějaké šílené vyhledávání, joinování, sortování, potom si uloží nějaké mezi výsledky do paměti...

Proto by mě zajímal nějaký universální hodněobjimající benchmark a zkušenosti lidí z praxe.

Radek

[Michal Vyskočil]

Na druhou stranu při ukládání registrů na zásobník se více nadře.

Proč? Uložení 32b registru pomocí 32b sběrnice a 64b pomocí 64 bitové by mělo být úplně stejně rychlé.

[Radek Hladik]

Jo ale těch registrů je víc.

Radek

[zde]

To by nevadilo- když už se gcc rozhodne že se něco vyplatí držet v registru, tak ten load/store samozřejmě předem amortizuje. Problém je spíš v tom, že u amd64 děsně bobtnaji sizeof(struct foo), limitně až na dvojnásobek- takže věci jako linked listy, hashe, bstromy apod fakticky sníží velikost cache o 30-40%... Indexování integerama místo pointerů asi pomáhá, ale málokdo to používá.

[David Maxera]

Binární konvence pro volání funkce je úplně jiná pro amd64 a i386. U i386 se parametry funkce se předávají na zásobníku. U amd64 se prvních 5 předává přímo v na to vyhražených registrech. Takže se ušetří spousta kopírování mezi pamětí a registry.

Jinak díky binárním konvencím téměř nedochází k tomu, že by se registry ukládaly zbytečně. Některé má volaná funkce právo přepsat - volající funce si pak zazálohuje jen ty, které skutečně potřebuje. Některé registry musí volaná funkce vrátit v původním stavu - opět ale zálohuje jen ty, se kterými pracuje. Takže pro daný algoritmus 64 bitový kod ukládá mnohem méně registrů do paměti.

Samozřejmě existuje řada svičů kompilátoru, které ovlivnují výsledný kod. Někdy se i na amd64 předávájí parametry přes zásobník - lépe se pak analyzují core dumpy - třeba v (Open)Solarisu. Možná že distribuce XY zrovna používá takové defaultní nastavení gcc - koho dnes zajímá nějaká rychlost ve srovnáné se snadnou debugovatelností ... V každém případě je více registrů výhoda, přinejhorším to vyjde nastejno.

[papundekl]

Existuje takovy pojem - multitasking.

[Radek Hladik]

Nechci být kousavý jako kolega výše, ale měl jsem na mysli hlavně případ, kdy systém potřebuje přepnout context procesu, což při vyšší záteži může dělat docela často...

Radek

[Kyosuke]

Taky nechci být kousavý, ale máte reálná čísla nebo jen vaříte z vody? Protože jestli přenést jednou za pár desítek tisíc hodinových taktů o 192 B navíc do spojitého bloku paměti (a to v rámci operace, která sama může mít tisíce cyklů) má být náročnější, než co chvíli trvale šoupat registr sem a tam, rád bych to viděl podložené podložené reálným měřením.