Benchmark: Ubuntu 32 bit vs. 32 bit PAE vs. 64-bit kernel

Ubuntu

Örökös vita tárgya, hogy van-e számottevő különbség a 32 bites és a 64 bites kernelek közt sebesség szempontból. A Phoronix egy Lenovo ThinkPad T61 gépen futtatott egy rakás tesztet annak érdekében, hogy kiderüljön valami. A teszteredmények itt.

( skynetpro | 2010. 01. 03., v – 10:20 )

"a phoronix"
itt abba is hagytam az olvasást

( klacus76 | 2010. 01. 03., v – 10:41 )

Én most váltottam a napokban Ubntu 9.10 koala 32 ről 64-re.

A bekapcsolás idő dettó ugyanannyi volt.

Ami javult számszerűen:
Lazarussal egy 47 mb -os futtatható állomány elkészítése 25 %-al kevesebb időt vett igénybe.

A Firefox kb 30 % -al javult. (fix honlapon mértem)

A virtualbox kb 15%-ot javult.

ami szubjektív:
Az Nvidia kártyám 9400 GS 512 mb azóta valahogy gyorsabban jeleníti meg mind a 3d-t, mind a 2d-t. (ezt nem tudtam lemérni, csak a kde 4.3 érzésre sokkal jobban karcol)

ami negatívum volt:
a flash plugin, de gugliztam és megoldódott.

Szvsz, aki teheti próbálja meg lecserélni, aztán véleményezze...

"Szvsz, aki teheti próbálja meg lecserélni, aztán véleményezze..."

Kb. két Ubuntu kiadás óta már 64biteset használok. Hát _én_ túl nagy gyorsulást nem tapasztaltam(max 10%), talán néhol érzek némi változást. Jó, egyébként is gyenge a gépem (cerka m520), lehet azért.
Nameg FF-ról kb akkoriban váltottam Chromium-ra, így a gyorsulást betudtam a váltásnak.
Evolution, OpenOffice, stb nem érződik igazán túl sok változás, "elvárható időn belül" előtte is betöltődtek, utána is.
3D alkalmazások, openGL: kb 10-15% gyorsulás, de gondolom inkább a driverfejlesztések miatt(intel), mintsem a 64bitre váltás miatt.
Lemezműveletekre se térnék ki, ekkor váltottam ext4-re.
Flash megy, egyéb 32 bites programok futtatására is (elvileg) van lehetőség, bár eddig nem volt rá szükségem, azt hiszem.

Szerintem inkább csak túl van lihegve picit ez az egész 32bit vs. 64bit, ma már nem kéne, hogy akkora újdonság legyen. Talán.

Az, hogy valamit nem lehet rendesen 64bitre portolni, hát előfordulhat.

( mrev | 2010. 01. 03., v – 10:47 )

Szerintem a gyorsaság kérdése másodrendű.

Ami elsőrendű, az a minél világosabb és egyszerűbb szoftver. A 64-bit nyilvánvaló előnyben van. A PAE léte önmagában mutatja, hogy a 32 bit kevés, és 64 bit nélkül zavaros megoldásokra kényszerülnek a programozók. (Úgy értem, az egyszerű lineáris címtérhez képest minden más zavaros.)

A másik, hogy a rendesen megírt szoftver nem nagyon veszi észre, hogy 64 vagy 32 biten fut. Ezért a programozóknak már csak becsületből is azonnal portolniuk kellett volna a vackaikat 64 bitre. Ami a flash-sel meg a javaws-sel történt, az kriminális. Különösen a javaws, aminek ab ovo Jávában kellett volna lennie, azaz eleve platformfüggetlennek.
--
CCC3

( tr3w v | 2010. 01. 03., v – 11:15 )

Gyanítom a kb 2x annyi regiszter többet számít mint a 64 bit...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

AMD64 utasitas alapvetoen csak akkor foglal tobb helyet ha kihasznalja a plusz regisztereket, vagy 64 bites (long long) operandusokat hasznal, mert akkor kell a REX prefix - az ekvivalens funkciot viszont meg hosszabb es lassabb lenne ekkor megirni 32 bites modban.
Patologikus esetben - mondjuk ha sok szaz/ezer fix memoriacimre irkal a program (amely muvelet tenyleg tobb byteot foglal 64 bites modban es kivalthato ekvivalens rovidebb utasitassal 32 biten) - lesz ugyanaz a kod hosszabb es igy az azonos cache meret miatt esetleg lassabb.

- Use the Source Luke ! -

( Dacr (nem ellenőrzött) | 2010. 01. 03., v – 12:12 )

nekem az Ubuntu Studio-m 64 bites. Ardourban a sávok egy wavvá való számolásánál érzem a különbséget, illetve a felpakolható effektek számában.

( sandras74 | 2010. 01. 03., v – 12:30 )

Ahhoz képest, hogy mióta is létezik a 64 bites processzor nagyon lesújtó a helyzet. Nem csak Linux alatt, hanem úgy általában. Még a Windows 7 se oldotta meg a problémát, mert az is tele van 32 bites részekkel. Tudom, PC iparban a kompatibilitás az elsődleges. De azért vannak határok. A mostani gépeken, amin a Windows 7 is fut, már mind 64 bites processzorral van ellátva. Innentől nem értem, miért is nem terjedt el jobban. A gyártók se igazán rukkolnak elő 64 bites alkalmazásokkal. A 32 bitre való átállás valahogy olajozottabbnak tűnt. Linux esetében erről ugye nem beszélhetünk, mert abból nem is készült 16 bites változat.
Linuxon érdekesen alakult a helyzet. Ahogy kijött a 64 bites processzor, röviddel utána már volt 64 bites kiadás is. (SuSE?) Szép apránként csökkentek a 32 bites csomagok, mára már alapból nem is települ fel Ubuntu alá egy sem.

Ez viszont elgondolkodtató: "This edition supports the X86_64 architecture and it is optimized for 64bit processors. Note that the Main Edition (which is 32bit) is usually more stable and it also supports 64bitprocessors." Ez olvasható a Linux Mint letöltési oldalán. http://www.linuxmint.com/download.php

Ezen elgondolkoztam kicsit... Windowsból volt 16-bites változat?
...Windows 3.1-ig igen, de annak csak a neve azonos a jelenlegi rendszerrel, még a fejlesztők sem... mindegy.
Valahol Windows NT-től indult a jelenlegi vonal, ami alapvetően 32-bites.

Linux esetén valóban nem igazán volt gondjuk a 16-bittel. :)

Amúgy a 16-32-bites váltás talán kicsit láthatóbb előnyökkel járt, ráadásul pl. a Microsoft meglépte a W3.1 --> W95 váltást, amihez viszont meg kellett venni az új gépet is.
Most nem ilyen erős a kényszer, de azért már jönnek elő problémák pl. a 4GB memória használatával...

Nem tudom, ki emlékszik erre még, de valamikor réges-régen, úgy Linux-1.0.x idején még lehetett úgy kernelt forgatni, hogy max 16 MiB memóriát (RAM+swap<=16 MiB) használjon. Ekkor a címek 24 bitbe, azaz 3 bájtba belefértek, kisebbé téve ezzel a kernel image-t és talán gyorsabbá a futást. Ez így egy (félig?) 24 bites Linux kernel volt.

Erről az ősi dologról van valakinek emléke/benchmarkja? Persze, nem sok gyakorlati jelentősége van, csak egy érdekesség lenne.

Bár x86 összes címzési disznóságát nem ismerem, de nem hallottam még arról, hogy 32 bites üzemmódban lehetne 3 byte-os pointereket használni. 16 bites üzemmódban ilyen near/far pointerekkel lehet, de tudtommal a Linux hivatalos kiadásai sosem használtak 16 bites üzemmódot. Az ELKS projekt készített 16 bites portot, de az egy teljesen más történet.

Ennek szerintem inkább az ISA busz címzési szívás lehetett volt az oka, ott ugyanis 24 bites a címtartomány. Külön memory-hole támogatás kellett, mert a perifériák 15-16MB közötti területre voltak illesztve. Kb ugyanaz a jelenség, mint hogy 4GB memóriát nem tudsz kihasználni 32 biten, mert a memóriatartományba illesztett perifériák ott lebzselnek a címtartomány tetején. A PAE is ilyen memory-hole jellegű módszerrel oldja ezt meg.
---
Internet Memetikai Tanszék

Emlékeim csaltak! Bocs!

Tényleg volt ilyen opció ("Limit memory to low 16MB?"), de ez nem gyorsított, hanem bizonyos hibás hardvereken szolgált workaroundként.

Még egyszer bocs, csak hát régen volt, ...

[De érdekes volt egy linux-1.0.tgz-t letölteni, kibontani, szörnyülködni, milyen kicsi (5.9MB) és hogy 1994-es dátumúak a fájlok, megnézni, hogy tényleg vana Makefile-ban mrproper target, ... :-) ]

"A gyártók se igazán rukkolnak elő 64 bites alkalmazásokkal."

Mert helyből ad egy + % -t a fejlesztési időhöz (szoftver típusától függően kisebb-nagyobb), plusz, ha olyan, akár meg is kétszerezheti a tesztelésre elköltött időt és ez plusz költség.

----------------
Lvl86 Troll

Jujj :)

Azt el szoktak felejteni hogy nincs olyan hogy "rendesen megirt kod" amit nem kell portolni.

Amikor a kod szuletik akkor a szempontok adott fontossaga mindig adott (pl teljesitmeny > portolhatosag). Amikor ennek a szempontrendszernek megfelelsz, akkor lesz "jo" a kod. Kesobb ezt a szempontrendszer valtozhat, ekkor jon az, hogy modositani kell. Ami korabban jo volt, vagy akar szuksegszeru/elkerulhetetlen is lehetett, az kesobb mar nem lesz jo. Ezek a kijelentesek csupan iskloapeldakra igazak, amiknek nem sok koze van a valosaghoz.