Test výkonu: 32-bit, 32-bit PAE a 64-bit jádro (diskuse)

[thingie]

Všichni se tam běžte podívat. Vezměte prášek, zalejte vodou, a máte článek. Ještě nastavte stránkováním, aby bylo víc muziky, teda pageviews. Takhle se to dělá. Nějaká hodnota? Ach, kdež, o to už dávno nejde.

[muhehe]

procpak se ti zda, ze onen clanek nema zadnou informacni hodnotu? ja bych rekl, ze celkem presvedcive informuje o tom, ze 64 bitove jadro je vykonnejsi nez 32 bitove jadro.

[-=eM=-]

pro mě mělo značnou hodnotu testování 32 bez a s PAE, protože jsem to před vánoci potřeboval v práci použít. dle některých informací měl být rozdíl až 10% ( s PAE pomalejší ). Ani porovnání 32 vs 64 bit není nezajímavý, takže jsem rád, že si někdo jiný dal tu práci.

[Liskni_si]

Píšou tam někde, jestli na těch 64b běžel 64b nebo 32b userspace? Běhá to takhle někdo z místních? Já to zkoušel už párkrát, jeví se to celkem svižné, ale vždycky pár blbin nefunguje (s2disk a wpa_supplicant, posledně).

[Pavel Půlpán]

pro mě mělo značnou hodnotu testování 32 bez a s PAE, protože jsem to před vánoci potřeboval v práci použít. dle některých informací měl být rozdíl až 10% ( s PAE pomalejší ). Ani porovnání 32 vs 64 bit není nezajímavý, takže jsem rád, že si někdo jiný dal tu práci.

K tomu nelze říci nic jiného, než +1!

[Nicky726]

Hm, zajímavé. Je ale škoda, že nezmiňují, za jakou cenu dává 64-bit kernel takový výkonnostní nárůst. Obzvláště na Ubuntu totiž využívá až o 80 % RAM více, než 32-bit kernel, jak jsme se nedávno bavili v poradně.

[trekker.dk]

V Linuxu spotřeba paměti tolik nenarůstá, takže v Ubuntu je to asi horší.

[kolotoc]

Přijatelná cena za nárůst výkonu i více než 100 procent. Nebo snad provozuješ 64 bit distro na méně než 512 MB ram?

[Nicky726]

Osobně nejméně na 1 GB a to jen pro to, že v dohledné době plánuju upgrade PC s tím, že si nechám současnou instalaci Archu. Asi bych ale do 64-bit pod 2 GB RAM už nešel. V reálu je mnohem víc znát dopad swapování, než i 100% nárůst výkonu v některých oblastech.

[Peter Fodrek]

to je ako napisany ten program, ktory pozuivas...

to by znacilo, ze 80% kodu su smerniky, alebo 64 bit. program pocita s vyssou presnostou longov http://www.sapac.edu.au/systems/corvus/docs/sgi-propack3/Porting_Guide/sgi_html/ch03.html

[sxznam]

Stačilo by, kdyby ti volové netestovali na Ubuntu. Pro benchmarky naprosto nevhodný systém.

[belisarivs]

Proc?

Je to hodne pouzivana distribuce a tak je vysledek relevantni pro vetsi cast uzivatelu.

[sxznam]

Tohle se resi na Phoronixu po kazde recenzi. Nemůžu si odpostit ten výraz, ale ti kreténi například nasadí do produkčního systému Ext3 fileystém s vypnutými bariérami (hazard). Výsledkem je, že Ubuntu vypadá v určitém Benchmarku rychleji než například Opensuse, které mělo u Ext3 bariéry vždy zapnuté. Canonical pěstuje určitý image Ubuntu a tohle je klasický marketingový podvod. Nic proti tomu, ať bojují jak umí, ale recenzent, který pak testuje Ubuntu Ext3 či ho porovnává s jinými distribučními Ext3 je ignorant. Protože to není standardní Ext3. Takže obecně, Ubuntu je poměrně nestandardně "tweakovaný" systém (slušně řečeno) a recenze postavená na Ubuntu netestuje standardní komponentu, ale nějaký distribuční "paskvil".

[l4m4]

Recenze na Phoronixu jsou zaměřeny na tutéž chásku co Ubuntu, takže to je asi v pořádku.

Důležitější je, aby je nebral vážně nikdo jiný...

[sxznam]

No nevím. Na Ubuntu forech hojně diskutují i různí developeři, třeba z AMD nebo Kanotixu. Určitou štábní kulturu by to mít s trochou dobré vůle mohlo. Další nesmysl typu zive/pctuning/tomshardware pro děti a flamující nuly by nebyl k ničemu.

[sxznam]

Pardon. Chtěl jsem říct na Phoronix forech. Ubuntu fora neznám (a ani nechci)

[vadimo]

Je to smutné ako sa niektorý Linuxaci nemajú medzi sebou radi. Len preto, že nepoužíva ten "správny" Linux. Ale tý ktorý sú nad vecou vedia aká je to úbohosť a malosť toho človeka. Sorry, ešte nikdy som nikoho na fóre neurážal a ani nechcem, ale Linux a komunita idú spolu.

[Senior Database Programmer]

Kazda distribucia je nejakym sposobom "twaekovana" a upravena. Napriklad Debian ma opatchovany Firefox nazvany Iceweasel takze uz to podla teba nieje slusna distribucia ale "distribuční paskvil" ?

[sxznam]

Nikoli.

Nevím jaké úpravy provedli ve Firefoxu v Debianu. Kauzu jsem sice sledoval, ale už si to nepamatuju. Za situace, kdy by Debian provedl zásadní změny do jádra Firefoxu, pak by asi logicky bylo poněkud divné testovat výkon prohlížečů na Firefoxu(Iceweasel) z Debianu.

Zpět k mému příkladu. Testovat Ext3 vs. Ext4 a vybrat si k tomu defaultní a tedy hrubě nestandardní Ext3 z ubuntu je krávovina. Navíc to je distribuční paskvil, dát do produkčního systému pro BFU filesystém Ext3 nastavený tímto hrubě nezodpovědným způsobem.

[Michal Kubeček]

Pokud by to mělo vliv na výsledky toho benchmarku, např. pokud by šlo o test rychlosti javascriptu v prohlížečích a patche Debianu by na tu rychlost měly vliv, ale při prezentaci by na to nebylo upozorněno, pak by to bylo špatně.

[Ondrej 'SanTiago' Zajicek]

ale ti kreténi například nasadí do produkčního systému Ext3 fileystém s vypnutými bariérami

Vypnute bariery na Ext3 jsou linuxovy default, takze neni divu, ze to Ubuntu (stejne jako velka cast ostatnich distribuci) ma take vypnute. Pokud se to nekomu nelibi, tak at si stezuje na LKML, ne na Ubuntu.

[trekker.dk]

Nemůžu si odpostit ten výraz, ale ti kreténi například nasadí do produkčního systému Ext3 fileystém s vypnutými bariérami (hazard).

Server je od toho, aby běžel, ne aby padal.

[l4m4]

Jenže tam žádná čísla ukazující 80% rozdíl nejsou, viz ty podrobné výpisy.

[Limoto]

Taky mohli otestovat 32b userspace s 64b kernelem, když už testují každou blbost... (ne, že bych čekal, že tam bude nějakej rozdíl)

[DNA]

než jsem přešel plně na 64-bit, tak jsem nainstaloval 64-bit jádro do 32-bit userspace a běželo to normálně (v Debianu unstable, stačí nainstalovat 64-bit jádro přes balíčkovací systém, ale rozdíl je jen v uname -a)

[Limoto]

Já na tom teď taky jedu... jo a uname je nejlepší hacknout tak, aby vypisovalo i686, protože jinak selhávají některý kompilace...

[DNA]

jo proto, dík

[petr_p]

setarch(8)

[Limoto]

Dík

[Grunt]

Aspoň co se týče videa, tak mám docela jasno:

./mplayer -nosound -vo null -benchmark -cache 8129 -endpos 300 Final.Fantasy.2001.1080p.BluRay.x264-TiMELORDS/tl-ff.mkv

x86_64:
BENCHMARKs: VC: 712.516s VO:   0.045s A:   0.000s Sys:   3.382s =  715.943s
BENCHMARK%: VC: 99.5214% VO:  0.0062% A:  0.0000% Sys:  0.4724% = 100.0000%

i686:
BENCHMARKs: VC: 821.932s VO:   0.050s A:   0.000s Sys:   4.739s =  826.721s
BENCHMARK%: VC: 99.4206% VO:  0.0061% A:  0.0000% Sys:  0.5733% = 100.0000%

U Epiphany subjektivně potvrzuji podobný efekt.

[Kvakor]

Když už chtěli testovat 32bit vs. 64bit, tak neměly použít distribuci s binárnímy balíčky jako je Ubuntu, přeloženými pro i[3..6]86, ale distribuci založenou na zdrojovém kódu a překládanou na míru, jako je třeba Gentoo. Takto z testu nejde poznat, jak moc ovlivnily rozdíl oprimalizace pro procesor, protože zatímco rozdíl v optimálním kódu pro obecný x86-64 a nejnovější generaci procesorů je poměrně malý (pokud nepočítáme speciality jako použití SSE3+ a HW virtualizace), rozdíl vůči "obecnému i386" je propastný a i u "obecného i686" je stále ještě dost velký. Bohužel, takovýto test by byl časově velmi náročný ...

Na druho stranu, i tak je test názornou ukázkou, že dnes nemá smysl používat 32bit Linux na 64bit procesoru (pokud opravu nepotřebujete 32bit OS).

[trekker.dk]

přeloženými pro i[3..6]86

Debian je AFAIK překládán pro 486 (až na výjimky), takže pokud Ubuntu svoje balíčky nedělá ze zdrojových Debianu, tak je taky pro 486

[baka]

Nesouhlasim. Pro vetsinu uzivatelu (i pro mne) je dulezity rozdil mezi binarnimi baliky - protoze to je to, co budou na svuj pocitac instalovat. Navic, pokud mate pocit, ze je dost lidi, pro ktere to bude zajimave v Gentooo, nic Vam nebrani provest ten test podle sveho a pokusit se ho publikovat treba tady na abicku.

[Kvakor]

Neříkám, že test nebyl užitečný, jen jsem zpochybňoval testovací metodiku, pri které se spojily dva jevy, které se sice v praxi vyskytují současně, ale nejsou na sobě závislé (existují balíčky, dokonce i celé binární distribuce, které jsou optimalizované pro nové procesory). Pro čistý test 32bit versus 32bit+PAE versus 64bit by musely být balíčky optimalizovány pro stejný typ procesoru.

[Zdeněk Štěpánek]

Na druho stranu, i tak je test názornou ukázkou, že dnes nemá smysl používat 32bit Linux na 64bit procesoru (pokud opravu nepotřebujete 32bit OS).

Jenže těch důvodů je pro BFUčka poměrně dost, zejména různé uzavřené 32bit programy, jak by řekl Jardík - šmejdárny.

[Jose]

Chtělo by to nějak věrohodně vysvětlit extrémní rozdíly v testu Apache a PostMark.

[disorder]

imho apache je rychlejsi kvoli tym diskovym operaciam. mozno kvoli velkemu adresovemu priestoru, pouzitiu mmap a pod.

[Jose]

Kdyby to tak bylo tak by vycházely extrémně vysoké výkony i třeba PostgreSQL, což ale nenastalo. Fakticky je udávaný výkon PostMarku na 64bit desetinásobně vyšší než na 32bit, Apache je na tom podobně. Buďto jsou ty testy špatně udělané, nebo je ve verzi jádra pro 32bit něco velmi špatně navrženo. Hrubý výkon 64bit architektury prostě není desetinásobně vyšší než 32bit.

[Michal Kubeček]

Pro určité specifické typy aplikací (např. komplikovanější šifrovací algoritmy) bych si to i dokázal představit, pokud byly opravdu jako "32-bitové" použity binárky přeložené pro starší procesor typu i386-i586 a jako "64-bitové" naopak plně optimalizované. Ale u Apache k tomu moc nevidím důvod.

Tedy jedna možnost mne napadla: že by to testovali na nějakém čtyřjádře a u 32-bitové verze použili jádro bez podpory SMP. Ale pokud by to tak bylo, musel by ten test dělat ještě větší blb než ti, kdo kdysi benchmarkovali dvoujádrové 64-bitové procesory pomocí 32-bitových úloh běžících na jednom jádře.

[koso]

Nenarazil niekto nahodou na porovnavacie testy 32b vs. 64b zamerane skor na desktopovych uzivatelov? Mna by zaujimala napr. rychlost startu systemu a inych pomalsich programov (firefox, thunderbird, OOo, ...), pripadne bezne operacie ako kopirovanie suborov, prehravanie HD videa, komprimovanie suborov...

Testy na spominanom linku su vhodne skor pre serverove nasadenie, resp. nasadenie na vypoctovo narocnych - vedeckych staniciach, ale tam neni preco vahat medzi 32b a 64 ak to zvlada hardware.

[Michal Kubeček]

U "normálního" desktopu to většinou bude jedno, tam mnohem víc než na procesoru záleží na dostatku paměti, rychlosti paměti a rychlosti disku (resp. filesystému).

[JoHnY2]

Moje osobni zkusenost jsou o kousek rychlejsi starty a lepsi plynulost na 64bitu.

[Radek Hladik]

Ja si na 64 bitech uprimne nejvic cenim bezproblemove podpory vic jak 4GB pameti. PAE je sice fajn a kdyz cpu neumi nebo nejde kvuli nake aplikaci pouzit 64b, tak se hodi. Narazil jsem ale napriklad na to, ze diskova cache (block device level, ne file level) na 32b Fedore nemuze mit vic jak 1GB, zrejme kvuli 3/1 splitu. Takze kdyz jsem do iscsi serveru dal 64b os a zvysil pamet na 8gb, tak se vyrazne zrychlily io operace na vsech klientech.

[mirec]

Moje skúsenosti s prechodom na 64 bit sú asi takéto: väčšie problémy, musel som dokúpiť 2x viac RAM, mám taký pocit, že všetko je ... pomalšie. Myslím, že na dobre optimalizovanom Gentoo by bol rozdiel vo výkone medzi 32 a 64 bit zanedbateľný. Prístup k RAM keďže 64 bit používa výrazne viacej RAM nebude asi práve silnou stránkou 64 bitových systémov. Podčiarknuté a sčítané - ak by som mal znovu inštalovať Gentoo tak si vyberám 32 - bitové.

[l4m4]

Přístup k RAM je silnou stránkou 64bitových systémů. Ty by si podle své logiky měl pořídit MS-DOS, ten je 16bitový a programy v real módu zabírají ještě méně paměti (no, ani jí moc zabírat nemohou), a tudíž zcela dokonalý.

Myslím, že na dobre optimalizovanom Gentoo by bol rozdiel vo výkone medzi 32 a 64 bit zanedbateľný.

Rozdíl ve výkonu je zanedbatelný u věcí, které nestojí na CPU, takže sekretářka asi rozdíl nepozná. Chci ovšem vidět tvůj benchmark, jak ti optimalizace v Gentoo čtyřikrát zvýší výkon GMP na 32bitu...

[petr_p]

Tak zrovna v reálném režimu se nevirtualizuje paměť, takže se není třeba zdržovat s TLB, takže by to fakt mělo být rychlejší. Ale je možné, že v dnešních procesorech panují jiné poměry než v 80386 :)

[Miloslav Ponkrác]

Problém je, že jsou určité režimy, na které se kálí při návrhu procesoru. Dnes se optimalizuje procesor pro flat mode 32/64 bitů a tam se vrtají všehcny optimalizace.

Většina věcí z reálného režimu je optimalizovaná na dnešních procesorech fakt mizerně – jako například šestnáctibitová aritmetika, která je zoufale pomalá, nebo operace s vyšší polovinami registrů.