Názory k článku
32 bitů + 64 bitů = to nejlepší z obou světů v x32 ABI

Ukazatele nejsou 2x větší nebo ano? Ve škole říkaly, že logicky ano ale prakticky se používají menší.

Když tak opravte :).

Ukazatele jsou buď absolutní (64 bit) nebo relativní (menší), podle toho jak daleko se skáče.

alebo 40 bitov fyzickej a 48 bitov virtualnej pamate. zalezi od hardveru.

Tohle je jenom hardwarový detail, absolutní ukazatele v aplikacích jsou vždy 64bitové.

isteze

a není náhodou adresování paměti věc operačního systému ? nedostává náhodou ta vaše "aplikace" vždy relativní adresu vůči stránce/segmentu operační paměti spravované OS ?

Ne tak úplně. Operační systém říká hardwaru, jak má mapovat jednotlivé stránky aplikace na fyzické stránky v RAM (není to segmentové mapování, ale stránkové). Ten hardware ale v současnosti umí mapovat jenom zmíněných 48 bitů ze 64.

To jo, ale do hornich 16ti bitu toho pointeru si nemuzes dat co chces. Abych parafrazoval jeden slavny citat: "172 TB of RAM must be enough for every application".

Este nejaky alternativny nazor: http://blog.flameeyes.eu/2012/06/last-few-notes-about-x32

Jinak mam pocit, ze dany pan k tomu opravdu ma co rict (vyvojar Gentoo, ktery mj. provozuje tinderbox). Na toto tema v posledni dobe napsal vcelku dost, ale je to velmi informativni cteni http://blog.flameeyes.eu/tag/x32 . Zvlast se mi libi nazor, ze prijit x32 pred deviti lety, byla by to uzasna technologie, ktere by nic nebranilo se ujmout; nicmene v dnesni dobe to je jiz vlastne neprakticke.

Jsem úplně stejného názoru. Myslím si, že je to úplně k ničemu, jen to zabírá čas, který by se dal využít lépe. Ale když si chtějí udělat novou x86 architekturu, ať si ji udělají.

A co věci šířené pouze binárně, třeba takový Flash? Nemám ho rád, ale přeci jen má stále v prohlížeči svůj význam. Z toho by koukalo zas drbání levou nohou za pravým uchem v podobě používání 32b či 64b firefoxu podle verze pluginu, tedy zase ten multilib, bez kterého se už dnes v čistě 64b systému obejdu?

Pluginy ve Firefoxu stejně kvůli stabilitě běží v odděleném procesu, takže je to jedno.

navrhujem vytvorit dalsie ABI - x32PAE - v ktorom by bolo mozne spustit aplikacie pre 32bit PAE v 64 bitovom mode...

PAE je věc jádra, nikoliv aplikací

bol to vtip, ale mas pravdu, PAE je vec jadra. Tak teda opravujem:

Navrhujem vytvorit x32PAE kernel ABI (kABI) aby kernel moduly v mode 32bit PAE mohli bezat pod 64bitovym kernelom...

(hadam je to stale vtip)

Vis co je PAE? ze OS muze pouzit vic jak 4GB pameti, ale omezeni 4GB aplikace stale ma (to se neda zmenit).

toto poznam... a mimochodom bol to pokus o vtip...

Ale da. Pouziva se okenko a adresnim prostoru aplikace a jadro na zadost aplikace meni, na ktere misto fyzicke adresy se tim oknem koukas. Pouzivalo se to ve windows. googluj Address Windowing Extensions (AWE).

Ale da ... jak tu rekl predrecnik, aplikace s tim muze pocitat, a nepouzivalo se to zdaleka jen na win, pouzivalo se to uz v DOSu, a co vic, dokonce davno pred nim. Strankovat pamet umi trebas ATARI 130 XE, tkery se mi tu vali na skrini - ma 128kB RAMky a primo adresovat umi samo jen 64kB, zbytek umi strankovat po 16kB - a to samo i mnohem vic nez tech 128kB.

Na PCcku tu mam aplikaci pro vytvoreni ramdisku, ktera umi na 32bit widlich pouzit jak pamet nad 4GB, tak pamet premapovanou HW (cca posledni 1/4 - 3/4GB z tech 4).

Urcite su taketo zmeny treba? Nepomoze to len tym, ktori pisu aplikacie "prasacky"? Ak ano, tak potom nejde o ziadne performance critical aplikacie.

Bobtnanie premennych sa da v C lahko obmedzit (a je mnohokrat vhodne ho obmedzit) tym, ze sa pouzije napriklad int32_t alebo int64_t namiesto long-u. Ak chce niekto rychlost, tak ma int_fast32_t a podobne. V obidvoch pripadoch mi to da aspon zaruku, ze mi nebude vadit napr. na 18bitovy long na obskurnej architekture, kam sa mi nevlezie to, co potrebujem (C specifikacia to dovoluje). Samozrejme by sa toto dalo zaistit kontrolovat cez LONG_MAX a pod, ale to je zbytocna kontrola (+co ked sa mi nieco aj tak nevlezie do datoveho typu?). Cela kontrola sa da lahko vynechat pomocou inych typov v <stdint.h>.

Bobtnanie pointerov je sice nutne, ale na druhu stranu podla mna nie je az tak vidiet. Ano, nieco sa mi natiahne do pamati a pointery budu 2x tak dlhe = o nieco vacsia spotreba pamati. Naproti tomu si myslim, ze sa inde skoro nic neziska - neviem nic o tom, ze by sa zrychlilo vyhladavanie v cache, ked sa hlada podla kratsieho kluca. Podobne je to aj s prenosmi 64bit adresy - prenasa sa tak isto cela naraz ako 32bit adresa - preto tu asi zrychlenie nebude?

Na zaklade coho sa teda usudilo, ze ma toto pomoct?

Ja myslim, ze duvod, proc se to dela je prave to "bobtnani pointeru". Prece jen, u aplikaci, ktere maji malou spotrebu pameti jsou ty 4 bajty nul navic zbytecna zatez pro cache a vubec pamet, ktera je uzke hrdlo na modernich procesorech (a prakticky se to pak projevi v tom namerenem zrychleni, o kterem se pise v clanku).

Vzdycky jsem si myslel, ze 64-bitove architektury skonci nejakym druhem kompromisu s 32-bitovymi. Tohle napriklad teoreticky umoznuje alokovat bezne objekty pod 4GB, a nad tim pouze specialni velke objekty, ktere muzeme explicitne adresovat dlouhym pointerem (pripadne mit HW podporu pro kompresi/dekompresi dlouhych zarovnanych pointeru). Aplikace si tak bude moci vybrat, na zaklade typu dat ukladanych do pameti (mnozstvi pointeru), kam je ulozit, a to povede k optimalnim vysledkum.

Ten kompromis je mozny uz ted. I v 64bit modu je mozne vykovavat 32bit instrukce. Staci kdyz tu instrukci prefixujete jednim bajtem. A o tohle asi v tom x32 pujde. Napriklad virtualni tabulka metod. Opravdu je potreba tam mit 64bit pointery? Dokaze nekdo vubec vytvorit binarku vetsi nez 4GB?

Jestli nejsem uplne vedle tak ani ten 64bit mod neni uplne cely vyuzit. Myslim, ze hornich 16 bitu adresy muze mit nejakty specialni vyznam anebo musi mit stejnou hodnotu jako bit 47.

O binárku větší jak 4G nejde. Je tu nějakej linker, kterej tu aplikace po spuštění linkuje s knihovnama. V x86-64 linuxu jdou většinou knihovny do adres nad 4GB a samotná binárka jde pod 4GB.

Jinak větší velikost ukazalů nemusí být pro některé aplikace problém. Kompilátor není debil (většinou) a dokáže použít relativní adresování (např. vůči RIP či nějaký tý adrese, kam byla nahrána knihovna/binárka, což je prakticky to position independent code, které stejně používá většina knihoven). Problém to asi může být spíše u aplikací, co používají hodně malých objektů a ukládají v nich ukazatele na jiné, např. nějaký stromy, spojový seznamy, kde se prostě většinou použije absolutní 64bit ukazatel (programátor si to ale prakticky může řešit sám tím, že si bude uchovávat třeba 32bit offsety k nějakýmu základu a pak je bude přičítat, je to pak přeci jen jedna instrukce tak jako tak.

Jinak já jsem známý odpůrce 32bit šmejďáren, který tu nemají co dělat na x86-64 procesorech, vypínám CONFIG_IA32_SUPPORT v kernelu (na které momentálně x32 závisí, ale plánuje se to změnit). Tenhle x32 vidím jen jako další šmejďárnu, né ani tak kvůli 32bit ukazatelům, jako kvůli tomu, že to umožní prasáckým programátorům portovat jejich rozbitý kód s chybnými předpoklady velikostí datových typů, s prasáckými přetypováními ukazatelů na čísla s předpokládanou velikostí a podobnými prasárnami, místo toho, aby byli donuceni opravit si vlastní rozbitý kód.

Tady je příklad "komprese" 64bit pointeru: pointer + spin lock + 16bit int. Ale bude to fungovat jenom do té doby, než příjdou procesory s "opravdovým" 64bit adresováním paměti. Zatím adresují paměť jenom 48 bitově.

Eh, ještě ten odkaz: https://github.com/facebook/folly/blob/master/folly/docs/PackedSyncPtr.md

To neni pravda... naopak v 64bit rezimu je 64bit instrukce prefixovana. Instrukce bez prefixu je 32bit.

Pak mě napadá, co brání běhu kódu x86 spolu s x32? (Např. x86 knihovna a x32 aplikace.)

Možná ten dotaz zní lamersky, ale nejsem assemblerista.

Brání v tom volací konvence funkcí. Nějak jsem to nestudoval, ale věřím, že díky většímu množství registrů se na x32 bude, stejně jako u x86-64, používat fastcall pro všechno, tj. argumenty se předávají v registrech. V x86 se argumenty cpaly na zásobník. Proto ta kombinace nebude možná.

Volací konvence jsou jiné, ale pokud kompilátoru řekněte, že pro dané funkce má použít jinou konvenci, tak to půjde.

Ještě to má jednu podmínku: ta x86-32 knihovna nesmí volat žádnou x32 knihovnu, tzn. třeba libc v takové aplikaci bude muset být taky x86-32.

<i>ze mi nebude vadit napr. na 18bitovy long na obskurnej architekture, kam sa mi nevlezie to, co potrebujem (C specifikacia to dovoluje).</i>

Tezko, o longu specifikace rika: At least 32 bits...

Prasacky kod - no rekni to treba vyvojarum Perlu. Stejna aplikace spustena v perlu na 32b a 64b je lahudka. Kdo si to nezkusil asi neuveri.

Ahoj, docela by me zajimaly podrobnosti, jeste jsem se s necim podobnym nesetkal. Muzes uvest nejaky priklad?
Zatim se setkal treba s tim ze na 32bit JVM blbne IPv6 uplne jinak nez na 64bit JVM.

Tak nevím jestli je +30% výkonu v extrémním případě a o pár procent menší footprint apikace (samotná binárka většinou není ta největší část programu) dostatečný důvod proč to zavádět a řešit problémy které to přinese.

Nasazení 64 bitového OS v "domácí" sféře nemá cenu dnes, ani v blízké budoucnosti.

Jednak téměř všichni mají 4GB RAM a stejně neví, jak je použít. I Windows Vista s bloatware nejde přes magickou hranici 1,5 GB RAM pro samotný systém.

Dále neznám "domácí" aplikaci, co chce více než 2GB RAM. A pokud hrajete nějakou náročnou hru, největší problém je GPU / CPU.

Dále i jako student-programátor vím, že RAM se hodí pouze pro simulace / optimalizace velmi netradičních problémů nebo pro nekonečnou smyčku s MALLOC. Velmi vtipná byla moje poslední semestrální práce, kde na začátku jsem měl prohledávat prostor o ~2^35 až 2^61 prvcích (což se mi zdálo nemožné provést) a nakonec jsem to vymyslel se "zásobníkem zásobníků" a ANSI C programu stačilo pro nejhorší případ 79 KB RAM.

Navíc servery s XXXX RAM stejně běží na jiném principu a lidé na katedře mechaniky/fyzi­ky/matematiky beztak musí výpočty velmi optimalizovat (neboť nemají peníze na zakoupení XXXX RAM k jejich 64 bitovému systému) a nebo jsou NASA a opět mají server, kde se řeší úplně jiné problémy.

Proto jakékoliv kombinování "výhod" (zvláště výhodné jsou 2x větší pointery :-) je IMHO zbytečné. Navíc hromada procesorů není 64 bit ale něco méně (třeba já jsem se dočetl, že můj Intel Core I3 neumí víc, než 8GB RAM). Užitnost některých instrukcí, které se použijí jedenkrát ve dvou aplikacích, se také nestihne projevit.

Mnohem zajímavější je PAE:
bez PAE 2,6 GB RAM (3,7 magická hranice - 1GB GRAM NVidia - 64MB sdílená pamět Intel GPU)
s PAE v klidu opět magických 3,7 GB RAM.

Uvidím, zda si za 10 let koupím notebook bez numerického bloku, dotykovou lesklou obrazovkou, rozlišením 2000x768, bez GPU akcelerace, s UEFI na kterém spustím pouze Windows 9 a 32 GB RAM, tak to jistě bude výhoda mít 64 bit OS (i když si nejsem jistý, zda Angry Birds napsané v HTML 5.1 dokážou tolik RAM využít naplno) .

;-)

No ono je to u Windows ještě o něco jednodušší, 64bit verze s sebou nese zpětnou 32bit kompatibilitu, takže to například vede na 2x nainstalovaný .NET framework se všemi knihovnami. Ve výsledku může známý WinSxS adresář vesele dosáhnout třeba 60GB.

Takhle to resi i AIX. Format XCOFF obsahuje jak 32bit tak i 64bit symboly, navic veskery kod je vzdy position independent. IBM kompilator xlc v defaultu kompiluje kazdy soubor 2x, kdyz vytvarite sdilenou knihovnu. Pro adminy je to pak jednodussi, nemusite resit jestli vam chybi 32bit anebo 64bit baliky/knihovny - vsechno je jen jednou. Navic nemate bordel adresarovy strukture, adresar lib je jenom jeden a odpada nutnost mit jeste lib64/lib32.

Samotny OS zase moc mista nezabira, neni tak bloatware jako na woknach.

dôvodom u Win je spätná kompatibilita, nazývať to bloatware je scestné

Spusťte si pár virtuálních strojů pro ladění v IE a k tomu třeba nějaké větší IDE. No, občas mám na notebooku málo RAM, jen 6 GB.

(Vím, tady by asi stačilo PAE.)

Já mám 8GB a občas se spuštěným eclipse a aplikačním serverem má ten notebook co dělat, ani nepotřebuju virtuální mašiny...

Ale k věci. Ono nejde jenom o ty pointery, které jsou zbytečně dvakrát větší, což přetíží cache. Ale instrukční sada x86_64 je přece jen o pár desítek let jinde než x86_32. Do jisté míry by stačilo, kdyby se kompiloval kód pro architektury SSE3+, případně vylepšit ABI. Jenže skutečnost je taková, že omezení jde maximálně na i686 v lepším případě, a na i386 v horším (viz Debian).

Myslel jsem, že tyhle názory "x KB musí stačit každému" už patří dávno do minulosti, ale zdá se, že někdo tomu věří ještě v 21. století.

Já mám doma 16GB, v práci 8 a na méně než 8 bych už dělat fakt nemohl. 4GB jsou tak na spuštění základních aplikací, ne na normální práci.

No ja mam na svem domacim pc 16GB RAM, a jsem rad ze mi to staci. Asi ma kazdej jinaci predstavu :D. Kazdopadne 4GB je minimum. Vetsinou mi 4GB nestaci. Napriklad si vem kombinaci Netbeans, Eclipse a QtCreator s Monodevelop (to je moje zakladni vybava v praci), k tomu Firefox, Opera, Chromium, Virtualni windows s WinXp a Windows 7, v kazde virtualce spusteny dalsi web prohlizece.

Na 16 GiB bych dost swapoval... Aktualne mam obsazeno (po odecteni slabu, buffers a cache) 18 GiB. 32 GiB je pro me sweet spot. A stoji necelych 7k...

Tak jo, budem si tu chvíli honit brka kdo ho má většího.
(toho paměťa samozřejmě)

Když jsem instaloval W7, hodil jsem rovnou 64bit. Všechno mi funguje bez problémů a až budu časem potřebovat víc paměti než 4 GB, nebudu muset reinstalovat :)

Tak to mas asi jine Windows 7 nez zbytek sveta.

Mno, pridani RAMeti widle prevazne prezijou bez uhony - teda, pokud se to neprezene, nevi nekdo kolik je omezeni w7? 98 s vice nez 512MB nenastartovaly.

Mam 32gb ram , a win7 home vidi 32 ale dovoli pracovat jen s 16 takze win7 home 16gb , pro asi 64gb.

Mam 32gb ale bez swapu a tempy do ramky. Je to optimalni a nebrzdi to system.

podle microsoftu mají 192GB, což je vtipný když standard server má jen 32GB

Tady nekdo zkousel 64GB v desktopovych windouz 7 a slo to:
http://miho.blog.zive.cz/2012/03/zivot-s-64-gib-pameti-a-windows/

A co se podívat přímo na informace od výrobce? Trvá asi pět vteřin to najít.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366778(v=vs.85).aspx#phy­sical_memory_li­mits_windows_7

Mno, to toho na PC asi moc nedelas ... mam 8GB a prijde mi to malo. Pouzivam jak tuxe tak widle. A aplikaci ktery si i pri tech 8GB swapnou tu mam celou radku - od grafickych veci, pres hry, ...

Jinak asi spatne ctes, protoze 4GB umela(primo) adresovat uz 386tka, se strankovanim jeste daleko vic (64GB). To ze ti integrovanej radic neuradi vetsi moduly, je ponekud jinej problem.

Desítky procent navíc na binárku amd64 vs i386? Např. v Debianu (vybráno 10 balíků pseudonáhodně):

libc6: amd64 → 9868 KB, i386 → 9360 KB, tj. -5.1 % oproti amd64
synaptic: amd64 → 5716 KB, i386 → 6394 KB, tj. +11.9 % oproti amd64 (!)
kdebase-bin: amd64 → 1340 KB, i386 → 1240 KB, tj. -7.5 % oproti amd64
mysql-server: amd64 → 14632 KB, i386 → 14008 KB, tj. -4.3 % oproti amd64
libqtcore4: amd64 → 6748 KB, i386 → 6760 KB, tj. +0.2 % oproti amd64
xserver-xorg-core: amd64 → 4872 KB, i386 → 4452 KB, tj. -8.6 % oproti amd64
mc: amd64 → 6508 KB, i386 → 6448 KB, tj. -8.6 % oproti amd64, tj. -0.9 % oproti amd64
libgcc1: amd64 → 104 KB, i386 → 152 KB, tj. +46.2 % oproti amd64 (!)
python2.6: amd64 → 9328 KB, i386 → 8976 KB, tj. -3.8 % oproti amd64
iceweasel: amd64 → 3996 KB, i386 → 3976 KB, tj. -0.5 % oproti amd64

A celé instalační ISO netinst: amd64 → 169 MB, i386 → 191 MB, +13 % oproti amd64 (!)

Nevím jak moc se liší statistika, když daný kód běží v paměti (někdo kdo by chtěl udělat nějaký test?), ale velikost samotných binárek zdá se nepřekračuje jednotky procent a může to být i opačně, kdy je amd64 binárka menší než i386.
Zajímavé také je, že jiné architektury mají binárky i výrazně větší (typicky ia64, mips, mipsel)...

Vzhledem k ostatním příspěvkům v odkazované diskuzi si nemyslím, že je podobné ABI přínosem (nekompatibilita, bezpečnost, ...), nechám se překvapit.

Pointery, o které jde, jsou v binárkách jenom za běhu

No nevim, pokud vim, tak ELF pri nahravani binarky do pameti do ni prilis pointeru nenainjektuje ;-)

Ale jo. Minimalne jeden pointer na kazdy symbol kazde knihovny. Viz LAZY_BINDING.
Tady ale jde hlavne o pointery ktere lezi na heapu - jako treba spojove seznamy, stromy, hash mapy, ...

To je zrejme, s tim nikdo nepolemizuje (az na rozsah; mam podezreni, ze si nekteri mysli, ze int na x86_64 je v linuxu 64bitovy...), v tomto threadu ale resime velikost binarky (at uz na disku nebo po nahrani do pameti)

Nějaký relevantní test či data ke svému tvrzení máte?

Druhý odkaz ve článku nestačí?

Nestaci protoze se tam referuje o narustu velikosti dat a ne o narustu binarky (o ktere se v tomto threadu uz od prvniho prispevku bavime).

Kecy jsou na nic. Změřil někdo někde reálnou náročnost identických běžících procesů na 32 a 64 bit? Pokud ne, jde o hospodské řeči třeba i pánů akademiků...