64bit de erdemes?

Notebook, laptop, mobiltelefon ...

Hi,
lattam mar sok hozzaszolast a 64bit mellett es ellen is.
no mar most desktopra erdemes 64 bites oprendszert hasznalni ?
ha igen milyet ?
en most egy gentoo -t gyurok de az nvidia sehogy sem szeretett meg :(
es mar lassan kifogyok az idobol ..., hasznalnam stabilan.

szep napokat
zsomi

  • 5494 megtekintés

( csearo | 2007. 10. 17., sze – 09:21 )

Szerintem csak akkor érdemes szivni vele, hogyha 4 GB-nál több memória van a gépedben.
Az enyémben ugyan csak 1 GB van, de azért kipróbáltam egy 64 bites gentoot. Több szívás amiatt volt, mert a 64 bites libek mellett kellenek a 32 bitesek is, mivel van pár plugin/progi, ami csak úgy fut tudtommal. Ezekre explicit oda kell figyelni telepítéskor.

Futásidőben én nem mértem jelentős gyorsulást, csak 5-10%-osat, de olyan is volt, hogy vmi lassabban futott, mint 32 biten. Ez állítólag a dupla hosszúságú pointerek nagyobb cache-fogyasztása miatt van. (Tömörítgetést, hash-kód számítást próbálgattam tesztelés gyanánt.)

Szóval szerintem az egyetlen ok, amiért érdemes használni, ha a címtartomány miatt kell a 64 bit (tkp. ezért is találták kis szerintem), amúgy felejtős.

Nem kell ahhoz tobb mint 4 giga, 3 giga felett ha hasznalni is akarod akkor mar nem art a 64 bites, mivel a 4 giga a cimzes, amiben benne van.

Egyebirant nekem mindig csak a szopas volt a 64 bites oprendszerekkel, mind linux(debian) mind windows (XP) teren.
Nem olyn regen fejlesztettem a gepemet, es miutan megvettem bele a 4 giga memoriat tudtam meg hogy ne is almodjak rola hogy azt barmi is hasznalni fogja normalisan 32 bites rendszeren.

------------------
- The Question is: What is mahna mahna?!
- No! The question is: Who Cares!

Szoktam értékelni, ha pl. virtuális gépeket futtatok, nem kell spórolnom a rammal (előbb XP betöltött 5-6 mp. alatt, adtam neki 1G-t. Host XP bootol 15-ből helyből, gondolom a virt-disk benne volt a fajl-cache-ban).

Amúgy igen, legtöbb feladatra a 2G is bőven elég. Játékoknál se láttam még nagyon olyat, aminél sokat számított a +2G. (Bioshock-t próbáltam, C&C:TW, HL2ep2-t végigvittem, mást nem próbáltam).

Viszont volt már olyan szitum, hogy szerveren (2G fizikai ram, de eléggé ki van használva) a MySQL azt mondja, hogy most nem talál 1900 mega szabad ramot, nem tudja megjavítani (az egyébként nem nagy, kb 70 megás) sérült adattáblát.

Viszont normalis chipset ES bios az igy elerhetetlenne valt teruletet atmappeli a 4G feletti teruletre, amit PAE-vel x86 arhitekturan is elerheto. Megfelelo operacios rendszerrel persze. Windozikszpevel (x86) nem fog menni. Pedig allitolag tudnia kellene neki a PAE-t boot.ini megfelelo kapcsolojaval, de a tapasztalatom az hogy akkor is csak 3.5G-t lat ha /PAE-vel inditom.

miutan megvettem bele a 4 giga memoriat tudtam meg hogy ne is almodjak rola hogy azt barmi is hasznalni fogja normalisan 32 bites rendszeren.

HIGHMEM64G + X86_PAE, es a 4G-t siman kezeli x86 alatt is hacsak nem nagyon bena a bios/chipset. Szoval csak merjel nyugodtan nagyokat almodni :-P 


compi@arwen-d32:~$ free
             total       used       free     shared    buffers     cached
Mem:       4151104     136196    4014908          0       6248      62584
-/+ buffers/cache:      67364    4083740

jaja PAE-val tisztaban vagyok,

Csak hat 4 gigat azert vettem hogy memoriabol ugye sosem eleg, es most hogy sok ev utan ujra fejlesztettem gepet, gondoltam felrakok egy winfost hogy kiprobaljam a mai divatos gamakat.
Windows XP baromira nem tamogatja ezt, Vistat nem fogok felrakni. XP64 meg egy rakat ....
Es ami poen hogy ahogy olvastam windows 64 (xp es vista is) ha 32 bites alkalmazast futtat(minden jatek pl) akkor ugyanugy 32 bites kornyezetben futtatja ahol is 4 giga a cimzes limit, PAE-t meg max a w2k3 vagy a Vista tud mivel ugye ez "forradalmian uj" technologia

------------------
- The Question is: What is mahna mahna?!
- No! The question is: Who Cares!

J2EE + Tomcat5 gyakorlatilag random módon összeomlott deployozás során, vagy csak úgy magától. A memórifoglalás csak nőt és nőt: 3-4 óra után a java 16GB ot használt már...

Rengeteg fórumon találtam bejegyzéseket a hibáról de megoldást sehol. Igazából azt sem derült ki, hogy Tomcat vagy Linux hiba, viszont ez a Tomcat hibátlanul működik minden más nemlinuxon.

Egy teljesen azonos J2EE+Tomcat config futott egy egy teljesen azonos vason Solaris 10-el stabilan. A linuxal azért próbálkoztam meg mert Oracle 11g-t kell használnom, és egyenlőre csak linuxra elérhető Solarisra nem. Ha meg lesz Solarisra az Oracle akkor az is oda kerül. Annyira nem voltam elvetemült hogy Windowst rakjak be az Oracle alá... :)

Szóval 2 hónapnyi hangolgatás és kudarc után született a döntés a Solaris 10-re; valamint kikerült Linuxra az Oracle. Most minden megy flottul, hibanélkül, nem görcsölök éjszakákat stb...

Ez a Tomact+J2EE rendszer évekig ment Debian 3.1 -en stabilan.

Egyébként amikről beszéltem intranet szerverek, tehát fontos a stabilitás.

Még annyit a témához, hogy én nem eröltetném egyenlőre a 64 bitesre váltást ha nem szükséges... Nálam az volt. Játszadozni, próbálgatni egy desktopon lehet.

Na sok mindent rá lehet fogni a 64 bitre, hogy miért nem jó, desktopra pl. tuti nem raknék.

De szerintem Java-s cuccok alá igenis jó.

Mi használunk jó sok 64 bites szervert 4-16GB RAM-mal. Java-val sose volt gond.
Pontosan milyen verziójú JVM-et használtál milyen processzoron és milyen oprendszerrel?
Milyen JVM kapcsolókkal?
Egyébként mi az a J2EE+Tomcat?

--
Gabriel Akos

az alkalmazás rögtön a deploy után az alábbi üzenettel elszáll:

java.lang.OutOfMemoryError: PermGen space

type Exception report

message

description The server encountered an internal error () that prevented it
from fulfilling this request.

exception

org.apache.jasper.JasperException: Servlet execution threw an exception

org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWra
pper.java:455)

org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:3
77)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)

root cause

javax.servlet.ServletException: Servlet execution threw an exception

org.apache.jasper.runtime.PageContextImpl.doForward(PageContextImpl.java:688
)
org.apache.jasper.runtime.PageContextImpl.forward(PageContextImpl.java:658)
org.apache.jsp.Proba_jsp._jspService(Proba_jsp.java:80)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)

org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:3
34)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)

root cause

java.lang.OutOfMemoryError: PermGen space

note The full stack trace of the root cause is available in the Apache
Tomcat/5.5 logs.

És ezt mindíg így történik Linuxnál, ugyan ez a szerver konfig Solarison stabilan működik.
Persze nem vagyok Linux expert, mert Solarist használok, de azt gondolom hogy Debian64 sem igényel űrhajósvizsgát, egy java fordító használatához. Talán valaki megmondja mit csinálok roszzul. A gépben 12GB REG ECC van, ami munka során hamar elfogy. Ennyire azért nem erőforrás igényes egy pár JSP script.

Sparcos solarison? Ott azért megy, mert más a JVM memória alapkonfig. De lehet hogy az inteles solarisos JVM alapkonfigja is más.

-Xmx kapcsoló csodákra képes.
Meg van valami -XX:PermGenSpace vagy hasonló kapcsoló, ott is be kellhet állítani. 64 biten értelemszerűen hamarabb elfogy a permgen a nagyobb pointerek miatt.
Java memória kezelésről érdemes guglizni, fontos hogy pontosan a megfelelő JVM-re való beállításokat használd, mert ez al-alverziónként is változhat.

--
Gabriel Akos

Én úgy tudom hogy windows 64 (xp es vista is) -en nem lehet már 32-bites alkalmazást futtatni direktben.

A xp x64 telepítés után kvázi 2 windows "rendszerkönyvtárat" pakol fel. Van a normál Windows\System32 (ebben vannak a 64bites göncök), meg egy Windows\WinWoV64 vagy hogy hívják (ebben vannak a 32bites cuccok futtatásához szükséges göncök.

Tehát neked semmit nem kell tenned. A 32bites alkalmazásokat "kezeli" a rencer.

Ennek egy spéci vírus/féreg fertőzés esetén megvan az az úm. "előnye", hogy az jóeséllyel csak a 32bites rendszerkönyvtárat fogja "összefertőzni". A 32bites bites prg-k számára ua. System32=WinWoV64. (tehát egyfajta ~chroot), ez persze a 32bites védelmi programokra is vonatkozik... Hátránya hogy a 32bites alkalmazasok futtatása mindig lassabb lesz, mint "normál 32bites" rendszeren.

Ua. van pl. IE64bites böngésző ami a 32bites nemkívánt "pluginokat" szintén nem fogja összeszedni. Persze a kívántakat sem (java plugin, flash plugin, WindowsUpdate ActiveX). (azokra 32bites IExplore.exe-t kell használni. A windowsupdate activeX nem elírás. Nincs 64bites verziója. legalábbis pár hete még nem volt. Iexplore (64) -el windowsupdate.com azzal kezdni, hogy akkor van 30 msp kivárásod amíg elindul a 32bites . ;-)

2féle Program Files könyvtár van, van a normál meg a Program Files (x86). utóbbiba kerülnek a 32bites göncök.

Másik amit sokan nem tudnak,hogy a 16bites programok, DOSos cuccok támogatása xp x64 alatt nem létezik. Ahhoz már DosBox kell, vagy virtuális gép.

Tehát a 32bit Kb. ua. működik linux alatt is, van a 64bites library, meg az ia32libs csomag amit fel tudsz tenni, ha a kernelben van IA32emu támugatás.

Én a 64-bites Linuxal is nagyon sokat szívtam SZVSZ nagyon nem stabil.

Ez konkrétan miben merült ki, csakhogy "leendő áttérők" is tudjunk róla?...

milyen KErnel_bug, stb...

Jóvan 2 sorral lejjeb kiderült. Hát a java az sajnos ilyen. Tjképpen nem a 64bites linuxxal volt a probléma, hanem hogy 64bitre nincs normális java támogatás.

Megmondjuk amúgy is érdekes egy dolog a java. valami saját "jelzéskezelő cucca" van. Mert alapértelmezés szerint a normál működéshez "sig11-jeleket" használ. (segmentation fault). Nálam úgy "bukott le" néhány éve, mikor a grsecurityben bekapcsoltam a signal logging funkciót, és java pluginos webes kártyázásnál/sakkozássi "szünetekben" irssi-zve ;-) a tty3-ba belerondított a kernel signal 11 java akármi pid mindjárt 8 darab. átváltok grafikusra és semmi baja a java appletnek, csak néhány régi java-s "pid"-es applikum "megsemmisült", és helyettük újak keletkeztek, de a program ment tovább. :)

----------------

Nem a zsömle kicsi, a pofátok nagy...

Mert mint irtam is jatszani akarok kicsit mindenfele modern izevel(BioShock pl kifejezetten bejon).
Es akarki akarmit mond Linux alatt nem lehet johetnek cedegaval meg wine-al egyik se jo.
Amugy baromi idegesito igy tobb ev linux utan a windows :), elso 2-3 hetben sik ideg voltam minden apro faszsagatol.
------------------
- The Question is: What is mahna mahna?!
- No! The question is: Who Cares!

( bokonon | 2007. 10. 17., sze – 12:04 )

Nekem 1,5-2 éve van fenn 64 bites gentoo és még most is sok mindent 32 bites lib-ekkel kell futtatni: firefox a flash miatt, openoffice, mplayer-bin ha win32 codec-eket használsz, stb.
Gentoo-val 64 biten sem volt semmi gond, viszont nem nyújt semmivel többet mint 32 biten. Gyakorlásnak jó kipróbálni ezt is, egyébként hanyagolandó a téma.
__________________________________________
Sex the unix way: unzip; strip; touch; finger; mount; fsck; more; yes; umount; sleep; exit 0

Koszi, direct rendering nekem is van, de neha fagyogat a gep. vagyis egy az egybe sotet kep lesz :(
ha ctrl+alt+del akkor szepen ujraindul ... :)

no ezt nem tapasztaltam, mondjuk ubuntuval. (csak most megint rendszert cserelni..., nem lesz erom egy 32 bites gentoo-t felhuzni)

no mindegy koszonom.

( lacika v | 2007. 10. 17., sze – 14:14 )

Kezd kedvenc indoklásommá lenni "csak akkor kell 64bit, ha 4GB vagy több van a gépben".
Ez igen megalapozott válasz. Nem kell 64bit ahhoz, hogy a linux kernel meg tudja címezni a 32bit feletti részeket.
Csak a megfelelő opciót kell kiválasztani a kernel forgatásakor.
Szerintem meg desktopra nem igen kell. A driverekkel és pluginekkel folyamatosan madárkodni kell. Felejtsd el szerintem. Semmi extrát nem nyersz vele, max. több szívást. De ha mazohista vagy .... :)

--
http://laszlo.co.hu/

Szerintem az altalad idezett indoklas nagyon is megallja a helyet. Kulonbseg van akozott, hogy mekkora nagysagu (4GB-64GB) cimeket tud megcimezni, vagy hogy mekkora annak a cimtartomanynak a merete, amit megcimez.
Attol meg, hogy meg tudja cimezni a 32 bit feletti reszeket, nem fog tudni egy adott processzhez 4GB-nal nagyobb memoriat hozzarendelni. (Pl. egy 4 GB-nal nagyobb meretu fajlt nem tud bemappelni a processz virtualis cimtartomanyaba.)

Igazad van. Típikus eset, hogy egy laptopon futó oprendszer egyik folyamata 4GB memóriánál többet szeretne.
Ha így is lenne, akkor az illető úgy sem laptopon fog dolgozni....
Azért vegyük figyelembe a környezetet is, hogy mit is szeretne az emberünk.
Megint más lenne a helyzet, ha pl. Oracle alá tervezne valaki vasat, akkor tuti javasolni lehet meki egy 64bites OS -t alá/mellé/felé. De egy notebookra, ami desktop célokra lesz.....

--
http://laszlo.co.hu/

( emberk | 2007. 10. 17., sze – 15:08 )

Attól függ mire kell. Simán elfut rajta egy 32-bites is ha csak desktopot akarsz akkor elég a 32-bites rendszer is de szerintem nem 5-10%-al lassabb szerntim kb 30-35% (én ennyit m,értem a mencoderrel, és az általam írt nuemrikus matematikai algoritmusokkal), de egy desktopnál ha tényleg cak net meg esetloeg 1-2 játék miatt kell akkor belefér a 32-bit is. Nekem is gentoom-volt, aztán kihalt (akár szerencsére is mert felraktam a frugalwaret), az pure amd64, viszont van rajta egy remekbeszabott chroot32- környezet. (Örök hála a fejelszőknek) Na azt én jól meghekkeltem ,ert szerintem túl volt banyolítva azóta fut az emulált környezetben a 32-bites firefox,javapluginostól flashostól STABILAN!!! Persze a flash az jó szokásához hűen néha lefagy. De az 32-biten is fagyott. Írtam patchet meg howtot a az emulált környezethez ha kell küldöm. (DE csak frugalware alatt megy a dolog, ugyanis ahoz írtam).

( uid_4672 | 2007. 10. 17., sze – 17:01 )

van, amikor kell 64 bites rendszer. még laptopra is.
nekem is nvidia kártyám van 64 bites linuxon, nincs bajom vele: a 32 bites libeket nem az installerével rakatom fel, hanem manuálisan kicsomagolom (másképp összevegyül valamikkel), de utána semmi gond.

:D Ez alapos indok. Egylbként soha nem értettem, miért akarják az az embert lebeszélni, a 64-bitről sokal gyorsabb, és iszonyat sok előnye van emiatt, a hátrány, hogy nem tudom nézni a "csudiszép" flash animációkat. A javaplugin hiánya pedig csak firefox esetén baj. Viszot vagy 1,3-1,6*gyorsabban tömörít. A képfeldolgozás dvd-rippelés, csomagolás, hasonlóan gyorsabb. De böngészni valóban nem a legoptimálisabb, ha fontosak a flashek, és ragaszkodok a firefox+java pároshoz. Ezen kívül ninc hátránya szerintem. Talán a vmw-k és a rm-filek még amik bajosak lehetnek, de ezek egyre kevésbé fontosak szerintem.

Mondjuk ez is igaz mert nekem a nyomtatót nem sikerült beizzítani eddig, mert egy zárt kódú driver van hozzá, és az is 32-bites, de azt olvastam, hogy túl sokat nem veszítettem vele mert piszokúl bugos. Nyomtatok win alatt ez van (gyak ezért van win-em is, mert az infraportom a telómhoz, és a nyomtató nem megy linnel, ja meg morrowind 2-3 havonta, csak mindíg elfelejtem hogy hol tartok és jegyzetelnem kell). A tickless kernel meg szerintem laptopnál igazán fontos, egy asztali gépnél szvsz mindegy. +-30 watt a laptopnál ez sok sok üzemóra.

Nekem chroootban megy az opera falshal, amit sosem használok, de a párom szeret honfoglalózni, a javat is megcsináltam, de cask azért mert kíváncsi voltam, hogy sikerül e. Hátha jó lesz valamire eddig semmire nem használtam max a szrakoztatásra használom ezekt.

Érdekes, mert én nem tapasztaltam ekkora gyorsulást. A töredékét csak.
Találtam pár oldalt, ahol mások sem láttak érdemi gyorsulást 64biten:
phoronix cikk

itt van egy jó kis összehasonlítás gentoo-ra

ez az oldal szerint is főleg csak szerverbe való a 64 bit (főleg az openssl-t meg a mysql-t találták gyorsabbnak)

Hmm, én nem ezt tapasztaltam. Nekem a gzip is jóval gyorsabb. A mencoder is. (a mencodernél mértem 30%-ot). Mit mértek ezek? Szerintem ez kamu. Mondjuk avlóban fura volt nekem hogy a lame 32/64-ből nekem a 32-es voklt gyorsabb kb 3-4%-al. De minden másban sokkal gyorsabb volt a 64-bit. Na mindegy. Ezek szerint hitvallás kérdése.

Annyiban igazad van hogy, akkor volt gyorsabb 60%-al a programom ha kifejezetten 64-bitr lett írva (egy kis asm), kb 20-25%-ot lehet elérni sima fordítási opciókkal, az "izomműveletek" terén.

Gyorsulasnak szerintem kell lennie (en nem mericskeltem), mert ketszer annyi hasznalhato regiszter van,ezert kevesebbszer kell atmenetileg kiirkalni memoriaba meg visszatolteni regisztereket (register spill) - es ez eleg nagy elony.

szerintem bizonyos esetekben azert nincs gyorsolas - pl. szerintem lame eseteben - mert lehet, hogy bizonyos assembly optimalizaciokat meg nem portoltak 64 bitre, ezert 64bit alatt nem az optimalizalt assembly rutint hasznalja nehany program, hanem a sima C rutint.Ezt nem ellenoriztem, de mast nem nagyon tudok elkepzelni.

- Use the Source Luke ! -

Szerintem is itt lehet a kutya elasva: az keves, hogy 64bitesre van leforditva, arra is kell hogy legyen megirva. Es ez meg is magyarazhatja, hogy bizonyos progiknal miert lehet gyorsulast tapasztalni, nemelyiknel meg miert nem.

Ez viszont jo hir, mert akkor csak ido kerdese, es tenyleg sokkal gyorsabb lesz 64 bitest hasznalni.

Én is ide jukadtam ki. Egyszerűen ha egy proci egyszerre több dolgot tud végrehajtani akkor jó program esetén tuti gyorsabbnak kell lenni. (Iszonyú bölcs votam). Szerintem nem feltétlenül kell a c-kódot hegyezni 64-biter, de a fordítót nagyon, ha meg asm-et raksz bel akkor ott figyelni kell, és úgy jár az ember mint én hogy +60%

( uid_16313 | 2009. 08. 28., p – 13:21 )

A topic indítása óta eltelt majdnem 2 év.
Sok érv van még mindig pro és kontra.

a minap olvastam a GCC manualban, hogy pl. az

-mfpmath=387 az i386-ban az alap, míg az amd64-ben ugyanez:
-mfpmath=sse

A kérdés az, hogy az FPU utasításkészlet mire van pozitív és negatív hatással?

A kérdés főleg FreeBSD specifikusan érdekelne, de általánosságban is várnék mindenféle konkrét tapasztalatokat!

szerk: még egy dolog. Olyat is olvastam már pl, hogy 64 bites rendszeren szebben szólt az alaplapi audió... Ez így első nekifutásra eléggé megmosolyogtatóan hat, de jobban belegondolva nem is nagy baromság...