Dotaz: Jaky je rozdil mezi 32bit a 64bit OS? A co ty bity znamenaji

[polo23]

Ahoj, chtel bych se zeptat jaky je rozdil mezi 32b a 64b OS. Prosim nepiste odpovedi jako vykonove temer zadny atd. Me to zajima ciste teoreticky... Co si mam predstavit pod tema 64 bitama? Vim ze 64b OS umi adresovat vic jak 4GB RAM. Ale to je vsechno co vim...ale prece tech 64 bit se netyka jen adresovaci sbernice ne? Ze skoly si pamatuju ze CPU aspon zjednodusene je povazovano za 32bit pokud ma 32b scitacku a secte tak naraz napr 2 32bit cisla... Dale me napada ze tech 64 bit jeste muze byt velikost typu promennych (napr integer atd) ale to uz fakt jen hadam...

Diky za rady

Odpovědi

[Josef Kufner]

Opravdu to je jen šířka adresové sběrnice. Na x86 architektuře je integer stejně široký jako adresová sběrnice, takže těch 32/64 bitů znamená i šířku integeru. To je celé.

V praxi to znamená to, že jeden proces je schopný adresovat místo necelých 4GB nějakých necelých 16PB a že binárky jsou větší a zabírají víc místa v paměti.

[trekker.dk]

že binárky jsou větší a zabírají víc místa v paměti.

Přičemž pro obojí platí, že zanedbatelně.

[Andrej]

Je trojnásobek opravdu zanedbatelný?

Nejde vůbec o velikost samotných binárek. Instrukce na x86 (narozdíl například od MIPS64) nenarostou s přechodem na 64 bitů na dvojnásobek. (Dokonce bych tipoval, že nenarostou vůbec...) Nicméně faktem je, že Linux + KDE zabírá ihned po startu na 32-bitovém stroji cca 100 MB paměti, zatímco na 64-bitovém zabere (opět ihned po startu) přes 350 MB. Stejné distro, stejná paměť (2 GB), stejné balíčky, stejní démoni na pozadí.

[Michal Kubeček]

Je trojnásobek opravdu zanedbatelný?

Tvrdit, že je to trojnásobek, je asi stejně nesmyslné, jako kdybych já prohlásil, že jsou 64-bitové programy asi dvaapůlkrát rychlejší, protože mi to tak v jednom konkrétním testu vyšlo.

Nicméně faktem je, že Linux + KDE zabírá ihned po startu na 32-bitovém stroji cca 100 MB paměti, zatímco na 64-bitovém zabere (opět ihned po startu) přes 350 MB.

Pak tam bude rozdíl i v něčem jiném.

[Andrej]

Například v čem? Jde o jeden a ten samý stroj, na kterém byl 32-bitový a 64-bitový ArchLinux. Je to jednoduché: Kdo chce 64-bitový systém, potřebuje přinejmenším dvakrát víc paměti, než kolik používal u 32-bitového systému. To samozřejmě není žádný problém, protože paměť je dnes velmi levná. Nicméně je potřeba s tímto faktem počítat.

[Michal Kubeček]

Je to jednoduché: Kdo chce 64-bitový systém, potřebuje přinejmenším dvakrát víc paměti, než kolik používal u 32-bitového systému.

Ne, tak jednoduché to opravdu není. Váš výsledek odporuje mým zkušenostem, takže si to zkusím sám. Před chvílí jsem rozběhl automatickou instalaci dvou systémů podle stejného profilu, až doběhne, napíšu sem, jak to vychází mně. Mělo by to trvat asi 20-30 minut.

[Michal Kubeček]

U mne je to zhruba o polovinu. Naběhlý systém včetně KDM bez přihlášení 40/65, po přihlášení do KDE a spuštění jedné instance konsole 64/99, totéž plus firefox s jednou zobrazenou stránkou 100/158. Spotřebované místo na disku: 2785/2831. (Všechny hodnoty jsou v MB)

[Vojtěch Horký]

znamená i šířku integeru

Jenom poznámečku - neznamená to ale, že Céčkový int musí být na 64 bitové architektuře 8 bajtový.

[trekker.dk]

Co se CPU týče, mají 64bitové procesory kromě větší šířky slova nějaké univerzální registry (r8-r15) navíc. Plus u 64bitových CPU můžeš počítat s tím, že mají třeba SSE a SSE2 (tudíž můžeš udělat univerzální 64bitovou binárku s instrukcemi pro tyhle jednotky a bude to chodit na všech AMD64 - u x86 tohle neplatilo)

[polo23]

No a kdyz je procesor 64bitovy tak to neznamena ze je rychlejsi? Ze proste zpracuje v jednom taktu 2x tolik dat nez 32bitovy?

[Ondrej 'SanTiago' Zajicek]

V nekterych hodne specifickych pripadech tomu tak byt muze (pokud se kod vhodne naprogramuje), ale v tech samych pripadech se stejne spis pouzije MMX nebo SSE, kde to je jedno. Obecne tomu tak neni.

[Michal Kubeček]

Použití funkce memcpy() vám připadá jako "hodně specifický případ"? :-)

[Ondrej 'SanTiago' Zajicek]

memcpy() je hodne specificky pripad, ktery se akorat pouziva hodne casto. :–)

 

[Josef Kufner]

Otázkou je, co si představíš pod "2x takový objem dat". Sčítání a násobení trvá pořad stejně dlouho, jen ty čísla můžou být větší. Pokud budeš kopírovat pole intů, tak ti to zabere také stejně dlouho i když překopíruješ 2× tolik dat…

[trekker.dk]

tak ti to zabere také stejně dlouho i když překopíruješ 2× tolik dat…

Vzhledem k tomu, že int (C int) je na AMD64 32bitový - určitě?

[Josef Kufner]

Hmm, koukám, že je v tom větší zmatek než jsem si myslel

[Michal Kubeček]

Dat se překopíruje stejně (bavíme-li se o linuxovém gcc na AMD64) a s chytrým překladačem to může trvat poloviční dobu.

[pht]

No a kdyz je procesor 64bitovy tak to neznamena ze je rychlejsi?

V některých případech ano. Například sečtení dvou 64-bitových čísel. V dnešní době se takových čísel vyskytuje hodně.

[Andrej]

Striktně vzato, ve velmi specifickém případě (bitové operace na nějakém proudu dat (tj. například šifrování)) tomu tak může být. Ve skutečnosti ale rozdíl není moc velký.

Důvodem je fakt, že procesor nežije ve vzduchoprázdnu. Používá RAM a cache. Jejich propustnost je samozřejmě omezená. Z toho taky plyne, že v některých situacích (práce s obrovskými dynamickými strukturami se spoustou pointerů) bude 64-bitový systém naopak pomalejší. To není problém samotného procesoru, ale prostě vlastnost těch zařízení kolem něj.

[Michal Kubeček]

Striktně vzato, ve velmi specifickém případě (bitové operace na nějakém proudu dat (tj. například šifrování)) tomu tak může být.

Už jsem se tu na to ptal jednou (jen někoho jiného): označil byste memcpy() za "velmi specifický případ"?

[Andrej]

Podle toho, co to znamená memcpy(). Implementací takové funkce je spousta.

Například v nastavení Xine backendu je na výběr cca deset různých implementací dostupných pro x86. Tupá implementace bude nejspíš na 64 bitech rychlejší a možná tedy bude tím specifickým případem, nicméně vsadil bych se, že u chytřejší implementace už to bude záviset pouze na rychlostí paměti, nikoliv na délce slova procesoru.

[Michal Kubeček]

Vsadit se můžete, ale prohrajete. Trik je v tom, že máte-li dual channel, může 64-bitový proces jednou instrukcí načíst nebou uložit 128-bitové slovo. A builtin memcpy() v gcc verze 4 to opravdu využívá.

[Andrej]

To přece může 32-bitový procesor udělat taky, nebo snad ne? Pokud vím, některé implementace memcpy() dělají různé triky s MMX registry, které jsou taky 128-bitové. (Možná si to pletu s něčím kolem SSE, ale faktem zůstává, že 32-bitové procesory něco takového umí.)

[Michal Kubeček]

Nějaký háček v tom asi bude, protože když jsem to kdysi zkoušel testovat, memcpy() na nepříliš dlouhých blocích (tak, aby se vešly do cache) bylo na počítači s dual channel s -m64 přibližně dvakrát rychlejší než s -m32. Ale přesný důvod neznám.

[trekker.dk]

Trochu problém je v tom, že ne všechny distribuce pro 32bitové procesory používají ve výchozích verzích balíčků MMX instrukce. Třeba Debian, pokud vím, překládá balíky až na výjimky pro instrukční sadu 486.

[pht]

Jakoby snad někdo tuhle architekturu ještě měl.

[trekker.dk]

Nojo, holt některá distra nehodí uživatele starších strojů přes palubu jen tak bez výčitek. A na menší router je procesor typu Pentium (který kromě posledních verzí MMX také nemá) naprosto dostačující.

[Andrej]

Na malý router bych spíš viděl něco se spotřebou pod 20W. (ARM? Nějaký malý MIPS?)

Tady nejde o házení uživatelů přes palubu. ArchLinux prostě nikdy ve své (krátké) historii staré Pentium nepodporoval. Zrovna u Debianu, který má balíčky pro spoustu architektur, by bylo řešení velice jednoduché. Stačilo by prostě přidat několik verzí x86 jako samostatné architektury. Mainstream by se měl dnes kompilovat s podporou alespoň SSE2 a výše. Netuším, proč to tak není.

Kdysi dávno existoval projekt, který vytvářel kompletní repository ArchLinuxu pro i586. (Normální balíčky se odjakživa kompilovaly pro Pentium Pro.) Nevím, jak to nakonec dopadlo a zda o to byl zájem. Nejspíš to ovšem zaniklo. Problém vidím hlavně v tom, že motherboardy pro Pentium měly (na desktopu) většinou podporu pro 64 MB nebo 256 MB paměti, víc ne. To už prostě na dnešní distro nestačí. Možná na ten router ano, ale pak není od věci zvolit jiné distro. Pokusy o portování ArchLinuxu na SPARC a MIPS taky nakonec nějak umřely. Jediný dnes funkční port na menšinovou architekturu je PowerPC.

Off-topic poznámka: Kdysi mě zajímalo, proč se ArchLinux kompiloval zrovna Pentium Pro, proč ne Pentium II. Pak jsem to zjistil. Zvolením Pentia II se ztratí podpora pro všechny procesory typu VIA 686, IBM 686 a jim podobné. Pentium II už mělo mnohem lepší FPU a například Ghostscript, který něco takového používá, pak například na 686 VIA okamžitě odletí kvůli kumulaci chyb ve výpočtu. (Podle hlášek se tam vypočte záporná velikost nějakého grafického objektu.)

[trekker.dk]

Na malý router bych spíš viděl něco se spotřebou pod 20W. (ARM? Nějaký malý MIPS?)

Že ty bys to tak viděl nemá žádnou spojitost s tím, co komu kde běží.

Stačilo by prostě přidat několik verzí x86 jako samostatné architektury.

Jo, jako by už teď těch architektur neměli na starosti dost.

Pokusy o portování ArchLinuxu na SPARC a MIPS taky nakonec nějak umřely. Jediný dnes funkční port na menšinovou architekturu je PowerPC.

Tak vidíš. ArchLinux umí dvě architektury (a dovedu si představit, jak ten port na PowerPC asi vypadá), ale přesto jiným radíš, aby jich podporovali víc.

[pht]

Při vší úctě k práci správců balíčků, dělat 486 z pentia 4 a vyhazovat tak do koše 15 nebo kolik let pokroku je trochu dost od věci.

[Andrej]

Že ty bys to tak viděl nemá žádnou spojitost s tím, co komu kde běží.

A co jako? Takhle to vypadá, když někdo nepochopí pointu. Pointa je v tom, že omezovat podporu procesorů kvůli nějakému dřevnímu a zastaralému routeru je prostě holý nesmysl. Pokud někomu někde běží router na Pentiu, měl by si prostě zvolit jiné distro než desktopové. Prostě proto, že distro pro dnešní desktopy už není pro Pentium vhodné.

Jo, jako by už teď těch architektur neměli na starosti dost.

Další nesmysl. O jaké starosti je tady řeč? Podporou několika x86 architektur by ztratili pouze počítačový čas pro kompilaci s různými flagy, nic víc. A počítačový čas je dnes velmi levný.

Tak vidíš. ArchLinux umí dvě architektury (a dovedu si představit, jak ten port na PowerPC asi vypadá), ale přesto jiným radíš, aby jich podporovali víc.

Je snad na tom portu pro PowerPC něco špatně? Rád se dozvím o nějaké osobní zkušenosti, ať už pozitivní či negativní. ArchLinux je pořád ještě „malé“ distro, nemá tedy dost prostředků a dost vývojářů na nějaké rozsáhlé portování. Nikomu nic neradím, pouze nachápu, jak může Debian, který podporuje hned několik téměř vyhynulých architektur, dodávat balíčky jen pro jednu verzi x86. To je zkrátka absurdní.

Jak už jsem tu psal, ArchLinux si pro každý stroj kompiluju, binární balíčky používám pouze při první instalaci, k ničemu jinému. Právě proto bych ocenil, kdyby existovala distribuce, u které by člověk něco takového nemusel řešit. Balíčkovací manažer by prostě věděl, který je to procesor a v jaké repository pro něj hledat balíčky. Nicméně zdá se mi, že taková distribuce neexistuje.

[trekker.dk]

Pokud někomu někde běží router na Pentiu, měl by si prostě zvolit jiné distro než desktopové.

Odroluj si, prosím, o pár příspěvků výš a podívej se, o kterém distru se tu bavíme. Charakterizovat Debian jako desktopové distro, to je hodně velkej ústřel. A to nebudu zmiňovat různé tlusté klienty, kde je staré Pentium naprosto dostačující hardware.

O jaké starosti je tady řeč? Podporou několika x86 architektur by ztratili pouze počítačový čas pro kompilaci s různými flagy, nic víc.

Za předpokladu dokonalých programátorů a tvůrců překladačů ano. Jinak samozřejmě ne, rozhodně se můžou objevit chyby, které postihnou jenom jednu variantu překladu. Navíc nevím jak v Archu, ale v Debianu nefunguje "tady jsme to přeložili a hurá, vydá se to" - když je zavedena nějaká architektura, tak se před vydáním musí otestovat, jestli všechno funguje. To prostě je práce navíc, kterou někdo musí udělat.

Nikomu nic neradím, pouze nachápu, jak může Debian, který podporuje hned několik téměř vyhynulých architektur, dodávat balíčky jen pro jednu verzi x86. To je zkrátka absurdní.

Tak jim to běž říct. A že ty nějakou architekturu nepoužíváš a x86 je pro tebe začátek a konec světa, ještě neznamená, že ostatní jsou na tom stejně.

Balíčkovací manažer by prostě věděl, který je to procesor a v jaké repository pro něj hledat balíčky. Nicméně zdá se mi, že taková distribuce neexistuje.

Ano, kombinaci Gentoo a Debianu bych uvítal taky, ale zrealizovat něco takového by bylo velice náročné - hlavně finančně.

[Andrej]

Tak jim to běž říct. A že ty nějakou architekturu nepoužíváš a x86 je pro tebe začátek a konec světa, ještě neznamená, že ostatní jsou na tom stejně.

Vtipálku! Podle sebe soudíš ostatní?

Jedna otázka je, kolik lidí používá jako svůj hlavní desktop něco jiného než x86. Velmi málo. Jiná otázka ovšem je, s čím se kdo má možnost setkat. Někdo třeba kompiluje každý svůj program taktéž pro SPARC64, aby ho mohl vyzkoušet v big-endian prostředí. (Píšu si u sebe plus.) Někdo zase dělal ve škole kernel pro MIPS. (Píšu si u sebe další plus.) A někdo zase má přístup třeba k PowerPC a tu a tam vidí nějaký drobný strojek s ARM. Takže se začátkem a koncem světa jsi trochu přestřelil.

Rád věřím, že napsat --march=pentium-m nebo --march=prescott do nějakého konfiguračního souboru je fakt šíleně těžká práce... Hlavně když se pak v jednom ze 100 balíčků kvůli tomu vyskytne nějaká chyba, to je pak hotové neštěstí! Ale teď vážně. Kdyby ta podpora pro několik různých verzí 32-bitových a 64-bitových Intelů a AMD v nějaké distribuci existovala, a to v binární podobě, abych nemusel nic kompilovat, velmi rychle bych na takovou distribuci přešel. I kdyby se to jmenovalo třeba Debian ultra-hyper-experimental.

[trekker.dk]

Jedna otázka je, kolik lidí používá jako svůj hlavní desktop něco jiného než x86. Velmi málo. Jiná otázka ovšem je, s čím se kdo má možnost setkat.

Spousta otázek, žádná relevantní. Klíčová otázka zde je: odroloval sis o pár příspěvků výše, aby zjistil, že se nebavíme o desktopovém distru, ale o Debianu, u kterého se primárně předpokládá nasazení na servery (i když sám za sebe můžu říct, že na desktop se hodí taky, ale asi budu v menšině)

Kdyby ta podpora pro několik různých verzí 32-bitových a 64-bitových Intelů a AMD v nějaké distribuci existovala, a to v binární podobě, abych nemusel nic kompilovat, velmi rychle bych na takovou distribuci přešel.

Můžeš takovou vytvořit. Jestli říkáš, že udělat několik větví pro varianty x86 a amd64 není nic těžké, určitě nebude udělat další fork Debianu - zdrojové balíčky pro vytváření těch binárních jsou k dispozici, stačí jenom udělat ten konfigurační soubor.

[Ondrej 'SanTiago' Zajicek]

> Mainstream by se měl dnes kompilovat s podporou alespoň SSE2 a výše. Netuším, proč to tak není.

Ono tam, kde to je dulezite, je casto runtime detekce procesoru a dynamicka volba konkretniho kodu. Takze i v tom Debianu, obecne kompilovaneho pro 486, se pak pouzije konkretni implementace treba vyuzivajici SSE2.

[petr_p]

Což zas potěší lidí, co si koupili stroj s NX a rádi by si ho užili.

[trekker.dk]

Jádro je jedna z binárek, která má více variant. Předpokládám (ale neověřoval jsem), že ve variantě -686 bude NX zapnuté.

[petr_p]

Ono tam, kde to je dulezite, je casto runtime detekce procesoru a dynamicka volba konkretniho kodu.

Tohle je problém aplikací. Ne jádra.

[trekker.dk]

Reagoval jsem na tvoje NX. (Přičemž předpokládám, že máš na mysli NoeXecute bit.)

[petr_p]

Vždyť jo. V ELFu je sekce, která popisuje požadovaná práva pro jednotlivé sekce binárky. Jádro pak při execu tyto informace použije, aby zakázalo provádění kódu od jinud než z textu, zakáže zápis do textu apod. Takže když pustíte aplikaci, která si přepisuje adresy funkcí přímo ve stránkách textu, tak pokud jste příslušně nezměnili elfová metadata (= efektivně jste nevypnuli ochranu), tak aplikace zemře na SEGFAULT. V Gentoo to je krásně vidět, když se po instalaci ošklivých věcí dodatečně přepisují pax hlavičky, aby aplikace kvůli NX nepadala na hubu. Jinak řečeno dynamická rekompilace je s NX neslučitelná.

[Ondrej 'SanTiago' Zajicek]

> Na malý router bych spíš viděl něco se spotřebou pod 20W.

Jsou x86 kompatibilni routery se spotrebou okolo 2 W (platforma ALIX postavena na procesoru AMD Geode).

[Andrej]

To je jeden z mnoha důvodů, proč si ArchLinux pro každý stroj kompiluju.

[Michal Kubeček]

Tohle nebude ten případ, ten test jsem překládal s -march=k8

[pht]

Zapomínáte na "velmi specifický případ" atomických operací nad 64-bit čísly, kterých je hodně a zejména ve vícejaderném systému to může být dost poznat.

[Peter Fodrek]

to nie je take jasne

pri 32 bit cislach je rychlost rovnaka

pri 64 bit cislach zaberie

A)scitanie a odcitanie

2x tolko casu na 32 bit

na naobeni a deleni je to 6x tolko casu, ale FPU ma uz davno viac nez  64 bit, takze tram sa rozdiel nepociti...

 

[otasomil]

Nejvetsi rozdil je v mnozstvi pameti kterou lze adresovat. Samozrejme pokud na 64 bit stroji bezi 64 bit system.

Nechci delat flame, ale netyka se omezeni RAM na 3 GB jen 32bit windows ?

Na jednom PC jsem testoval Slax a dle vypisu free byly vyuzity skoro cely 4 GB, df vypsal rozvrzeni pameti na dve casti (zhruba napul) a to unionfs a tmpfs.

Rychlost behu 32 bit windows na 64bit CPU je takrka stejna jako 64bit windows na tom stejnem hw (win xp).

V Linuxu (Ubuntu 9.04) je to tez srovnatelne.

V extremnich vypocetnich pripadech to snad bude znatelne. Pro bezneho uzivatele patrne nikoliv

Nicmene RAM v radu desitek GB je uz hodne rozsahle pole kde se vyrazne projevuji kapacity mezi spoji na DPS, indukcnost a podobne zakladni fyzikalni jevy ktere omezuji prenosovou rychlost resp rychlost prebehu z log nuly do jednicky. Mozna jednou budou pametove moduly se seriovym rozhranim a tento problem se tak podari trochu potlacit. Tedy neco jako SATA u HDD - je tam pouzit seriovy prenos dat a presto je rychlost vyssi nez u PATA.

Zkratka zadny radikalni rozdil jako je mezi uvedenym prikladem SATA a PATA HDD necekejte.

[pavel]

3GB RAM je omezení jen pro Windows XP Home. Windows Servery některých řad umožňují pomocí PAE (umí to i Unixy/Linuxy) adresovat na 32bitech i více než 4GB paměti. Na rootu je o tom myslím článek.

[jam001]

Avsak stale ostava limit 4GB na proces ak sa nemylim, takze system dokaze spracovat viac ale jedna aplikacia nie.

[JMP]

pokud umi 32b linux dat na jeden proces max. 4 GB RAM, tak je na tom lip nez 32b windows, protoze ty daji na userspace normalne max. 2 GB a s prepinacem to jde zvednout na 3 GB

a jestli se nepletu, tak u  32b windows XP se MS na rozbehani PAE nakonec vykaslal...

nekdo linuxu znaly si muze projit toto: msdn.microsoft.com/en-us/library/aa366778%28VS.85%29.aspx a porovnavat, jak na tom byl a je linux ve vztahu k windows za poslednich deset let (ja na to znalosti nemam)

[trekker.dk]

a jestli se nepletu, tak u 32b windows XP se MS na rozbehani PAE nakonec vykaslal...

Jestli se nepletu, tak se pleteš.

[JMP]

hmm, oni rikaji "design change" (support.microsoft.com/) a ja uz jsem napsal, jak to vidim (kdyz jsem v praci dostal stroj s Win XP SP3 a 8GB RAM, tak at bylo PAE zapnute nebo ne, tak to videlo jen 3.2 GB RAM)

[trekker.dk]

Nevim, co znamená, že "to vidělo", nicméně i MS tvrdí, že PAE na Windows XP funguje

[pht]

PAE je v XP zapnuto pouze kvůli NX bitu (bezpečnost), ale veškeré rozhraní k systému tento fakt maskuje kvůli zpětné kompatibilitě. Takže 4 giga, tečka.

[trekker.dk]

Četl jsi ten odkaz?

Rozšíření fyzické paměti (PAE) X86 umožňuje softwaru se sadou rozhraní API AWE (Address Windowing Extensions) v počítači s procesorem Intel Pentium Pro či vyšším a více než 4 gigabajty (GB) fyzické paměti mapovat více fyzické paměti na virtuální adresní prostor aplikací.

Rozšíření fyzické paměti (PAE) X86 přináší výhody i aplikacím, které nevyužívají sadu rozhraní API AWE, protože operační systém využívá větší fyzickou paměť, která snižuje potřebu stránkování a tedy zvyšuje výkon. Rozšíření také přináší výhody konsolidačním serverům, které jsou hostiteli více aplikací.

[Josef Kufner]

Tož to se nevylučuje. Nikde není řečeno, že když se to zapne, tak se to musí používat.

[Petr Šobáň]

Mám visty basic (32b) na hry a měl jsem v PC 8G RAM a visty viděly pouze 3G a nějaké drobné. Takže o PAE mám pochybnosti a myslím že to vůbec windows neumí použít, možná po nějaké upravě registrů.

Linux (64b) viděl bez problémů vše.

Jinak na NB mám 4G a v PC taky 4G, těch 8G (4G+4G) jsem skoušel než ty 4G dám do nového MB, a zjistil jsem že pro mě je 8G zbytečnost (na desktopu).

[Josef Kufner]

Vždyť to říkám...

[pht]

Je dost jedno co se píše tam či támhle (navíc v citované pasáži není zmínka o tom, že XP umí víc než 4 G), protože já mluvím o tom, jak se to reálně chová.

[pht]

Home a Pro. Každopádně i sebePAEvatější systém dá jednomu procesu max. 4G.

[trekker.dk]

Nicmene RAM v radu desitek GB je uz hodne rozsahle pole kde se vyrazne projevuji kapacity mezi spoji na DPS

Hezké, ale s režimem adresování to moc společného nemá A dát dohromady 16GB jde dneska i na lepší desktopové desce. (Na serverové 32 a taky to nebude stát moc)

[Bilbo]

No, jenze za rozumnou cenu jsou jen 2GB moduly a typicky tam jdou nacpat 4 kousky, tedy 8 GB. 4 GB moduly (at uz DDR2 nebo DDR3), ze kterych by se dalo sestavit 16 GB, uz jsou pekelne drahe (cca 4-5 nasobek 2 GB modulu)

[Sten]

Pokud se bavíme obecně o 32bitových a 64bitových systémech, tak rozdíl je jen a pouze ve velikosti procesorových registrů, což jsou malinké paměti na jedno číslo, pomocí kterých se provádí veškeré výpočty. Většinou velikost registrů omezuje i velikost použitelné paměti, ale nemusí to tak být vždy (viz např. s PAE u x86-32).

Pokud bychom se bavili o x86-32 a x86-64, tedy o 32bitových a 64bitových systémech v IBM PC, tak tam je těch odlišností více. 32bitové aplikace nemohou využívat více než 3 GiB RAM (mohou adresovat až 4 GiB RAM, ale 1 GiB z toho si zabírá jádro pro vlastní potřebu - a to u Windows i Linuxu). Celý systém potom bez PAE neumí využívat více než 4 GiB RAM (3,5 GiB u Windows XP) a neumí NX bit ochranu (PAE je úprava adresace paměti, aby šlo použít až 36 bitů). x86-64 má kromě více adresovatelné paměti také dvakrát tolik registrů, pokročilejší matematické instrukce SSE3 a relativní pozicování ukazatelů, což značně zrychluje běh programů (obzvlášť to poslední se v Linuxu dost projevuje). Navíc přidává NX bit, který slouží k ochraně systému před využíváním nejčastějších bezpečnostních děr v aplikacích. Na druhou stranu používání 64bitových registrů znamená větší nároky na paměť, což je také důvod, proč se 64bitové systémy nepoužívaly od počátku (paměť byla příliš drahá).

[Michal Kubeček]

Na druhou stranu používání 64bitových registrů znamená větší nároky na paměť, což je také důvod, proč se 64bitové systémy nepoužívaly od počátku (paměť byla příliš drahá).

To není moc šťastně řečeno. Používání 64-bitových registrů neznamená větší nároky na paměť, větší nároky na paměť jsou způsobeny používáním 64-bitových datových typů místo 32-bitových, k čemuž vás ale nikdo nenutí, pokud je nepotřebujete. Co se týká historie, 64-bitové operační systémy se používaly už dávno, v podstatě jakmile se objevily 64-bitové procesory. Podobně to bylo i na PC - 64-bitové linuxové distribuce se začaly objevovat a používat velmi krátce poté, co se na trhu objevily první procesory s architekturou AMD64. Jenže holt platí, že co neposvětí Microsoft, to oficiálně neexistuje, takže spousta lidí (bohužel včetně "odborných" novinářů) se zcela nesmyslně tváří, jako by 64-bitové systémy byly nějaká horká novinka poslední doby.

[miho]

Ten thread je označený jako vyřešený ale řekl bych, že tady je více údajů, které tazatele zmatou nebo dokonce přivedou na zcestí :)

n-bitovost nemá nic společného s šířkou adresové sběrnice. To by pak, pokud se podíváme do historie) osmibity adresovaly jen 256 bajtů paměti nebo v současnosti x86 nemohly adresovat 36bitů a naopak současné x64 procesory zase neumí adresovat plnými 64bity virtuálně natož fyzickou paměť

n-bitovost také né vždy souvisí s velikosti typu int v jazyku C. Závisí to na zvoleném datovém modelu viz http://en.wikipedia.org/wiki/64-bit#Specific_data_models na x64 se používá buďto LP64 nebo LLP64,  ve skutečnosti je 64bit int na 64bit procesoru je opravdovou raritou.

velikost kódu - instrukce x64 jsou rozšířením x86, pokud se využívá 64bit registry nebo dodatečné registry tak instrukce narostou o jednobajtový prefix. V praxi je obvykle 64bit binárka o nejakých 10 % větší i když by mohl abýt za určitých okolností 

velikost dat - narostou jen ukazatele na dvojnásobnou velikost. Násrust proměnných typu size_t se dá obvykle zanedbat. 

 

SSE3 i SSE4 jsou použitelné i na x86.

Win XP (od SP2) nejen že PAE podporuje ale i implicitně zapíná u všech počítačů, které umí NX bit viz http://en.wikipedia.org/wiki/Physical_Address_Extension#Microsoft_Windows

rozdíl ve velikosti registrů - to také neni tak zcela pravda pokud bychom chtěli být exaktní. MMX registry jsou 64bit, SSE 128bit, FP typicky 80bit... n-bitovost ani neznamená, že general purpose registry mají n bitů páč třeba osmibitový Zilog Z80 měl registry 16bit HL a BC, které mají k pojmu general purpose hodně blízko.

 

Takže jaká je vlastně odpověď na tazatelův dotaz? Taková, že odpověď rozhodně není triviální jak by se mohlo na první pohled dát :)

 

[trekker.dk]

Ten thread je označený jako vyřešený ale řekl bych, že tady je více údajů, které tazatele zmatou nebo dokonce přivedou na zcestí

A proto sem nějaké přidáš a tam kde chyba nebyla, pro jistotu odpověď zopakuješ... (chtělo to přečíst celou diskuzi, nejenom první dva příspěvky)

n-bitovost také né vždy souvisí s velikosti typu int v jazyku C

#9

velikost dat - narostou jen ukazatele na dvojnásobnou velikost. Násrust proměnných typu size_t se dá obvykle zanedbat.

#29 a celé vlákno pod tím

SSE3 i SSE4 jsou použitelné i na x86.

Univerzálně použitelné? Tzn. udělám jednu binárku používající SSE4 a ta půjde spustit na všech x86 procesorech? (omezím se na ty, na kterých běží Linux, tj. od 80386 výše) To asi ne, že ne...

n-bitovost ani neznamená, že general purpose registry mají n bitů páč třeba osmibitový Zilog Z80 měl registry 16bit HL a BC, které mají k pojmu general purpose hodně blízko.

Jedna výjimka a ještě ne úplná, protože "hodně blízko" a "je to general purpose registr" jsou dvě různé věci. A jestli velikost univerzální registru není ukazatelem x-bitovosti procesoru, tak co teda je?

Takže jaká je vlastně odpověď na tazatelův dotaz? Taková, že odpověď rozhodně není triviální jak by se mohlo na první pohled dát

Zvlášť když každý čtvrtý příspěvek celou diskuzi zmate ještě víc, než byla.

[VM]

Ten thread je označený jako vyřešený ale řekl bych, že tady je více údajů, které tazatele zmatou nebo dokonce přivedou na zcestí

Ono neškodí shrnout argumenty, a tohle vlastně popisuje, jak moc zamotané to je.

n-bitovost ani neznamená, že general purpose registry mají n bitů páč třeba osmibitový Zilog Z80 měl registry 16bit HL a BC, které mají k pojmu general purpose hodně blízko.

Jedna výjimka a ještě ne úplná, protože "hodně blízko" a "je to general purpose registr" jsou dvě různé věci. A jestli velikost univerzální registru není ukazatelem x-bitovosti procesoru, tak co teda je?

On ten tzv. 8bitový Z80 měl 16bitové registry skoro všechny, viz. en.wikipedia.org/wiki/Z80#Programming_model_and_register_set . 8bitový byl jen akumulátor a flags. Některé z těch 16bitových registrů fungovaly jako páry 8bitových (BC, DE, HL, ale např. instrukce pro cykly používaly všech 16 bitů, a podobně fungují registry v x86). Některé byly jen 16bitové - IX,IY,SP,PC. Takže to jediné, čím se pro programátora jevil Z80 8bitový, byl 8bitový akumulátor, a některé aritmeticko-logické operace tím pádem byly jen 8bitové (ale jiné ne, např. sčítání a odčítání fungovalo i na 16bitových registrech HL, IX a IY jedinou instrukcí). A například na zásobník se ukládaly jen 16bitové registry, 8bitový tam ani uložit nešlo.

 

[Ondrej 'SanTiago' Zajicek]

> velikost dat - narostou jen ukazatele na dvojnásobnou velikost. Násrust proměnných typu size_t se dá obvykle zanedbat.

Struktury pak jeste narostou kvuli alignmentu. Tedy pokud mas treba ve strukture na stridacku integery a pointery, pak pointery se zvetsi na 8 B, ale musi byt alignovane a tak za kazdym 4B integerem bude jeste 4B mezera.

[trekker.dk]

Existuje nějaká situace, kdy to tak opravdu musí být a nejde ty integery jednoduše přeskládat?

[Ash]

Pokud ta struktura popisuje třeba nějaký fyzicky existující objekt (hlavička paketu třeba) tak to nejde přeskádat.

[Michal Kubeček]

V takových případech je ale většinou naopak potřeba, aby ta struktura vypadala na různých platformách stejně.

[Ash]

Ano, co nejde přeházet, je dobré zarovnat.

[Michal Kubeček]

Chtěl jsem hlavně upozornit, že pro diskusi o datových strukturách, které zaberou na 64-bitovém sytému víc paměti než na 32-bitovém, není hlavička paketu příliš vhodný příklad.

[Ash]

Máte pravdu, cílem člověka který na takovýto problém narazí je takovou strukturu co nejrychleji zarovnat, čímž ve výsledku dochází k rovnosti obou architektur. Ale odpovídal jsem na dotaz ve vlákně které se týkalo přehazování, konkrétně "kdy nejde struktura přeházet", což se týká případu, kdy chci rovnosti architektur dosáhnout, nebo třeba uspořit místo. Pokud by mi byla rovnost šumák, nemusím nic přehazovat ani zarovnávat a spokojím se s konstatováním, že tato struktura je na 64bitu větší.

Možná byste chtěl nějaký příklad kdy struktura NUTNĚ zabere víc místa a nejde s tím nic dělat (jen říkat jak je ten 64bit nenažranej). Takový příklad mne nenapadá, protože asi neexistuje, vyjma datových struktur které prostě obsahují stejně se jmenující primitiva, která jsou na různých platformách různě velká (jako int apod.).

[Ash]

Nicméně i v praxi se člověk setká s nějakými nepřenostnými fyzickými strukturami (daty) mezi platformami, které by sice měly být (bylo by hezké kdyby byly) přenosné, ale nejsou (např. rrd databáze), která jsou popisována různě velkými strukturami, a žádné přehazování nebo zarovnávání nepřipadá v úvahu, protože to autor nechce. Takže možná místo toho paketu dám rrd databázi. Lze namítnout že by to autor mohl přeházet či zarovnat, ale asi k tomu bude výkonnostní důvod to nedělat, takže ve finále ta struktura zabírá větší místo. Ale je to dáno vůlí člověka který se tak rozhodl, ne "že by to nešlo".

[Ondrej 'SanTiago' Zajicek]

Takova hlavicka paketu obvykle nebude obsahovat pointery.

[Ash]

Já jsem taky o pointrech nic neříkal. Pro více informací vizte Wikipedia: Data structure alignment

[Ondrej 'SanTiago' Zajicek]

Obvykle to jde jednoduse preskladat. Ale musi se to udelat rovnou v kodu, protoze je zaruceno (akorat si ted nejsem jist, zda primo standardem C, nebo nejakou specifikaci binarniho rozhrani), ze se ukladaji v tom poradi, v kterem jsou v kodu.

A programatori maji radsi polozky ve strukture usporadane podle logickych souvislosti, nez podle velikosti typu.