32bit nagy teljesítményű gépre

 ( PP | 2015. március 27., péntek - 7:38 )

Sziasztok.

Érdekelne, hogy mennyire észrevehető a teljesítményen, ha 64bit helyett 32bit rendszer lenne telepítve. Tudom, van lehetőség multilib rendszerre is. Kicsit utána olvasgatam, de elég megosztott a vélemény.
Úgy olvastam, hogy a 64bit programok több memóriát is fogyasztanak mint a 32bit-es társaik. Gondolom, ha igaz is, akkor se jelentős a külömbség (lehet, hogy tévedek). Ha jól tudom, akkor mostmár a 32bit rendszer is kezelni tudja a 4gb feletti memoriát. A kernelbe lévő PAE supportnak köszönhetően. Nézegettem teszteket is. Tesztek szerint, a 64bit jobb, de nem sokkal ért el jobb eredményt mint a 32bit társa. Régebben használtam 32bit-es rendszert de nekem úgy rémlik, hogy nem volt külömség legalábbis nem vettem észre.
Esetleg van valakinek személyes tapasztalata?

Válaszokat előre is köszönöm.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

64 bites rendszer akkor éri meg, ha 4GB+ memória van a gépben, hiszen 32bit-en maximum 4GB RAM-ot kezel a rendszer.
Én Windows 8.1 alatt komoly teljesítmény-növekedést vettem észre, persze 8GB RAM-al.

Szerveren és akár linux alatt is ugyanez a helyzet.

THE DIFFERENCES BETWEEN 32-BIT VS. 64-BIT OPERATING SYSTEMS EXPLAINED

Hozzátenném, pár hónapja arról lehetett olvasni, hogy a nagyobb linux distribúciók dobnák a 32bit-es kiadásokat.

"Értem én, hogy villanyos autó, de mi hajtja?"

Az nem derült ki egyértelműen, hogy Linuxot vagy Windowst esetleg más oprendszert akar használni.
Abból a mondatból, hogy "Ha jól tudom, akkor mostmár a 32bit rendszer is kezelni tudja a 4gb feletti memoriát." én arra következtetek, hogy mégis csak a Linuxról beszél. :-)
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

Természetessen linuxról beszélek.

Linux 32bit változata már képes a 4gb feletti memória használat kezelést is a PEA kernel supportnak köszönhetően. Erről viszont nem tudtam, hogy megszüntetnék a 32bit-et. Mondjuk, kiváncsi leszek mi lesz azokkal a programokkal aminek kell a 32bit. Úgy vettem észre, emlékeim szerint és tesztek szerint is. Van külömbség, de nem nagyon észlelhető.

Nézd meg a RHEL/CentOS 7-et, az már pl. 64bit only (viszont vannak 32 bites libák is hozzá)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Sosem teszteltem a PAE és a 64 közötti különbséget, hanem elhittem a RedHat által mondott (és mindenhol idézett) adatot, miszerint átlag 1%, extrém esetben 10% a PAE szintezettsége miatt a tempócsökkenés.

Aztán olvastam ezt, amely szerint az extrémnél is akad szélsőségesebb forgatókönyv: http://www.phoronix.com/scan.php?page=article&item=ubuntu_32_pae&num=1

Nem jártam utána - mindenesetre abban maradtam magammal, hogy a memóriavarázslás lehetőségétől függetlenül jobb azt a 64bites utasításkészletet a kernelben tudni.

Szerintem a baj az lesz, hogy PAE-val nem nő meg a processzenkénti max. 4GB-os limit. De ezt meg kellene nézni.

Fuszenecker Róbert

2GB az a 4, és valóban nem nő meg.

Ez így még szigorúbb limit.

Fuszenecker Róbert

Lenne, ha igaz lenne. De nem az.

Megosztod melyik része és miért nem igaz?

Honnan jott a 2GB???

Az Windows a címtér felső felét saját használatra lefoglalja. A Linux csak 1G-t vesz így el.
--
ulysses.co.hu

Meg ez sem pontos. A RHEL3-ban pl. volt olyan kernel (hugemem), amiben nem 3/1 split volt, hanem durvan 3.9GB jutott a userspace-nek.

Korábbi tanulmányaimból. Most utánaolvasva valóban csak Windows (ill. Linux vanilla 2.4) esetén volt ilyen limit.

Itt egy nagyon korrekt összefoglaló:
http://stackoverflow.com/questions/5079519/memory-limit-to-a-32-bit-process-running-on-a-64-bit-linux-os

Linuxon 3G az a 2G.
--
ulysses.co.hu

4G az a 3G, de a teljes IO címtartománnyal együtt. És ez innentől HW függő.
--
PtY - www.onlinedemo.hu, www.westeros.hu

4G-nél kisebb memóriájú gépen is van értelme a 64-bitnek. A filemapping behozza egy file tartalmát a _virtuális_ memóriába, ami max akkora lehet, mint a címtér. Tehát 32 bites rendszerrel max 4G méretű filemappinget tudunk kezelni, míg 64 bites rendszerrel jóval nagyobbat. Egy 4G-s fájl már nem számít olyan nagynak.
--
ulysses.co.hu

A CentOS a 7-essel már dobta, meg a KaOS is, mondjuk ez utóbbi nem "nagyobb" disztribúció.

--
robyboy

"Gondolkozni nehéz, ezért legtöbben ítélnek." - Márai Sándor

Meg van egy halom plusz regiszter, ami azért nem keveset számít.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Én egy jó ideje, ha a CPU 64 bites akkor csak 64 bites oprendszert telepítek. Ez a "jó ideje" Windows esetében legalább 3-4 éve, Linuxnál még ennél is több.
Nem igazán méricskéltem, de nem vetem észre semmit ami miatt 32 bites jobb lett volna.
Az is igaz, hogy pont pár napja akartam telepíteni egy P4-es gépre CentOS 7-et, de már nincs is belőle 32 bites kiadás. Kell néznem egy másik gépet!
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

Én is évek óta 64bit-et telepítek. Csak elgondolkodtam, hogy a csomagjaim közül van pár olyan aminek kell a 32bit környezet. Mivel, a linux képes már kezelni 64gb-ot 32bit-es köznyezetbe felmerült bennem a kérdés, miért használok 64bit-et. A multilib környezetnek van egy olyan "melékhatása" szinte dupla helyet foglal.

""van egy olyan "melékhatása" szinte dupla helyet foglal.""

Azt írtad, "nagy teljesítményű gépre".
Azon meg van hely bőven, mit számít pár giga mínusz?

Én nagy számításigányű programokat írok (C, és C++-ban ion/eleptronoptikai szimulációk, és komplex függvény analízis), 64-bites vátozat több memóriát eszik, 5-10%-al, de a futási idő rövidebb ~20-30%-al. Teljesen pontosan soha nem mértem. Linuxon (Gentoo). Manapság szerintem már a 32-bit pont ugyan olyan mértékben támogatott, mint a 64. Mindössze helyigényesebb. Ha a ram/háttértár neked a szűk keresztmetrszet, akkor tudsz sprolni pár%-ot (egyéni véleményem mondjuk 10%).

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

http://yarchive.net/comp/linux/highmem.html

Keress rá a "PAE does add overhead" kijelentésre és nézd meg ki tette.

Használd nyugodtan a 64 bites OS-t.

nagyon sok proginak már leálltak a 32bites fejlesztésével. pl.: lightroom,archicad. 4gigából én pillanatok alatt kiszaladok!:D de ez speciális felhasználás már.

Jelenleg, nekem is 8gb ram van a gépembe de közeljöböben szeretnék még belevenni még legalább még egy 8gb-ot. Viszont, ha leállnak a 32bit fejlesztésről akkor muszáj lesz nekik a 64bit-es progika (azok amiknek kell a 32bit könyvtárak) újra tervezniük.

Hacsak nincsen sok binary only third party csomag, ami csak 32 biten érhető el, és nem engedi a rendszer egyszerre két változat telepítését valamelyik függőségnek, akkor imho 64 bit.
Off: külöNbség, n-nel. M-mel csak poliverzum írta.

Leginkább olyan csomagok vannak, aminek kellenek a 32bit könyvtárak. Ezt meglehet oldani könnyen. Eddig is jól elvoltam multilib rendszeren. Kiváncsi leszek, tényleg megszünik e a 32bit rendszerek.
Arra is kiváncsi leszek, ha megszünik, akkor mi lesz az olyan csomagokkal ami igényli a 32bit közremüködését.

Nekem jelenleg a 64 bites Debianon két csomag miatt van 32 bites alrendszer telepítve: Skype és Steam.

Ha a főbb Linuxok dobják a 32 bites rendszert, tuti a Steamet és a Skype-ot is kiadják végre 64 bites verzióban is. És onnantól azt fogom letölteni, és nem lesz 32 bites alrendszer a továbbiakban telepítve.

Remélem is én is a steam miatt használok 32bit-es libeket.

Azon kivul, hogy a 4 GB feletti memoriat is latod (32 biten PAE-vel is latod ugyan, de 1-2%-kal lassabb), ketszer annyi altalanos celu regisztered van (sokkal gyorsabb a feldolgozas, mint ha a memoriaban tartanad a valtozokat), es a fuggvenyek parametereit regiszterekben lehet atadni (kimarad a sok push es a valtozok betoltese a regiszterekbe).

Igen, ezt tapasztaltam én is. Erről emberk is írt fentebb.

Saját C kódot ugyanazon a gépen gcc-vel fordítva 32 vagy 64 bites Linux alatt utóbbinak mérhető (15-30%) sebességelőnye lett, ami a proci képességeinek (pl. regiszterek) jobb kihasználásából fakad. A plusz memóriaigény elhanyagolható volt nálam.

Egy kis összefoglaló, igaz windowshoz...

http://blogs.msdn.com/b/tom/archive/2008/04/10/chat-question-memory-limits-for-32-bit-and-64-bit-processes.aspx

Szóval hiába pakolsz bele 16 gb ramot a gépbe, ha 32 bites OS (windows, linuxnál nem tudom mi a helyzet) van alatta, akkor is max 2-3 GB memóriát tud használni egy processz. Magyarul, ha valóban nagy teljesítményű gépre van szükség, ahol az alkalmazásoknak sok memóriára van szüksége, akkor nincs semmi értelme 32 bites OS-t használni.

Ez - szintén a PAE óta - még winen sem mindig igaz, csak a furmányos licenszelés miatt ez nem látványos.

Ha én jól értettem, itt két külön dolog van. Az egyik, hogy az oprendszer mennyi memóriát tud kezelni, a másik, hogy ebből egy processz mennyit tud látni.

Mondasz valamit...

32 bit korlátai, lehetőségei:
- egyazon processznek ha kell > 2 GB RAM, akkor a kicímzéssel gondja van.
- több processz esetén az össz memória felhasználás > 4 GB-ját a PAE megoldja.
- 64 bites pointer tényleg nem 4 byte, hanem 8. Lassabb.
- x86_64 az RAX, RBX, ... összesen 8 regiszterén túl további 8 regisztert kapott (r8...r15). Ez kompenzálja az előbbi lassulást.

Végszó: ha nincs olyan processzed, amely a futásához > 2 GB RAM-ot igényel, vagy > 2 GB-os fájlt mmap()-olni akar, akkor teljesen mindegy. Oka: 32 bites pointer a processzen belül, amiből bizonyos "memóriacímek" egyéb célokra, tehát nem fizikai RAM elérésre foglaltak.
A sok processznek a pl. 16 GB RAM 2 GB-os szeletekben való belapozását a PAE megoldja.

Mivel jó ideje nem láttam 32 bites gépet ezért nem vagyok benne hogy ez még mindig igaz, de 2.6.32 idején a Linux SLAB allokálásra nem tudta használni a highmem-et. Ebből komoly teljesítménybeli gondok származtak bizonyos környezetekben. 64 biten ez a limitáció természetesen már nincs.

(Jelenleg a desktop gépemen 3GB SLAB allokált. Ez 32 biten lehetetlen lenne, hiába a PAE. AFAIK.)

Amenyire sikerült értelmeznek, amit írtatok, abba az esetbe ajánjátok a 32bit-et ha a futtatandó program nem haladja meg 2gb-ot. Mondjuk, én elég gyakran játszok a gépen és ez gondolom túlhaladja a limitett.
Esetleg tud valaki valamit az x32 ABI-ről?

Max. akkor érdemes 32 bites, ha <=2GB ramod van. Felesleges vele szórakozni, nem véletlen akárják jelenleg néhány distronál dobni a 32bitet.

A 64 ites sz@r körül több légy röpköd, és csak gyűlnek. Az a kérdés, hogy mennyi ideig kell támogatni azt a nagy teljesítményű rendszert.
-
JVM futásidejű monitorozása

Otthoni használatba lévő rendszeről van szó. Csak kiváncsi voltam, mennyire van értelme, multilib rendszert használni ha szükség van 32bit-es libekre. Ezek szerint, ha lehetőség van inkább multilib rendszer.

Összefoglalva:
- 64 bites rendszer egyetlen hátránya, hogy több ramot igényel valamivel.
- Viszont messze nem annyit, mint amennyi van általában egy gépben.
- 64 biten több regiszter, új utasítások -> gyorsabb programok
- Trükközés nélkül látja a több memóríát.
- Nagyobb címtér nyújtotta plusz lehetőségek.
- pl. NX bit és társai (biztonságosabb egy fokkal)
- Előremutatóbb
- Ugyanúgy futtathatóak a régi 32 bites programok.

Hacsak nem valami low-mem rendszert építesz speciális célra, 0 értelme van a 32 bites rendszernek 2015-ben.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Most építettem magamnak lfs-multilib rendszert. Pusztán kiváncsi voltam.
Olvastam ABI x32-ről is. De nem nagyon volt világos mi is pontossan. Esetleg, tudna valaki mondani róla? Esetleg van tapasztalat?

Az x32 jol hangzo terv volt, de tudtommal semmi konkret nem lett belole... Mintha a gcc tamogatja, meg meg par cucc tamogatja, de kesz rendszert senki nem allitott ossze belole.
Az elonyei: minden processznek 4G cimtartomany; az x86-64 extra regiszterei rendelkezesre allnak; a pointerek 32 bitesek, ugyhogy nem hasznal tobb memoriat a x86-32-hoz kepest. Lattam par benchmarkot, egyes esetekben gyorsabb volt a x86-64-nel.
A hatranyai: egy uj abi, tehat a multilib rendszered jo esellyel igy nez ki: x86,x86-64,x32... tehat 3 peldanyban kell fent legyenek a lib-ek... Elojohetnek bugok programokban, mert az abi egy reszet az x86-64-bol vettek at, mas reszet az x86-32-bol. Pl ha jol emlekszem a timestamp-ek 64 bitesnek voltak definialva.

Szerintem a programok nagy reszenek az x32 idealis, szovegszerkeszto, chat program, kep nezegeto, film nezo, zenelejatszo szamara nincs szukseg a 64 bites cimtartomanyra.

Arrol nem tudtam, hogy csak terv volt, de azt tudom, hogy a lfs multilib leírásba támogatva van. Kicsit furcsálom, hogy tesztek alapján egész jó volt akkor miért hagyták abba. Kernelbe viszont ládtam támogatást is.

SZerk: Ha jól tudom akkor a gentoo-nak van belőle livedvd is.

Még amikor 10+ éve bedobta az AMD a PC-s 64bitet (nekik már volt IA64-ük), akkor az intel nagyon nem örült neki. Ehhez képest beállt a sorba, mert a K8-as CPU családdal és a 64bittel keményen odapörkölt nekik az AMD. Sajnos még a néhány éves AMD fölény is kevés volt, hogy érdemi változás legyen az intel abszolút piacvezetésében.

Nehéz nekik ellenük, mikor az intelnek vagy 10x annyi pénze van a fejlesztésre.

Annyira nem kell félteni az AMD-t. Egész jól tarja magát. Jó procikat csinálnak és olcsobb mint az intel.

Én az utóbbi időben néztem, de nem igazán láttam az az olcsóbb és jó AMD processzorokat. Maximum papiron tűnnek erősebbnek, de az összes
teljesítménytesztben az intel procik odavernek (legalábbis az i3-i5 kategóriában).

Régebben viszonylag gyakran nézegettem a teszteket. Emlékeim szerint, nem minden tesztbe verte meg az intel az amd-t. Nekem mindig is amd-m volt ahogy most is, de soha nem volt gond velük. Lehet, hogy valamivel jobb az intel, de annyival nem hogy megérje a többlet kifizetést.

Szintén. Már jó sok éve amd only vagyok, ügyfeleknek is amd-s gépeket viszek ki. Szimplán ár/teljesítményben jobbak, és ma igazán nincs szüksége az átlag(!) usernek egy i5-i7 teljesítményre.

AMD-ben is vannak erősek.
http://www.cpubenchmark.net/cpu_lookup.php?cpu=AMD+FX-9590+Eight-Core&id=2014

Bár számomra az alábbi a teteje, mivel a fentiben nincs videó chip, ebben viszont van egy normális videóchip is:
http://www.cpubenchmark.net/cpu_lookup.php?cpu=AMD+A10-7850K+APU&id=2133

i3-akat az utóbbi is simán veri, jónéhány régebbi i5 és i7-et is. Viszont egyvalami azért átverős a benchmarkban. Asztali gépes alkalmazásnál gyakran a kevés erős magtempó származó tempó még mindig nyerőbb a sok magra elosztott kisebb magtempóból összeállónál. Bár az igazán erőforrásigényes alkalmazások közül egyre több szépen szálakra bomlik.

"AMD-ben is vannak erősek. [...]8 core[/...]"

Hja, csak /mag levetítve már nem túl nyerőek és azért manapság még mindig jobban jár egy erősebb, de kevesebb magos CPU-val otthon az ember. Szóval mint ahogy te is írod, gyakorlatban nem annyira érik meg ezek.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Én egy amd buldozer melett döntöttem tavaj.
Most csak gyors utána néztem az amd vs intel-nek.
Intel Core i7 4770K vs AMD FX 9590. Az intel ért el a teszt szerint 8.7-et az AMD 8.2-t. Szerintem ez nem nagy külömbség. Az ár viszont annál inkább. A legolcsobb árak a következök.
Inter: 101.854 Ft
Amd: 68.655 Ft

Majdnem úgyan az a teljesitmény, csak majdnem a dubla anyi pénzért. Számomra ez egy kicsit elgondolkodtató.

Hja, csak az intel ezt 4 magon és 3,5 Ghz-n éri el, az AMD meg 8x4,7-en. Gyakorlatban az i7 sokkal tartósabb, mint az AMD. Másrészt nem egy túlárazott i7-et kell venni, hanem egy i5-öt. Szintetikus tesztek nem számítanak semmit.

Nekem is sokáig AMD-m volt, de az Intel most egyszerűen jobb, hosszú távúb befektetés, akárhogy is nézem.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

+sok
Főleg, hogy virtualhoston az AMD-nek gyalázatos az IO terhelhetősége... Intel keresztben megeszi.
--
PtY - www.onlinedemo.hu, www.westeros.hu

Na meg ennek megfelelően töredék az AMD fejlesztő gárdája.
Intel szándékosan akarta a 32 bit korlátjában tartani az x86-ot. A jövőt Itanium procival képzelte el. Ebbe a tervbe rondított bele az AMD a 64 bites kiterjesztéssel. A kocka innentől el volt vetve, be kellett állni a sorba.

Többet fogyaszt, mert minden adat 8 byte-os határra kerül a kód optimalizálása végett (pl. egy bool változó 32 bit helyett 64 lesz - ugye, a régi szép 8 bites évek...) de ez valóban elhanyagolható, pár %.

Idézet:
...akkor se jelentős a külömbség...

Ez fájt...
Nem a 4GB feletti memória kezelése a lényeg, hanem a teljes memória kezelése (PAE-vel) egy processz azonban csak 4GB-ot láthat max. Ha vannak alprocesszei, és közös memóriaterületet használnak, akkor értelem szerűen ezen osztoznak.
Csak olyan helyen használok 64 bitet, ahol futha olyan processz, aminek kellhet 4+GB RAM.
A desktopjaim ennek megfelelően 32 bitesek, mert ilyeneket nem használok, hiába van 8+GB némelyikben.
Kisebb szerverek (tűzfal, dns, kisebb appszerverek, szintén. DB szerverek, egyes web/mailszerverek értelem szerűen már 64 bitesek.

De láttam már olyan nagyvállalati (!) rendszert, ahol a 64bites Windows szerveren 12GB RAM mellett (!) 32 bites MySQL volt a gépen - persze a gépet másra nem használják, csak arra - ez itt meg ugye már csak 3GB... Móka, kacagás.
--
PtY - www.onlinedemo.hu, www.westeros.hu

Es az nem zavar, hogy a cache merete is limitalt -e miatt ?

A kernel legyen 64 bit-es 4G ram felett, az userland lehet mas.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Az nem zavar. Ott nem, ahol nem szükséges a 64 bit.
--
PtY - www.onlinedemo.hu, www.westeros.hu

Idézet:
A desktopjaim ennek megfelelően 32 bitesek, mert ilyeneket nem használok, hiába van 8+GB némelyikben.

Hehe, kaptam már olyat, hogy az egyik hírhedt magyar prezentációs szoftver alatt a Flash konzisztensen összeomlik. Process explorer, szépen látszott, hogy megnyitáskor vadul elkezdte vinni a memóriát [a készítő tele rakta 10+ megapixeles képekkel...] és kifutott a 32 bites tartományból.
Ugyanezt Linuxon megnyitva megevett ugyan vagy 5 giga ramot, de egy mozdulattal lehetett törölni a képeket.

Úgyhogy erősen user függő is a dolog.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Na igen, a fejlesztőnek erre gondolni kell.

Nekem van egy olyan példám is, hogy W2k3 Enterprise+32GB RAM. Userek TS-ként repülnek rá. Használják, elég nekik userspace-ben annyi, amit kapnak. Ám van egy szoftver (gyártót nem mondok), ami a nyomtatásokat naplózza. Fut egy szerviz, avval kommunikálnak a kliens oldali appok ugyanazon a hoston. Random usereknek működik a naplózás, random usereknek nem. Kérdeztem a fejlesztőt, hogy hogyan kommunikál a szervizzel a kliens. Tök természetesen mondta, hogy egy adott memóriaterületen. Mikor kérdeztem tőle, hogy a 32GB RAM miatt nem kéne-e inkább socketen keresztül beszélgetniük, azt sem értették, mit akarok kihozni belőle. 3. évezred...
--
PtY - www.onlinedemo.hu, www.westeros.hu

Ez tenyleg 2015 -os topik ?

Kis erdekesseg.: http://en.wikipedia.org/wiki/X32_ABI

Csak 32 bitet tudo x86 rendszerek kvazi kihaltak,
varhatolag OS -ek is kovetik (tamogatasban),
nem ertem minek kell meg veluk foglalkozni.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Nem hiszem, hogy mostanába fog eltüni a 32bit.

Gyartanak meg 486-os szintu, compatibilis CPU-t,
de nem a tipikus desktop/server/notebook felhasznaloknak.

Intel gyart -e meg 32 bit only x86 CPU -t ?
AMD ?


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Nem gyártanak != nincs
--
PtY - www.onlinedemo.hu, www.westeros.hu

Inkább:
Ha nem gyártanak != nem támogatja
és
Nagy teljesítményű gép != PC