| 64 bitů - revoluce nebo jen marketing? |
| autor: Petr Koc , publikováno 4.9.2006 |
| Seznam kapitol |
|---|
| 1. 16, 32 a 64bitové procesory |
| 2. AMD64 - rozšíření x86 |
| 3. Windows XP Professional x64 Edition |
| 4. Kompatibilita mezi programy a ovladači |
| 5. 64bit aplikace: kde se berou a co výkon? |
| 6. FAQ - často kladené otázky: 64-bit vs 32bit |
64 bitové čipy jsou, společně s dvoujádrovými procesory typu 2-in-1, bezesporu největší inovací v oblasti procesorů určených pro osobní počítače, která proběhla za posledních deset let. Vzhledem k tom, že 64 bitů vyvolává "optický dojem", že se jedná o dvojnásobek 32 bitů, slibují si někteří uživatelé od těchto procesorů až 2x vyšší výkon, než který podávají dnešní procesory v 32 bitovém režimu. Proč se 64 bitové procesory prosazují tak pomalu? Hraje se s námi nekalá hra?
Jiří Kwolek: *Tuto část jsem do článku doplnil, abych problematiku 64 bitových procesorů a aplikací stručně shrnul a případně doplnil některé detaily.
64bitové procesory jsou už známé 15 let, proč se prosazuji teprve dnes?
Odpověď: Prvním komerčním 64 bitovým procesorem byl v roce 1991 uvedený MIPS R4000 (který tehdy pracoval s neuvěřitelnou frekvencí 100MHz) - rok nato debutovala 64 bitová Alpha AXP od firmy DEC. Od té doby byly nastupující 64 bitové procesory využívané ve firemním a korporátním prostředí, které mohlo nejvíce těžit z výhod 64 bitové platformy - zejména ze schopnosti adresovat velké množství operační paměti. 64 bitové procesory firem MIPS, DEC, Sun, IBM a HP využívaly nativní firemní platformy (IRIX, VMS, Solaris, AS/400, HP-UX) a nebyly vzájemně kompatibilní.
Osobní počítače řady PC (Personal Computer) používaly zase vzájemně kompatibilní procesory, které využívaly instrukční sadu x86. Tato 16 a později 32 bitová instrukční sada byla v průběhu doby rozšířená o tzv. extenze (MMX, SSE, SSE 2 až 4), které procesorům mj. umožnily zpracovávat i 64 bitové operandy (64-bit floating point) a v neposlední řadě také instrukce typu SIMD (Single Instruction, Multiple Data). Tato vylepšení původní instrukční sady umožnila původním 32 bitovým procesorům další vývoj do té míry, že dokázaly 64 bitové procesory překonávat na svém vlastním hřišti (firma / kancelář / domácí použití), v oblastech kde se od nich očekával vysoký výkon - například při práci s multimedii (včetně komprese a dekomprese videa), práci s 3D grafikou, animacemi, u počítačových her (Intel při uvedení MMX tvrdil, že procesor zvládne i 3D akceleraci na úrovni grafické karty).
Obrovskou výhodou při tom bylo to, procesory x86 byly vždy zpětně kompatibilní - tj. bylo na nich možné spouštět programy psané pro předchozí řadu procesorů. Díky tomu současné moderní procesory sdružují vysoký výpočetní výkon (současné aplikace jsou dnešním procesorům šité téměř na míru) s výhodou zpětné kompatibility.
Přesto se doba 32 bitových operačních systémů a aplikací pomaličku blíží ke konci. Vývoj směřuje k 64 bitovým operačním systémům společně s tím, jak se chystají nové, na paměť hladové aplikace (velkokapacitní optické disky, HDTV...).
Čím se liší původní 64 bitové procesory a dnešní 64 bit. procesory určené pro osobní počítače PC?
Odpověď: Když firma AMD uvažovala o nové linii procesorů, která se měla nahradit končící Athlony XP (tehdy vznikala řada K8 - tedy dnešní Athlony 64), napadlo inženýry vytvořit zásadní "generálku" instrukční řady x86, která by tuto instrukční sadu posunula do 64 bitového světa. Vymysleli nejen novou instrukční sadu (x86-64), ale i způsob jak procesor "přepínat" mezi 32 bitovým a 64 bitovým režimem (64-bit mode / Compatibility mode). Tím se otevřely dveře k vytvoření operačních systémů schopných bezproblémového provozování původních 32 bitových aplikací x86 i v prostředí 64 bitového operačního systému.
Právě kompatibilita se světem x86 je tím, čím se liší dřívější 64 bitové procesory (včetně 64 bitového procesoru Intel Itanium, který musí kód x86 softwarově "pracně" emulovat), a dnešními 64 bitovými procesory kompatibilními s instrukční sadou x86 (AMD64 a EM64T).
Co je to instrukční sada x86-64 a co s ní má společného AMD64 a EM64T?
Odpověď: Nová 64-bitová instrukční sada firmy AMD rozvíjející tehdy nejpoužívanější instrukce x86 byla nejdříve nazvaná x86-64 (naznačující 64 bitové rozšíření instrukcí x86), ale v zápětí byla, z marketingových důvodů, přejmenována na AMD64.
Vzhledem k tomu, že firma Intel měla se společností AMD uzavřenou smlouvu o vzájemné výměně licencí a patentů (crosslicensing - jinak by se obě firmy navzájem blokovaly při vývoji nových procesorů), použila stejnou instrukční sadu, i když ji pojmenovala po svém: EM64T. I když v minulosti se diskutovalo o tom, nakolik jsou instrukční sady AMD64 a EM64T kompatibilní, dnes je jasné, že se v zásadě jedná o stejnou instrukční sadu, která se liší jen v několika málo podstatných detailech (tyto rozdíly jsou už dnes zachycené 64 bitovými kompilery). Současné (a i budoucí) programy určené pro instrukční sadu AMD64 budou bez změn pracovat i na procesorech s podporou EM64T od firmy Intel.
Které procesory jsou kompatibilní s instrukční sadou x86-64?
U základů instrukční sady x86-64 (alias AMD64) jsou pochopitelně procesory rodiny AMD K8:
- Athlon 64
- Athlon 64 FX
- dvoujádrový Athlon 64 X2
- notebookový Turion 64
- serverový Opteron.
Původní procesory řady Sempron instrukce AMD64 neovládaly - až do steppingu E6 na platformě Socket 754, pozdější typy už 64 bitovou instrukční sadu podporují.
Mezi modely firmy Intel, které instrukce EM64T (verze x86-64 firmy Intel) podporují patří:
- Xeon (od jádra Nocona)
- Celeron D (modely 3x6/3x1)
- Pentium 4 (modely 6xx/5x6/5x1)
- dvoujádrové Pentium D (modely 8xx/9xx)
- Pentium Extreme Edition
- nové Core 2 Duo a Core 2 Solo (mikroarchitektura "Conroe")
- nový Xeon (jádro Woodcrest, mikroarchitektura "Conroe")
U procesoru Intel pro segment notebooků se jedná pouze o nejnovější (a dosud docela drahé) procesory založené na platformě Core 2. Velmi populární Pentia M, Celerony M ani procesory Core Duo výše zmíněné 64 bitové instrukce nepodporují!
Ve stručnosti lze říci, že veškeré nové "desktopové" procesory 64 bitovou instrukční sadu podporují - a to včetně těch nejlevnějších Celeronů D a Sempronů.
Které operační systémy podporují instrukce x86-64 (AMD64)?
Odpověď: Dnes máte na výběr celou řadu operačních systémů podporujících instrukční sadu AMD64 (dále budu používat především tento název). Dále vyjmenuji jen ty nejdůležitější:
Free BSD - podporuje AMD64 od verze 5.1 (experimentálně), u pozdějších verzí patří AMD64 už mezi preferované procesorové platformy. 6.0-RELASE odstranila pak některé problémy se spouštěním 32-bitového kódu. Instrukční sadu AMD64 podporují také dnešní NetBSD (od 2.0) i OpenBSD (od 3.5).
Solaris - od verze 10 umožňuje tento operační systém firmy Sun zavedení 64 bitového jádra kompatibilního s 64 bitovými ale i 32 bitovými (novými i starými) aplikacemi.
Linux - už verze jádra 2.4 byla schopna běhu v režimu "Long mode" AMD64 - návrh byl dokonce zahájen před uvedením prvních procesorů Athlon 64! Linux také umožňuje kompatibilitu 64 bitového jádra s 32 bitovými aplikacemi (které musí být překompilované právě do tzv. Long mode; aplikace mohou však zůstat 32 bitové). Dnešní populární distribuce Linuxu nabízejí 64 bitová jádra pro AMD64 (pochopitelně i pro EM64T) - SUSE dokonce obsahuje na distribučním DVD 32 i 64-bit systém a uživatel může zvolit, ke které platformě se při instalaci přikloní.
Mac OS X - od verze 10.5 (Leopard) bude podporovat 64 bitové aplikace na strojích vybavených i procesory x86 - avšak podpora bude omezena pouze na počítače ze stáje Apple.
Windows XP Professional x64 Edition a Windows Server 2003 SP1 x64 Edition - první zcela funkční operační systémy Microsoftu plně podporující 64 bitový režim procesorů (AMD64 i EM64T). Umožňují i běh většiny stávajících 32 bitových aplikací bez překompilování. Oba operační systémy vyžadují nové 64 bitové ovladače a prakticky boří paměťové limity Windows (128 GB u Windows XP nebo 1 TB pro Windows Server 2003 x64 Edition). V případě Windows XP Professional x64 Edition se jedná o takový malý "trénink" na nadcházející Windows Vista.
Windows Vista - počítá se s tím, že právě Vista prolomí brány "lidového" 64 bitového computingu. Veškeré verze Windows Vista (mimo verzi Starter) budou k dispozici jako 32 i 64 bitové verze. 64 bitová verze bude umožňovat běh 32 bitových programů podobně, jak to dnes umožňuje Windows XP Professional x64 Edition. Očekává se, že hlavní výrobci aplikací (jako je například firma Adobe) uvedou své nové aplikace v obou verzích (32 i 64 bitové verzi).
Kdy konečně zmizí 32 bitové programy?
Odpověď: Velkým problémem bránicím v rychlém přechodu na 64 bitovou platformu je stále obrovský počet 32 bitových procesorů (a to nemluvím jen o velmi starých procesorech). Nejvíce "pozadu" jsou v tomto ohledu notebooky - ty jsou dodnes často osazovány ještě stále čistě 32 bitovými procesory Pentium M, Celeron M nebo Core Duo.
Předpokládá se, že podpora 32 bitových operačních systémů skončí teprve v roce 2012 - z toho vyplývá, že 32 bitové procesory a 32 bitové aplikace před sebou ještě mají dlouhý život. Jinak v tomto ohledu na tom budou profesionální aplikace - tam bude přechod relativně rychlý. Předpokládáme, že v roce 2009 bude většina profesionálních (serverových, databázových, grafických i videoeditorů) aplikací dostupná pouze v 64 bitové verzi (tj. ekvivalentní 32 bitové verze nebudou existovat).
Jaký je výkonový přínos 64 bitových programů?
Mnohem menší, než se původně očekávalo - přitom nejvíce záleží na typu programu. V některých případech může po překompilování na 64 bitový spustitelný soubor dokonce dojít ke zpomalení programu (zejména u raných 64 bit programů). Pokud bude program pečlivě optimalizován, nemělo by k poklesu výkonu docházet - naopak, ve většině případů můžeme očekávat narůst výkonu v rozsahu +3% až 40%, s tím, že většina aplikací se bude vykazovat zrychlení do 10%.
Jaké jsou paměťové nároky 64 bitových programů?
Délka 64 bitových programů je obecně stejná nebo nepatrně vyšší (o 5 až 10%), mohou však nastat případy, kdy bude nový kód (díky většímu počtu registrů) dokonce štíhlejší. 32 bit a 64 bit spustitelné soubory se od sebe (alespoň velikostí) nemusí vůbec lišit.
Očekávejte ale, že nové aplikace (to je ale obecný trend) si budou vždy žádat víc a více paměti - bez ohledu na efektivitu kódu.
Redakce si vyhrazuje právo odstranit neslušné a nevhodné příspěvky. Případné vyhrady na diskuze(zavináč)pctuning.cz
Ked som k nam do firmy kupoval nove blade servery s 64bit opteronmi tak som vsade nahadzal 32bit OS, ziadny z tych serverov nema viac ako 4GB ram a za tie problemy s drivermi mi to nestoji.
Jinak článek je opravdu výborný.
Už z názvů plyne, že tyto čipy umí počítat s čísly, které jsou tvořeny z dvě na šestnáctou, resp. dvě na třicátou druhou bitů
Hmm, takze to uz su na trhu 65536b CPU. MEGAROFL. Prosim opravte tu vetu.
jinak velmi dobrý článek o technologii, která bude pro běžného smrtelníka ještě pát let na nic.
http://xbitlabs.com/articles/cpu/display/core2duo-64bit.html
Ano, je pravda, že 64 bitové režim u Core 2 není tak vymazlený, jako v případě 32 bitového režimu. Předpokládám, že Intel nechtěl už 64 bitů dále ladit za cenu zpoždění uvedení procesoru a 64 bitové optimalizace jsou v laboratořích na pořadu dne až dnes.
http://www.thejemreport.com/mambo/content/view/120/81/
Ale ten program asi len nasobi, lebo prvotna nalyza AMD64 hovorila, ze teoreticky je scitanie a odcitanie 64 bit typov na AMD64 rovnako rychle ako na 32 bit CPU, ale nasobenie a delenie 64 bit typov je na AMD64 az 6x rychlejsie..
to vyplyva zo 64 bitov
Ked ste uz pisali o Alpha-e, tak ste mohli spomenut
Alpha - Dick Sites and Rich Witek
* Dick Sites and Dirk Meyer, Alpha architecture video, April 1992
AMD Athlon (K7), 1999 - Dirk Meyer (Dir. Engr.), Fred Weber, ...
http://www.cs.clemson.edu/~mark/architects.html
a k tomu
Dirk Meyer
President and Chief Operating Officer
Dirk Meyer je president and chief operating officer firmy AMD
Pred AMD, Meyer robil skoro desatrocie u Digital Equipment Corporation, kde bol spoluarchitektom procesorov Alpha 21064 a 21264
http://www.amd.com/us-en/Corporate/AboutAMD/0,,51_52_570_11573,00.html
AMD vymenovalo Rich-a Witek-a na post firemneho odborneho poradcu
SUNNYVALE, CA -- September 23, 2002 --AMD prave vymenovalo Rich-a Witek-a na post firemenho odborneho poradcu, co je najvyssia vyvojraska pozicia . On je prvym clovekom, ktory zastav u AMD tento post
http://www.amd.com/us-en/Corporate/VirtualPressRoom/0,,51_104_543_8001~43200,00.html
Dick Sites je u Adobe
a K7/K8 sa az napadne podoba
http://www.cpuid.com/reviews/K8/index.php
na Alpha AXP 21164PC (str.32)
http://ftp.digital.com/pub/digital/info/semiconductor/literature/ 164pchrm.pdf
Co bol skrachovany projekt, kde mala Alpha interpretovat nativne x86 a AMD pre nu robilo dekoder x86 instrukcii
Senior Team Members
AMD SENIOR FELLOW, Former Chief Engineer of PowerPC 601 and Power4:
AMD CORPORATE FELLOW, Former IBM Fellow, and Chief Architect of Power, PowerPC, xSeries 440,445, and CTO of Newisys:
AMD FELLOW, Former Chief Architect of UltraSparc III:
ci Witek
AMD CORPORATE FELLOW, Former Lead Architect of Alpha Architecture:
Prave teraz vediem team, ktory vyvyja mobilne CPU a platformy u AMD
>
LAME 32bit 3.98 alpha 6 - 47s
LAME 64bit 3.98 alpha 6 - 48s (-2%)
LAME 32bit no-ASM 3.98 alpha 6 - 50s
LAME 64bit no-ASM 3.98 alpha 6 - 49s (+2%)
MD5 32bit - 309 MB/s
MD5 64bit - 318 MB/s (+3%)
CRC32 32bit - 739 MB/s
CRC32 64bit - 737 MB/s (-0.3%)
Cinebench 9.5 32bit - 361 bodů
Cinebench 9.5 64bit - 402 bodů (+11%)
Čili až na Cinebench je to to samé v bledě modrém. U CRC32 a MD5 došlo k výměně - na Core 2 Duo byl u MD5 pokles a u CRC32 nárůst, tady je to naopak.
Nicméně přechod na 64 bitů bude podpořen silným marektingem, ať už výrobci HW nebo MS, a to i přesto, že pro domácnosti není 64 bitů potřeba, alespoň zatím ne. Jednoduše nás přesvědčí, že více je lépe a 64 je přece více než 32 :-)
HP povestny bezproblemovou podporou a chodem driveru ma pro moji HP BI 3000 DTN drivery pro Itanium a pro bezne WIN XP x64 je udelal teprve pres 2 tydny.
Kdyby to bylo za nejake domaci siditko, jak se zminuje v clanku...ale je to tiskarna za 1000 dolacu.
Jsem zvedavy, jak se Adobe pochlapi se 64-bit verzi - u Photoshopu by to me bylo velkym prinosem.
Teď trochu vysvětlím, jak používám počítač. Metoda konečných prvků není nic jiného než operace s maticemi, představte si matici, která je třeba 8x8. Na 32bitech ji spočtete rychle a na 64bitech nepoznáte žádný nárůst výkonu. My ale pracujeme s maticemi o velikosti až 3e+6x3e+6 a to už pak jenom taková jednoduchá operace, jako je transponování matice udělá svoje a na těch 64 bitech to jde hodně poznat a operace jsou skutečně až 2x rychlejší. Ale to není domácí použití a domácí počítače ještě tak 2 roky nebudou potřebovat více než 2GB RAM.
Jinými slovy, systém aplikaci nedovolí adresaci od 0x80000000 výše, protože to považuje za prostor pro kernel.
Nicméně každá aplikace má teoreticky 2GB, takže stačí dvě a můžete zaplácnout klidně 4GB ;).
Co se týká switche při bootu, ten slouží pouze k tomu, že zmenší adresový prostor pro kernel (a zvětší pro aplikace). Logicky to ovšem může vést k problémům, protože tím pádem má kernel méně prostoru (nikoliv fyzicky, ale virtuálně - což je horší). Už nevím, jestli to psal Jeffrey Richter nebo Mark Rusinovitch, ale ač se to nezdá, tak Microsoft má co dělat, aby se vešel (s jádrem) do těch 2GB.
"Applications like Microsoft Office work just fine on the x64 versions of Windows Vista, but almost nothing else does. Adobe Photoshop won't install at all, citing an unspecified compatibility issue. Ditto for Virtual PC 2004. And AnyDVD. And Nero. And iTunes."
ještě potrvá,než se objeví dost 64 bitových programů pro "domácnost". Zatím tu máme dual-core,pro který nejsou v dostatečném množství programy,nebo SLI či CrossFire,které jsou zatím spíše pro parádu. S 64 bity to myslím nebude jinak....aspoň zatím.
myslím, že jde o zcela jiné problémy - navíc SLI a CF nemají budoucnost (slepá vývojová větev), "skončí" s integrováním více jader na jedno PCB a další evolucí
Trochu sem doufal že Microsoft vydá jen x64 a tím uživatele trochu donutí přejít na 64 bitů.
Věřte mi, že nejsem jediný člověk, který z tohoto důvodu s SHW skončil. Dal jsem jim šanci, ale majitel (Zdeněk Michálek) zjevně stále nepochopil, o co tady běží, a proto nečiní žádné kroky, které by tomuto zabránily. To, že vám SHW zaplatí 70 až 90 Kč za 1000 znaků a maximálně 2500 Kč za článek, prostě není finanční motivací - v libovolném zaměstnání pro vysokoškoláka vyděláte víc. Když si nechtějí udržet ani levného člověka, který to dělá primárně pro radost, tak už nevím, kam hlouběji mohou klesnou. Nicméně je to jejich věc, mohou si dělat, co se jim zlíbí, já ale za těchto okolností nechápu, co by mělo normálně jednajícího autora na Svět hardware momentálně táhnout.
Je mi lito ze je ale tento prechod z takoveho duvodu avsak pouze mi potvrdil muj nazor na magazin SvetHardware...
Tak ať se ti u nás daří... - GL & HF (:
BTW na PCT mi vadí snad jenom nekorektní zobrazování komentářů v Opeře, protože musím pokaždé najet na IE6 při odesílání komentáře, což je prostě OPRUZ! :_D
Druha vec je sirka datove sbernice a tedy i datova propustnost. Ta je u grafickych karet velmi dulezita. A jestli je to 64-bit nebo 256-bit je uz podstatny rozdil.
je link, otazka 4.
Dále tuším neobsahuje resource editor, což je o dost větší ztráta (dá se, ale jen pro managed kód).
Dále neobsahuje "redistributables", což znamená, že to co si přeložíte a spustíte pouze tam, kde je celé VC++ 2k5 Express, nebo kam se vám podaří nějakým hackem dostat VC++ runtime, který je nově (aby se nedal tak snadno šířit) v side-by-side assembly
Přesto bych považoval VC++ 2k5 Express za jeden z velice dobrých (ne-li) nejlepších překladačů, co se týká standard conformity. Dále má poměrně slušnou implementaci STL.
3000+ nema stejnou frekvenci ani na 754 a 939... ani na 939 a A... Jinak bych ale taky byl pro nějáký rozsáhlejší test procesorů, kde by byly pro porovnání zahrnuty nějáké starší kousky....athlony XP s 256 a 512 kb cache proti sempronům64 a athlonům 64 a ještě srovnání s conore... Hodně lidí používá přetaktované athlony do socketu A (třeba já) a zajímalo by je jak moc si pomůžou upgeadem a A64 nebo conore...
Nadrazenost si nech na jiny fora kde ti to zerou.
V skutocnosti pouzili ten isty system ako pri prechode z 16 na 32bit - rozsireny mod procesora a prefixy.
Přínos dodatečných registrů nemusí být zdaleka tak veliký, jak od něj většina lidí očekává. Moderní out-of-order procesory totiž dávno obsahují mnohem větší počet registrů, které dynamicky mapují na pro programátora viditelné "názvy". Tento register renaming mechanismus se dodáním dalších viditelných registrů nijak nemění, tj. počet hardwarových registrů zůstává stejný. To
Toto je podla mna nezmysel - ak ma raz funkcia 12 lokalnych premennych tak bezny procesor umiestni polovicu z nich do registrov a polovicu do RAM, resp. zasobnika, 64bit procesor ich umiestni do registrov vsetky, ak pojde o zlositejsiu funkciu, tak narast moze byt aj 200 az 300%
Preco testy athlon64 udavaju 20% narast pre 64bit mode?
Pozrite si ako sa vysporiadali s 64bit mode v Linuxe a zacnete mat pocit ze sucasny stav je maslo na hlave firmy Microsoft, tam to proste funguje.
ad 2) Není to tak docela pravda. Stack je dnes virtuální záležitostí. Pokud se na to podíváte z pohledu out-of-order, je to úplně o něčem jiném. V 32bit omezený počet registrů může několikrát používat ("recyklovat") eax, a proto to virtuálně vypadá pomalejší než 64bit, kde se použijí pro stejnou operaci dva registry. Jenže v praxi se i v 32bit režimu použijí dva registry - procesor při schedulingu microOPs naalokuje dva registry eax do fyzických registrů (říkejme jim třeba registr 1 a 2) a provede je úplně stejně paralelně jako kdyby alokovat na fyzické registry 1 a 2 například rax a r8. Vyšší výkon 64bit plyne z toho, že alokace na separátní registry může být průhlednější z hlediska schedulingu a jeho zkoumání závislostí.
64 bitů není zdaleka tak světlý zítřek, jak se někteří snažili před pár lety tvrdit. Nabízí sice větší adresový prostor (a jak tady zaznělo, existují speciální aplikace - např. numerické metody - které z toho mohou hodně získat), ale "běžných" aplikací, které by potřebovali tak velkou paměť moc není (pokud jsou, jsou většinou špatně napsané).
Dále 64 bitů nabizí 64 bitovou aritmetiku (za cenu 32 bitové), což může také vypadat skvěle, protože se to dá v marketingovém hype prezentovat tak, že se provede dvojnásobně složitá operace za stejný čas. Co se ovšem v marketingovém hype už neobjeví je to, že málokterá aplikace potřebuje plných 64 bitů.
Potřebuji mít 2^64 adres v adresbooku, nebo 2^64 emailů, nebo souborů v adresáři, nebo pixelů ve snímku, bajtů v souboru .. atd.? Dost zřídka (a kdo to skutečně potřebuje, tak to nejspíš už nějak řeší). Takže sice mohu vesele provádět operace nad 64 bitovými čísly ale ta čísla budou typicky obsahovat pouze "malé" hodnoty, které by se stejně dobře vešly do 32 bitů - nicméně zaberou dvakrát tolik místa v paměti.
Např. takový překladač Visual C++, když generuje prostor pro proměnnou "bool", která je jednobitová, tak na ni vyhradí na 32 bitové architektuře 4 bajty (které zarovná na adresu dělitelnou 4 kvůli optimálnímu přístupu). Nevím jak to je na 64 bitech, ale nedivil bych se, kdyby vyhradil 8 bajtů.
Takový základní typ, který používají Windows je HANDLE (což je v podstatě adresa). Na 32 bitových Windows má 4 bajty, na 64 bitový 8. Takže pokud si nainstaluji 64 bitové Windows, potřebuji na každý HANDLE o 8 bajtů víc (a pokud by mi 32 bitové stačily, tak zbytečně). A že těch "handlů" ve Windows je ...
Jak už tady někdo psal, 16 bitů nebylo udržitelné, ale 32 bitů je už pro většinu lidí/aplikací/potřeb dostačující. A 64 bitů se platí, hlavně pamětí, takže je opravdu potřeba pro to mít dobrý důvod.
"potřebuji na každý HANDLE o 4 bajty víc"
Bool je sice z logiky věci 1bit, ale v praxi nemůže být méně než 1byte, jelikož adresuje se po bytech, ne bitech. Osobně jsem tedy příliš nezkoumal, jakým způsobem VCPP kompilátor alokuje tuhle proměnnou, ale většina kódu, který jsem viděl, beztak obsahovala pro true/false věci proměnnou char. Případně můžete pomocí precompileru nadefinovat, že boolean bude jako char.
ad HANDLE - To jsem přece psal, jen jsem to nazval lépe jako pointer.
C standard velikost integrálních typů výslovně nespecifikuje a definuje pouze určité podmínky:
sizeof(short)
Jen jsem chtěl říct, že to není tak jednoduché jak píšete
A co se týká char a bool je to jedno, na 32 bitech ve standardním nastavení překladače zaberou 4 bajty.
Sizeof(int) jsem bohužel nezkoumal, doufal jsem, že zůstane na 32bit, protože jinak by každá překompilovaná aplikace byla najednou poněkud velká.
A co se tyce typu char je to skutecne tak, ze je jedno jestli se pouzije char nebo bool, oboji pod 32-bit zabere 4B (i napr. u funkce s vararg musite char nacitat jako int, jinak to vypisuje warning a pod nekterymi prekladaci pada), pod 64bit nevim, ale jestli se zarovnava pamet po 8B tak by skutecne mohl zabrat i char i bool tech 8B.
(osobne jsem spise nez char videl pouzivat misto bool klasicky int, samozrejme se to delalo prevazne v klasickem C, kde bool neni datovy typem)
Je ovsem pak trochu slozitejsi prace s nimi (cteni/ulozeni, ale lze si na to udelat makra), a musite mit hodnoty boolean v polich, proto to malokdo dela, protoze malokdo potrebuje takhle setrit na ukor prehlednosti programu :-)
Jo, to v .NETu je System.Boolean objekt, tam se takove blbosti neresi (:
Ohledne zarovnani ... ty windows handly .. budiz, ale hadat se, ze mi jeden char zabere misto 4 bajtu 8 je docela scestne ... kolik takovychhle samostatnych globalnich promennych/clenu objektu v programu mate v pomeru s ostatnimi daty (velka pole, bitmapy, ... ) ... tipoval bych +-1%.
A u poli .. kdyz udelate pole znaku, tak se samozrejme znaky naskladaji za sebe, takze kazdy zabira jeden bajt.
A bajtů v souboru? .. 2^32 je malo ... bohuzel to stasle nekteri tvurci knihoven nepochopili a tak třeba FTP klient internet exploreru neumi spravne zobrazit velikost DVDcka.
- FPU je v Intelech pocinaje Pentiem - to je take blabol, samozrejme je tam FPU pocinaje i486...
Ma vubec cenu to dal cist ?
Odkdy měla 486ka SXko FPU jednotku? "Od dob Pentia všechny procesory" - to slovo tam zřejmě není zbytečné, že?
Takže místo blábolení radši pořádně čtetě a zkuste u toho taky přemýšlet.
- pres 50% v soucasnosti prodanych CPU je 8bit
- formulace v clanku zni "To je také důvod, proč osmibitové procesory neměly dlouhého trvání" coz je v roce 2006 prinejmensim nepresne
- vsechny 486-ky maji FPU, u 486SX je pouze nefunkcni ci deaktivovana
- S touto logikou má HyperThreading i P4 Willamette z roku 2000. Z mé strany se rozhodně nejednalo o slovíčkaření, kdo má aspoň minimální právní cit, v tom ten rozdíl cítit musí.
Jeste dalsi priklad: http://en.wikipedia.org/wiki/Commodore_64
A ani se nezminuju o klonech ZX-Spectra, ktere se treba na Slovensku delaly jeste v roce 1994.
8 bitove pocitace mely dost dlouhe trvani - ty osobni/domaci se uspesne prodavaly cca +- nejakych 15 let
i486SX samozrejme koprocesor mel. Byla to z nouze ctnost - marketingovi zvanilove potrebovali levnejsi CPU pro masy a kohosi chytreho napadlo vyuzit defektni cipy. Pozdeji ty cipy defektni uz ani nebyly, FPU byla jen "vypnuta". i486 byl od pocatku vyvijen jako CPU s FPU.
- dnesni mladez umi spatne cist
- link na Apple II: http://en.wikipedia.org/wiki/Apple_II
Poznámka ohledně jakéhosi klonu ZX-Spectra mi přijde lehce komická - v roce 1994 už bylo na trhu Pentium, které bylo řádově rychlejší. Já se nebavím o prosazování zastaralých koncepcí. Pokud bych chtěl argument pro argument, reagoval bych přesně jako Vy. Mohl bych pak třeba i tvrdit, že parní lokomotivy se používají dodnes... nevím, zda to cítíte stejně, ale mně by takové tvrzení nepřišlo moc v pořádku. Stejně tak je to s osmibity.
pokud se nemylim, tak 85+200 nebude 30, ale 29
timeline:
1991 - MIPS R4000
1992 - DEC Alpha
...
1999 - Pentium III - SSE
Intel dodaval superskalarni RISC procesor i960CA jiz v roce 1989, vyvojarsky tym i960 se podilel na priprave pentia
s prvni realizaci superskalarni architektury prisel uz v roce 1964 Seymour Cray ve svem CDC 6600
Musím Vás zklamat, procesor čte a zapisuje se stále po 64-bitech a cache-line na to nemá vliv.
Jeden takt = 64 bitů. No vidíte, že se nakonec domluvíme :-)
Důvod, proč jsem použil MD5ku a CRC32, je velmi prostý - jsou to společně s SHA nejčastěji používané kontrolní součty. Knihovny Zlib používá kdejaký program a OpenSSL také.
Je ovšem pravda, že najít dneska dobrý praktický test na 64-bitové výpočty je těžké.
> výsledné číslo (checksum) padne do rozsahu
> 32bit čísla.
Drtivá většina algoritmů CRC, které znám, je fixně optimalizována na konkrétní bitovou šířku od začátku až do konce výpočtu. Bitová šířka obvykle bývá identická s bitovou šírkou ALU, protože tehdy bývají základní instrukce nejfektivnější. Může se proto stát, že se začně používat CRC64 ne proto, že by bylo nutně potřeba, ale prostě proto, že to bude rychlejší.