Zpět na článek

Diskuze: 64 bitů - revoluce nebo jen marketing?

Nejsi přihlášený(á)

Pro psaní a hodnocení komentářů se prosím přihlas ke svému účtu nebo si jej vytvoř.

Rychlé přihlášení přes:

Uživatel bez registrace

Level 1

13. 9. 2006 18:07

Komentáře tohoto uživatele máš zablokované.

Vybrat testy, kde vyjde 32 b a 64 b výkonnostně nastejno umím také. Stejně tak umím vybrat testy, kde 64 b drtí 32 b. Když už jsme u kryptografie, proč autor místo hashe md5 nepoužil třeba šifru aes? Já bych věděl...
- Ritchie

Uživatel bez registrace

Level 1

13. 9. 2006 19:48

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace No schválně, jsem na ten důvod zvědav.

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é.
- Eagle

Uživatel bez registrace

Level 1

15. 9. 2006 13:00

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace CRC32 se používá hlavně kvůli tomu, že CPU x86 jsou 32-bitové. Na 16-bitových strojích se používá i 16-bitové CRC, na 8-bitových strojích se používá i 8-bitové CRC a jsem přesvědčen, že na 64-bit strojích se za několik let bude používat i 64-bitové CRC.
Je ovšem pravda, že najít dneska dobrý praktický test na 64-bitové výpočty je těžké.
- rnb

Uživatel bez registrace

Level 1

14. 9. 2006 13:54

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace Spusťte si openssl speed aes jednou 64b a podruhé 32b a uvidíte sám. Rodinu SHA jsem sám zatím netestoval, ale nárůst výkonu bych očekával až u SHA-512, která na rozdíl od nižších verzí používá 64b slovo.
- Ritchie

Uživatel bez registrace

Level 1

17. 9. 2006 12:15

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace @rnb: Vcelku odvážné tvrzení. Bohužel se nezakládá na pravdě. CRC32 je totiž 32bit pouze v tom směru, že výsledné číslo (checksum) padne do rozsahu 32bit čísla. Umožňuje tedy 4294967296 možných hodnot. 64bit CRC by mělo smysl pouze v situaci, kdy se chceme s téměř jistotou vyhnout možnosti identického kontrolního součtu rozdílných souborů. Zbytek např. tady - http://apollo.backplane.com/matt/crc64.html
- Eagle

Uživatel bez registrace

Level 1

17. 9. 2006 17:53

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace @Eagle: > CRC32 je totiž 32bit pouze v tom směru, že
> 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ší.
- rnb

Uživatel bez registrace

Level 1

18. 9. 2006 12:21

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace @rnb: 64bit procesor snadněji (= rychleji) spočte 32bit číslo. Čili k tomu nevidím důvod.
- Eagle

Uživatel bez registrace

Level 1

4. 9. 2006 08:23

Komentáře tohoto uživatele máš zablokované.

... ak neplanuje viac ako 4GB ramky tak 64bit je vam na 2 veci...

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.
- Barell

Uživatel bez registrace

Level 1

4. 9. 2006 11:48

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace vidím, že začala škola a tak se zase vynořili puberťáci klikající na "blábol" ;-)
- RS

Uživatel bez registrace

Level 1

4. 9. 2006 10:16

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace dneska muzes mit klidne komp s vic jak 4giga ram a mit 32bit system...jedine omezeni je v tom, ze programy nemuzou adresovat vic jak 4giga...ale nic nebrani tomu, ze tyhle 4 (no mozna 2giga) si muze zabrat nekolik programu najednou. system totiz pouziva k adresovani vic jak 32bitu (48?) - ve windows se tomu rika "rozsireni fyzicke adresy"
- hekrhy

Uživatel bez registrace

Level 1

5. 9. 2006 09:38

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace Hmm. To je sice prima, ale napiste mi link na zakladni desku rekneme do 5.000 Kc, ktera podporuje vice nez 4 GB RAM. Ja takovou zatim nenasel. Mozna spatne hledam ... :-)
- koloděj

Uživatel bez registrace

Level 1

4. 9. 2006 13:47

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace Vazne?Neni pravda WIN XP 32bit ani nahodou:-(Vice nez 3GB RAM je pod WIN XP 32bit nefunkcnich.Kdyz das 4x1Gb RAM tak se ti stejne nadresuje jen 3GB a tecka.Resil sem to i s microsoftem a je to bohuzel tak.Takze me vazne zajima jak chces pdo 32bit OS provozovat vic jak 4Gb RAM.Mozna pod linuxem a taka le bohuzl Microsoft to neumoznuje
- karel

Uživatel bez registrace

Level 1

5. 9. 2006 11:00

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace @koloděj: Např. P965 umí 8GB DDR2-667.
- Eagle

Uživatel bez registrace

Level 1

4. 9. 2006 09:03

Komentáře tohoto uživatele máš zablokované.

Zatímco přechod s 16 na 32 bitů byl ve své době opravdu nutný,tak 64 bitové procesory, ač už jsou na trhu opravdu dlouho, nemají zatím pro normálního uživatele velký význam.Budoucnost CPU je jistě 64 bitová,ale protože u počítačů pro "domácnost" zatím 32 bitů není žádnou brzdou výkonu,tak je přechod na 64 bitů velmi pozvolný.Jak je v článku uvedeno,tak ani "blízká" budoucnost není 64 bitům nějak nakloněna a dá se spíše očekávat optimalizace programů pro dual core,než pro 64 bitů. Zatím opravdu není kam spěchat a 32 bitů je stále dostatečných.

Jinak článek je opravdu výborný.
- Gaskoňec

Uživatel bez registrace

Level 1

5. 9. 2006 10:43

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace Clanok je plny chyb. Uz v prvej kapitole je tato perla:
[I]Už z názvů plyne, že tyto čipy umí počítat s čísly, [B]které jsou tvořeny[/B] z dvě na šestnáctou, resp. dvě na třicátou druhou bitů[/I]

Hmm, takze to uz su na trhu 65536b CPU. MEGAROFL. Prosim opravte tu vetu.
- advanced BFU

Uživatel bez registrace

Level 1

5. 9. 2006 11:28

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace Stane se. A ty další chyby?
- Eagle

Uživatel bez registrace

Level 1

3. 10. 2006 11:27

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace @Eagle: jen drobnost, a to že FPU je na procesoru uz od 486DX čímž se lišil od SX ... prvni Pentia mely jako prvni dve ALU na jednu FPU z čehož plynula potřeba optimalizovat kód pro dve celočíselné jednotky, jinak se ta druhá flákala ... historie se pořád opakuje a pořád na nas zkouší ty samé triky ;) než aby zvyšovali výkon pomocí optimalizace jádra, zvyšují počet trenzistorů, instrukcí, jednotek a teď už i jader ...

jinak velmi dobrý článek o technologii, která bude pro běžného smrtelníka ještě pát let na nic.
- Mrtvej Brouk

Uživatel bez registrace

Level 1

4. 9. 2006 10:17

Komentáře tohoto uživatele máš zablokované.

Super, naco som cital cely clanok, stacilo si precitat tvoj komentar. Milujem nic nehovoriace vseobecne alebo zhrnujuce komentare.
- modo

Uživatel bez registrace

Level 1

4. 9. 2006 10:39

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace Ale já tě nenutil číst můj příspěvěk? To je tvá blbost :-)
- Gaskoňec

Uživatel bez registrace

Level 1

4. 9. 2006 11:13

Komentáře tohoto uživatele máš zablokované.

mohl by prosím autor přidal alespoň jeden test nějakého athlonu, četl jsem, že AMD o něco lépe pracuje se 64 bity
- Fernando Cortéz

Uživatel bez registrace

Level 1

13. 9. 2006 19:57

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace Výsledky na Athlon 64 3800+

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.
- Eagle

Uživatel bez registrace

Level 1

4. 9. 2006 15:03

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace teraz program napsiany pre AMD64 bol asi 3x rychlsjei ako ten napisany pre x86.
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

- fotoba

Uživatel bez registrace

Level 1

4. 9. 2006 15:08

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace Podla sefvyvojarov
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
http://www2.amd.com/us-en/Corporate/Careers/1,,51_82_13175_13439%5e13184,00.html[U]null[/U]

- fotoba

Uživatel bez registrace

Level 1

4. 9. 2006 13:08

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace Může být, ale napřed potřebuju odpovídající hardware, který momentálně nemám.
- Eagle

Uživatel bez registrace

Level 1

4. 9. 2006 12:59

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace Tak tuto otázku jsme s autorem rozebírali podrobně a došli jsme k závěru, že pokud je při stejně taktovaných procesorech (například 2.5GHz) v 32 bitových aplikacích náskok Core 2 Duo před Athlonem 64 x2 asi 20%, pak v 64 bitech se tento náskok smrskává na 15-10%. Nelze tedy hovořit o propadu, ale o tom, že Core 2 Duo nemá v 64 bitovém režimu tolik optimalizací jak v 32 bitech.
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.
- Kwolek Jirka

Uživatel bez registrace

Level 1

4. 9. 2006 12:15

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace nechci mluvit za autora, ale tohle asi nebyl zamer clanku a navic na internetu se toho vali spousta, staci hledat.... ;-)
http://xbitlabs.com/articles/cpu/display/core2duo-64bit.html
- Petr Ent

Uživatel bez registrace

Level 1

4. 9. 2006 16:44

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace Alebo tu: http://www.pcstats.com/articleview.cfm?articleid=1988&page=15
- lm

Uživatel bez registrace

Level 1

4. 9. 2006 11:46

Komentáře tohoto uživatele máš zablokované.

živím se numerickými simulacemi (metoda konečných prvků, metoda konečných objemů) a 64bitové aplikace používáme už celá léta. Je to právě ten případ, kdy pracujete s obrovskými databázemi a není problém mít výsledkový soubor o velikosti 100GB. V takových případech je nárůst výkonu u 64 bitů oproti 32 bitům obrovský. Sice se v článku píše, že 32bitů dokáže adresovat více než 4GB ram (např. linux to podporuje), ale pokud jste to někdo zkoušeli v praxi na MS Windows XP, tak zjistíte, že windows XP neumí dobře adresovat ani ty 4GB. Jednak je limit 2GB na procesor, takže XP dokáží adresovat 4GB RAM pouze v případě, že máte 2 procesory, ale i tak je stále limit 2GB na aplikaci. To znamená, že když máte 4GB RAM a 32bitové windows, tak svoji paměť stejně plně nevyužijete. 64bitové XP už jsou na tom lépe, ale bohužel podpora HW je slabá. Výrobci nedělají ovladače a tak např. HP LaserJet 5550dm nemá driver pro XP x64 a tak nejsem schopný ze svého počítače tisknout.
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 :-)
- RS

Uživatel bez registrace

Level 1

5. 9. 2006 14:03

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace Souhlas... Ono opravdu zalezi na aplikaci. Protoze ve chvili, kdy potrebujete 64-bit presnost vypoctu, skutecne dochazi k vyraznejsimu narustu vykonu. Autor clanku ma pravdu v tom, ze beznemu uzivateli muze byt kauza kolem 64-bitovych procesoru vcelku ukradena. Ve chvli, kdy se clovek zabyva takovymto druhem aplikaci, ma 64-bit sve kouzlo. Nevite nekdo, jaky je teoreticky narust vykonu pri zpracovani 64-bitoveho (int a float) cisla na 64-bitovem procesoru, oproti 32-bitu?
- Grolman

Uživatel bez registrace

Level 1

4. 9. 2006 22:52

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace Mám dojem, že se to tady trochu plete. WinXP umí adresovat 4GB paměti. Ovšem virtuální adresový prostor je rozdělený na "dolní" 2GB, které má aplikace (proces) a "horní", které adresuje kernel.
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.
- Richard Musil

Uživatel bez registrace

Level 1

5. 9. 2006 08:12

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace to je prrávě ten problém windows, že i když máte 4GB RAM, tak systém vidí pouze 3GB RAM. Myslel jsem, že je to pouze problém počítačů u nás ve firmě, ale z příspěvku od Honzy vyplývá, že má ten samý problém. Co se aplikace týče, tak ta je naprogramovaná dobře a když ji nainstalujete na 64 bity, tak sice běží v 32-bitovém módu, nicméně dokáže adresovat celou paměť - 4GB.
- RS

Uživatel bez registrace

Level 1

4. 9. 2006 13:17

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace Jenom malé upřesnění - je to 2 GB na proces, nikoli na procesor.
- Eagle

Uživatel bez registrace

Level 1

4. 9. 2006 13:44

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace A ještě jedno upřesnění - ve 32bit Windows Server 2003 a Windows 2000 je možné pomocí přepínače /3GB v boot.ini zapnout podporu 3 GB na proces. Bližší detaily viz http://support.microsoft.com/kb/283037/
- Eagle

Uživatel bez registrace

Level 1

4. 9. 2006 15:23

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace @Eagle: ten přepínač nefunguje vždycky, je tam na to někde upozornění a sytém nemusí v některých případech vůbec nabootovat. Navíc to nic nemění na tom, že 32 bit by měly podporovat 4GB a i s tím přepínačem to jsou stále jen 3GB.
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.
- RS

Uživatel bez registrace

Level 1

4. 9. 2006 16:27

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace @RS: "32 bit by měly podporovat 4GB" - ono je tam nutne zapocitat i jakysi virtualni adresovy prostor pro pristup k ruznym zarizenim, takze 4 GB fyzicke RAM opravdu adresovat nejde. A co se tyce tech 2 GB, tak nektere spatne napsane programy berou nejvyssi bit jako znamenkovy, takze muzou mit nad 2GB problemy.
- xR->

Uživatel bez registrace

Level 1

4. 9. 2006 12:31

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace Mam podobne zkusenosti ohledne M$ Windows a (ne)podpory pameti, kdyz jsem pred nekolika lety zkousel masinu ze 4GB. 3 giga a konec, 2 giga na proces/aplikaci (:-

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.
- Honza

Uživatel bez registrace

Level 1

4. 9. 2006 12:34

Komentáře tohoto uživatele máš zablokované.

Moc pěkný článek, který vysvětluje o tomto tematu vše potřebné srozumitelnou formou. Děkuji.
- myom

Uživatel bez registrace

Level 1

4. 9. 2006 12:46

Komentáře tohoto uživatele máš zablokované.

Dobry clanok, na tretej strane "Klikněte pro zvětšení" nejde len mne?

- Teho

Uživatel bez registrace

Level 1

4. 9. 2006 13:13

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace Také jsem si toho všimnul. Už jsem o tom informoval Jirku Kwolka, snad to brzo opraví.
- Eagle

Uživatel bez registrace

Level 1

4. 9. 2006 12:52

Komentáře tohoto uživatele máš zablokované.

Pekny clanek...velice to ocenuji. Ale na tuto otazku: "Co prinasi 64bitu?" by se dalo snadno odpovedet: Pro bezneho uzivatele uplny hovn*. :-D jinak clanek sqělej ;-)
- $uch@rC

Uživatel bez registrace

Level 1

4. 9. 2006 13:07

Komentáře tohoto uživatele máš zablokované.

"Windows Vista - počítá se s tím, že právě Vista prolomí brány "lidového" 64 bitového computingu" u RC1 to zatím vypadá s kompatibilitou u x64 Vistou dost bledě, stačí si přečíst [URL=http://www.winsupersite.com/reviews/winvista_rc1_02.asp]tohle.[/URL]

"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."

- Squish

Uživatel bez registrace

Level 1

4. 9. 2006 13:20

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace Vista je ale ve stádiu betaverze. Oni to ještě spraví, toho bych se nebál. Na Windows XP x64 jsem žádný problém nezaznamenal.
- Eagle

Uživatel bez registrace

Level 1

4. 9. 2006 14:23

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace Uvidíme, maj ještě trochu čas.
Trochu sem doufal že Microsoft vydá jen x64 a tím uživatele trochu donutí přejít na 64 bitů.
- Squish

Uživatel bez registrace

Level 1

4. 9. 2006 14:02

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace Osobní zkušenosti s XP 64 nemám,ale co jsem četl několik příspěvků od uživatelů, kteří tento OS používají,tak o spokojenosti se mluvit opravdu nedalo. Windows Vista je určitě v oblasti 64 bitů mnohem dále,ale ani zde nepočítám u domácích uživatelů s masivním rozšířením.Myslím,že nějakou dobu "asi dlouhou"
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.
- Gaskoňec

Uživatel bez registrace

Level 1

4. 9. 2006 18:59

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace @Gaskoňec: SLI a CrossFire jsou nákladné a neefektivní, 64 bitů jsou nutnost budoucnosti, stojí pouze mírně vyšší počet tranzistorů a efektivní teprve budou až se začneme zabývat méně komprimovaným videem, kvalitnější grafikou v PC hrách atd.

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í
- Michal Mitrega

Uživatel bez registrace

Level 1

4. 9. 2006 14:03

Komentáře tohoto uživatele máš zablokované.

diky za clanek a i nektere komentare pod nim :)
- David Budac

Uživatel bez registrace

Level 1

4. 9. 2006 14:35

Komentáře tohoto uživatele máš zablokované.

Ja jsem asi neco minul, Eagle ze pise pro pctuning? No shoda jmen to asi nebude, takze jedine dobre. Takze timto vznika zrejme nejkvalitnejsi IT webmagazin v CR:)
- Lukas

Uživatel bez registrace

Level 1

4. 9. 2006 15:15

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace Ono když vám šéfredaktor napíše, že ho zajímají jen jeho názory a názory majitele, ale už ne treba přímého nadřízeného (ředitele divize eMedia: "neni to clovek, ktery me zamestnava... co se projektu SHW tyce, nic s nim neprojednavam"), natož vaše názory, dále vám řekne, že tím, že děláte spoustu věcí pro časopis zdarma, se pouze zviditelňujete, a prohlašuje o vás lživé věci na diskuzním fóru (... které je pod jeho kontrolou) tak, aby si získal čtenáře na svojí stranu, zjevně nemáte důvod pokračovat. Tím spíš ho nemáte, když jsou neshody zapříčiněny jeho neustálou posedlostí dokazovat všem svojí nenahraditelnost (na kterou objektivně vzato nemá) a to i před čtenáři tak, že autokratickým způsobem rozhoduje o filtrování nepohodlných názorů. Můj a jeho přístup k lidem se zjevně velmi liší, neboť jsem toho názoru, že filtrovat se mají jen příspěvky urážlivého charakteru, nikoli například oprávněná kritika či lehčí off-topic.
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.
- Eagle

Uživatel bez registrace

Level 1

4. 9. 2006 19:03

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace Super, že teď děláš u nás Eagle. ;) Jsi totiž jedním z mála odborníků "na slovo vzatých".

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
- Michal Mitrega

Uživatel bez registrace

Level 1

4. 9. 2006 17:17

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace V tom případě ... VÍTEJ ZPĚT CHLAPE! Chyběls tady jako sůl. Doufám, že svými články zvedneš opět úroveň PCTuningu, tak jako zvednuls úroveň Světu Hardware. Takže SHW zase půjde down a PCTuning UP. :-D
- GOS

Uživatel bez registrace

Level 1

4. 9. 2006 15:35

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace Taky jsem rad ze Eagle presel na nas magazin - kazdy schopny a sikovny redaktor se hodi :-)

Je mi lito ze je ale tento prechod z takoveho duvodu avsak pouze mi potvrdil muj nazor na magazin SvetHardware...
- Martin Kuchař

Uživatel bez registrace

Level 1

4. 9. 2006 15:20

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace Tak tohle je docela zajimavy postreh, byt lehce off-topic.
- Honza

Uživatel bez registrace

Level 1

4. 9. 2006 15:36

Komentáře tohoto uživatele máš zablokované.

asi mám blbý dotaz, ale je to tím, že jsem se doteď o to moc nezajímal. Jak je to s bity u grafických karet? Pokud 64bitů dokáže adresovat "cokoli", tak jaký má význam 256 bitů a jestli by teda 128-mi bytový procesor měl nějaký reálný význam - např. ve větší propustnosti dat.
- RS

Uživatel bez registrace

Level 1

4. 9. 2006 16:40

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace Jedna vec je adresni prostor - nez budou mit bezne grafiky 4 giga pameti bude jeste par let trvat.
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.
- Honza

Uživatel bez registrace

Level 1

4. 9. 2006 15:42

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace Grafická karta je v podstatě SIMD procesor. Čili tam těch 256 bitů je velikost pakovaného registru (např. osm 32bit čísel).
- Eagle

Uživatel bez registrace

Level 1

4. 9. 2006 16:29

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace Bitovost je u GPU pouze marketingova zalezitost.
- xR->

Uživatel bez registrace

Level 1

4. 9. 2006 17:22

Komentáře tohoto uživatele máš zablokované.

K tomu prekladaci: od Microsoftu je dostupna free! verze prekladace Visual Studio [B]Express[/B] 2005, ktera obsahuje prekladac 64-bit (vcetne optimalizaci - samoty prekladac 64-bit je myslim i v Platform SDK nebo .NET SDK 1.1 uz nevim presne, ale tam zakazali optimalizace, musel se predtim pouzit ten co byl ve Visual C++ Toolkit, coz byl predchudce MSVC Express 2005, ten umel optimalizace, ale zase byl myslim jenom 32-bit). Nevim teda jak moc je to free i pro profesionalni sferu, ale zadna takova poznamka v licenci neni, a lze jej volne stahovat. Je to jakoby "ocesana" verze MSVC 2005, ale zatim jsem neprisel na nic, co by mi tam chybelo. Nainstaluje se to komplet s IDE, lze tam delat projekty atd., a dokonce i [B][I]debugovat[/I][/B], takze v postate vsechno co programator potrebuje, vcetne profi nasazeni. Docela me i dost prekvapilo, ze to Microsot poskytnul volne ke stazeni. Je tam jenom treba doinstalovat Platform SDK (taky volne ke stazeni) a nastavit do nej z IDE cesty :-)
- koloděj

Uživatel bez registrace

Level 1

4. 9. 2006 18:59

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace Jo mmch. jsem to napsal blbe, Visual Studio Express 2005 samotne neobsahuje prekladac 64-bit, ale obsahuje jej Platform SDK for Server 2003, ktery lze take volne stahnout jak uz bylo receno, je tam cl, link, lib pro 64-bit (ja to zatim nepouzival, nemam 64-bit Woknous :-) ).
- koloděj

Uživatel bez registrace

Level 1

4. 9. 2006 18:35

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace pletu se, nebo VS Express je dle licencnich podminek mozne pouzivat jenom 6mesicu? (Mozna dokonce jenom 1/2 roku :) nejsem si jisty).

- petr treti

Uživatel bez registrace

Level 1

4. 9. 2006 18:49

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace Hmm, vsude to maji tak nejasne napsany, navic bylo vic verzi, nejdriv byla nejaka beta, ted lze stahnout ISO obraz finalniho MSVC Express; nekde jsem nasel, ze bez registrace je funkcni jenom 30 dni, coz ovsem zda se platilo pro Betu, ja ho uz mam nainstalovanej a pouzivam nejaky 2 mesice bez registrace a zatim to stale funguje. Nu uvidime za rok :-), prinejhorsim se vratim k Eclipse jako IDE, kterou jsem asi nejvic pouzival predtim, a command-line prikazy pro preklad patrne budou fungovat stale.
- koloděj

Uživatel bez registrace

Level 1

4. 9. 2006 18:54

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace @koloděj: Tak, vysvetleni se ukazalo, ted jsem to tam nasel ... je free "navzdy" :-), [URL=http://msdn.microsoft.com/vstudio/express/support/faq/]stejny link[/URL] jako jsem zminoval vyse ohledne licence, otazka 11. Jsem sam rad ze jsem si to ujasnil :-)
- koloděj

Uživatel bez registrace

Level 1

4. 9. 2006 17:35

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace Nechci se plést, ale tuším, že Express edice nedokáže zkompilovat všechno, protože jí chybí některé knihovny. O volném komerčním užití bych si také dovolil vcelku pochybovat. Souhlasím ale, že Microsoft s tímhle udělal dobře - dávat tak kvalitní nástroj zdarma podpoří začínající vývojáře.
- Eagle

Uživatel bez registrace

Level 1

4. 9. 2006 23:03

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace Visual C++ 2005 Express neobsahuje MFC a ATL knihovny. Což kovanému Windows vývojáři může chybět (hlavně to ATL v návaznosti na WTL), ale na přeložení GNU utilit by to mělo stačit :).

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.
- Richard Musil

Uživatel bez registrace

Level 1

4. 9. 2006 18:14

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace No prave proto je potreba doinstalovat Platform SDK, knihovny WinAPI jsou v nem (ty po instalaci chybi, ale stejne jsou vsecny nejnovejsi ve zminovanem Platfor SDK for Server 2003). Mam to nainstalovane a prelozil jsem tim zatim vsechno co jsem potreboval. Spis pocitam, ze tam nebudou nektere sablony projektu (ktere ja nepotrebuji), nejsem si tedy jist jestli je tam vizualni editor Oken, jako je napr. ve MSVC 6, protoze ten nepouzivam. Mozna tam chybi MFC nebo AFX, ani jedno taky nepouzivam takze to nevim (kvuli portabilite jedu stejne na wxWindows). S licenci je to otazka, jeste se na to kouknu, ale uz jsem to studoval a nic o tom, ze by to nemohli pouzit profi vyvojari, jsem tam nenasel.
- koloděj

Uživatel bez registrace

Level 1

4. 9. 2006 18:43

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace @koloděj: Takze, co se tyce licence Visual Studio Express 2005, je skutecne free i pro komercni pouziti:
[URL=http://msdn.microsoft.com/vstudio/express/support/faq/]zde je link[/URL], otazka 4.
- koloděj

Uživatel bez registrace

Level 1

4. 9. 2006 17:33

Komentáře tohoto uživatele máš zablokované.

Co se tyce porovnani vykonu mam nasledujici zkusenost s AMD: procesor Athlon 64 (plna verze, ne Sempron) 3000+, ktery jsem daval do noveho pocitadla, byl podle mych testu [B]pomalejsi[/B] nez muj 2 roky stary Athlon XP (32-bit) 2500+ pretaktovany na 3000+ (tedy mely stejny rating, a ten 64-bit byl skutecne pomalejsi v procesorovych testech integer i float v Sandre, a to o dost, cca o 15%). Na obou byl system Win XP Pro 32-bit (na tom AMD64 dokonce uplne cistej). Celkem dost me to prekvapilo, ocekaval jsem ze ten 64-bit bude minimalne o trochu rychlejsi nez ten 32-bit (mmch. maximum pameti, ktere slo dat do te desky k tomu AMD64, bylo taky 4GB, coz je AFAIK u vetsiny desek pro skt.939, ktery je primo urcen pro AMD64, takze mi uchazi jaka je vyhoda s velikosti pameti, kdyz tam vic stejne nedate).
- koloděj

Uživatel bez registrace

Level 1

4. 9. 2006 21:17

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace Raiting od AMD je pro lamy.... je to pakárna...
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...
- Vít Pešek

Uživatel bez registrace

Level 1

5. 9. 2006 09:27

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace Prave ze si moc nepomuzou, aspon co se tyce procesoru to je zhruba to, co jsem tim chel rict. Pomuze patrne prechod ze socketu A na AM2, kdyz uz umi DDR-II pameti a ma vyrazne vyssi FSB, pripadne dalsi veci okolo jako PCI-E atd., ale neni to nic zavratneho, rozhodne neni ve 32-bitovych aplikacich nejaky velky zretelny rozdil mezi 32 a 64bit procesory, zrejme i 64bity AMD maji vice "nadsazeny" rating a pak mohou byt 64bit proc. o stejnem ratingu i slabsi nez ratingove odpovidajici 32bit (takze pozor na to, skutecne nelze koukat jenom na rating). Prechod ze skt.A na skt.939 v soucasne dobe IMHO v podstate nema smysl, jediny plus jsou tam dvoukanalove pameti. A pokud ja osobne budu delat upgrade (pricemz je treba obmenit desku, pameti a grafiku), tak v soucasne dobe to bude nejspis Intel Core Duo.
- koloděj

Uživatel bez registrace

Level 1

4. 9. 2006 18:29

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace Co se tyce blabolu :-), ty vysledky skutecne takove byly, nemam duvod si to vymyslet. A ohledne te pameti, pokud se podivate na bezne prodavane desky se skt.939, mozna i AM2 (na ty jsem zatim moc nekoukal), pokud to neni zrovna serverova deska za >10kKc podporujici ECC, tak tam stejne vic jak 4GB nedostanete (vsude mate Maximum memory 4GB non-ECC), tj. pametove vyhody 64-bit procesoru v techto beznych deskach ani nemate sanci vyuzit. Mozna by clovek leda vyuzil 64-bit celociselne pocitani, ale na vetsinu [I]celociselnych[/I] vypoctu 32-bitove cislo staci (a pokud nestaci, tak se to zpravidla stejne pocita ve float), a na float operace taky staci rozsah cisel 32-bitoveho procesoru.
- koloděj

Uživatel bez registrace

Level 1

6. 9. 2006 12:04

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace Nemuzete ale porovnavat rating Athlonu a Sempronu. Ten rozdil ve vykonu imho odpovida, protoze jeden rating by mel udavat stejne vykone P4 a druhy rating stejne vykony Celeron.
- Lukáš Kadlec

Uživatel bez registrace

Level 1

6. 9. 2006 12:07

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace @Lukáš Kadlec: Jezis, ted jsem si to jeste jednou precet a zjistil jsem, ze jsem na psal blabol. Takze se omlouvam.
- Lukáš Kadlec

Uživatel bez registrace

Level 1

4. 9. 2006 18:31

Komentáře tohoto uživatele máš zablokované.

Co je to za blabol?
- Olda

Uživatel bez registrace

Level 1

4. 9. 2006 20:01

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace Bavit se s někým bez vychování je pod mojí úroveň, ale budiž, v tomto případě udělám výjimku - long double je už dlouho identický s double (má jen 8 byte, nikoli 10). http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_CRT_Long_Double.asp
- Eagle

Uživatel bez registrace

Level 1

4. 9. 2006 20:27

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace Ok, beru. Sice bych moh argumentovat ze teda MVS C++ uz nezma double a stejne ho nativne nahrazuje long double, ale neudelam to :D
Nadrazenost si nech na jiny fora kde ti to zerou.
- Olda

Uživatel bez registrace

Level 1

4. 9. 2006 19:39

Komentáře tohoto uživatele máš zablokované.

po dlhom case som si tu precital clanok od zaciatku do konca a cely ;-)
- ff

Uživatel bez registrace

Level 1

4. 9. 2006 20:11

Komentáře tohoto uživatele máš zablokované.

[I]AMD64 je, stejně jako x87, MMX, 3Dnow! a SSE, plnohodnotná přídavná sada instrukcí k x86.[/I]
V skutocnosti pouzili ten isty system ako pri prechode z 16 na 32bit - rozsireny mod procesora a prefixy.

[I]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[/I]
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.
- Marian Krivos

Uživatel bez registrace

Level 1

4. 9. 2006 20:35

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace ad 1) Ano, to je pravda. Ale to nic nemění na tom, že instrukční sada nemá nějaká pseudo-omezení, jak se o ní často říká.

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í.
- Eagle

Uživatel bez registrace

Level 1

5. 9. 2006 11:56

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace Problem je ale ten, ze pokud kompilator nema dost registru, tak tam pridava dalsi instrukce (PUSH apod.) a ty pak trochu zdrzuji...
- xR->

Uživatel bez registrace

Level 1

17. 9. 2006 12:17

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace @xR->: Tyto out-of-order procesor IMHO stejně ignoruje. Mohou ale zdržovat při dekódování, to je pravda.
- Eagle

Uživatel bez registrace

Level 1

4. 9. 2006 20:15

Komentáře tohoto uživatele máš zablokované.

Hele lidi a ohledne vytízeni CPU neni to tak ze 64bit. AMD snesou vice aplikaci narocnych na CPU nez treba 32bit Semprony :) na sk. A kterej mam ja ted(planuju Upgrade:)) treba prehravani HDVidea neni u me mozne pac me to proste CPU nestiha ale u kamose kterej ma prave 64Bit. Athlon na sk 939 to jede v klidu :) tak jak to teda s timto skutecne je :) diky za reakce :)
- Hellraiser

Uživatel bez registrace

Level 1

4. 9. 2006 22:26

Komentáře tohoto uživatele máš zablokované.

Opteron 244 s 1GB DDR333 RAM a RAID 1 SCSI polem běžící pod 64bit Gentoo kompiluje glibc cca 20 minut (pod gcc 3.3.6) a mému Athlonu XP 3200+ s 1GB DDR400 RAM a 160GB PATA diskem to trvá cca hodinku pod stejnou verzí překladače.
- Milan Beneš

Uživatel bez registrace

Level 1

4. 9. 2006 23:22

Komentáře tohoto uživatele máš zablokované.

V článku se naznačuje, že se očekává přechod na 64 bit a "zatím tomu brání hodně aplikací ve 32 bitech případně špatná kompatibilita s DOSem" (volně parafrázováno).

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ě [B]zaberou dvakrát tolik místa v paměti[/B].

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.
- Richard Musil

Uživatel bez registrace

Level 1

2. 10. 2006 16:37

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace Vy jste zajiste programator, podobne jako Eagle take vi spoustu veci o programovani, presto bych zde rad neco podotknul k te vasi diskuzi.

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.

- Adam

Uživatel bez registrace

Level 1

4. 9. 2006 23:51

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace ad 64bit integery - slušný programátor používá datové typy, které jsou pro daný problém adekvátní. Tedy jestli někdo začne hromadně používat 64bit integer (... jak naznačujete), je to jeho hloupost.

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.
- Eagle

Uživatel bez registrace

Level 1

5. 9. 2006 08:11

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace Slušný programátor určitě používá správné typy :). Bohužel, dlouhou dobu platilo (na x86), že sizeof(int) == sizeof(long) == 4 (pro 64 bitové proměnné byl na 32 bitech typ "long long").

C standard velikost integrálních typů výslovně nespecifikuje a definuje pouze určité podmínky:
sizeof(short)
- Richard Musil

Uživatel bez registrace

Level 1

5. 9. 2006 09:59

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace @Richard Musil: Jinak pokud chcete skutecne usetrit pamet, muzete mit bool i na 1 bit, pokud pouzijete bitove posuny a maskovani ANDem (anebo i jenom maskovani), coz jsou oboji pomerne rychle operace :-P

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 :-)
- koloděj

Uživatel bez registrace

Level 1

5. 9. 2006 09:51

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace @Richard Musil: Jojo, na 64-bitech je tohle trochu problem. Premejslel jsem, jestli int bude 64-bit (protoze na 16 i 32 je nativnim typem procesoru), ale nakonec je to pekne zamotany, int je i na 64 porad 32bit, a long je na pod MSVC 64bit a pod GCC 32bit, pod GCC je 64bit cislo reprezentovano pomoci "long long". (uz jsem portoval par programu pod 64-bit linux, a tohle jem tam musel resit)

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)
- koloděj

Uživatel bez registrace

Level 1

5. 9. 2006 08:14

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace @Richard Musil: No nic, bylo toho víc, ale systém se rozhodl, že "většítko" je asi speciální znak - škoda.
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.
- Richard Musil

Uživatel bez registrace

Level 1

6. 9. 2006 20:32

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace @koloděj: Vystup z kompilatoru jsem sice nezkoumal, ale kdysi jsem cetl, ze bool se interne uklada do bitoveho pole a pristup se pak deje pres or a and. Protoze ale vetsinou v ramci jedne funkce clovek potrebuje stejne tak 1, maximalne 2 booly, pouziva se v cecku misto toho BOOL, coz je jenom define intu. Zabere to v dusledku tu samou pamet (zarovnani na 4B) a prace s tim je rychlejsi.
Jo, to v .NETu je System.Boolean objekt, tam se takove blbosti neresi (:
- polygon

Uživatel bez registrace

Level 1

5. 9. 2006 11:24

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace @Richard Musil: Nápověda u MSVC udává, že char zabere 1 byte.

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á.
- Eagle

Uživatel bez registrace

Level 1

5. 9. 2006 10:03

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace @koloděj: A lze to samozrejme do dusledku aplikovat i na vsechny male ciselne typy, napr. muzete nacpat 4 chary nebo 2 shorty do jednoho intu :-P
- koloděj

Uživatel bez registrace

Level 1

5. 9. 2006 18:11

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace @Eagle: Skutečně platí, že sizeof(char) je 1. Nicméně, pokud se podíváte jak překladač zarovnává paměť ve strukturách, nebo předává parametry do funkce, tak to jsou defaultně 4 bajty. Dá se to samozřejmě vypnout (ale není to implicitní chování).
- Richard Musil

Uživatel bez registrace

Level 1

4. 9. 2006 23:25

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace oprava:
"potřebuji na každý HANDLE o 4 bajty víc"
- Richard Musil

Uživatel bez registrace

Level 1

5. 9. 2006 16:21

Komentáře tohoto uživatele máš zablokované.

- 8bitove procesory nemely dlouheho trvani...cca 20 let je asi kratka doba, nektere s epouzivaji dodnes.
- FPU je v Intelech pocinaje Pentiem - to je take blabol, samozrejme je tam FPU pocinaje i486...

Ma vubec cenu to dal cist ?
- HM

Uživatel bez registrace

Level 1

5. 9. 2006 16:40

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace Ve kterém osobním počítači měly osmibity dlouhého trvání? Možná na ulici řídí semafor, ale to je asi tak všechno.

Odkdy měla 486ka SXko FPU jednotku? "Od dob Pentia [U]všechny[/U] 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.
- Eagle

Uživatel bez registrace

Level 1

7. 9. 2006 15:30

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace Aby to bylo s obrazky (dnesni mladez to tak vyzaduje, protoze uz spatne cist), dam odkaz do Wikipedie: http://en.wikipedia.org/wiki/Apple_II. Schvalne se podivejte, jak dlouho se treba tento VELMI OBLIBENY pocitac vyrabel.
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.
- HM

Uživatel bez registrace

Level 1

6. 9. 2006 05:20

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace pokud by si nekdo nehral se slovicky, pak by si mohl najit, ze
- 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
- paco

Uživatel bez registrace

Level 1

8. 9. 2006 23:28

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace @HM: Neděláte si takhle náhodou legraci? IBM PC bylo představeno v roce 1981 a už tehdy mělo 16bit procesor. V roce 1986 přišel Intel s 32bit x86 procesorem. Pokud budeme uvažovat, že osobní počítače se začaly používat v osmdesátých letech (což je i tak optimistické - zjistěti si ceny a pochopíte proč), je úplně jasné, že osmibity skončily ještě před tím, než se počítače začaly nějak rozumně prodávat. Proto opravdu neměly dlouhého trvání. Pokles cen spojený s rozvojem litografie odstranil osmibity už v osmdesátých letech. Naopak 32bit čipy ani s technologickým pokrokem nebylo potřeba vyměnit.

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.
- Eagle

Uživatel bez registrace

Level 1

7. 9. 2006 15:35

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace @HM: Omlouvam se za preklaepy opravuji :
- dnesni mladez umi spatne cist
- link na Apple II: http://en.wikipedia.org/wiki/Apple_II

- HM

Uživatel bez registrace

Level 1

6. 9. 2006 20:52

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace @paco: - 100 % procesorů pro PC a jiné podobné stroje je 32bit nebo 64bit. Článek byl o PC, tak to snad dá rozum, že se nebavíme o průmyslových řešeních.
- 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í.
- Eagle

Uživatel bez registrace

Level 1

5. 9. 2006 17:21

Komentáře tohoto uživatele máš zablokované.

486 SX zpočátku neměla FPU a později se takto značily 486 DX s vadnou a vyřazenou FPU. Dokonce i u dobrých 486 DX se z prodejních důvodů vyřazovala FPU a dělaly se z nich levnější SX.
- šarik

Uživatel bez registrace

Level 1

7. 9. 2006 10:11

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace Originál Intel 80486SX vždy obsahuje FPU, ta je ale vypnuta - neprošla testy. Klony některých jiných výrobců 486 neměly FPU vůbec.
- rnb

Uživatel bez registrace

Level 1

5. 9. 2006 17:25

Komentáře tohoto uživatele máš zablokované.

Co si tak pamatuju z dětství, tak matematický koprocesor býval dřív diskrétní součástka. Můj první počítač, osazený CPU i8088 měl i koprocesos i8087, foto je třeba [URL=http://www.funkygoods.com/mb/pc9801/pc9801_03.jpg]tady[/URL]. Externí koprocesor zůstal až do doby i386, byl to čip i80387.
- Milan Beneš