64 bitů? Nemám... není důvod

Záleží na čem a jak člověk pracuje. Když si spustím dvě databáze, web server, Visual Studio, k tomu třeba VMWare s virtualizovaným dalším OS, a Photoshop x64 s velkým projektem, i 8GB RAM je málo a vytížení se pohybuje kolem 12GB.

Když člověk píše ve vim/u, stačí mu méně RAM ;)

"Pravda je, že 64bitový systém/aplikace jsou náročnější na paměť, kód je dvakrát delší."

nooo to tedy pravda opravdu neni! kod je jen o kousek vetsi! maly pokus treba na http://tukaani.org/xz/xz-4.999.8beta.tar.gz

./configure;ma­ke;make test;strip src/xz/xz; ls -l src/xz/xz

x86: 156184 (gcc 4.3.2)
amd64: 157256 (gcc 4.3.2)
ppc: 149488 (gcc 4.2.1, nemam 4.3 :()

[1] Souhlasím, určitě existují takové případy. To ovšem jen potvrzuje názor, že 64 bitů má smysl jen kvůli množství paměti.

[2] To je velmi zajímavé a překvapující. Jak je to možné? Myslel jsem, že instrukce jsou kvůli adresaci obecně dvakrát delší.

"Navíc testy ukázaly, že jsou situace, kdy jde naopak o stejně mírný pokles."

mam podezreni ze k tomuto dochazi jen v situaci, kdy x86 kod je optimalizovan v assembleru a amd64 ne

typicky priklad bylo kodovani filmu do xvid na stejnem 64bit stroji 32bitovym mencoderem a 64bitovym mencoderem, ten prvni byl dost zretelne rychlejsi; ale v soucasne verzi xvid uz je assembler i pro amd64, takze k tomu jiz nedochazi...

Méně než 4GB paměti je pro vývojáře opravdu nesmysl a to i na Linuxu. A proč si nedopřát rychlou práci, když ceny pamětí už dávno nejsou podstatná brzda.

K tomu procesor s triple-channel a je jasné, že 6GB je minimum. A proč nemít rovnou 3x4GB, když to stojí pár korun? Opravdu se divím, že taková celebrita, jako je Radek Hulán, má pouhých 8GB RAM. To vypadá, jakoby ani neměl triple-channel procesor! Skoro se bojím zeptat na to, jaký má disk. Každý přece ví, že dnes je jediná volba SSD!

[3] "ovšem jen potvrzuje názor, že 64 bitů má smysl jen kvůli množství paměti." -- ne tak docela, nové instrukce, více registrů, to může znamenat urychlení aplikace, pokud s tím bude nativně počítat. Navíc je x64 režim bezpečnější - třeba Vista x64 implementuje PatchGuard a DEP.

Ale samozřejmě hlavní přínos je možnost spouštět (mnohem) více aplikací aniž se používá swap file, popřípadě náročné jednotlivé aplikace jako je ten Photoshop CS4 x64. Ten nemá problém použít 14GB RAM pro velký projekt a na rychlosti je to sakra znát :)

>> Když si spustím dvě databáze, web server, Visual Studio, k tomu třeba VMWare s virtualizovaným dalším OS, a Photoshop x64 s velkým projektem, i 8GB RAM je málo

Je nějaký důvod(kromě obsazení paměti), proč to mít spuštěné zároveň ? Buď dělám v Photoshopu x64 grafiku nebo ve Visual Studiu program nebo si hraji s virtualizovaným dalším OS. :)

Si myslim ze sice pre 64b je takmer vsetok soft ako na 32b ale niektore distra to maju blbo riesene.. niektore podporuju emulaciu ako debian a tiez mandriva ma to tiez dobre urobene ze mozes mat 64 aj 32b kniznice a soft nainstalovany naraz. ja osobne tiez sa priklanam ze 32b su ok ale s PAE kedze mam 4gb ram a treba brat do uvahy ze urcitu pamet si namapuje aj grafika atd.

Fakt se mi líbí, jak se tu řeší, jestli sežere o 10MB víc GNOME nebo KDE a pak se tu mávne nad "pár megabajty paměti", to pár mohou být nemalá čísla a přitom rychlostní přínos je na mém železe opravdu 0 - takže to není "nula od nuly pojde", můžete si prostě dobrovolně nainstalovat paměťově rozežranější systém, který nemá žádnou výhodu - a to se vyplatí :) (mluvím o systémech do 4GB, kterých je většina)

Já si dal 64bit jen kvůli 4 GB RAM - kdysi (kernel snad 2.2?) jsem PAE zkoušel a zdálo se mi to příliš pomalé (=PAE způsobilo zpomalení, ale neměřil jsem o kolik).

3: jak dvakrat delsi instrukce? ktery? to jste asi zase neco nepochopil/popletl

v 64bitovym modu ma procesor k dispozici dvakrat delsi REGISTRY a ma jich vic, to ovsem nezere zadnou pamet...

vice registru je taky hlavni duvod, proc v 64bitech programy bezi o neco rychleji

11. operacni kody instrukci delsi nejsou, ale adresni cast je skutecne dvojnasobna. To znamena, ze kazdy ukazatel, plny offset od bazove adresy ci integerova konstanta je dvakrat vetsi, coz sice prilis neprodlouzi vyslednou binarku (precejen instrukci typu load, store ci add reg, const je v dobre generovanem strojaku malo), ale pri behu programu je to jiz poznat - zvetsi se datovy segment a to v tech nejhorsich pripadech klidne i na vic nez dvojnasobek (jeste je zapotrebi pripocist vliv zarovnani).

Priklad natazeni binarek v realne aplikaci - JRE kompilovane pomoci GCC:
OpenJDK @ i386 - sdilene knihovny maji 13 MB
OpenJDK @ x86_64 - sdilene knihovny maji 16 MB

11. zpomaleni-zrychleni: to zalezi na konkretnich podminkach. Pokud mi krasne optimalizovany kod pro x86_64 vypadne z cache (coz je pravdepodobnejsi nez u i386), tak vice registru apod. nepomuze (v dalsich pripadech zase ano, ze statickeho kodu se to vsak neda vycist). Prave pomerne veliky cache miss je jeden z nejvetsich problemu RISCovych procesoru, proto se u nich nove zavadi "komprimovany" instrukcni kod, ktery jde proti puvodni filozofii RISCu.

Na 64bitu jedu už od Ubuntu 7.04 a můžu říct, že za tu dobu se mnoho zlepšilo.Tenkrát spousta aplikací byla pouze 32bit (např. flash),pamatuji si, jak dlouho jsem vše rozjížděl aby to fungovalo tak, jak jsem chtěl. Nyní naprosto bez problémů (dokonce jsem si i 64bit hodil na ntb).
Btw. nejsem si zcela jist, ale mám za to, že už jsem někde viděl skype 64bit (alespoň verzi pro Ubuntu).

3: S tim zdvojnasobenim delky instrukci jste to asi opravdu prehnal. Architekturu amd64 uz moc neznam, ale pokud mohu srovnat s davnym prechodem na 32 bitu, delka instrukce naroste pouze pokud instrukce primo obsahuje hodnotu nebo adresu/offset. To se ale nestava tak casto, vetsinou se manipuluje s registry a hodnotami/adresami v nich a takove instrukce jsou v zasade stejne. Nemusite byt odbornik, ale prekvapuje mne, ze si to alespon nezkusite (jo vy vlastne nemate ten 64-bitovy system:).

Jinak si myslim, ze jste opominul dalsi duvod k prechodu na 64 bitu --- jednoduse je to budoucnost a cim vice lidi ji bude pouzivat, tim vice bugu pro 64 bitu bude hlaseno, tim stabilnejsi aplikace budou, tim vice aplikaci bude ... Rekl bych ze vyvojari a lide kteri hlasi bugy (konkretne napr. gentoo bugzilla) uz z vetsiny jsou na amd64 a neni daleko doba, kdy budou aplikace stabilnejsi nez na 32 bitech.

4: Je to tim, kdyz vam 64bitovy kod/data vyletava z cache. U dat neni problem dosahnout dvojnasobneho zvetseni, napriklad pokud se pouziva typ long (32 vs 64 bitu).

[15] Ano, neuvědomil jsem si, že se to týká jen některých instrukcí. Upravil jsem to v blogu. Předtím jsem to nezkusil, důvod nebyl, ale teď jsem si cvičně zkompiloval links a narostl z 991 Kb na 1036 Kb. Nárůst je tedy jen o 4,5 %.

A jak je to se zarovnavanim instrukci?

Kdysi davno bylo jedno co je to za instrukci, obsahovala vsechny slozky, ale nektere se proste nepouzivaly/pri­padne se jejich ucel menil podle instrukce.

Procesor (alespon x86) prece nacita instrukce po plnych intech a pocet dratu vedouci do dekoderu instrukci nebo datove sbernice se dynamicky nemeni.

Tudiz teoreticky pri pouziti samych 64bit instrukci by to dvojnasobek byt mel. Tedy co se tyce kodu, resources, hlavicky, diry a podobne jine soucasti binarky zustanou temer stejne.

Zasadne nesouhlasim s tim, ze neni duvod!
Doba, kdy kazde PC bude mit vice nez 4GB neni tak daleko a v te dobe uz musi byt 64bit systemy (vcetne veskereho SW) plne odladene.
Jako pokrocily uzivatel nemuzete udelat nic jednodussiho, nez si 64bit nainstalovat a pripadne nedodelky hlasit. Vas pristup brzdi rozvoj vypocetni techniky.

,,Rekl bych ze vyvojari a lide kteri hlasi bugy (konkretne napr. gentoo bugzilla) uz z vetsiny jsou na amd64 a neni daleko doba, kdy budou aplikace stabilnejsi nez na 32 bitech."

Já jsem si myslel, že zdroják napíšu jen jednou a pak to proženu 32/64 bit kompilátorem?

Väčšina rozumných systémov (t.j. nie Windows) nemá problém pomocou PAE adresovať 32 alebo 64GB pamäte aj s 32 bitovým jadrom. Niektoré (OSX) sú schopné s 32 bitovým jadrom spúšťať 64 bitové aplikácie. Akurát pár ľudí nevie pochopiť že netreba mať X rôznych edícii OS, stačí 1 ktorá pokryje všetky prípady. A potom netreba riešiť 64 alebo 32bitov.

18. Ahoj. Na x86 se instrukce nezarovnavaji, tj. treba za jednobajtovou instrukci se nedela "vypln" 3 nebo 7 bajtu. To rozsekani na instrukce se resi ve fronte instrukci az na procesoru, takze on opravdu v mnoha pripadech nacita (a vykonava) instrukce "zbytecne", aby jejich vysledek zahodil :-)

19: Tak nejak i kdyz ne tak zasadne jsem to myslel. Navic bych se uz celkem rad zbavil i tech compat/emul32 knihoven a vyhodil podporu pro 32bit i z jadra (to uz je spis jakasi zvrhla estetika, to obhajovat nebudu). Kdyz uz je i ta Java a Flash, tak je casto jedinym duvodem Wine nebo jine :) blob hry.

20: To je samozrejme pravda; mel jsem na mysli, jaky system dany clovek prevazne pouziva pro praci. Jednoduse mam dojem, ze napr. v te gentoo bugzille uz casteji vidim prispevek "Confirming bug/bugfix on ~amd64" nez "... on ~x86". Stejne tak muj spolubydlici vyvojar pouziva 64 bit. Jinak je to muj dojem, pruzkum jsem nedelal.

Ja osobne vidim 3 duvody pro 64bit.Linux:

1) Pamet - nezalezi ani tak kolik je v pocitaci fyzicke RAM, ale kolik virtualni pameti je pristupne v jedne aplikaci. Zkuste namapovat 2GB soubor do pameti na 32 bitech. Jiste, da se mapovat po castech, ale proc si s tim zasvinit kod, kdyz staci naistalovat 64bit. Linux.

2) Registry - 2 x vice registru jak 'general purpose' tak XMM. To je vec, ktera dela 64bit procesory rychlejsi. Navic pokud pocitate s 64bit cisly tak, ten rozdil proste poznate.

3) Mate ambice delat SW pro 64bit Linux? Treba programujete neco, co pak pobezi na 64bit bestii s 16GB RAM. Nebo potrebujete vyvijet jak pro 64bit tak pro 32bit OS.

Pokud Vam ani jeden z techto bodu nic nerika, at uz se rozhodnete pro 32bit., nebo 64bit. Linux, je to fuk, rozdil ani nepoznate.

Da se rici to same o 64bitovych win32?

Nevyhody 64bit Linuxu:
Je jich malo, ale prece jenom jsou:
1. podpora 32bit aplikaci k kernelu neni 100%. Treba video4linux nebo debugovani 32bit aplikaci na 64bit.
2. g++ v nekterych pripadech ma g++ exponencialni naroky na pamet/cas pri generovani kodu. Treba boost::spirit
3. spatne napsane programy nemusi fungovat a nemusi byt na prvni pohled zrejme proc. Nedavno jsem se s tim setkal u tacasc serveru, kde na 64bit verzi nefungovalo pocitani md5 hashe. Server bezel, logoval ale neexistoval zpusob jak autentizovat switche.

Ve Slezku se ovšem říká spíše "vlou-vylou" :) ale je fakt, že možná jenom u hranic...

Delsi jsou instrukce, ktere pracuji s 64bit daty a dodatecnymi registry protoze maji jednobajtovy prefix (tzn. jejich delka se zdvojnasobi jen v pripade jednobajtovych instrukci) + pokud pracuji s okamzitou 64bit hodnotou pak se prodlouzi o dalsi 4 bajty.

Dale je treba uvedomit si, ze na x64 ma int stale stejnych 32 bitu. Pokud si nekdo primo nevyzadal long (se vsemi zvlastnostmi tohoto typu) nebo long long nebo glibc hnusy typu int64_t, pak se zadne prefixovani nekona.

Ono je stejne zbytecne resit velikost kodu protoze je beztak v dnesni dobe oproti datum, se kterymi pracuje zanedbatelne velikosti...

Taky stále 32bit (a 4GiB paměti). Nějak mě to k 64bit systému netáhne, navíc mé distro již ve výchozím nabízí PAE jádro.

[26] Co to meleš? Celkově jsem nikdy nic takového neslyšel a bydlím ve Slezsku 22 let.

Proc je 5 hodin po uverejneni clanku zamkle hlasovani?

Není zamčené, ale kontroluje to IP adresu. Pravděpodobně jste za NATem a už z vaší sítě někdo hlasoval.

13: to mas na mysli thumb extenzi na ARM? to teda podle me nebylo zavedeno kvuli cache-miss ale kvuli "zhusteni" kodu, teda aby binarky byly co nejmensi

27: tak tak, krome toho, jak zde nekdo zminoval, ze ti 64b kod muze pretect z cache, kdezto 32b by se tam jeste tesne vesel

Mozno totu uz niekto pisal ale aj tak to zopakujem je skype aj pre 64bit OS.
Mozno to nema vyznam si davat 64 bit system ale v nicom sa nelisi tak preco si ho nedat? A este je tu ten IT pokrok. Cim nas bude viac tym bude pre nas viac vyvijane a casom uz nebudem mat problem tabat soft pre 64bit system.
A este jedna vec aj tak raz prejst musite :)

Neměla by otázka spíš znít: "proč používat 32b když mám 64b procesor"?

Na 64b procesor patří 64b systém. 32b jenom v případě, že je to bezpodmínečně nutné - např. proto, že moje nenahraditelná klíčová aplikace prostě nic jiného než 32b nepodporuje.

;-)

Nevim proc, ale zrovna Firefox 32bit zabira mnohem min pameti nez stejna verze 64bit. Mam to overene uz na spouste verzich, minimalne od 3.0 (2.x na tom byly myslim stejne).

Napr. jenom po spusteni 64bit Firefox zabira o 23 MB vice nez 32bit Firefox. Coz je divne uz jenom proto, ze je to spusteno na 64-bit systemu a tudiz 32-bit verze musi nacist extra 32-bit sdilene knihovny navic (ktere zarucene zadna jina aplikace nepouziva, protoze zadna jina 32-bit app nebezi).

U jinych aplikaci jsem si neco tak vyrazneho nevsim.

Já osobně o tom moc nepřemýšlím, prostě na 64bitový procesor nainstaluju 64bitovou Mandrivu a ono to funguje.
Na 32bitovém procesoru má nainstalovanou 32bitovou Mandrivu 2008.0, na 64bitovém notesu 64bitovou Mandrivu 2008.0. Jediný rozdíl, který jsem našel, je, že v přibalených OpenOfficech v 32bitové verzi není asijský fonetický rádce, ale při výběru fontů je zvlášť nabídka pro latinku/cyrilici, asijské fonty a hebrejštinu. V 64bitové verzi fonetický rádce je, ale na v nabídce fontů je zvlášť nabídka pro latinku/cyrilici a asijské fonty (hebrejština chybí).

27. ceckovy int bude na i386 32bitovy i na x86_64, ale uz (void *) nebo jakykoli jiny ukazatel je 64bitovy, stejne jako padding. V aplikacich se slozitymi datovymi strukturami se to uz dost pozna - ostatne i takovy DOM je samy ukazatel :-)

Datum.

Dalším důvodem pro přechod na 64bit systémy může být datum. Unix timestamp je na 64bitovém systému také 64bitový, takže Vám nepřeteče v roce 2037, čehož se mnoho z nás může dožít.

moj HW: 64bit
moj SW: 32bit
spokojnost: dobra

cas, ktory by som privital aby to fungovalo o nieco lepsie: asi 5 minut denne

„Já na přechod na 64 bitů vlastně nemám vyhraněný názor.“

Taky nemám extra vyhraněný názor. Prostě jsem jednou vyzkoušel 64 bitový Linux (když už mám takový procesor, tak proč to nezkusit, že?) a už mi to zůstalo.

„Stejně tak ale neexistuje důvod nepřejít.“

Na problémy jsem nenarazil, všechno funguje. Systém mi přijde o něco rychlejší, ale neměřil jsem to.

„Současná situace je tedy poněkud patová.“

Z dnešního pohledu možná ano, ale 64 bitů znamená pokrok a je to budoucnost – tak ho chci používat už teď. 64 bitový procesor má dnes téměř každý, ale Linuxáci rádi zkoušejí nové a moderní věci, asi proto je mezi uživateli tohoto OS mnohem větší podíl 64bitařů než třeba u nejmenovaného majoritního OS.

Já bych k těm důvodům PRO 64 bit přidal často přehlížené/ba­gatelizované:

1) 4 GB limit není pouze na celkovou instalovanou paměť (a NENÍ pravda že každý 64 bitový kernel bude umět využít 4GB fyzické RAM!). Důležitá věc je, že _adresní prostor jednoho procesu_ má limit 4 GB (z čehož 1GB sežere jádro; kde se ta paměť vezmě je dost jedno, viz swap, GPU, ...). Dokonce i s PAE na 32 bitovém systému budou aplikace trpět tímto limitem.

2) 4 GB limit se vůbec netýká pouze paměti. Čítačů, které pracují s čísly >2^32 je poměrně mnoho: velikost souborů, časovače, ... toto všechno je v 32 bitovém systému potřeba řešit dvěma zápisy do paměti, které nejsou z hlediska synchronizace cache atomické a musí se řešit zámky.

3) Tvrdí zastánci 32 bitů obvykle nezapínají ani PAE, čímž se připravují o bezpečnostní bit NX v procesoru.

No a pak jsou tu samozřejmě obligátní výhody typu 16 general purpose registrů a pokud toto nestačí tak už nevím co... názory typu že 64 bitová adresa je 2x delší než 32 bitová jsou mimo mísu, s tímto přístupem bychom mohli ještě stále používat 16 bitů...

Jsem doufal, ze tady dostanu nejaky presvedcivy argument pro pouzivani toho nebo onoho systemu. A nic. Jedinym racionalnim duvodem by zrejme bylo > 4 GB RAM, ale to nemam a ani v brzku mit nebudu (protoze nevyuziju), takze zustanu na 32b a to asi jeste hooodne dlouho :-)

20: vedlejsim efektem prechodu vetsiny vyvojaru na 64 bitove systemy je, ze nektere programy nejsou dobre testovany na 32-bitech a zlobi...

37: datum. Na 64-bitovem systemu se muzete dockat veci, az se Vam protoci panenky. Treba NTP protokol s 64 bity nepocita a klidne Vam nastavi datum na rok 2281. NTPD pracuje jen s offsetem, zalezi jake mate vychozi datum, pokud se posune "omylem" do daleke budoucnosti, NTP protokol Vas do soucasnosti nevrati... :-( Pokud mate 64-bit system, lze snadno vyzkouset. ;-)

[5] Zase tak horké to není – na předchozím počítači jsem začínal s 256 MB RAM a psal jsem v tom Javu v Netbeansech – nic moc pohodlí, ale dalo se v tom pracovat. Časem jsem postupně upgradoval na 1 GB a na současném počítači mám 4 GB, lidi jsou ale dneska hrozně zmlsaní. :-)
64 bitový OS mám kvůli mírnému zrychlení a z ideologických důvodů (aspoň to uznám). :-)

[7] Spíš když to s tou prací myslíš vážně a nechceš se jen vytahovat v internetových diskusích, tak máš kromě pracovní stanice (desktop/notebook) ještě server, na kterém si virtualizuješ nebo provozuješ různé databáze a aplikační servery. ;-)

Obdivuji téměř "svatou" trpělivost s jakou pak Krčmář odpovídá na dotazy zvláště těch pánů, kteří se nejen že skrývají za přezdívku, ale navíc by nebyly schopni takovou úvahu vyplodit.

Tak tedy:

Ohledne adresace pameti: je potreba rozlisovat mezi virtualnim adresnim prostorem a fyzickou pameti. Klasicke i686 ma 32b virtualni adresy, ktere se pres strankovani prekladaji na fyzicke, ktere maji 36b, coz je pro rozumne desktopove pouziti vice nez dost (ukazte mi nekdo desktopovy chipset, ktery te pameti umi vic). Uvaha, ze jeden proces potrebuje vic je dost mimo, veci ktere vyuziji vic to stejne vyuziji na veci typu blokovou cache, kde je to stejne nezajimave, protoze to resi kernel a resi to jinak.

Velikost kodu: amd64 kod proste je vetsi o ty REX prefixy, je otazkou proc to tak panove v AMD vymysleli, ale proste je to tak. Druha vec je, ze amd64 umi RIP relativni adresovani, ktere vetsinu realistickeho (tj. generovaneho) kodu na ELF platformach vyznamne zmensi. Na COFF systemech, coz jsou treba (a vlastne jenom) windows, je ten kod proste jenom bez jakehokoli uzitku vetsi.

Velikost dat: tady jde dost o system na kterem to bezi a jeho ABI. Pointer proste je vetsi (a vzhledem k tomu, ze snad neexistuje procesor, ktery vrchni byte neignoruje tak i zbytecne), to zcela evidentne zvetsuje zatez cache, coz je to misto na kterem stoji a pada vykon dnesnich (+- deset let) procesoru.

Rozsah datovych typu: u veci jako off_t a time_t je celkem uplne putna, jestli se aritmetika provadi jednou nebo ~3 instrukcemi, vykonostni rozdil je celke zanedbatelny, jednak kvuli superskalarnosti dnesnich procesoru, druhak proto, ze se to az tak casto nedeje. Predstava, ze time_t je proste ten architekturni int pod tim je celkem uplne mimo, zvlast proto, ze amd64 ABI je LP64, kde int je stejne 32 bitu. off_t ma 64 bitu dnes snad uz uplne vsude (alespon s -D_FILE_OFFSET_BIT­S=64).

Vec kterou si mnoho lidi celkem neuvedomuje, je ze mnohe mikroarchitektury jsou v long mode vyznamne pomalejsi, nez v normalni i386 PM. Problem je, ze pak jsou jine, kde je to presne naopak.

Zaver je, ze pokud o to cloveku vazne jde (a typicky fakt nejde), tak to stoji za to vyzkouset na konkretni aplikaci a konkretnim HW.

A jeste takovy dodatek k tomu je PCI bus mastering, ale to je magie celkem dlouhodobe, takze je otazkou jak moc ma cenu se o tom rozepisovat.

Kdyz jsme po vymene serveru nainstalovali 64bitovy CentOS misto 32bitoveho, k memu velkemu prekvapeni fungovalo temer vse hladce :) Jedinou vyjimkou, se kterou jsem stravil krusne casy, byl radius server. Prestoze konfiguracni soubor byl zkopirovany z 32bitoveho systemu, nefungoval a nefungoval. Nakonec kvuli nemu provozujeme jeden 32bitovy CentOS virtualizovany. Mozna je dnes situace jina, zatim jsem nenasel odvahu do toho znovu stourat :)

Když jsem před léty na svůj první 64-bitový HW (NB ASUS - konstrukčně hrozný šmejd, jak jsem později zjistil) nainstaloval 32-bitový Linux, tak se mi sekalo síťování - ztrácela se přerušení od síťovky. Po přeinstalování na 64-bitů vše OK (ale dnes si myslím, že to bylo zpraseným návrhem výrobce).
Nicméně udělali jsme další srovnání a zjistili jsme, že 64-bitový systém běží "hladšeji" a "plynuleji" než 32-bitový - připomíná to rozdíl mezi systémem na 32-bitovém Pentiu a Solarisem na SPARCu.
Pokud někdo používá počítač pouze na psaní/čtení/brou­sení, tak na 32/64 nezáleží, ale pokud má větší požadavky, tak je rozdíl cítit.
Pro zajímavost můj systém: NB MSI s AMD Tution64X2, původně 1MB RAM rozšířen na 2MB (když je tak levná), Gentoo64. Jsem vývojář SW, a běžně mám současně celý den spuštěný Firefox, Thunderbird, OOo, a vývojové prostředí i s testovaným systémem.

>42: Přesně tak! Vždyť 32bitových systémů je mraky (starší PC, alixy, malé servery...) a pro mnoho užití zcela dostačují a budou tu s námi ještě dlouho. Jak to bude s testováním???

ok, skuste si nechat rozbalit archivovany subor na 32 a 64 bit systeme .... aj preto pouzivam 64 bit ;)

autor o 64 bit systeme len pise, alebo ho aj niekedy aktivne nejaky cas pouzival ?? :-)

32bit OS nemuze efektivne vyuzit celych 4GB RAM

This behavior is due to "memory mapped IO reservations". Those reservations overlay the physical address space and mask out those physical addresses so that they cannot be used for working memory. This is independent of the OS running on the machine.

Pamatam si clanky - IBM PC AT-286, je zbytocne drahe. Na pracu plne postaci IBM PC XT.
Tento blog je o niecom podobnom.

[45] Obdivuji téměř "svatou" trpělivost s jakou pak Krčmář odpovídá na dotazy zvláště těch pánů, kteří se nejen že skrývají za přezdívku, bla bla..

ja tiez obdivujem takych panov, ktorym viac zalezi na "opravdovym jmenem" nez na tom co kto napisal ... ..a to akoze ked si napisem svoje ozajstne meno tak moje prispevky automaticky nadobudnu pravdivosti, serioznosti, ci vierohodnosti? smiešne; ze na tom v tejto dobe niekomu vobec zalezi nez nad obsahom prispevku ;) / tym neospravedlnujem zname excesy elvena aka stana hofereka na linuxovych forach, obzvlast linux.os, to je uz "iny" pripad ;)

[54]
Nesouhlasim, situace v IT sektoru se oproti vami popisovane dobe docela radikalne zmenila. Jsem si takrka jisty, ze obdobne diskuse se neobjevovaly 10 let po uvedeni 286 procesoru. Popravde, podle Wikipedie byl Intel 286 vyraben od roku 1982, Intel 386 od roku 1985 a jiz v roce 1989 tady byly 486ky. Porovnejte s nastupem 64b a je vam to snad jasny :-)

56: nu AMD vypousti amd64 v roce 2000, ale Intel se pridava az v roce 2004, je snad jasny, kdo je ta brzda :)

[53] precti si neco o PAE .. vyuzije i mnohem vic nez 4GB ... osobne ted na svem stroji vyuzivam 8GB.

Priznavam, ze take zustavam u 32bit .. a to dokonce i na serveru. Multimedialniho. 3x DVBT karta s MythTV jako nahravaci server. A print server. Duvod je jednoduchy - potrebuju aby to fungovalo. 64bit neni tak dobre odladeny jako 32bit.

Provedl jsem i test (Core2duo 2.66GHz, 4GB RAM) 32bit PAE verus 64bit (Suse11.1) .. prevod 3GB MPEG2 DVBT nahravky do 700MB xvid .. nevidel jsem prakticky rozdil v rychlosti enkodovani. To by byla jedina vec ktera by mne primela prejit na 64bit. Bohuzel, (s)prostym zkompilovanim pod 64bit nic moc nevylepsi, nekdo by musel provest optimalizaci.

Prechodem na 64 bitovy system jsem pri stejnem pouzivani na notebooku dostal teplotu procesoru dolu prumerne o 7-10 stupnu celsia. A to za to stoji, vetracek se spousti jen pri kompilaci ci zatizeni graficke karty...

Na větších serverech, kde provozuji mj. virtualizaci (VMware server) mám 64bitový CentOS a má to pochopitelně svůj důvod, je to prostě nejlepší volba. Na malých serverech 32 bitů, protože zatím pro nic jiného důvod není.
Na desktopu jednoznačně 32 bitové distribuce (SLED, OpenSUSE) - 64 bitů je pro tento účel jenom koledování si o naprosto zbytečné problémy (totéž platí i v případě stanic s Windows) - tedy pokud s počítači pracujete a ne si jen hrajete jako řada lidí v této a podobných diskusích.

no, existuje další i když jen fylozoficko-sociální důvod pro 64bitů... a to ten, že více uživatelů systému motivuje vývojáře. Těžko se vyvíjí třeba KDE 4.0 když je nikdo nepoužívá, ale KDE 4.3 už mají HODNĚ reportů od normálních uživatelů... což se počítá.

Používám 64bit na gentoo. Zřejmě kvůli tomu, že je to uplně jedno jestli to budu kompilovat pro 32 nebo 64. Rozdíly v tom nevidím, snad jen to postrkávání pokroku (((-:
W

Na 64-bit architekturu jsem nepřecházel, ale když jsem si na začátku roku 2008 koupil nový notebook, rovnou jsem 64-bit instaloval, protože jsem na to byl zvědavý. Je pravda, že v té době byly problémy s flashem a javou, které byly trochu nepříjemné, ale už je to pryč a jsem rád, že využívám všechno, co procesor umí :) Nemůžu říct, že by 64-bit byl lepší, než 32-bit, ale vidím to jako futureproof řešení (zvlášť při klesajících cenách pamětí). PAE sice detailně neznám, ale z dálky mi to připadá jako obezlička, jen aby se nemuselo přecházet (podobně jako třeba NAT).

Je pravda, ze na stejnem notebooku (Core Duo 2) jsou Windows 7 64bit NESROVNATELNE rychlejsi nez Visty 32bit. I Ubuntu 32bit se ve srovnani s nimi vlece jak snek (ikdyz je mnohem rychlejsi nez Visty).
Ja vim, Windows sem nepatri ...
Ale muj pristi linux uz bude jen 64bit, tenhle system uz vyzral (jadro i aplikace) a je jednoznacne budouctnost!

Core Duo 2 nic neni. Myslite Core 2 Duo - ale ten NENI plne 64-bitovy procesor. Dle meho arogantniho nazoru je 64-bit vice mene na obtiz. Cesta kterou volil Intel u svych Core2Duo je nejlepsi - 64 bitu jen tam, kde je skutecne potreba (nektere sbernice). Dlouha slova se hodi na matematickem "koprocesoru" a na videoprocesoru. Na normalnim procesoru s obecnym pouzitim dostacuje i 16-bit (dobre, tedy 32-bit a kdyz, tak PAE). Daleko lepsi volbou, ktera zrychluje a usnadnuje praci je vyuzit kremik v cipu na vice jader. howgh.

necetl jsem vsechny prispevky pozorne, ale nezaznel tady argument ze napriklad nasobeni 64bit*64bit udela 4x vic prace nez 32bit*32bit..

http://gmplib.org/32vs64.html

25% je "ale ne o moc"? 8-O

64bit aplikace jsou rychlejší. Alespoň benchmarks to říkají. Osobně už instaluju jenom x64. Ale pravda, že starší mašiny nechávám tak jak jsou. Z lenivosti. :)

mám na polovině pleček 32bit a na polovině 64bit a souhlasím s názorem, že je to u pr..... Chovají se naprosto stejně.

No ja pouzivam KVM a funguje vubec v 32bit, myslim ze ne.

Dale, vetsina distribuci pro x86 kompilu i386 kod, optimalizovany max pro pentium, pritom ne -march, ale -mtune nebo neco jeste mensiho, tedy kod bezi i na i368

Pokud to distributor prelozi pro x64, nejen ze kompilator jiz nepouziva zastarale instrukce, ale automaticky se predpoklada SSEx MMXx a jine veci a halvne, uz se koncne nevyuziva mat. koprocesor, ale misto toho se pouziva mnohem rychlejsi SSE
-mfpmath=sse ....

Takze 32bit uz je fakt prezitek, jo a PAE je bugove, sam Linus prohlasil, ze ho to nezajima a neprijme pro to jediny patch a vzkazuje, at si lidi na server poridi 64bit verzi, linux ma s PAE drobne prolemy uz nad 4GB, do 8GB je to pouzitelne a nad uz jsou zajimave problemy ....

Jo a co mapovani karet, ktere umi bezet jen v 1. 1GB ? ... pro 64bit to linux resi, pro PAE nikoliv a nikdy resit nebude, proc ? PAE jiz neni udrzovan a jak jsem rekl, linus uz pro nej neprijme jediny patch i kdyby byl sebeprevratny.

[69] Dobra, presvedcil jste mne. 64bit si dam na masiny, na kterych mi nezalezi. Kde ale potrebuju 1000% funkcionalitu, zustavam u 32bit. Btw .. jak je na tom pod 64bitem VMWare a v nem 32bit WXP? Jak je na tom pod 64bitem Wine a spousteni beznych 32bit win-aplikaci?

No já mám 64 a vpodstatě nevim proč :) Přišlo mi asi škoda dávat na 64bitovej procesor 32bitovej OS a tak nějak tiše doufám že některý věci běhaj rychlejc :)

[70] VMWare na 64bitovém systému provozujeme (a uvnitře běží kde co, i 32 bitové systémy) a není s tím problém.

Wine funguje, ale je potřeba mít v Linuxu 32bitové knihovny (ty ale člověk má tak jako tak – jinak je to celkem sebevražda (provozuje to třeba jeden Jardík a pořád mu něco nefunguje) – 64bitový systém s knihovnami 32 i 64 je dobrá volba).

Já bych tu otázku rozdělil na 2 skupiny:

1) málo zatížené - domácí využití na hry a multimedia, kancelářské stroje a podobně
2) vysoce zatížené - většinou profi aplikace typu DB a informační servery ve velých podnicích, CAD systémy, DTP studia, technické výpočty, ...

Úmyslně se vyhýbám slovům jako low end a high end, ono se to s tím využitím často moc nekreje. Paradoxně bych i hry zařadil mezi ony málo zatížené, protože vývojáři her z drtivé většiny do dnes "nepřišli" na to, že jsou 64bit stroje s více procesory a najít hru která by dokázala (smysluplně) využít více jader/nebo dokonce samostatných procesorů a ještě na 64b, tak to aby svíčkou pohledal... Takže skoro celý herní svět je odkázaný na hrubý výkon jednoho jádra (max. jako druhé jádro je grafika na GPU). Od toho se odvíjí celý domácí segment. Jakmile bude něco zajímavého co pod 32b nejede (nebo jede hodně špatně) a pod 64 výrazně lépe, velká část domácího sektoru na to přejde. To znamená hry a multimedia. Do té doby bude platit 32b prostš jen ze setrvačnosti uživatelů... Konec konců stejné je to jako s IPV4 a IPV6.

Kancelář ... na co v kanceláři 64b? Všechny aplikace jsou 32b, je to léty ověřená klasika, stále podporovaná a ještě dlouho bude. Admin je konzervativní tvor, nechce objevovat a řešit neznámé (teda on by často i chtěl ale nemá na to čas) a tak vsadí na jistotu.

Naproti tomu vysoce zatížené aplikace a stroje, většinou (ale ne vždy) profesionálního charakteru jako je reklamní a mediální grafika, CAD systémy, velké DB, technické a jiné výpočty... to žere enormně paměti, strojového času, velké nároky na přesnost výpočtu, ... a to je doménou 64b od začátku. Jenže to je zlomek trhu (byť velmi důležitý zlomek).

Takhle ty důvody vidím já.

[72] To je zajímavý. Já 32b knihovny nemám a všechno mi funguje na 100 %. Žádné chyby, žádné problémy.

takovy zacarovany kolotoc - nepotrebuji 64 bitu, nebot mam mensi pamet... Nebudu rozsirovat pamet, nebot mam jen 32 bitovy system ;-)

Ja pouzivam celkem velke objemy dat, tak bych vyrazne vetsi pamet vyuzil a tudiz bych potreboval 64bitovy system. Kdyz ale notebooky s vetsi pameti moc nepocitaji... ? :-(

Argumentovat pamětí... no nevím. 8bitové procesory obvykle umějí adresovat 64 KB paměti (16 bitů), 16bitové obvykle alespoň 1 MB (20 bitů, ale i 24, 32...), 32bitové 4 GB (32 bitů). Ale nějak mi uniká, proč je najednou nezbytné kvůli rozšíření adresové sběrnice roztahovat i datovou sběrnici a ještě ke všemu na dvojnásobek. Někomu asi jeblo a mám takový pocit, že tyhle nápady nevzešly z hlavy inženýra, ale nějakého marketingového ředitele, který o technice ví prd. Prostě "čím víc proužků, tím víc adidas".

Aaa bože, člověk napíše článek a pod článkem se začnou rozebírat kokotiny, jak jinak to nazvat. Prioritní je, že autor to vidí tak a tak, a je zbytečné mu to rozmlouvat. Rozebírat kolik můžeme adresovat paměti na té a té architektuře a tom a tom procesoru, to asi nemáte lidi nic jiného na práci že? Obvykle si článek přečtu, a bud s autorem souhlasím, nebo nesouhlasím, každopádně tam nebudu vytahovat podobné věci....potom je to tu OFF TOPIC

[76]Protože adresovat jenom jedním registrem je strašně praktické. Obzvlášť pokud se pro práci s adresami a celými čísly používají stejné registry.
A dvojnásobná šířka se použila, protože s mocninama dvojky se prostě dobře pracuje.
Když už se vymýšlí nová architektura, tak je dobré ji navrhnout tak, aby stačila na delší dobu. A v rámci zpětné kompatibility ji u AMD navrhli celkem pěkně. Buďme rádi za 64b. Aspoň nebudeme nějakou dobu muset vymýšlet hnusné hacky jako PAE.

[77] Když ty příspěvky ale srovnám s příspěvkem, rozebírajícím to, jak asi lidi nemají nic na práci, když mají na jejich sepisování čas, a mentorováním, jak správně číst články, protože to tak děláte vy (a zároveň to samotná existence vašeho příspěvku popírá), pořád to vychází o kategorii smysluplněji. ;-)

[78] 1) to není s tou praktičností zas tak žhavé (kdy kdo využije možnost indexovat celý 64 bitový adresový prostor jedním registrem?), 2) když už to za každou cenu někdo chce mít, dá se to vyřešit mnohem úsporněji (např. rozpůlením indexového registru). Stávající řešení je naprosto "neinženýrské" - nutnost zdvojnásobení počtu spojů, počtu klopných obvodů uvnitř procesoru atd. a to vše v podstatě úplně zbytečně.

celý tenhle článek dostává poněku zvláštní pachuť, kyž si člověk uvědomí, že napsání této úvahy vás stálo pravděpodobně více času a úsilí, než by vás stál onen přechod z 32 na 64 bitů. Vzhledem k tomuto působí argumenty typu o tom jak to neřešíte, že by jste zmigroval, ale 30 minut je moc práce poněduk zvláštně

Já si myslím, že 640 kB RAM musí stačit každému ....

[21] Matej K
Systém používající PAE je pomalejší, než bez PAE. Navíc umožní adresovat každé aplikaci opět jen 2-3GB paměti. Pouze aplikace napsané pro použití PAE jsou schopné využít více paměti v jednom procesu. Bohužel opět pomalu...

[22] Na x86 se typicky alignment neprovádí. ALE. 1) Některé nezarovnané operace jsou výrazně pomalejší, takže kompilátor při optimalizaci zarovná. Vložení NOP na vhodné místo tedy zvýší výkon, což je možná trochu neintuitivní. 2) Existují výjimky typu stránkování video RAM, kde při přístupu do dvou stránek zároveň může dojít k problému (vidíte jednu nebo druhou stránku, přístup vždy hodí page fault). 3) Pokud argument instrukce není zarovnaný, může dojít k porušení atomicity na víceprocesorových systémech.
http://blogs.msdn.com/oldnewthing/archive/2004/08/30/222631.aspx

>> technologii PAE, která jim umožní jejich paměť naadresovat i na 32bitovém systému.

Blbost. Ano, naadresujete fyzickou paměť třeba celou, ale ten program má jen 32bitové ukazatele, takže víc jak 4GB nenaadresuje (možná přes nějaké fígle, ve Windows je nějaká funkce, která dokáže pro proces alokovat kýbl paměti a pak se to další funkcí dá přepínat, aby se to vešlo do 32bit ukazatelů). A nejde jen o fyzickou paměť, ale i virtuální. Víte, jak je pohodlné zavolat mmap() či CreateFileMaping() na soubor a zacházet s ním jako s ukazatelem? Systém se pak už o vše postará za vás.

>> k tomu assembleru
Např. SSE2 instrukce jsou pořád stále stejně velké. Jen při použití "nových" registrů (xmm8-15) se zvětší o 1B.
V "normálních" instrukcí se většinou používají 32bit adresy a dochází k relativnímu adresování vzhledem k RIP (což je registr ukazující na instrukci za aktuální). Jediná instrukce, kde se dá použít 64bit adresa jako imm je "mov".
Berte taky v úvahu, že díky tomu, že všechny x86_64 procesory podporují SSE2, tak je mnohem lepší možnost optimalizace než pro x86, kde na nějaké 386 sse2 není a např. u debianu je to i386 balíčky prolezlý od shora dolů.

[58] tak jsem testoval mencoder prevod do xvid a v soucasne dobe (xvid 1.2.2) vychazi 64b verze rychlejsi o asi 10% nez 32b.

zrejme mate vice jader, pak pouziti -xvidencopts threads=2 zrychli prevod o dalsich asi 50% (threads mi nefungovali ve 32b verzi, teda nic to nehlasilo, ale zrychleni se nekonalo a mencoder zabiral jen 100%cpu)

takze dohromady 64b + threads je o 60% rychlejsi, nez 32b verze a to uz je poznat :)

(amd64 assembler je v xvid od verze 1.1.3)

[85] threads mam vypnute, na tom 32bit OS to spis zhorsi rychlost prevodu. Bezny zpusob je, ze si v avidemux pripravim JOBy (jsem tak trochu hifista na video, takze kazdou DVBT nahravku rucne oriznu a volim resolution a size aby vyslo pekne BPP). JOBy pak predhazuju na serveru avidemux2-cli s vypnutymi multithreads pres xargs tak, aby bezely max 3 prevody zaroven (kazdy si vezme jen jedno jadro cpu), aby na 4-cpu serveru zustalo jedno cpu na nahravani DVBT a ostatni sluzby. Multithreads (i kdyby fungovalo na 1000%) mi moc nepomuze, nejde mi o rychle xvidovani jednoho mpegu. Vzdy jich mam ve fronte 10-20. Vecer pripravim joby na desktopu a pak je na noc pustim na serveru, desktop pc vypnu a jdu spat.
Takze bez multithreads - mozna je to na AMD 64bit rychlejsi o 10% .. na intel Core2 quad/duo 45nm 64bit to bylo rychlejsi jen asi o 5% (holt je poznat ze to od AMD jen opraskli .. a intel byl vzdy mirne pomalejsi, jde jim vic o spolehlivost). Ja jedu cely zivot jen na intelu, hlavne kvuli spolehlivosti, a nehodlam to menit - je to moje volba. Mozna v poslednich letech to AMD dotahlo, ale znate to, kdyz ma clovek tech kompu kolem sebe vic, je dobre se drzet jedne platformy, v pripade potreby se to da ruzne prohazovat. Nebudu kvuli 5% vykonu navic menit 6 PC na AMD :-)

86: aky vyznam ma kopirovanie celeho vysielania dvbt na disk? a kde ta niekto ukecava na prechod na amd?

[87]:
1) nikde netvrdim, ze cele vysilani DVBT :-) obcas se ale stane ze se nahravaji 3-4 porady soucasne (mam osazene tri DVBT karty). 300GB disk je tak na 14-21 dnu nahravek .. Prevazne dokumenty z CT1/2, k tomu par starsich filmu, a kompletni serialy z Prima Cool (Futurama, Angel, BBT, etc) .. k tomu nahravam jeste par veci pro kamarady, protoze na tom nahravacim serveru s MythTV je to proste EASY (par kliknuti pres web odkudkoli na svete). Automat je to bajecny ( PowerSearch rulez! :-) ) - teda pokud je vporadku EPG. A zaroven ten stroj je i printserverem a fileserverem (3TB) s temi zpracovanymi zaznamy v avi (protoze v xvidu to zabere na disku cca 1/3 nez puvodni mpeg2). Kdokoli z rodiny se na cokoli muze kdykoli podivat (cca 5PC).

2) nevim ci to zaznelo i tu, ale obecne se "tvrdi" ze AMD je v 64bitu vykonnejsi. Tak asi tak. Ja na intelu C2D/C2Q 45nm opravdu nevidel oproti 32bit vyssi vykon v 64bitu nez tech 5% (pri xvidovani mpeg2 - coz je jedine, kde mne vykon zajima).