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.
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?
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.
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á.
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/fyziky/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) .
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.
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).
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.
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#physical_memory_limits_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.
Celý nápad typu „vraťme se do pravěku, ale ne úplně“ mi připadal od začátku nesmyslný. Pak jsem zjistil, že si něco takového myslí dokonce i víc lidí. :-)
http://blog.flameeyes.eu/2012/06/is-x32-for-me-short-answer-no
http://blog.flameeyes.eu/2012/06/debunking-x32-myths
http://blog.flameeyes.eu/2012/06/last-few-notes-about-x32