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

Közösségi kerekasztal

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.

( agostonl | 2015. 03. 27., p – 07:06 )

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

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

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.

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

( dejo v | 2015. 03. 27., p – 07:19 )

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

( emberk | 2015. 03. 27., p – 07:40 )

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

( ncc1701 | 2015. 03. 27., p – 07:52 )

Használd nyugodtan a 64 bites OS-t.

( copass | 2015. 03. 27., p – 08:05 )

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.

( wachag | 2015. 03. 27., p – 08:08 )

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.

( muszi v | 2015. 03. 27., p – 08:09 )

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.

( sz332 v | 2015. 03. 27., p – 09:54 )

Egy kis összefoglaló, igaz windowshoz...

http://blogs.msdn.com/b/tom/archive/2008/04/10/chat-question-memory-lim…

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.

( uid_6201 v | 2015. 03. 27., p – 10:59 )

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

( PP v | 2015. 03. 27., p – 11:42 )

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?

Ö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™

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.

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

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™

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.

( PtY | 2015. 03. 30., h – 01:16 )

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

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

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

( turul16 v | 2015. 03. 30., h – 02:05 )

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.