32 kontra 64 bit

[quote:965636bae4="LeoALo"]A 64-32 Bitről meg annyit: Egy 64 bites program 64 bites címeket használ. Ennek az előnye az, hogy több memóriát tud egy process allocalni.
Nem több és nem kevesebb.

Ezt remélem, nem komolyan írtad, csak vicc volt.

[quote:b021e233a0="LeoALo"][quote:b021e233a0="bra"][quote:b021e233a0="algernon"]
Persze ahany 64bites architektura, annyi elony es hatrany :) Mas elonyei vannak amd64-nek, mips64-nek, ppc64-nek, sparc64-nek meg alphanak. (ia64nek meg csak hatranyai, de psszt)

Ez is olyan divat-utálat, mint a "Windows alapból szar"?
Meg tudnád indokolni, hogy az IA-64-nek miért csak hátrányai vannak? (azon kívül, hogy nem fut rajta a DOS, meg a 32 bites windows alkalmazások is lassúak, más bootolási és particionálási metódust használ mint az Intel 8086)

Éppen ez a baja. Minthogy egyenlőre a szoftverek töredéke 64Bites, és mert a 64Bit-es program nem is feltétlenül előny minden esetben, ezrt igenis nagy hátrán, hogy a 32Bites emuláció nem teljesen kompatibilis és lassú. Főleg akkor, ha ezt a konkurencia tökéletesen meg tudta oldani és még olcsóbb is. (AMD64)

Persze már ez sem igaz, mert az új IA64-be "átcsorgott" az AMD módszere és ezekben már használható a 32Bites emuláció.

A 64-32 Bitről meg annyit: Egy 64 bites program 64 bites címeket használ. Ennek az előnye az, hogy több memóriát tud egy process allocalni.
Nem több és nem kevesebb. Ha egy gépben van 512MB memória semmi értelme nincsen. Ha gyorsabb lesz, akkor azért gyorsabb, mert a 32bites emuláció is gyorsabb.

Ami még jobb, az a memóriakezelés hardware-esen. Az AMD 64 tud egyszerre írni és olvasni a fizikai memóriából. Ez sokat gyorsíthat, de jelenleg nagyon drága. (spéci memória kell hozzá)

Nem értem. Attól, hogy nincs rá program egy processzor lehet jól átgondolt. Engem az érdekelne, hogy az IA-64-nek miért csak hátránya van. :)

Az AMD 64 bites processzora pedig alapvetően egy továbbfejlesztett 8086-os, amelyet most már nem 16,32, hanem 64 bitesnek hívnak. Ettől még maradt a sok sallang, amit Intel x86 kompatibilitásnak szoktunk hívni...

A 64 bites belsőnek pedig úgy gondolom nem csak a nagyobb memóriaméretben van előnye, hanem másnál is. Van, amit egy 64 bites processzor kevesebb órajel alatt megcsinál, mint a 32 bites társa.

A HyperTransport valóban jó dolog, bár úgy tudom, az Itaniumnak is van előnye memóriakezelésben (nagyobb címtér, 40/48 bit helyett 50/60 bit).

Nem azt mondom, hogy az IA-64 jó, vagy jobb bárminél (Itanium mint processzor és IA-64 mint architektúra), csak érdekel, hogy más mi alapján fikázza le.

[quote:dbcdec0914="LeoALo"]Minthogy egyenlőre a szoftverek töredéke 64Bites, és mert a 64Bit-es program nem is feltétlenül előny minden esetben, ezrt igenis nagy hátrán, hogy a 32Bites emuláció nem teljesen kompatibilis és lassú.

Linuxpowa: forgatsz magadnak mindenből 64 biteset, és akkor nem kell emulálnod semmit :)

[quote:40dd5f48bb="drojid"][quote:40dd5f48bb="LeoALo"]Minthogy egyenlőre a szoftverek töredéke 64Bites, és mert a 64Bit-es program nem is feltétlenül előny minden esetben, ezrt igenis nagy hátrán, hogy a 32Bites emuláció nem teljesen kompatibilis és lassú.

Linuxpowa: forgatsz magadnak mindenből 64 biteset, és akkor nem kell emulálnod semmit :)

Azért van már pár zárt forráskódú Linux alkalmazás...

[quote:1503855003="bra"]Nem értem. Attól, hogy nincs rá program egy processzor lehet jól átgondolt. Engem az érdekelne, hogy az IA-64-nek miért csak hátránya van. :)

A processzor magában jó, csakhogy... Fischer Eriket idézve a hwsw fórumról:
[quote:1503855003="Elric (@HWSW)"]Vegeredmenyben az Intel csinalt is egy nagyon jo architekturat, meghozza egy CPU architect szemevel nezve egy egyenesen gyonyoru architekturat. En ezt minden alkalommal elismertem. Mert valoban szep, barkivel beszelek, aki tervezett mar CPU-t, az is ezt mondja. Csak eppen tul naiv es tul optimista. Tulzottan szamit a compiler-re, ami viszont problema, meghozza nem is kicsi...

[quote:2b6914a809="bra"]Azért van már pár zárt forráskódú Linux alkalmazás...

Vicc volt.

[quote:a298832039="sz"][quote:a298832039="bra"]Nem értem. Attól, hogy nincs rá program egy processzor lehet jól átgondolt. Engem az érdekelne, hogy az IA-64-nek miért csak hátránya van. :)

A processzor magában jó, csakhogy... Fischer Eriket idézve a hwsw fórumról:
[quote:a298832039="Elric (@HWSW)"]Vegeredmenyben az Intel csinalt is egy nagyon jo architekturat, meghozza egy CPU architect szemevel nezve egy egyenesen gyonyoru architekturat. En ezt minden alkalommal elismertem. Mert valoban szep, barkivel beszelek, aki tervezett mar CPU-t, az is ezt mondja. Csak eppen tul naiv es tul optimista. Tulzottan szamit a compiler-re, ami viszont problema, meghozza nem is kicsi...

Átfogalmazhatom kicsit?
"Ez az operációs rendszer jó, sőt gyönyörű. Csak túlzottan számit az alatta futó programokra (mármint arra, hogy azok jól legyenek megírva), ami viszont probléma."

Nem teljesen értem miért baj az, ha egy amúgy jó architektúra megköveteli, hogy az alatta lévő rétegek is jók legyenek, amennyiben ki akarod hozni belőle az elvárt teljesítményt.

Koszonom!
Ezek jo hirek. Akkor nem cserelek CPU-t.
Az is nagy orom, hogy jo a 32bites OS, igy nem kell 2 repository-t leszednem, egy havi 3GB-os kapcsolat-ot 2fele subarch-hal nyaggatni.
Masik 4 gep ugyanis i386-os.

[quote:09c8590514="bra"][quote:09c8590514="sz"][quote:09c8590514="bra"]Nem értem. Attól, hogy nincs rá program egy processzor lehet jól átgondolt. Engem az érdekelne, hogy az IA-64-nek miért csak hátránya van. :)

A processzor magában jó, csakhogy... Fischer Eriket idézve a hwsw fórumról:
[quote:09c8590514="Elric (@HWSW)"]Vegeredmenyben az Intel csinalt is egy nagyon jo architekturat, meghozza egy CPU architect szemevel nezve egy egyenesen gyonyoru architekturat. En ezt minden alkalommal elismertem. Mert valoban szep, barkivel beszelek, aki tervezett mar CPU-t, az is ezt mondja. Csak eppen tul naiv es tul optimista. Tulzottan szamit a compiler-re, ami viszont problema, meghozza nem is kicsi...

Átfogalmazhatom kicsit?
"Ez az operációs rendszer jó, sőt gyönyörű. Csak túlzottan számit az alatta futó programokra (mármint arra, hogy azok jól legyenek megírva), ami viszont probléma."

Nem teljesen értem miért baj az, ha egy amúgy jó architektúra megköveteli, hogy az alatta lévő rétegek is jók legyenek, amennyiben ki akarod hozni belőle az elvárt teljesítményt.

Azért, mert ezt a követelményt előreláthatólag pár éven belül nem fogják tudni teljesíteni.

smafu wrote

AMD: 2003 ota forgalmaz 64b rendszereket, mara biztosan a tulnyomo tobbseg 64b, van meg egyaltalan 32b AMD?
Intel: 2005-ben kezdte a 64b-t, de egyesek szerint mar csak par honap es kifogynak a raktarkeszletbol a 32b-s CPU-k.

Az nagyker árlistákat elnézve, 32 bites AMD gyakorlatilag elfogyott,
Intel-ből még van elvétve 32 bites Celeron, de jóval drágább, mint a 64 bites... Meg mardt raktáron egy-két nagyobb s478-as 1M-s P4 is.

Szóval vége a 32 bites korszaknak.

A szervereink 64 birtes debian-nal mennek lassan másfél éve (még az Alioth-félét telepítettem), és bírják a napi sok ezer látogatót.
Ellenben az ugyailyen 32 bitesek szoktak fagyni, pl. a mail szerverünk.
(a hw. gyakorlatilag azonos, sőt az egyik 64 bites web-szerver nForece 4 ultra-s (!) (ezt is megértük... :oops: )).

[quote:3b485543e6="bra"][quote:3b485543e6="algernon"]
Persze ahany 64bites architektura, annyi elony es hatrany :) Mas elonyei vannak amd64-nek, mips64-nek, ppc64-nek, sparc64-nek meg alphanak. (ia64nek meg csak hatranyai, de psszt)

Ez is olyan divat-utálat, mint a "Windows alapból szar"?
Meg tudnád indokolni, hogy az IA-64-nek miért csak hátrányai vannak? (azon kívül, hogy nem fut rajta a DOS, meg a 32 bites windows alkalmazások is lassúak, más bootolási és particionálási metódust használ mint az Intel 8086)

A windowst nem utalom, nem ismerem (amit ismertem belole, mar elfelejtettem :P), nem hasznalom, felolem azt csinal amit akar. ia64 szereny tapasztalataim szerint azert csak hatranyokkal rendelkezik, mert kozel sem valtotta be a hozza fuzott "remenyeket". Legalabbis az a nehany HP szerver amivel volt szerencsetlensegem talalkozni valami eszmeletlen lassu es instabil volt (nem az OS rajta, maga a hardver dobta szet magat nem is kevesszer; ugyanakkor x86-os hp gepek teljesen jol szuperaltak mashol).

Az hogy nem fut rajta dos meg mas a particionalas, kit erdekel? Alphanal meg powerpcnel lattam szerintem mar kulonbet is :)

(Ok, az is benne van az ia64-utalatomban, hogy hp amiatt ejtette alphat, ami szerintem sokkal de sokkal jobb architektura)

IMHO egy sparc64 hez eleg olcson hozza lehet mar jutni pl ebayen. Igaz ebay.at -n most csak egyet találtam. http://cgi.ebay.at/ws/eBayISAPI.dll?ViewItem&category=22462&item=5724141684&rd=1&ssPageName=WDVW
Nekem egy hasonló gepem van itthon (Ultra 5) és nagyon meg vagyok vele elégedve. Ezel tényleg minőségi termékek.

[quote:ce5ab6f692="thuglife"]IMHO egy sparc64 hez eleg olcson hozza lehet mar jutni pl ebayen. Igaz ebay.at -n most csak egyet találtam. http://cgi.ebay.at/ws/eBayISAPI.dll?ViewItem&category=22462&item=5724141684&rd=1&ssPageName=WDVW
Nekem egy hasonló gepem van itthon (Ultra 5) és nagyon meg vagyok vele elégedve. Ezel tényleg minőségi termékek.

A minoseggel egyetertek, de ezek mar eleg regi gepek.

"gyomber"-nek most P4 2,6-osa van, te meg ajanlasz neki egy P2/P3 szintu gepet...(nekem is van egy Ultra 5 270, ami kb max P2 333-nak felel meg)

[quote:2a45ebfdb5="samson"][quote:2a45ebfdb5="thuglife"]IMHO egy sparc64 hez eleg olcson hozza lehet mar jutni pl ebayen. Igaz ebay.at -n most csak egyet találtam. http://cgi.ebay.at/ws/eBayISAPI.dll?ViewItem&category=22462&item=5724141684&rd=1&ssPageName=WDVW
Nekem egy hasonló gepem van itthon (Ultra 5) és nagyon meg vagyok vele elégedve. Ezel tényleg minőségi termékek.

A minoseggel egyetertek, de ezek mar eleg regi gepek.

"gyomber"-nek most P4 2,6-osa van, te meg ajanlasz neki egy P2/P3 szintu gepet...(nekem is van egy Ultra 5 270, ami kb max P2 333-nak felel meg)

A kettot nem lehet megfeleltetni egymasnak. Es te is tudod jol, hogy lehet ujabbakat is kapni olcson. Es szerintem ha az ember 64 bites architecture-t szeretne hasznalni akkor mar inkabb fektessen bele tobb penzt.

[quote:0880c32ded="algernon"]
hatranyokkal rendelkezik, mert kozel sem valtotta be a hozza fuzott "remenyeket". Legalabbis az a nehany HP szerver amivel volt szerencsetlensegem talalkozni valami eszmeletlen lassu es instabil volt (nem az OS rajta, maga a hardver dobta szet magat nem is kevesszer; ugyanakkor x86-os hp gepek teljesen jol szuperaltak mashol).

Az itanium2-vel kicsit más a helyzet. Sokkal jobban együttműködtek a résztvevők és a külső nagy cégekkel - sőt kicsikkel is ! - foglalkoztak. HP például tartott szakmai napot is. Aztán az új intel termékek között lesz olyan, ami nagyon brutál. Elméletileg aláírtam egy Corporate NDA-t, de nem árulok el titkos adatot, hogy például lesz raid1-hető és spare-be rakható memória lehetőség az újabb középkategóriás szerver alaplapokon is, de rengeteg más újítással is lehetett találkozni.
Kaptam egy 600 oldalas pdf-et, amiben leírták, hogy mik lesznek az új dolgok, hol lehet hasznos. Én nem temetném azért az intelt... de hajrá opteron :-)

vmiklos,E-Medve kosz

Tehat: 3 program miatt (Java,Flash,OOo) desktopon erdemes 32 bites rendszert valasztani. Van meg mas "kenyes" program is? Az Opera pl megy 64 bites rendszeren? Ja, es latom meg algernon irta 2004.10-ben hogy jatekok sem mennek 64b-esen.

Ezzel szemben:
AMD: 2003 ota forgalmaz 64b rendszereket, mara biztosan a tulnyomo tobbseg 64b, van meg egyaltalan 32b AMD?
Intel: 2005-ben kezdte a 64b-t, de egyesek szerint mar csak par honap es kifogynak a raktarkeszletbol a 32b-s CPU-k.
Ide jol jonne egy megerosites/cafolas.

A fenti tenyek a Unix-like rendszereknek desktop teren rossz hirt jelentenek.
A programok nagy reszenek nem szamit a 64b, kompatibilisek, a fentiek miert nem mennek?

Kicsit mas tema:
Gondolom nem veletlenul van 1-1 rendszerbol (Debian GNU/Linux, FreeBSD,OpenBSD,NetBSD,*Solaris) i386,ia64 es amd64 verzio.
Ha egy 64b-es hw-re 32bit-es (i386) OS-t akarok tenni az maradektalanul, teljesen rendben fog futni?
Gondolom igen, a Linux-hoz tudnam hasonlitani, amit ha P1-re forditok, elindul P2-n, PIII-n, stb; de forditva ez nem igaz.
De egy disztribnel tobb 100 v 1000 programrol van szo, ezert tettem fel a kerdest.

Egyebkent ugy latom, hogy a sw-vilag meg eleg i386 kozpontu. Pl:
- Az fsn vagy barmilyen szerveren ha egy subarch hianyzik akkor az sosem az i386, inkabb az ia64, amd64;
- Trey i386-ra keszitett OpenBSD 3.8 CD-t;
- stb.
Nyilvan a felulrol kompatibilitas miatt, ugye?
A Unix-like szerver teren ezek szerint jo a helyzet? Az i386-os OpenBSD CD futni fog fennakadas nelkul amd64-en,ia64-en?

Megint mas:
32bit-es MicroSoft Windows XP Home miert fut minden programmal jol 64bites vasakon?

Ahogy telnek a honapok a HW eladok egyre inkabb azt fogjak mondani, hogy "hozom a 64bit-es CPU-t", illetve
"a 32bit-es CPU-ra varni kell /elfogyott; de mar ugyis teljesen mindegy,sot ez gyorsabb,tobb memoriat fogad,nem fordul at 4.3 GB-nal, es amugy is kompatibilis lefele minden 32bit-es programmal"
Holott nem az.

Egy szo mint szaz: Gepvasarlas desktop celra, nem megy Linux-on az uj gepek tobbsegen(?) a Java,Flash,OOo.

Ti hogy oldjatok ezt meg 2006-ban? Biztosan sokan hasznaltok Linux-ra epulo disztribet desktop celra!

Ez jo tema, az ilyet mindig szerettem.....

A desktop 64 bit mostanaban kezdi megerni, de jelenleg csak az Athlon64 rug labdaba ezen a teren. Nagyobb cimter jol tud jonni mar egy desktop alkalmazasnak is (CAD,CG,Anim elsosorban). A nagyon tapos desktopokba erdemes csak Opteron-t, horribile dictu Itaniumot v. Power-t venni.

A lebegopontos reszekrol most vitaztunk a hwsw.hu-n, igy utolag azt mondom izles kerdese. Leelheted az eletedet ugy, hogy nem kell 64 bites float, sok helyen feleslegesen van jelen, mashol viszont rohadtul kellhet. A desktopon alapjaban veve jo a 32bites lebegopotty.

Ja az szerintem nem ilyen egyertelmu, hogy a 32bit rossz a 64 bit jo. A jelenlegi top500 vezeto gep (IBM Blue Gene) is 32bites PPC440-esekre epul.

Az a keves dolog, ami a 64 bites gepek ellen szol:
- Az utasitasok 64 bitesek, igy nagyobbak
- Emiatt a vegrehajthato programok nagyobbak
- Erre meg rafejel, hogy a 64 bites RISC CPU-k utasitasai egyszerubbek, igy tobb utasitas is kell.

Emiatt vannak a mai RISC-ekben orbitalis meretu cache-k (sot neha L3,L4 cache is).

Itanium: a hwsw-n 1000+ hozzaszolas van mar a temaban. Sajnos elegge atlathatatlan annak, aki nem kovette az elejetol, mert mikroelektronikai flemtol-architektura anyazasig volt mar minden. Egyszoval igazi chat topic, de azert tanulsagos.

Az Itanium eddigi sikertelensegenek van nehany oka:
- A high-end piac konzervativ, a RISC-VLIW valtas nem megy gyorsan. Meg ugysem, hogy a Transmeta mar utotte ezt a VLIW vasat korabban nehany kategoriaval lejjeb.
- Az Itanium olyan dologban nagyon jo, ami mostanaban nem olyan erdekes (lebegopontos teljesitmeny), az integerekben viszont az Opteron is hasit sokkal olcsobban.
- Borzaszto draga es sokat fogyaszt ezert extrem nagy rendszerek epitesere nem biztos, hogy jo valasztas a jelenlegi teljesitmenyszintje mellett (ertsd amig partiban van a Power-el, addig ezek a parameterei nehezen eladhatova teszik ilyen gepekbe)
- Allitolag lenne meg szufla az architekturaban, csak kellene jol optimalizalo forditoprogram, ami a dolgok jelenlegi allasa szerint meg evek kerdese. Ehhez tudni kell, hogy az Itanium egy EPIC (explicitly parallel instruction counting) architektura. Ez azt jelenti, hogy a szuperskalar mukodeshez szukseges gepi kodbeli parhuzamossagrol a forditoprogram general informaciot a processzornak, nem pedig a proci izzadja ki runtime. Ez jo a processzornak mert masra tudja hasznalni a tranzisztorokat (pl. tobb cache v. tobb vegrehajtoegyseg v. akarmi), a forditoprogram pedig konnyebben megoldhatja mert rendelkezesere all egy magasabb szintu reprezentacio is: a program fuggosegi grafja.
- Szvsz az Intel tole szokatlan modon nem tudta jol bevezetni az Itaniumot a piacra (vendorokat, usereket megnyerni, atterelni a 32bites felhasznalokat)

Alpha: Az Alpha fejleszteset nem a HP, hanem a Compaq kuldte padlora (mondjuk valoban az Itanium miatt). A HP mar csak az utolso szogeket csapkodta be a koporsoba. Egyes mendemondak szerint az Alpha 21364-et (EV78) azert nem banchmarkoltak az Itanium 2 ellen, mert az Alpha jobb lett volna. Nyugtassa a szomorkodokat az a tudat, hogy a 2007 kornyeken megjeleno Itaniumokat mar az Alpha gardaja tervezi. Az AMD procikban pedig az Alpha 21264-21364 memoriabuszat talalhatjuk meg (EV6-EV7). Szoval egyes reszei meg mindig kisertenek :) . Azert jo lett volna latni az EV8 (Arana) cuccost, de ez mar biztosan nem jelenik meg.

Andrei

[quote:82e6f758bd="smafu"]...Tehat: 3 program miatt (Java,Flash,OOo) desktopon erdemes 32 bites rendszert valasztani. Van meg mas "kenyes" program is? Az Opera pl megy 64 bites rendszeren? Ja, es latom meg algernon irta 2004.10-ben hogy jatekok sem mennek 64b-esen....

Felreertettel... Megy a java, a flash es az OOo, de a kernelbe be kell kapcsolni a 32 bites modot is. Vagyis specko libekkel lehet emulalni 32 bitet.
Pl. ha flashes vagy javas weboldalt akarok nezni, akkor 32 bites chrootal inditom a Firefoxot.

Ami meg nem megy 64 biten: a Mplayer Windowsos kodekjei, pl. a realplayer vagy a quicktime.

En egyebkent meg vagyok elegedve az AMD64-emmel, igaz nem nagyon jatszok (tobbnyire csak Foobillard es Armagetron), csak irodai (OpenOffice, email, stb.) es devel (gcc, opengl fejlesztes, stb.) jellegu cuccokra hasznalom.

E-Medve

[quote:8070310b57="Ago"]Az itanium2-vel kicsit más a helyzet.

Orvendetes hir.

[quote:8070310b57="Ago"]
Sokkal jobban együttműködtek a résztvevők és a külső nagy cégekkel - sőt kicsikkel is ! - foglalkoztak. HP például tartott szakmai napot is. Aztán az új intel termékek között lesz olyan, ami nagyon brutál. Elméletileg aláírtam egy Corporate NDA-t, de nem árulok el titkos adatot, hogy például lesz raid1-hető és spare-be rakható memória lehetőség az újabb középkategóriás szerver alaplapokon is, de rengeteg más újítással is lehetett találkozni.

Ez nagyon szep es jo, de ugyanezt a meglevo 64bites architekturakon is meg lehetett volna csinalni (emlekeim szerint vannak is olyan architekturak ahol kb ilyesmik meg is vannak. CPU hotswaprol nem is beszelve). Szoval szvsz ez nem az ia64 ujdonsaga, max ahhoz is csinalnak ilyet.

Mindegy... En egy picit ferde szemmel nezem a "vegyes" 32/64 bites architekturakat.. Tessek eldonteni hogy most milyen! Persze, persze, a kedves vevokre gondolni kell, kell azoknak a 32 bites kompatibilitas is... *sigh*

Debian AMD64-re itt: http://www.debian.org/ports/amd64/
Nem minden i386 csomag erheto el, de nekem eddig a 2 honap alatt jonak tunik...

Nos. Az IA32 (i386) kompatibilis 64 bites processzorra (amd64, x86-64, em64t), akkor az gond nelkul menni fog. Tehat felrakod a 32 bites windowsod, es a 32bites linuxod, es menni fog minden.

Ezutan ha pl 64 bites linuxot raksz ra, akkor "menetkozben" csak 64 bites dolgok fognak futni. Es a java,oo,flash azert problemas mert nincs 64bitre normalis. _de_ van libkompatibilitasi reteg, amivel sima ia32 libeket felrakva, a 32bites oo -t es 32bites firefoxot/konquerort(ehez ugye komplett 32bites kde is kell)/opera -t tudsz futtatni, es lesz benne flashtol kezdve javan at minden.

64bites windowssal nekem elsosorban driverezesi gondjaim voltak, de csupa csupa olyan hw amelybol ujat kellene vennem, minthogy meg mindig ezthasznalni. (pl tvtunerkartya, vagy usb-s bluetooth).

egyebkent meg macromedia szajat kell ragni hogy ne csak ia32 linuxra, hanem amd64 linuxra is forditsa le a flash pluginjat... de pl ugyonigy nincs arm/linux es powerpc/linux -ra sem flash pluginjuk.

[quote:0d0dbbf3d2="Andrei"]Ez jo tema, az ilyet mindig szerettem.....

Az a keves dolog, ami a 64 bites gepek ellen szol:
- Az utasitasok 64 bitesek, igy nagyobbak
- Emiatt a vegrehajthato programok nagyobbak
- Erre meg rafejel, hogy a 64 bites RISC CPU-k utasitasai egyszerubbek, igy tobb utasitas is kell.

Emiatt vannak a mai RISC-ekben orbitalis meretu cache-k (sot neha L3,L4 cache is).

Andrei

aha.
hát nem ismerem az IA64-et, de PPC/PPC64-en az utasítások 32 bitesek,
van 32db 32/64 bites GPR regiszter (kb. egész), 32db 64bites FPR (lebegőpontos), 32db 128 bites VR (amelyikben van vektor aritmetikai egység)

annyiban igazad van, hogy az i386-osnak vannak 8 bites és 16 bites utasításai is emlékeim szerint :) , így egy RISC gépi kódú program hosszabb egy CISC gépi kódú programnál, de az architektuális különbségek miatti méretkülönbség:
1. egy program a lemezen nem csak utasításokat tartalmaz, hanem adatokat is és azok mérete egy CISC vagy RISC-re lefordított programnál lényegében nem változik.
2. egy program a memóriában általában sokkal több adattal dolgozik, mint a program mérete, így a teljes felhasznált memória aránya még tovább csökken.
3. ha megnézed pl. a ppc-re és a i386-re lefordított deb csomagok méretét, ugyan nem mindegy hogy egy csomag 1M vagy 1.1M? (csak hasraütöttem, felőlem lehet 1M vs. 1.5M is :)

a 32bit és 64bit -re lefordított programoknál (csak a PPC-ről tudok nyilatkozni):
1. az utasítások mérete nem változik.
2. egy 64 bitesre lefordított program olyan esetben ahol a 64bit előnyére elegendő 1 utasítás a végrehajtáshoz, ott rövidebb lesz mint a 32bites megvalósítás, ahol ezt több utasítással kellett megvalósítania.
3. lehet hogy sebességre optimalizálás miatt egy 32bites alkalmazásnál egy változót 16bitesre veszek, mert tudom hogy össze kell szorozni egy ugyancsak 16bites változóval, és így gyorsabb lesz a program, míg ha 64bites platformon dolgozom, ott lehet hogy 32bitesre veszem a változót, így tényleg több helyet fog elfoglalni mind a lemezen mind a memóriában, ellenben nem lesz sebességcsökkenés és a program tartalékai (ilyenekre gondolok itt mint maxint, stb.) által jóval tovább nem kell hozzányúlnom (akár forrásszinten) úgy is működni fog.

Köszi, x-daemon, kb szó szerint ezt akartam leírni válasznak :-D

En is _desktop_ teren erdeklodnek.
Konretan adott lesz egy Intel Celeron D 336, vagyis EM64T-rol van szo.
Java (web bongeszoben),OOo, illetve a par hettel ezelotti HUP hir miatt a Flash miatt is aggodok.
Olyanokat olvastam itt (ha jol ertettem), hogy a fenti 3 program nem megy 64bites rendszeren?! E teren szeretnek bizonyossagot szerezni. Igaz, vagy valamit felreertettem?
Koszonom

Ram ezen nem segít, sem a 64 bit, szerintem a legjobban akkor járnál, ha felélesztenéd wine(x) alatt, valahogyan csak lehet... Ha máshogy nem, ajánld fel a plusz ram árát annak, aki először ad Neked egy működő wine(x)-es példányt... :)

[quote:909ee295b6="gyomber"]Először arra gondoltam, hogy egy duálprocos felépítéssel próbálkozom a gyorsítással, de erről lebeszéltek... Ezért kérdezem azt, hogy ezen a 64 bit segít vagy inkább vegyek egy marék RAM-ot (jelenleg 512 Mb van). Szóval mit tanácsoltok (azon kívül, hogy vegyek még egy gépet és azon menjen a sakk :twisted: :twisted: )??? Szeretnék jó és megalapozott döntést hozni, de ehhez alapos információkra van szükségem. :roll: :roll: :roll:

Szerintem 64biten ez lassabban menne, hacsak nincs a sakkprogramodbol 64bitre optimalizalt valtozat.. Ha gyorsabb lenne is, akkor sem sokkal - szerintem. Mivel beszeltek le dual procirol? Elso hallasra az teljesen korrekt es hatasos megoldas lenne. Egyik procira odakotod vmware-t, a masik procit meg hasznalja a tobbi cucc. Igy sem biztos, hogy lassulasmentes lesz a program, de 30%-nal velemenyem szerint sokkal kevesebbet fog lassulni...

Extra RAM nem rossz otlet (nekem 1G van, vmwarenek ki van ajanlva 384Mb, abban eddig minden jol elfutott.. mondjuk amiket en hasznalok alatta, azok nem tul memoria-intenzivek)

[quote:9673958369="algernon"]Mivel beszeltek le dual procirol? Elso hallasra az teljesen korrekt es hatasos megoldas lenne. Egyik procira odakotod vmware-t, a masik procit meg hasznalja a tobbi cucc.

Akkor az egyik procin futna 30%kal lassabban... :)
Extra ram mindig jó ötlet, csak ezen a problémán most nem segít :)

[quote:a6832c9cb6="drojid"][quote:a6832c9cb6="algernon"]Mivel beszeltek le dual procirol? Elso hallasra az teljesen korrekt es hatasos megoldas lenne. Egyik procira odakotod vmware-t, a masik procit meg hasznalja a tobbi cucc.

Akkor az egyik procin futna 30%kal lassabban... :)
Extra ram mindig jó ötlet, csak ezen a problémán most nem segít :)

Miert? Ha vmware-n kivul semmi mas nem eszi azt a procit, miert futna akkor ugyanolyan sebesseggel, mintha vmwaren kivul X is, desktop is, meg kb minden mas ugyanazt az egyetlen szegeny procit eszi?

Mert nem a többi alkalmazás fél %-a eszi meg szerintem az erőforrásait, hanem az emulált pc. (szvsz)

Másrészt pedig, nem tudom, oda lehet-e ragasztani egy alkalmazást egy cpu-hoz, és megmondani a Linuxnak, hogy más processz ne használja, csak a másik processzort.

Harmadrászt pedig, bármit is választ, ha nem új gépet vesz, az teljesítménycsökkenéssel járó barkács lesz.

A vmware egy komplett PC-t emulál, ez mindenképpen egy lassú folyamat. A wine csak windows-os API-kat biztosít, de az OS-ed natív kódot futtat, fizikai eszközökön.
Vmware mellett a linuxos dolgaid is elszaladgálnak - ez dícséretes, wine mellett is el fognak.
Azt miből gondolod, hogy több ram mellett a windows is gyorsabban fut? Bizonyos korlátok között ez persze igaz, de ha 4terabyteot pakolsz bele sem lesz sokkal gyorsabb, mint mondjuk 1GB-tal. Ha a vmware alatt futó windowsod most sem swapel sokat, akkor a 2G RAM nem nagyon fog rajta javítani.

[quote:0582c853bf="drojid"]Mert nem a többi alkalmazás fél %-a eszi meg szerintem az erőforrásait, hanem az emulált pc. (szvsz)

Azert eleg sokat el tud venni a tobbi alkalmazas is, tapasztalatom szerint. Meg az hogy valtogatni kell az egyes processzek kozott. Ha egy gnome is, vagy vmilyen desktop is fut, nem csak egy X meg egy vmware, akkor meg plane van ott proci eves.

[quote:0582c853bf="drojid"]Másrészt pedig, nem tudom, oda lehet-e ragasztani egy alkalmazást egy cpu-hoz, és megmondani a Linuxnak, hogy más processz ne használja, csak a másik processzort.

Meg lehet, csak kellenek a megfelelo utilok.

[quote:0582c853bf="drojid"]Harmadrászt pedig, bármit is választ, ha nem új gépet vesz, az teljesítménycsökkenéssel járó barkács lesz.

Jah, ha gyorsitani akar rajta, akkor ahhoz relative uj hw is kell, meg az o eseteben x86 kompatibilitas sem hatrany.

Azt lehet meg esetleg kiprobalni, hogy win2k/winxp + colinux, hatha a ugy gyorsabb a dolog, mint vmwarezva..

[quote:30cbd5ae10="algernon"]Azert eleg sokat el tud venni a tobbi alkalmazas is, tapasztalatom szerint. Meg az hogy valtogatni kell az egyes processzek kozott. Ha egy gnome is, vagy vmilyen desktop is fut, nem csak egy X meg egy vmware, akkor meg plane van ott proci eves.

Gondolom, nem futtat SuperKaramba-t közben, csillivilli KDE appleteket, és Doom3-at a háttérben, ha kell neki a ram és cpu minden kis morzsája. Ha mégis, akkor meg felesleges bármit is írnunk, egy 8 utas Xeonos rendszert is agyon lehet terhelni :)

[quote:30cbd5ae10="algernon"]Azt lehet meg esetleg kiprobalni, hogy win2k/winxp + colinux, hatha a ugy gyorsabb a dolog, mint vmwarezva..

Hát nem tudom, szerintem elvileg ez nem gyorsabb, mint egy linux+wine kombináció, de a colinuxot nem ismerem közelről.

[quote:1d119bc678="drojid"]Másrészt pedig, nem tudom, oda lehet-e ragasztani egy alkalmazást egy cpu-hoz, és megmondani a Linuxnak, hogy más processz ne használja, csak a másik processzort..

Ezt meg lehet csinálni, mingo schedulerjével itt a HUP-on trey már leírta hogyan lehet.
[quote:1d119bc678="drojid"]A vmware egy komplett PC-t emulál, ez mindenképpen egy lassú folyamat. A wine csak windows-os API-kat biztosít, de az OS-ed natív kódot futtat, fizikai eszközökön.

Ez így igaz, épp ezért meg lehetne próbálnia bochs-sal, az nem emulálja a teljes hardware-t, ezért jóval gyorsabb is, ráadásul open source project.

Én azt ajánlom, vegyél még tíz-húsz amd opteront a gépedbe, 4 tera memóriát, és akkor valamelyest javulnak az esélyeid.

következő miatt kérdezem: sajnos a sakkprogramjaimat (shredder8, chessbase) nem tudtam átnyomatni linuxra, mert sem wine, sem winex, sem CrossOver...

ez ismeros en mar belenyugodtam, hogy ezeket XP alol tudom hasznalni, tulajkeppen
ezert nem szabadultam meg az XPtol /meg par jatek/ :D
szal egyszerubb meghagyni XP-t erre celra szerintem

vagy megprobalod kivaltani linux/unixos progikkal

ventura

[quote:c54a17df4d="drojid"][quote:c54a17df4d="algernon"]Azert eleg sokat el tud venni a tobbi alkalmazas is, tapasztalatom szerint. Meg az hogy valtogatni kell az egyes processzek kozott. Ha egy gnome is, vagy vmilyen desktop is fut, nem csak egy X meg egy vmware, akkor meg plane van ott proci eves.

Gondolom, nem futtat SuperKaramba-t közben, csillivilli KDE appleteket, és Doom3-at a háttérben, ha kell neki a ram és cpu minden kis morzsája. Ha mégis, akkor meg felesleges bármit is írnunk, egy 8 utas Xeonos rendszert is agyon lehet terhelni :)

Hja... De ha valami keves van, az mar tud enni. Igazabol ezt tole kene megkerdezni, es az alapjan lehetne agyalni realisan ^_^"

Az tuti hogy az en gepemen segitene +1 proci, mert itt eszik mindenfele okos dolog sokat :)

[quote:c54a17df4d="drojid"]
[quote:c54a17df4d="algernon"]Azt lehet meg esetleg kiprobalni, hogy win2k/winxp + colinux, hatha a ugy gyorsabb a dolog, mint vmwarezva..

Hát nem tudom, szerintem elvileg ez nem gyorsabb, mint egy linux+wine kombináció, de a colinuxot nem ismerem közelről.

Ha csak annyira gyors, mint wine az mar jo. Az gyorsabb sokszor, mint vmware :)

(colinuxot egyebkent en is csak hallasbol ismerem)

java van, de browser-plugin csak blackdownhoz, es azis eleg instabil

OOo van

flashbol meg egy gplflash nevu cucc, szinten eleg kezdetleges/instabil

[quote:af100b187e="lacipac"]Ez így igaz, épp ezért meg lehetne próbálnia bochs-sal, az nem emulálja a teljes hardware-t, ezért jóval gyorsabb is, ráadásul open source project.

:lol: :lol: :lol:
Te most nem azért, de tudod, mi az a bochs? :)
Az nem csak a perifériákat emulálja, hanem még a CPU-t is, azért legalább egy nagyságrenddel lassabb...

Utánanéztem, kettővel:
Bochs executable compiled from the Bochs CVS on Jul 10 2003 with no configure options. The option 'pit: realtime=1' was used to have an accurate time measurement inside Bochs.
...
TEST (itt benchmark adatok vannak)
...

Bochs is about 270 times slower than native code on integer code.
( http://fabrice.bellard.free.fr/qemu/ )
Ennél a qemu is 65x gyorsabb, pedig az is emulálja a cpu-t.

Ehhez képest a vmware csak a sallangokat emulálja, így LÉNYEGESEN gyorsabb.

[quote:f3a7a11e96="x-daemon"] aha.
hát nem ismerem az IA64-et, de PPC/PPC64-en az utasítások 32 bitesek,
van 32db 32/64 bites GPR regiszter (kb. egész), 32db 64bites FPR (lebegőpontos), 32db 128 bites VR (amelyikben van vektor aritmetikai egység)

annyiban igazad van, hogy az i386-osnak vannak 8 bites és 16 bites utasításai is emlékeim szerint :) , így egy RISC gépi kódú program hosszabb egy CISC gépi kódú programnál, de az architektuális különbségek miatti méretkülönbség:
1. egy program a lemezen nem csak utasításokat tartalmaz, hanem adatokat is és azok mérete egy CISC vagy RISC-re lefordított programnál lényegében nem változik.
2. egy program a memóriában általában sokkal több adattal dolgozik, mint a program mérete, így a teljes felhasznált memória aránya még tovább csökken.
3. ha megnézed pl. a ppc-re és a i386-re lefordított deb csomagok méretét, ugyan nem mindegy hogy egy csomag 1M vagy 1.1M? (csak hasraütöttem, felőlem lehet 1M vs. 1.5M is :)

a 32bit és 64bit -re lefordított programoknál (csak a PPC-ről tudok nyilatkozni):
1. az utasítások mérete nem változik.
2. egy 64 bitesre lefordított program olyan esetben ahol a 64bit előnyére elegendő 1 utasítás a végrehajtáshoz, ott rövidebb lesz mint a 32bites megvalósítás, ahol ezt több utasítással kellett megvalósítania.
3. lehet hogy sebességre optimalizálás miatt egy 32bites alkalmazásnál egy változót 16bitesre veszek, mert tudom hogy össze kell szorozni egy ugyancsak 16bites változóval, és így gyorsabb lesz a program, míg ha 64bites platformon dolgozom, ott lehet hogy 32bitesre veszem a változót, így tényleg több helyet fog elfoglalni mind a lemezen mind a memóriában, ellenben nem lesz sebességcsökkenés és a program tartalékai (ilyenekre gondolok itt mint maxint, stb.) által jóval tovább nem kell hozzányúlnom (akár forrásszinten) úgy is működni fog.

Az IA64 utasitasok 128 bitesek (bar ez harom gepi utasitast tartalmaz egybecsomagolva). Emiatt VLIW (Very Long Instruction Word) architektura.

A 64 bites forditoknal nem ugy tortennek a dolgok, hogy pl. az int merete az altalanos celu regiszterek meretevel egyezik meg? Azaz ha 64 bitre forditasz akkor 64 bites, ha 32-re, akkor 32 bites?

Emiatt egy int a[1000000] tomb eleve 4 mega illetve 8 mega lesz. Ha a heapen foglalod, akkor a programod merete nem lesz nagyobb, de runtime-ban lesz kulonbseg meretben.

1Mega VS 1.5Mega nem veszes bar megjegyzem, hogy van mar 1Megas L2-vel rendelkezo proci (tobb is), ugyhogy egeszen durva kulonbsegek is elofordulhatnak (probald ki!!!!). De egy 64 vs 92 mega vagy 512 vs 768 megas runtime mar mellbevago dolgokat hozhat.

Az utasitasoknal az a problema, hogy a Power, Alphap, SPARC, PA-RISC, Itanium es tarsai LOAD/STORE RISC utasitaskeszlettel birnak. Azaz a legtobb gepi utasitas regiszteren tud csak dolgozni. A memoriamuveleteket csak a LOAD illetve a STORE utasitasokkal lehet megvalositani. Az x86-on legtobb utasitas egyik operandusnak elfogad memoriacimet is. Ergo sokszor 2-3 RISC op == 1 x86 op. Ofkorsz ettol meg jo dolog RISC, mert azt a generalt kodot viszont a compiler remekul tudja optimalizalni, szemben az x86 generalt koddal, ami inkabb kezzel hangolhato jol. De ez nem valtoztat a tenyen, hogy maga a RISC binary nagy.

Andrei

Na akkor most en is meselek:

Kb. november eleje ota nyuzok egy AMD64 3000+-t 512 Mbyte Rammal.
A videokartya egy NVidia 5500.
Debian for AMD64 lakik rajta.

Tapasztalatok:
desktop eseten macera van a flash-el, a java pluginnel es az openoffice-al.

Az Nvidia 7676-os drivere hibatlanul megy. Az elmult ket honapban a gep nem fagyott, nem lassult le ok nelkul. A proci huzamosabb teljes terhelesnel se ment 57 fok fole...

Jatszani csak a FooBillard-al es az Armagetron-nal szoktam, de azok csont nelkul mennek.

Beszeljunk egy kicsit a felvett teljesimenyrol is!
Engem erdekelne hogy olcsobb fentartani egy bizonyos szukseges proc. teljesitmenyt?
- Tobb kissebb gep szukseg eseten ki-be kapcsolgatva,
- oszevonni amit lehet mert sleep-ben a proc amugy sem kajalja az aramot?

hát attól függ mire használod a gépet. pl. ha éppen shrek 3-at készítesz otthon, akkor szerintem érdemes lenne befektetni, de ha csak mindennap hallgatsz délután egy kis mp3-at, meg hetente megnézel egy dvd-t, akkor nem látom értelmét.
Én úgy állok az ilyen kérdésekben, hogyha a mostani működik, akkor minek cseréljem le? amit én használok az elég gyorsan megy így is, a többi meg annyira nem izgat.

Mi a különbség alapvetően a két felépítés között?

Az egyik 32 bites, a másik 64 bites.

A Linux menyire tudja ezeket a lehetőségeket kihasználni?

AFAIK eléggé

Nem túl drága váltani erre?

no ez engem is érdekelne...

[quote:8f1468b475="gyomber"]
Nekem most egy P IV 2,6-osom van, érdemes váltani? :roll: :roll: :roll:

Manapsag mar ilyen gepeket adunk el (A64-2800/3000) jatekgepnek. 32-biten is sokkal gyorsabb mint egy P4, es 29 fokos....

Szervernek tuti, a 64 bites sarge pl. nagyon szepen megy apache es psql-el.

Akkor eri meg cserelni, ha hangos a geped.... A 64 bit miatt meg ne fajjon a fejed :-)

[quote:a287be5445="gyomber"]Mi a különbség alapvetően a két felépítés között? Mekkora előnyt jelent a 64 a 32-vel szemben. Mi ennek a gyakorlati haszna egy desktop rendszerben? Milyen alkalmazásoknak kedvez? A Linux menyire tudja ezeket a lehetőségeket kihasználni? Nem túl drága váltani erre?

Bocsi a sok kérdésért, de ezek nagyon érdekelnek...
Nekem most egy P IV 2,6-osom van, érdemes váltani? :roll: :roll: :roll:

Software szinten Linux-szal nem drága váltani rá. A hardware költésgek megítélése pénztárcától függ és elég tág határok között változhat.

Ajánlom figyelmedbe a következő HUP cikkekben hivatkozott Anandtech cikkeket:
https://portal.fsn.hu/modules.php?name=News&file=article&sid=6641
https://portal.fsn.hu/modules.php?name=News&file=article&sid=6671
https://portal.fsn.hu/modules.php?name=News&file=article&sid=6933

A tesztek tanulsága szerint egyes alkalmazásokban megéri a 64bit. Pl.: adatbázis, encryption.

Üdv,
Dw.

Én arra lennék kíváncsi, hogy 64 biten a mencoder mennyivel gyorsabban tömörít mint 32 biten. Ha valakinek van jól belőtt 64 bites rendszere, akkor szívesen küldenék egy tesztfájlt, amit megadott paraméterekkel kellene átkonvertálni. Az ídőeredményeket már össze lehetne hasonlítani.

[quote:195adbe081="gyomber"]Mi a különbség alapvetően a két felépítés között?

Az egyik 32, a masik 64 bites. 64 bites elonye hogy altalaban tobb ramot tudsz belegyomoszolni, es alapbol, Large File Support nelkul tud nagy fileokat kezelni. Meg amugy is nagyobbakat tud, mint 32 bites.

Persze ahany 64bites architektura, annyi elony es hatrany :) Mas elonyei vannak amd64-nek, mips64-nek, ppc64-nek, sparc64-nek meg alphanak. (ia64nek meg csak hatranyai, de psszt)

[quote:195adbe081="gyomber"]Mekkora előnyt jelent a 64 a 32-vel szemben. Mi ennek a gyakorlati haszna egy desktop rendszerben?

Desktopon kb semmi haszna szereny velemenyem szerint. Szerver oldalon van haszna, desktopon erosen ketlem. Foleg hogy pl videokartyak tamogatasa 64 bites platformon siralmasabb, mint 32 bitesen. Szal 3D-s jatekokat jatszani pl eselyed nincs, kb.

[quote:195adbe081="gyomber"]Milyen alkalmazásoknak kedvez?

Adatbazis-szervereknek, rengeteg szamitast igenylo alkalmazasoknak (render falm, molekularis biologia, atomkutatas, etc) pl biztos.

[quote:195adbe081="gyomber"]A Linux menyire tudja ezeket a lehetőségeket kihasználni?

Leven hogy az elso linux port 64bites architekturara kb 1996 fele elkeszult - ugy gondolom elegge jol ki tudja hasznalni :)

[quote:195adbe081="gyomber"]Nem túl drága váltani erre?

Attol fugg. Egy regebbi alpha relative olcso. Egy ujabb, vagy egy amd64 - gondolom itt x86 kompatibilis rendszerben gondolkosz - mar dragabb. ppc64, sparc64 meg plane. s390x-et meg ha veszel otthonra, akkor meg kell hivnod latogatoba, feltetlenul.

[quote:195adbe081="gyomber"]Bocsi a sok kérdésért, de ezek nagyon érdekelnek...
Nekem most egy P IV 2,6-osom van, érdemes váltani? :roll: :roll: :roll:

Szerintem desktopnak nem eri meg, legalabbis meg nem.

[quote:eb38e991f0="algernon"]
Persze ahany 64bites architektura, annyi elony es hatrany :) Mas elonyei vannak amd64-nek, mips64-nek, ppc64-nek, sparc64-nek meg alphanak. (ia64nek meg csak hatranyai, de psszt)

Ez is olyan divat-utálat, mint a "Windows alapból szar"?
Meg tudnád indokolni, hogy az IA-64-nek miért csak hátrányai vannak? (azon kívül, hogy nem fut rajta a DOS, meg a 32 bites windows alkalmazások is lassúak, más bootolási és particionálási metódust használ mint az Intel 8086)

[quote:659acbefb5="bra"][quote:659acbefb5="algernon"]
Persze ahany 64bites architektura, annyi elony es hatrany :) Mas elonyei vannak amd64-nek, mips64-nek, ppc64-nek, sparc64-nek meg alphanak. (ia64nek meg csak hatranyai, de psszt)

Ez is olyan divat-utálat, mint a "Windows alapból szar"?
Meg tudnád indokolni, hogy az IA-64-nek miért csak hátrányai vannak? (azon kívül, hogy nem fut rajta a DOS, meg a 32 bites windows alkalmazások is lassúak, más bootolási és particionálási metódust használ mint az Intel 8086)

Éppen ez a baja. Minthogy egyenlőre a szoftverek töredéke 64Bites, és mert a 64Bit-es program nem is feltétlenül előny minden esetben, ezrt igenis nagy hátrán, hogy a 32Bites emuláció nem teljesen kompatibilis és lassú. Főleg akkor, ha ezt a konkurencia tökéletesen meg tudta oldani és még olcsóbb is. (AMD64)

Persze már ez sem igaz, mert az új IA64-be "átcsorgott" az AMD módszere és ezekben már használható a 32Bites emuláció.

A 64-32 Bitről meg annyit: Egy 64 bites program 64 bites címeket használ. Ennek az előnye az, hogy több memóriát tud egy process allocalni.
Nem több és nem kevesebb. Ha egy gépben van 512MB memória semmi értelme nincsen. Ha gyorsabb lesz, akkor azért gyorsabb, mert a 32bites emuláció is gyorsabb.

Ami még jobb, az a memóriakezelés hardware-esen. Az AMD 64 tud egyszerre írni és olvasni a fizikai memóriából. Ez sokat gyorsíthat, de jelenleg nagyon drága. (spéci memória kell hozzá)