Ubuntu: 32-bit v. 64-bit teljesítmény

Címkék

Nem egyszer felmerült már a kérdés, hogy van-e értelme 64 bites desktop gépen 64 bites Ubuntu-t használni a 32 bit-essel szemben. Van aki szerint nincs ( o/ ), mert több vele a gond, mint amennyi haszna van, vagy aki szerint van. A Phoronix készített egy tesztet, amelyben lemérte az Ubuntu Edgy és Feisty x86 és x86_64 verziói közti teljesítmény-különbséget ugyanazon a gépen. Tanulságos. Itt.

Hozzászólások

Arra nézve, hogy cserébe a szívásért, workaround-okért, stb. nekem minimum kétszer gyorsabb eredményeket kellene produkálnia a 64 bites Ubuntu verziónak a 32 bitessel szemben a kulcsterületeken, hogy egyáltalán fogalkozzak azzal a gondolattal, hogy a 64 bites verziót telepítsem, most 2006-ban desktop-ra.

--
trey @ gépház

A Kiskapunak van egy könyve, IBM Linux kiszolgálók tejesítményének fokozása, vagy valami hasonló a címe. Abban az író azt állítja, hogy nem érdemes szerveren sem a 64 bitet használni, ha nincs szükség 4G+ memóriára, mert sok esetben még lassabb is. Mondjuk konkrét példákat nem hoz fel, de pl a cache rosszabb kihasználásával indokolja a dolgot.
ESRnek úgy látszik igaza van, amikor azt fejtegeti, hogy csak akkor éri meg váltani, ha kell a plusz memória. Én csak abban nem vagyok biztos, hogy desktopon már 2008-ban eljön ez az idő. (Nem hiszem, hogy az MS erőltetné a dolgot, lásd ESR írását.)

Ja ott lenne. De szerintem nem is az az A64 elonye, hogy 64 bites, hanem az, hogy bevezettek +8 alatalanos celu regisztert, amit ha jol tudom az SSE es a 3D-Now is hasznalhat.
Az x86-nak alapbol egy szutyok, retek regiszterkeszlete van, van 4 regisztere (EAX, EBX, ECX, EDX) amik altalanos celunak vannak hazudva, de valojaban meg ezek sem azok.

Hat azert van meg ott ESI, EDI, EBP is... sot anno assemblyben neha meg az ESP-t is felhasznaltuk ha sokat kellett szamolni es epp nem kellett kozben stack :)

Masreszt 32 bites modban (szemben a 16 bites XT/286 moddal) mar nincs (annyira) megkotve ezeknek a funkcioja, gyakorlatilag barmelyikkel csinalhatsz barmit. 1-2 kivetel van scak, pl. a 64 bites szorzas/osztas eredmenye mindig edx:eax-be kerul stb, de pl. 32 bites szorzast csinalhatsz barhova (IMUL ECX,[mem] stb).

MMX/SSE meg eddig is rendelkezett eleg sok kulon regiszterrel (mondjuk MMX az shared az FPU-val, windoz kompatibilitasi okokbol, de altalaban ritkan kell a 2 egyszerre ugyh nem akkora baj).

Na csak azt akartam mondani, hogy nem erzek nagyobb kulonbseget a 32 es a 64 bites utasitaskeszlet kozott mint mondjuk ket P4 generacio kozott (p4 es core utasitasok vagy sse vs. sse3 pl).

Masreszt jo lenne ha a fenti tesztet nem i586-ra optimalizalt koddal vegeztek volna 32 bites oldalrol, hanem min. i686 de inkabb p4.

A'rpi

Az a + 2 regiszter amit 64 bites használatban ki tudsz használni az AMD procikon 64 bites módban az nem dob annyit bele valóban... Viszont gondolj arra, hogy lassan eljutunk oda, hogy 4GB lesz desktopon is. 99ben nekem 64MB volt.. most 1GB előbb utóbb eljutunk a 4Ghez is. Nem most, talán 2-3 év múlva. Ha azt vesszük akkor most még a két vagy több magos prociknak sincs létjogosultsága, hisz nem tudja rengeteg program kihasználni, de az, hogy ezek most megjelentek egy fejlődési irányt mutat ami egyszer majd jó lesz talán neked is. Valamiért a 16 bites DOSt is dobták egyszer. Az, hogy most van 64 bites asztali oprendszer az jó, mert ki lehet próbálni, lehet rá fejleszteni. Az, hogy használják hibajelentenek csomóan biztos segíti a platform kiforrását.

Software is like sex, it's better with a penguin. :D (r)(tm)(c)

Rohogni fox, de pl. van a zlib forrasaban assembly optim tobbfele procira is, de ezek defaultbol nincsenek benne (sot nem kis buveszkedes elerni hogy hasznalja oket). Es ezekkel ugy 3x-5x gyorsabb lesz. Es mivel a gzip, libpng es meg sokminden erre epul, ennek erezheto hatasa van pl. egy kepnezo proginal vagy egy tomoritesnel. Persze a bzip2 nem gyorsul tole (bar lefogadom ahhoz is van optimalizalt kod), dem a libjpeg (de annak van mmx-es verzioja is). Kivancsi lennek a sok optimdisztro ezeket mennyire hasznalja vagy kimerul a tudasuk a -O9 -march=i786-ban.

A'rpi

zlib forrasat ahogy nezem mmx -et csak arra hasznalja, hogy 64 bittet tud shiftelni meg bittenkenti logikai muveleteket, amd64 -nem is hasznalja, mivel a 64 bittes regeiszterek itt jol jönnek :).
ms asm -hez látam benne kódot ami gondolom azért van, mert VS roszul optimalizált kodot gyárthat.

De ha tudsz más kódrol is benne akkor szolj, vagy van hozzá patch akkor az érdekelne.

Néhány csomag ahol a gentoo explicite mmx -es assembly kódokat használhat
(equery h mmx) :

media-gfx/gimp-2.3.13, media-gfx/inkscape-0.44.1, media-gfx/sodipodi-0.34, media-sound/mpg123-0.59s-r9, media-libs/smpeg-0.4.4-r8, media-libs/libquicktime-0.9.10, media-libs/gdk-pixbuf-0.22.0-r5, media-libs/libggi-2.1.1, media-libs/libmpeg3-1.5.2-r3, media-libs/imlib2-1.3.0, media-libs/sdl-gfx-2.0.13-r1, net-irc/xchat-2.6.8-r1, media-video/mjpegtools-1.8.0-r2, media-video/avifile-0.7.43.20050224-r1, media-video/ffmpeg-0.4.9_p20061016, media-video/transcode-1.0.2-r3, media-video/mplayer-1.0_rc1,

Hát így tényleg nincs az égvilágon semmi értelme 64bitre váltani.

az alam leesett a teszt lattan. nem gondoltam volna, hogy ilyen negativ eredmeny szuletik.

Szakértők: ennek a jelenségnek mi a magyarázata?
--
Gentoo motto: It's worth spending eight hours trying to make something load 20ns faster.

Semmire. Illetve ha van pl. 16 giga ramod azt picit egyszerubb megcimezni de tok mind1 mert ugyis a ram tetu lassu a procihoz kepest es igyis-ugyis varni kell ra a procinak, igy az az 1-2 utasitas amit a 64 bittel megsporolnak sz@rt sem er a gyakorlatban.

Ja megvan mire jo: hogy 2006 lehessen a 64 bites linux desktop eve. Van meg 2 napjuk ra!

Meg ketszer nagyobb lesz tole az e-penis is, asszem.

A'rpi

A sebesség érdektelen. A 64 bit értelme nem a sebesség, hanem a nagy címtér, ami pl. lehetővé teszi a file mappinget sok GB-os filékre, ezzel hosszabb távon csökkenteni fogja a szívást.

Én két éve használok 64-bites Ubuntut. Kifejezetten azért álltam rá, hogy a programjaimat portolhassam és tesztelhessem 64 biten. Szívás csak azért van, mert ezt nem teszi meg mindenki.

igen, de az nagyságrendileg már határeset, figyelembe véve a z erőforrásigények növekedésének szintjét nem feltétlenül túlzottan korai most elkezdeni a fokozatos átállást (erre lehet elég az általad írt <=1G és a gyakorlati határ közti különbség), azt fájdalommentesebbé téve a chicken-egg probléma előrehozásával

nem, nekem annyit sem ér, hogy egy ingyenes vista/64-et használjak, nekem az az érdekem, hogy olyan rendszerem legyen, amikkel naponta dolgoznom kell
nem azt mondom, hogy bárki is váltson, hanem azt, hogy nem baj/korai, hogy van rá lehetőség, mert most még lehetőség, és nem kényszer

Windows x64 editionra talán még megérné váltani desktop kategóriában, mégpedig TALÁN - hangsúlyozom talán - mert annyira azért nincsenek terjedőben a 64bites férgek, vírusok, stb. De másért valóban nemigen érdemes. A 64bites IE talán egy kissé ellenállóbb, stabilabb jószág is, mint a 32bites. Mondjuk a férgek mellett védelmi programok is csak korlátozottan vannak úgy tudom, bár mióta legutóbb láttam lehet hogy kicsit elszaporodtak. pl. tűzfalak nemigen vannak.

A vírusírtók javarésze is vegyes működésű, van egy 64bites rendszerkomponens, és egy 32bites keret hozzá...

Bár ugye 64bites jáva plugin a mai napig nincsen ha jól tudom. meg flash, meg egyéb pluginek sem.

Viszont amit esetleg lehet nyerni a "biztonságon" - esetleg - azt játék kategóriában simán el lehet veszíteni, mivelhogy 64bites játék baromi kevés van winre is. A 32bitesek meg ott is emulációból mennek (=lassabb).

A játékok többsége ráadásul igen trágya minőségű, instabil, bugos,mint a rossebb. A netes félék biztonsági lyukairól ne is beszéljünk... Úgyhogy nem hiszem hogy a játékfejlesztők repesni fognak, hogy 64bites kódokat írkásszanak... Addig viszont user sem igen fog 64btitre váltani.

Linux alatt meg annyival több a szívás, hogy ott mindjárt 32bites chroot környezet "megépítésével" kell kezdeni, mert ugye jáva, flash itt sincs, a w32codecs meg ugye már a nevéből is... :)

Meg azért a biztonsághoz sem tesz hozzá, mint amit esetleg windows alatt jelentene.

--------

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

Elfutni elfutnak, de nem tudnak akkora kárt okozni, mert csak 32 bites system könyvtárhoz férnek hozzá a 64biteshez nem. Ergo kiírtásuk is egyszerűbb.

Ha megnézed pl. egy régi 32bites total/win commanderrel az x64 rendszerkönyvtárát a sysow64 és a system32 teljesen ugyanaz lesz, az igazi 64bites rendszerkönyvtárhoz nem férsz hozzá, csak 64bites fájlkezelővel.

Eleinte a vírusírtók is beszopták ezt a csak 32bites komponensükkel, ugyanis azok sem tudtak keresni a 64bites rendszerkönyvtárban.

--------

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

jáva böngésző plugin használatára nincsen szükség, hacsak nem chat.hu függő vagy ;) meg amúgy is idegesítő mikor bizonyos oldalak(ahol semmi szükség jávára) 3200+ -os procin 1g rammal fél percig jön be; így legalább ettől a kellemetlenségtől megszabadultam.
flash-t kétféle ember használ: egyikre rákényszerítik, a másik pedig hamis papírokkal szabadult a zártosztályról ...
w32codecs: gondolom mplayer és társaira célzol, bár nemtudom ki hogy van vele, nekem már évek óta nincsen szükségem rá, ui.: mindent lejátszik a 64bites mplayer amivel eddig csak találkoztam!
csakhogy benevezzek a mai napi nagyotmondó versenybe én simán le tudok játszani bármi "érdekes" szemetet a youtube-ről és persze a videobombról is, ehhez semmiféle flash,32bit nem kell ;)
de ennek ellenére nálam is van 32bites chroot, két progi miatt: IE-t kell futtatnom, ehhez pedig wine kellesz; néha kellene skype is; thats all

ok, de melyik kettőhöz kellett neked 32 bites chroot?

wine megy chroot nélkül is, és skype is...
skype-nak csak ia32-libs-et apt-get installtam, és statikus qt verzióst töltöttem le, minden szopás nélkül megy...
a wine meg... amikor volt az az ies4linuxos hír itt a hupon valahol a linkek közt találtam olyat + talán gugli, ahol le volt írva, hoyg kell amd64-re debeket építeni wine-ból (volt egy shellscript is mondjuk, ami egykét i386.deb-et letöltött, és pár .so-t kiszedett belőlük, ami /usr/local/... került, de csontnélkül megy)

update: közben sikerült saját kútfőből megoldani, kösz a tippet!

milyen igaz, muxik is a skype, csak nekem dynamic volt, nem static.
viszont ezt a wine-t valahogy sehogy sem sikerül amd64-es etch-re feltenni, pedig már fél éjszaka guglizok/forgatok ...
tudnál esetleg vmi linket adni, hogy mégis hogyan? ugyanis eddig nem sok használható infot találtam ...

Huhh... Etch-en nem tudom mit kell vele csinálni... És már lövésem nincs mi volt a guglitalálat.
Amit ki copy&pasteztem a fórumból, hogy dapper-re hogy kell lefordítani:


wget -c http://mirrors.uwa.edu.au/ubuntu/pool/main/i/icu/libicu34-dev_3.4.1a-1ubuntu1_i386.deb
wget -c http://mirrors.uwa.edu.au/ubuntu/pool/main/i/icu/libicu34_3.4.1a-1ubuntu1_i386.deb
wget -c http://mirrors.uwa.edu.au/ubuntu/pool/main/f/freetype1/libttf2_1.4pre.20030402-1.1ubuntu1_i386.deb
wget -c http://mirrors.uwa.edu.au/ubuntu/pool/main/f/freetype1/libttf-dev_1.4pre.20030402-1.1ubuntu1_i386.deb
wget -c http://mirrors.uwa.edu.au/ubuntu/pool/main/libx/libx11/libx11-dev_6.2.1+cvs.20050722-8_i386.deb
wget -c http://mirrors.uwa.edu.au/ubuntu/pool/main/libx/libxext/libxext6_1.0.0-0ubuntu4_i386.deb
wget -c http://mirrors.uwa.edu.au/ubuntu/pool/main/libx/libxext/libxext-dev_1.0.0-0ubuntu4_i386.deb
for i in *.deb; do dpkg -x "$i" `basename "$i" .deb`; done
rm -Rf *.deb
sudo -i
cd /home/<username>/tmp                 # replace <username> with your username, obviously ;)
cp -r libicu34_*/usr/lib/*.so.34.1 /usr/lib32
for i in /usr/lib32/libicu*.so.34.1; do ln -fs "$i" /usr/lib32/`basename "$i" .1`; done
for i in /usr/lib32/libicu*.so.34.1; do ln -fs "$i" /usr/lib32/`basename "$i" .34.1`; done
cp -r libicu34-*/usr/lib/*.a /usr/lib32
cp -r libicu34-*/usr/lib/icu /usr/lib32
cp -r libttf2_*/usr/lib/*.so.2.4.0 /usr/lib32
ln -fs /usr/lib32/libttf.so.2.4.0 libttf.so.2
ln -fs /usr/lib32/libttf.so.2.4.0 libttf.so
cp -r libttf-dev_*/usr/lib/*.[al]* /usr/lib32
cp -r libx11-dev*/usr/lib/libX11.a /usr/lib32; cp -r libx11-dev*/usr/lib/pkgconfig/* /usr/lib32/pkgconfig
ln -fs /usr/lib32/libX11.so.6.2.0 /usr/lib32/libX11.so
cp -r libxext6_*/usr/lib/libXext.so.6.4.0 /usr/lib32
ln -fs /usr/lib32/libXext.so.6.4.0 /usr/lib32/libXext.so.6
ln -fs /usr/lib32/libXext.so.6.4.0 /usr/lib32/libXext.so
cp -r libxext-dev*/usr/lib/*.a /usr/lib32
cp -r libxext-dev*/usr/lib/pkgconfig/* /usr/lib32/pkgconfig/
ldconfig

No, evvel előkészíted a rendszert, letöltöd a forráscsomagot, és dpkg-buildpackage...

A szopás MAC -en is a game, mert kurva kevés játék van MAC-re.
Nem hiszem hogy fel tudnál mondani olyan g* -es MAC en menő játékot, ami linuxon nincs, de windowson van, és én szivesen játszanék vele linxon, de wine se viszi.

Legtöbb game gyártónak nem számit a MAC piac, ugyan azért és ugyan úgy, mint linux piac.

A szopás MAC -en is a game, mert kurva kevés játék van MAC-re.

hazugsag.

Nem hiszem hogy fel tudnál mondani olyan g* -es MAC en menő játékot, ami linuxon nincs, de windowson van, és én szivesen játszanék vele linxon, de wine se viszi.

van szerencsem nem tudni hogy mivel jatszanal (de ezekszerint te is ebben a cipoben jarsz).

Legtöbb game gyártónak nem számit a MAC piac, ugyan azért és ugyan úgy, mint linux piac.

kivancsi vagyok mivel tamasztod ala ezt a hazugsagot.

Tényleg több játékot adnak, ki MAC -re ezt benéztem.

igen. es van amiket nem irnak meg mac-re, csak windowsra (official transgaming support for mac/~~ de ez nem szamit szamomra).

gaming support: windows > mac >>>>>>> linux

tanulsag? legkozelebb nem az eladtam-a-macem-mert-feketeparducvektor tipusu faszsagok menten erdemes csipobol kommentelni :(

Gabu mar javasolta a www.amazon.co.uk oldalt, "Video Games" search:
- "linux games" kereses: 24 talalat, tobbsegben egyszeru es regi jatekok
- "macintosh games" kereses: 268 talalat, a legujabb jatekok is

Valoszinuleg mindket oldalon van ne'mi elteres, de ez tizszeres szorzo a Mac javara!

Csak nehany "meno jatek" az elso oldalrol, ami van Mac-re es nincs Linux-ra:
- Lego: Star Wars (Mac)
- Sims 2: Pets Expansion Pack (Mac)
- Call Of Duty: Deluxe Edition (Mac)
- Civilisation IV (Mac)
...

Nem tudom, hogy ezek az "es en szivesen jatszanek vele linuxon, de wine se viszi" kategoria-e, de nem hinnem, hogy az atlag usert (akik megveszik ezeket a jatekokat jo nagy mennyisegben) erdekli, hogy 3 nap google turassal es szopassal hany jatekot lehet reszlegesen beuzemelni.

én annyit csináltam rootként, hogy apt-get --build source wine majd ekkor letölti a cosmagokat, kitömörít, debian patch, majd megáll, hogy oó, itt vmi nem stimmel
ilyenkor szerkeszt: wine-0.9.25/debian/control és itt az összes Architecture: -nél a különálló i386 -ot cserél amd64 -re (ez egyből a kettőspont után van!).
majd ebben a fileban: wine-0.9.25/debian/rules kikommentezi ezt a sort: "mv debian/libwine/usr/lib/wine/glut32* debian/libwine-gl/usr/lib/wine", ami nálam jelenleg a 185. sorban van.
majd cd wine-0.9.25 és dpkg-buildpackage -b -uc -d
majd cd .. és azt installálsz dpkg -i -vel, amit akarsz; persze egy 2gigás, 3200+-os, 1G ramos gépen vársz kb félórát ...

Hát pl. jáva plugin sajnos kell, néha szoktam a neten sakkozni, ultizni. A sakk még megoldható freechess.org-on, viszont az "állandó partnerek" azt nemszeressék, így marad a kurnik, pogo, ahhoz pedig kell. Ultihoz meg mindenképpen kell. Ez van. valamelyik még a flash-t is igényli.

w32codecs: nem sűrűn, de azért kell.

Mások az igényeink nyílván.

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

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

Volt, mikor 4, 8, 16 bitet tartottak elégnek.
Volt, amikor azt mondták, hogy 640 KB mindenkinek elég lesz.

Könnyen lehet csinálni olyan karakteres file viewer programot, amivel úgy nézegethetsz egy 10 GB-os text filét (mondjuk egy naplót), mintha az a memóriában volna. Ez a technika a file mapping (lemez i/o helyett memóriacímzés). Ez csak egy egyszerű példa a nagy címtér alkalmazására.

Vannak olyan adatbáziskezelők (Object Store, bár erről régen nem hallottam), amik teljesen a file mappingre alapoznak. Ezeknél az adatbázis méretét a címtér mérete korlátozza. 4GB az édeskevés.
Szerintem bőven megvan a 64 bit helye desktopon is.

Mintha az oo-ban (vagy a böngészőkben?) is volna ilyen Object Store Personal típusú belsőleg használt memória adatbázis. Persze nem azt mondom, hogy a desktopon nem elég 4GB fizikai memória, hanem, hogy (hosszú távon) nem elég 4GB címtér. Azért kell nagy címtér, hogy a lemez címzése és a memória címzése egyforma lehessen.

De azt is mondhatnám: Mire jó egy 4WD autó, ha nem megy gyorsabban, mint a kétkerék meghajtású?

Hello!

Megdöbbentően csekély a különbség a 64 bites és a 32 bites rendszerek között. Az mp3 kódolást kivéve és a kernel forditást kivéve szinte elhanyagolható ,de ezek sem olyan egetverőek ami miatt érdemes lenne lecserélni a bevált 32 bites disztrót.
Bár nem lett volna rossz egy olyan teszt sem amikor pontosan a konfigra csinált kernellel teszik meg ezeket a próbákat nem csak a gyári kernelekkel.Bár szerintem ez a 32 meg 64 bites processzor meg egy nagy humbuk,mert csak a memória kezelés terén "64" bites ,hogy az egyre többet zabáló programoknak elegendő ramot lehessen használni. Emlékszem annak idején a Pentium I procikról is azt mondták hogy 64 bites proci meg hű meg há. Aztán kiderült ,hogy csak a lebegőpontos számkezelése lett 64 bites minden más ugyanúgy maradt a régiben ,mint a 486 processzoroknál.Sajnos az alap még ma is ugyanaz a jó öreg technika mint annak idején.Majd akkor lehet a 64 bitet elhinni ,ha olyan procikat lehet asztali gépekbe is kapni ,mint az Intel Ithanium(remélem jól írtam). Addig az egész csak megint egy újabb parasztvakítás,bár én ennek most sajna be is dőltem.
Bocsi ,ha egy kicsit hosszú voltam.

Üdv.

Mitől "64 bitesebb" az Itanium a K8-nál?
A memóriakezelése (címzése) meg pont nem 64 bites, csak 44 vagy 48, nem emlékszem pontosan, de az is elég lesz egy darabig :)
Ha meg Itaniumot kellene használnod desktopon, akkor eléggé gondban lennél a programok hiánya miatt.
Az AMD ezért csinálta meg ezt az öszvért, megy 64 bites üzemmódban is, de 32 bitesként is.
64 bites üzemmódban átlag 10-15% (hasraütés szorozva sacc/kb) teljesítménynövekedés lenne várható a megduplázott számú regiszterek miatt, az, hogy ez nem jelentkezik, nem a processzor hibája...

Igen... Sajnos ez így van.
Mi több: az xvid kódolás kb. 2x lassabb 64 bites OS-sal. (Valszeg az xvid enkódolót nem optimalizálták 64 bitre, de ebbe nem mennék bele, mert csak feltételezés.)

A tapasztalatom az, hogy ha már egyszer 64 bites gépet kapsz, hogy csinálj belőle kiszolgálót, akkor meg lehet oldani, de multimédiás eljárásoknál semmi pozitívumot nem éreztem.
Én is 32 bites kubuntut használok, mert a 64 bittel sok a szívás.
Idővel majd minden program elkészül 64 bitre optimalizálva...

OFF:

Mellesleg en teljesen egyetertek a fenti sorrendel. Video kodolasban a minoseget mindig magasabb rendunek tartottam, mint a sebesseget. A masodik pont Milti-Core tamogatas. Ezzel jo esetben 2x/4x-es sebessegnovekedes varhato. A 64bit meg max 10%-al lehet gyorsabb a 32bitesnel.

"van-e értelme 64 bites desktop gépen 64 bites Ubuntu-t használni a 32 bit-essel szemben"

Ha csak az érdekel, hogy milyen gyorsan futnak a programok, akkor nem.

Ha érdekel az új technológia, vagy segíteni akarod az Ubuntu fejlesztését bugreportokkal, akkor igen.

Ha flash-t akarsz használni, akkor nem.

Ha programfejlesztőként ki akarod használni az új lehetőségeket, akkor igen.

Ha sok desktopot felügyelsz, akkor nem.

Ha nem akarod, hogy a programod hibái a júzernél derüljenek ki, akkor igen.

Én azért vettem amd64 -et, hogy legyen benne egyszerre SSE2 meg 3dnow, azt is csak azért, hogy, ha arra adom a fejem tudjak játszani ezekkel az utasításokkal, tudtam hogy nem lesz gyorsabb.
Amikor azt mondtam, hogy 64bit szerintem biz. esetekben lassabb lesz kinevettek :)

32 bittes számok helyett, minek utaztassunk 64 bitteseket, amikor a felső 32 bitt 0?

Nagyobb sávszélesség 64 bit miatt? :)

3200 Mbyte/sec DDR-400Mhz (2x200Mhz), Proci ~2.8Ghz, 7 orajelre jut egy 64 bittes transzfer persze hátszélben, valójában többet kell várni (dual DDR-nél sem sokkal rózsásabb a helyzet) , és trükkös cachelési technikák, miatt szinte semmi előnyét nem látod, 32 bittes rendszer esetébben jobb trükökk vannak :)

hát én azért tettem fel 64 bites ubuntut, mert 64 bites debiant az istenért nem tudtunk beüzemelni (voltunk rá, és volt tapasztalat is debian téren)... mindegy, a 64-es ubuntu felment... Annyit akartam csak kipróbálni, hogy hogy megy a Maya 8 64 bites linux környezetben. Mert az, hogy alap, régi 32 bites progik nem mennek gyorsabban, sőt lassabban mennek, nem kellene messzemenő következtetéseket lemérni, inkább megnéznék egy Maya 8 unlimited 32 bit windows-on vs Maya 8 unlimited 64 bit linuxon renderelés meccset... De sajna nem tudom elindítani linux alatt a maya-t ( http://magnificat.uw.hu/ubuntuerr.png : ez a hiba)

az már valszeg régen lehetett mikor te amd64-re nem tudtál feltenni debiant ...
pl én két hónapja installtam újra a rendszert, hogy legyen full 64bites gép. akkor még a d-i rc1-es volt asszem, ami én esetemben hiányosság volt az az, hogy nem ismerte az alplapi via sata raid-et. asszem az rc2-re már javítják/javították.

Hali most archiválom a gépemről az adatokat. Újra fogom rakni a rendszert teljesen.
A gépemen mindig szokott lenni egy 32 bites és egy 64 bites rendszer.
Most külön a teszt miatt mind a kettő Frugalware lesz. Egy Blend filet fogok renderelni.
Arra gondoltam futtatom a renderelésel párhuzamosan a Gvidcapot azonos beállításokkal.
Ha szerencsém van az idén kész leszek a dologgal.
Nem mondómell előre miért szoktam 64 bites rendszert telepíteni. A videókból szerintem kifog derülni. Bár azonos disztróval még nem hasonlítottam össze soha.

Üdv Joco

Gentoo alatt tiltva van 64bit-en az oszes MMX/SSE USE flag. Szoval amig nem lesz egy jobb gcc addig ne is varjunk jo eredmenyeket. Meg nem kell elfelejteni, hogy jelenleg minden 32bitre van optimalizalva, 64biten meg az a cel, hogy minden program fusson.

Egyebkent en azert raktam fel 64bites Gentoo-t, mert az elkovetkezo sok evben nem kivanom ujratelepiteni a rendszert, es egyszer ugy is valtani kell.

Nekem szamit, hogy 64biten gyorsabban fordit mint 32biten. Plusz a forditas az esetek 90%-aban kihasznalja a DualCore procit is.

if use amd64; then
myconf="${myconf} --enable-sse --enable-sse2 --enable-mmx"
fi

Nincs tiltva, amd64 -en alpból használva van a legtöbb ebuildben, a fenti az mplayer ebuildjéböl idézet.

Tudsz olyan amd64 et amiben nincs mmx,sse,sse2 ? Na ezért nem használják külön use flegként, de ahol értelme van bekerül a kódba.

Valaki a nagy öregek közül nem emlékszik a Linux 1.0.x idejére? Ha jól emlékszem, akkor lehetett úgy kernelt fordítani, hogy a címeket _3_ bájton tárolta. Ez ugyan limitálta a megcímezhető virtuális memória méretét 16 MiB-re, de volt valami előnye.
(Az ősi 386-osomon használtam is, mert ennyim volt.)

Arra emlékszem, hogy a kernel image így kissé kisebb lett, de nem emlékszem, gyorsabb is lett-e tőle a rendszer. (Nekem volt ilyen szubjektív benyomásom, de nem teszteltem.)

Szóval, van még itt valaki, aki ilyesmire emlékszik ;-) ?

[[Tudom, tudom, ez nem sokat mond el a mostani 32/64 bites váltásról, de van annyira "on topic", mint egyes notórius kötekedők unalmas dumája.]]