Dotaz: Stojí za to přejít na 64bit aplikace

[ivitek]

Dobrý den, mám AMD64bit a stále 32bit verzi OS. Dá se nějak odhadnout o kolik výkonu přicházím používáním této neoptimalizované distribuce. V čem je vlastně ta optimalizace pro 64bit- je to dáno jen kompilátorem? Nebo i nějak programově - v kódu. Vysvětlete mi to prosím jako totálnímu BFU - třeba to pochopím.

Odpovědi

[Pinky]

Ano mělo by to být rychlejší, ovšem záleží co na tom děláš, je to dáno hlavně kompilátorem, jen některé drobnosti se musí upravit v některých programech které jsou na něčem 32bit závislé. Pokud máš volnou nějakou partition tak si tam zkus nainstalovat něco co je pro 64 bit optimalizované a uvidíš, jinak zkus hledat, pokud chceš vědět víc. Jen tak náznakem jen pro BFU, když máš dva otroky a jeden unese 32kg a druhý 64kg a v dalším se moc neliší, který je lepší?

[Zdeněk Štěpánek]

Zdravim

Pokud po nem budu pravidelne kazde pondeli chtit aby mi odnesl na postu pul kilovy balicek tak kterej je vyhodnejsi? Jednoznacne ten druhej, kdo vi proc?

Zdenek

[Zdeněk Štěpánek]

sakris, vyhodnejsi ma byt ten PRVNI...........

[SYSMAN]

Zalezi jestli jsou ti otroci OpenSource, pak je vyhodnejsi ten druhy

[Jirka]

Vim, ze ses opravil. Ale opravil ses spatne.

Vyhodnejsi je kazdopadne ten druhy, protoze otrokum se NEPLATI.

[_]

spis bych rekl, ze mas dva otroky. oba unesou 128kg ale ten jeden ma dvakrat vetsi pytle na prenaseni - blbe se drzi ze sou vetsi a tak.

[Jiří Svoboda]

Urcite existuje par aplikaci, ktere budou pod 64 bity vyrazne vykonejsi. Urcite exituje spousta aplikaci, ktere budou o neco malo vykonejsi. A u velkeho mnozstvi aplikaci nedojde k zadne zmene. (Clanek na root.cz).
Ja mam po mesici provozu AMD64 a vyzkouseni tri distribuci zatim ten nazor, ze pokud clovek vystaci s binarnimi balicky, nema vyrazne problemy. Ty zacinaji az v okamziku, kdy se rozhodne sam neco zkompilovat. Uz jsem to tu na par mistech resil, nicmene par prikladu zopakuji:
- 64 bitove distribuce, pokud maji byt zpetne kompatibilni, musi mit sadu knihoven pro 32 bitove aplikace a sadu pro 64 bitove aplikace. Resi se to dvema oddelenymi adresari. Napriklad Fedora ma adresar '/lib64' pro nativni a adresar '/lib' pro 32 bitove knihovny, coz musel vymyslet fakt nejakej _dement_, protoze diky tomu mj. neprobehne zadne './configure' normalne a ke vsemu se musi davat spousta parametry stylu '--with...=/lib64'. Gentoo to ma naopak (logicky spravne), navic je '/lib32' link uplne bokem.
- 64 bitovy mplayer bezi bezvadne, jen (logicky) neumi pouzivat Win codecy, ktere jsou obcas potreba. Jako 32 bitovy nejde zkompilovat.
- e-uae (fork Amiga emulator) se pod 64 bity zkompiluje, ale pri spusteni okamzite segfaultuje. 32 bitovy nejde zkompilovat.
- 32 bit aplikace jsem nakonec zkousel kompilovat a spoustet v chrootu do me puvodni distribuce, lec tam jsem zase narazil na jine problemy.

Takze ja jsem nakonec po malem kolecku po ostatnich distrech obnovil ze zalohy Slackware a jedu zpatky na 32 bitech...

[Michal Kubeček]

Napriklad Fedora ma adresar '/lib64' pro nativni a adresar '/lib' pro 32 bitove knihovny, coz musel vymyslet fakt nejakej _dement_, protoze diky tomu mj. neprobehne zadne './configure' normalne

Nikoli, dementi vymýšleli pouze ty configure skripty, které místo aby k detekci knihoven používaly linker, jak velí zdravý rozum (koneckonců je to linker, kdo je bude potřebovat), a jak je autoconf navržen, hledají knihovny natvrdo v /lib. Abychom byli adresní, tak se jedná o např. o PHP (4.3 i 5.0). Apache 2.0 pro změnu hledá i v lib64, ale pokud jsou nainstalované obě verze (což většinou jsou), pokouší se linkovat natvrdo proti té 32-bitové... Slušně napsané configure skripty ale fungují bez problémů.

Jinak bych k problémům přidal 64-bitový Firefox, se kterým celkem pochopitelně nefunguje 32-bitový flash plugin (a jiný neexistuje). Ale to je v podstatě totéž, co u mplayeru.

[Jiří Svoboda]

Diky za poopraveni. Nicmene pokud jde o nazvy tech adresaru, tak si porad myslim (resp. vysvetluji si tak UNIXovou filozofii), ze nativni knihovny systemu by mely byt v '/lib' (a pokud bezi 64 bit kernel, tak jsou to ty 64 bitove) a jine (napr. od jine architektury, nejake emulace nebo 32 bitu) pak nekde jinde.

[Michal Kubeček]

S tím souhlasím, také by mi to připadalo logičtější. Mám ale pocit, že autoři linuxových distribucí (přinejmenším u SuSE je to stejně) tentokrát neprojevili vlastní iniciativu, ale udělali to podle jiných platforem. Pokud si vzpomínám, když jsem googloval poznatky k těm problémům s configure skripty, zahlédl jsem popisy prakticky stejných problémů o pár let dříve z nějaké jiné platformy (že by Solaris?).

[unchallenger]

AFAIK je to vcelku standard^Wúzus (akorát IRIX má navíc ještě lib32, protože má dvě 32bitové ABI...), takže přenositelné programy se s tím dávno vyrovnaly a IMHO by spíš přineslo problémy, kdyby to Linux dělal jinak.

[Michal Kubeček]

Tak jsem mrknul, co na to FHS, a vypadá to, že je to kvůli existujícím 32-bitovým binárkám, které mají v sobě natvrdo cesty ke knihovnám. Jsem v pokušení prohlásit něco o autorech takových programů, dehtu a peří, ale asi budou situace, kdy to dává smysl.

[MOJE]

Jo treba o autorech OpenOffice.org
Ale samozrejme pokud to dokazete, tak si je muzete prekompilovat pro 64bit a netrapit se s existenici lib64

[Stanislav Brabec]

Ono když už máte jednou zkompilovaný 32bitový program, který hledá pluginy v /usr/lib/program, těžko ho přesvědčíte, aby hledal jinde. To je jednodušší to naučit ten 64bitový od začátku.

Ale napadá mne, že nutnost přidávat --libdir do každého configure skriptu by vyřešil config.site (CONFIG_SITE).

[David Watzke]

Jinak bych k problémům přidal 64-bitový Firefox, se kterým celkem pochopitelně nefunguje 32-bitový flash plugin (a jiný neexistuje). Ale to je v podstatě totéž, co u mplayeru.

Když už to stoletý vlákno někdo vytáhl: to už dnes není pravda, viz gnash homepage. Ale nevím jak funguje, posledně když jsem ho zkoušel v 64-bit Konqueroru, byla to bída.

[_]

podstata x86-64 je ta, ze program muze provest mmap na dvd.iso nebo vetsi soubory, ale vykoupi se to vetsimi pointery a tim i plytvanim fyzickou ramkou.

jinak na procesoru se da uvazovat asi tak, ze se 64bit instrukce maji prefix pokud neni procesor preply instrukci do 64bitoveho adresniho rezimu = mene mista v prefetch.

pokud je v 64bit rezimu nebo 32 s prefixem tak adresy maji vic mista = mene mista v cache.

vychazim z toho, jak to implementoval intel u prechodu 16 -> 32

[outlier]

Zajímavý. No říká se, že rozdíl je 10-20 procent, záleží, co tam chceš provozovat. Já mám taky AMD64, ale 64-distro jsem zatím nezkoušel...

[Michal Kubeček]

No říká se, že rozdíl je 10-20 procent, záleží, co tam chceš provozovat.

Takové jednoduché číslo má nulovou vypovídací hodnotu. Mezi jednotlivými aplikacemi jsou obrovské rozdíly podle toho, co vlastně dělají. Tam, kde pracujete s 64-bitovými daty, je rozdíl značný, kde ne, může být jen nepatrný, občas dokonce může být 64-bitový build i o pár procent pomalejší (zřejmě ne úplně doladěné optimalizace). V každém případě není rozdíl tak výrazný, jako při přechodu z 16-bitových procesorů na 32-bitové, protože zatímco s 32-bitovými daty pracuje prakticky každý program, 64-bitová tak často potřebná nejsou.

[Spike411]

AMD64 je platforma velice nová, jsou to vody neprobádané.

Tudíž sem tam nějaký pakl nejde moc pod 64-bit zkompilovat. Je také dost možné, že se díky jiné architektuře vyskytnou jiné bezpečnostní díry...

Přechod na 64-bit dnes znamená zpomalení hlavně v oblasti videa, zvuku a 3D grafiky. Jinak enlightenment lítá pořád stejně ;)

1 a 2) Většina kodérů a enkodérů má velké části optimizované v x86 assembleru. Zatím jsem zaznamenal nějakou práci na přepisování do 64-bit instrukcí u XviD kodeku.

3) Nevím, jak je na tom nVidia, ale ATi stále ještě nevydala 64-bit drivery (a drivery pro X.org 6.8 také ne...). Zde jsou pak tři možnosti:

a)žádné 3D

b)DRI

c)chroot

Jinak jsem si opravdu nevšiml, že by byl systém výrazně rychlejší. (Doporučuji novější jádra – 2.6.9 nebo 10, s 8 byl fakt nějak pomalý...)

Ale v 64-bit je budoucnost, vždyť za „pár“ let dojde velikost 32-bit proměnné pro unixový timestamp. (2037, myslím)

[unchallenger]

nVidia vydává drivery pro amd64 normálně -- v praxi jsem je ale zatím nezkoušel, takže to nemusí mnoho znamenat.

[Slezik]

Nvidiacky se mi podarilo nainstalovat na Mandrake 10.0 s 2.6.7 jadrem (s 2.6.3 mi to neslo) a chodi bezproblemove. Teda poradne je zkousim jen v Enemy-Territory. Slezik

[MOJE]

Drivery od nvidie normalne pouzivam a nemam problemy. Vykon je asi slusny, ale protoze nehraju, tak to muzu otestovat maximalne tak na aplikacich, jako je stellarium.

[Michal Kubeček]

Ale v 64-bit je budoucnost, vždyť za „pár“ let dojde velikost 32-bit proměnné pro unixový timestamp.

Je to přibližně rok, co uplynula polovina té doby... Ale hlavně mi uniká důvod, proč by time_t nemohl být 64-bitový i na 32-bitových platformách. Daleko větší problém bude IMHO s datovými formáty, které timestamp ukládají natvrdo jako 32-bitovou hodnotu. A to bude problém i na 64-bitových platformách...

[MOJE]

problem bude v tom, ze spousta v RFC definovanych protokolu (treba NTP) ma time definovany, jako 32bit cislo.

[Stanislav Brabec]

Na to vidím rozumné řešení: Každých x let (cca 30/60?) vydat RFC, které změní definici tohoto stringu z unsigned na signed a za dalších x let zase zpět. Samozřejmě to předpokládá nepoužívat binárky starší než x let.

[MOJE]

ja bych radeji videl update NTP protokolu, nebo vytvoreni NTP64, nebo NTP2, proste novejsiho s jedinou zmenou a to bude 64bit time_t. Tim by mohlo byt na nejakou dobu vystarano (pro paranoiky mozno vytvorit NTP256 a budou mit do hodne dlouhe budoucnosti po starostech)

[Jiří Svoboda]

Jeste jednou ja, tentokrat se dvema konkretnimi cisly. Stejny stroj, (Athlon64 3200+, pujcena GeForce FX5600 256MB), nVidia drivery 1.0-6629, 'glxgears' (v okne, bez parametru):
Fedora Core 3 x86_64: necelych 2000 FPS
Slackware 10 i386: necelych 1750 FPS
Tedy rozdil temer presne 250 FPS. Tolik jsem necekal!

[Petr Šobáň]

Trochu se přidám mám

[petr@soban ~]$ cat /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 6
model           : 8
model name      : AMD Athlon(tm) XP 1700+
stepping        : 0
cpu MHz         : 1460.712
cache size      : 256 KB

A budu to překopávat na 64bitů AMD Athlon A64 3500+ 64-bit Orleans (MB, RAM, CPU je objednané má přijít zítra)

Mám FC5 a samozřejmě vemu jenom HD a přehodím je na nový MB a teoreticky by to mělo chodit.

A teď k problému dají se normálně instalovat 64bit programy (že bych doinstaloval 64bit knihovny z 64b FC5) prostě že nové věci bych měl 64b nebo dá se to upgradovat pomocí yumu na 64b - má s tím někdo skušenosti ?

[Stanislav Brabec]

Musíte vyměnit jádro.

Nevím, jak je tomu v FC5, ale např v SuSE se samotné 64b knihovny nevyskytují - jsou tam pouze plné balíčky 32b a 64b, a pak samostatné knihovny *-32bit. To znamená nahradit 32b balíček 64b balíčkem a doinstalovat -32bit pro staré aplikace. A může se také stát, že některé knihovny se jako -32bit vubec nebalí. Případně, že narazíte na chybu vyplývající z neotestované kombinace.

[Petr Šobáň]

No jadro už jsem si stáhl abych ho měl jak přehodím disk tak uvidím jak to zítra přijde doufám že vše bude OK.

[Petr Šobáň]

Tak zatím s

[petr@soban /proc]$ cat /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 79
model name      : AMD Athlon(tm) 64 Processor 3500+
stepping        : 2
cpu MHz         : 2200.000
cache size      : 512 KB

A s FC5 s balíčky pro i386 a kernelem i686 vše běží OK zatím.

MB: ASUS M2NPV-VM

Pouze jsem musel přehodit ovladače pro zvukovku a síťovku.

[vitko]

Treba oggenc a mencoder maji podle mych hrubych mereni na AMD64 asi 25-30% bonus. Az nasadim kernel 2.6.18, zkusim to opet porovnat, jinak oba testovaci systemy jsou unstable Debian (Sid), takze vsechno ostatni je uz ted stejne.

[Stanislav Brabec]

Zrovna u mencoderu jela podle mých měření AMD64 verze o 50% pomaleji než ix86 verze. ix86 verze je optimalizovaná v assembleru, a x86_64 přinejmenším v době mého měření nebyla. Nehledě na to, že 64bitová verze nemůže používat binární 32bitové kodeky.