Quickbench S01E03: Mi fordít gyorsabban Linux kernelt?

Vélemény

Trey legutóbbi játéka és a vele kapcsolatos hozzászólások nyomán elgondolkoztam, vajon mi fordíthat gyorsabban Linux kernelt?
A Linux, vagy a Linux egy bináris kompatibilitási rétegben? A válasz kézenfekvőnek tűnik, hiszen a natív linuxos környezet mindenképpen gyorsabb kell, hogy legyen, mint egy "emulált", illetve a Linux messze földön híres arról, hogy az ütemezője milyen jó.

A valóság azonban néha meglepetéseket tartogat...

Tesztalanyunk egy erősnek mondható gép, négy darab két magos AMD Opteron processzorral (2,6 GHz órajelen) és 8 GB memóriával, továbbá pár gyors SAS merevlemezzel és egy hozzájuk illő RAID kontrollerrel.

Az első teszt a Linux és a FreeBSD bootolása volt a gépen, sajnos ezen a Linux csúnyán elvérzett. i386-os módban minden rendben ment, azonban AMD64-en az alaplapi Broadcom NetXtreme II-es NIC-eken semmilyen forgalmat nem volt hajlandó fogadni, vagy küldeni, minden úgy látta, hogy nincs link, pedig volt.
A FreeBSD-vel ilyen gondok nem voltak, de vetélytárs híján a 64 bites teszt most elmaradt.

32 biten viszont minden jól ment. A teszt a Trey által végzett make allyesconfig-os kernelfordítás, egyre növekvő párhuzamossággal.

A FreeBSD-n a fordítás ugyanazzal a Linux környezettel történt, a különbség csak annyi volt, hogy nem Linux kernel futott a Linux binárisok alatt (hanem a FreeBSD Linux kompatibilitási rétege), a fájlrendszer pedig a Linuxnál async mountolt ext2 volt, míg a FreeBSD-nél egy softupdates-szel mountolt UFS2.
A szemfüles Linux-hívők most minden bizonnyal felugrottak a székükből, hiszen évek óta azt mondják, hogy az async mount fényévekkel gyorsabb a BSD-k softdepsétől, dehát handicappel szép nyerni. :)

Van tehát 8 fizikai processzormagunk, nézzük mit csinál ugyanaz a Linux OS más-más kernelen, a 2.6.17.11 kernel fordítása közben:

Linux 2.6.17.11 fordítás Linuxon (2.6.17) és FreeBSD-n (6-STABLE)
Parancs Linux FreeBSD
make -j 1 real 30m26.166s
user 27m44.664s
sys 2m53.507s 		real 34m5.555s
user 32m52.187s
sys 3m17.783s
make -j 2 real 17m15.958s
user 27m43.564s
sys 3m1.867s 		real 18m24.749s
user 32m57.835s
sys 3m48.246s
make -j 4 real 10m27.026s
user 28m0.505s
sys 3m13.424s 		real 10m38.893s
user 33m15.917s
sys 4m43.041s
make -j 6 real 8m11.923s
user 28m16.042s
sys 3m19.308s 		real 8m6.513s
user 33m39.892s
sys 5m45.467s
make -j 8 real 7m37.856s
user 28m53.756s
sys 3m23.329s 		real 7m9.830s
user 34m9.094s
sys 5m59.881s
make -j 10 real 7m27.454s
user 29m7.817s
sys 3m29.129s 		real 7m13.928s
user 34m33.028s
sys 6m11.497s
make -j 12 real 7m29.878s
user 29m19.722s
sys 3m30.665s 		real 7m15.565s
user 34m38.831s
sys 6m21.460s
make -j 14 real 7m1.048s
user 29m20.666s
sys 3m33.309s 		real 7m16.959s
user 34m47.279s
sys 6m30.954s
make -j 16 real 7m1.879s
user 29m24.794s
sys 3m35.305s 		real 7m18.305s
user 35m10.469s
sys 6m41.654s

 
Természetesen a tesztből messzemenő következtetéseket nem érdemes levonni, azonban számomra mindenképpen érdekes, hogy a FreeBSD annak ellenére volt képes bizonyos (nem is kevés) esetben gyorsabban futtatni a Linux kódot, hogy közben egy syscall-fordítást is kellett csinálnia, illetve a softupdates (amely garantálni igyekszik a fájlrendszer konzisztenciáját) ellenére tudott gyorsabb lenni a Linux async mountjával (amely ugye semmit sem garantál) szemben.

A fordítás során rengeteg adat keletkezik, hiszen a párszáz MB-os forráskódból a végére több, mint 3 GB-os helyfoglalás lesz, így ebben a tesztben jelentős mértékben számít a fájlrendszer is.

A fordításnak sajnos van olyan része (a vége), ahol meglehetősen sokáig fut a linker, ilyenkor pedig egy kivételével az összes processzor unatkozik.

Érdekes kísérlet lenne lefordítani a Linux kernelt natív FreeBSD-s környezetben is, de ennek összerakásához nem volt már türelmem és időm.

( Hunger | 2006. 09. 17., v – 20:51 )

Esetleg még érdemes lenne kipróbálni más ütemezőkkel is.
Egyébként thx a tesztet, brada. :)

Az ULE eléggé csúnya rohadásokat produkált nálam, úgyhogy ismét nem próbálkozom vele pár évig (ha a FreeBSD-re gondoltál).

Nem az volt a célom, hogy kihozzam a legjobbat, hanem az, hogy out of the box tesztet csináljak. Egyik OS-hez sem nyúltam, mindkettő alapbeállításokkal ment, ennyire voltak képesek.

Nemrég elolvastam a FreeBSD handbook Linux kompatibilitással foglalkozó részét és gondoltam érdemes lenne utánajárni, hogy igaz-e még az állítás:
"It is also reported that in some situations, Linux binaries perform better on FreeBSD than they do under Linux."

Úgy gondolom bent maradhat még a doksiban egy picit. :)

( trey | 2006. 09. 17., v – 21:00 )

"Az első teszt a Linux és a FreeBSD bootolása volt a gépen, sajnos ezen a Linux csúnyán elvérzett. i386-os módban minden rendben ment, azonban AMD64-en az alaplapi Broadcom NetXtreme II-es NIC-eken semmilyen forgalmat nem volt hajlandó fogadni, vagy küldeni, minden úgy látta, hogy nincs link, pedig volt.
A FreeBSD-vel ilyen gondok nem voltak, de vetélytárs híján a 64 bites teszt most elmaradt."

Ezt a problémát a FreeBSD-nél megoldottam úgy, hogy tettem bele egy hálókártyát. Adjak egyet kölcsön? :)

--
trey @ gépház

Köszönöm szépen, van nekem is, de mivelhogy fogalmam sincs, hol van a gép, ez nem volt opció.

Én csak egy távoli hozzáférési lehetőséget kaptam a kollegáktól, megnéztem, vihetik. :)

Biztos az AMD64-en is be lehetne valahogy hergelni azt a portot, de így is elég időt elkeféltem ezzel, többet már nem akartam.

A múltkori kérdéseidre azt hiszem válaszoltam. ;)

( XMI | 2006. 09. 17., v – 23:50 )

Mit látok én ebből:
A user time-ban és a sys time-ban a linuxnak végig tetemes előnye van. Ez várható is volt, hiszen nyilván nagyobb overhead-je van a kompatibilitási rétegnek. A FreeBSD-nél a folyamatok számával monoton növekszik a user time és a sys time is. Ez is várható volt. A Linuxnál viszont helyenként nem, ami furcsa.
Az is látszik, hogy a freebsd-nek folyamatosan csökken a real time-ja egészen 8 folyamatig, ahonnan lassan monoton növekedni kezd. Micsoda meglepetés, hiszen 8 mag van a gépben ennek is így is kell lennie. De a linux megintcsak nem követi a várható mintát. Nem monoton a változás, ami még betudható akár mérési hibának is, de a csökkenés hirtelen 14 processznél az finoman szólva is furcsa. Ráadásul végülis 14 folyamattal megveri a freeBSD legjobb, 8 folyamatos értékét (de elég kevéssel, ha figyelembe vesszük azt, hogy mennyivel kevesebb az overhead). Ez olyan, mintha valahogy 8 folyamatnál még nem tudna elég feladatot adni a 8 magnak, 14 folyamat kell ahhoz, hogy mindegyiket ki tudja teljesen használni. Vagyis bármennyire is furcsa, a linux skálázódik rosszabbul, a linux tudja kevésbé kihasználni a sok magot. Tényleg érdekes lenne a natív fordítási teszt, ebben ugyanis a freebsdnek az extra overhead nélkül rommá kéne vernie linuxot. Persze kérdés, hogy az overhead mennyire csökken attól, hogy natív.

---
Az ember mindig szerepet játszik. Ha másnak nem, hát saját magának.

( trey | 2006. 09. 18., h – 07:20 )

Nekem e számok helyett az volt meglepő, hogy a Woodcrest 4 maggal "make -j 4"-ig elég szépen rávert a 8 magos rendszerre. :)

4 magos Woodcrest 8 magos Opteron
make -j 24m8.490s 30m26.166s make -j 2 13m29.288s 17m15.958s make -j 4 8m27.997s 10m27.026s

 
--
trey @ gépház

Igen, ezen én is gondolkoztam és két dologra jutottam:
- lehet, hogy segít a 64 bites környezet
- lehet, hogy az amd64-es kernelben kevesebb minden fordul le
- lehet, hogy a Woodcresttel az Intel utolérte az AMD-t teljesítmény/órajel arányban, így pedig a 2,6 GHz-es Opteronnal szemben a 3 GHz-es Xeon okozhatja a különbséget

A kettő szerintem jelen formájában semmilyen módon nem összehasonlítható, kellene minimum egy 32 bites teszt is a Xeonon, vagy egy 64 bites az Opteronon.

De nem tartom kizártnak, hogy az új Xeonok gyorsabbak legyenek, sőt, inkább ezt tartom valószínűnek.

( crown v | 2006. 09. 18., h – 15:10 )

Itt nem volt fontos tenyezo, hogy ki milyen file rendszeren mukodott? 3GB adat pl. nemely fs-t meg akar kepes is belassitani, tudtommal.

Ti nagyfiuk elveszitek az egyprocis emberek kedvet mindenfajta kernelforditastol!!! Gyalazat! ;-)

FreeBSD-n nyilván nincs túl sok opció (UFS és annak különféle módjai), Linuxon már van, de francnak sem volt kedve 28 fájlrendszerrel megismételni ezt a tesztet.

Nem hiszem, hogy egetrengető különbségek születtek volna, mindamellett, hogy a fordítás valóban io intenzív.

Milyen szempontból?

FreeBSD alatt legalábbis "nagy" fájlokkal már a kezdetektől nincs probléma, azaz a legszutyibb 386-osodon a legrégebbi FreeBSD-vel is tudsz GB-os fájlokkal dolgozni.

Logikailag a fájlrendszer (UFS1) mérete is elég nagy volt emlékeim szerint, az UFS2-nél ha minden igaz teljesen 64 bites, azelőtt gondot okozhatott 1-2 TB-nál nagyobb fájlrendszer kezelése (de fájlokat használhattál ennél nagyobbat is).

Vannak ACL-ek, van az EA-knak is helyük (UFS1-ben utóbbi kevésbé jó, UFS2-vel jobb).

Tud fájlrendszer szintű, de csak RO snapshotokat, lehet rajta kvótát használni (csak mint linuxosnak mondom, ott nem mindig triviális ;).

A 6-os, ill. 7-es verzióban már teljesen SMP biztos, bár bizonyos részek (pld. kvótakezelés) még magukkal húzhatják a giant lockot.

Specialitás a soft updates, amely a journalinghoz képest egy más megközelítést ad a fájlrendszer konzisztenciájának megtartására. Elméletben akár gyorsabb is lehet, mint a naplózás.

Hátránya, hogy azért ha jót akarsz, érdemes fsck-znod nem tiszta leállásnál, ilyenkor viszont használhatsz background fsck-t, amely miatt lényegében a snapshotot megcsinálták. Ez egy snapshotot készít a fájlrendszerről, azt ellenőrzi, majd az árva dolgokat (feltéve, hogy az SU konzisztens maradt) visszaírja az éles fájlrendszerre. Nagyobb fájlrendszernél (pár TB) géptől és a fájlrendszer paramétereitől függően egy fsck több tíz perc, vagy akár óra is lehet.

Nem tud online átméretezhetőséget, offline-ban viszont a growfs utillal növelhető (csak, csökkenteni nem lehet).

Nem tud osztott médiát kezelni, még úgy sem, hogy egy RW, a többi felhasználó RO. Természetesen ha mindenki RO, az működik, mint máshol is.

Nem "byte order neutral", azaz egy Sparc-on formázott fájlrendszert nem tudsz a csilivili PC-dben használni.

Nem tud storage tieringet, azaz bizonyos könyvtárakat, vagy fájltípusokat nem tudsz eltérő storage-okra tenni (pld. a .mp3-at SATA-ra, a .db-t pedig FC-re).

Van benne némi autotuning. Ha a fájlrendszer kevésbé telített, megpróbálja elkerülni a fragmentációt, ha már nagyon telített (8%), inkább az allokáció idejét próbálja csökkenteni.

Egy alap ext2 formázáshoz képest UFS2-vel formázni egy 128TB-os kötetet annyit tesz, mint teleporttal, vagy gyalog lemenni Szegedre, persze ez mindkét helyen tuningolható az mkfs/newfs oldalon. Mivel kevesebbet ír alapból, a formázott diszken is kevesebb metaadat lesz->több hely marad neked (konkrét méréseim nincsenek.

Lehet a fájlrendszerre címkéket akasztani, ezeket a rendszer képes okos GEOM classok révén felismerni és így a /dev-ben a címke alapján hivatkozhatsz a fájlrendszerre. Előnye, hogy akárhová kerül a diszk, akármilyen vezérlőre, az fstab-od mindig jó lesz.

Tuningolható a blokkméret és sok egyéb más is, ehhez mondjuk nem árt érteni is hozzá.

A különböző OS-ekben lévő UFS-ek az idők során elágaztak, a Solarisban az UFS például képes journalingra is és van benne pár extra okosság, illetve eltérés, amit máshogy oldottak meg. Pld. a FreeBSD-ben a nagy fájlrendszerek és a többi sallang miatt az UFS1 nem kompatibilis az UFS2-vel.

Nincs fájlrendszerrel egybegyógyított volume menedzsment, RAID és hibatűrést növelő checksumok (lásd ZFS).

Nincs verziózás sem.

Nagyjából ennyi jutott eszembe. Persze ezek nagy részét a linuxodon sem találod meg, legfeljebb több fájlrendszerben, vagy pénzbe kerülő termékben.

extX-en (e2label) és reiser-en (az eszközre már nem emlékszem) biztosan van ilyen, csináltam ilyet a laptopom Linux részén, és mind Linux alól, mind FreeBSD alól a label alapján mountoltam a linuxos fájlrendszereket. Linux alatt valami label=akarmi kellett az fstabba a device (első) oszlopba, de ha a root-ot is így akarod mountolni, akkor lilo/grub segítségével valami kernel opciót kell átadni boot-kor.

( szaszg | 2006. 09. 18., h – 19:49 )

Elso kerdesem: hany meres atlagat raktad ide?
Azutan: hany processz futott a hatterben a forditason kivul?(boot utan rogton nekifutottal? ha igen az jo, mert akkor fut le egy csomo dolog...)
Amugy:
man time 


ACCURACY
       The  elapsed  time  is not collected atomically with the execution of the program; as a re-
       sult, in bizarre circumstances (if the time command gets stopped or swapped out in  between
       when  the  program  being timed exits and when time calculates how long it took to run), it
       could be much larger than the actual execution time.

Nem kell annak much larger-nek lenni, hogy felrevezessuk a jonepet...

Lehet, hogy a forditas idoigenyet talan valamivel jobban kozeliti a User ill Sys ertek osszege:
(man time: 


              S      Total  number  of CPU-seconds used by the system on behalf of the process (in kernel mode), in seconds.
              U      Total number of CPU-seconds that the process used directly (in user mode), in seconds.

)

Ha felretesszuk a hulyeseget, akkor a kovetkezoket vonhatjuk le:
0. gondolom egyszer merted minden pontjat, ergo az egesz nem rendelkezik gyakorlatilag ertekelheto jelentessel
1. a Linux User+Sys mindenhol jobb, mint a BSD-s
2. mivel a sys-ben leledzik a filesystem reteg nagy resze ezert azt is megallapithatjuk, hogy valoszinuleg tenyleg lasabb a softupdates
3. a skalazhatosaggal osszefuggo resz a USER-ben van. Ez BSD alatt 1972.187 s-rol 2110.469s-ra nott ami 138.282s ez a kiindulas 7%-a;
Linuxon 1664.664s-rol 1764.794s-ra nott ami 100.13s ez a kiindulas 6%-a. Ebbol le lehet vonni, hogy a mind a ket rendszer gyakorlatilag ugyanugy skalazodik.

Zsiraf

p.s.: ;-) igy tovabb... Amugy halottal valamit statisztikarol, meg student faktorrol?

Nem átlagoltam, egy teljes fordítás után néztem sorban az összeset, azaz az első fordítás eredménye nem szerepel. Egy alaprendszer futott, cron, sendmail és a társai leállítva (furcsa, hogy ezeket nem említed).
A gépben nem volt swap (furcsa, hogy ezt nem említed), így az általad idézett manlap részlet irreleváns.
User és sys: ezeket a kernel méri, ő tudja hogyan és nyilván nem ugyanúgy egy emulált, mint egy natív esetben. Az, hogy valójában hány óra volt a fordítás megkezdésekor és ehhez képest mennyi telt el a befejezéséig szerintem jobban jellemzi azt, hogy meddig is tartott a folyamat. Magyarázd el kérlek, hogy miért gondolod azt, hogy a fordítás időigényét a kernel által számolt user+sys jobban jellemzi, mint az, hogy VALÓJÁBAN meddig tartott. Ember vagyok, elvégzendő feladatokkal. Ha egy gép a feladatot egy óra alatt végzi el, azért, mert bár két processzor van benne, de az egyik feladat végrehajtására vár a másik, akkor hiába eszik feleannyi processzoridőt a cucc, nekem végig kell várnom az egészet.
Itt ugyanaz volt a feladat mindkét gépen, az egyik hamarabb végzett, mint a másik, mindezt úgy, hogy több CPU időt töltött a feladattal. Ez utóbbiból mindkét esetben ugyanannyi állt rendelkezésre, így az én szemszögömből nézve lényegtelen, hogy mennyi fogyott belőle, ha a teljes folyamat gyorsabban befejeződik.
0. nyilván, hiszen egy swap nélküli, sshd-n kívül szinte mást alig futtató környezet erősen nem determinisztikus. Nem is értem, miért nem említed a hőmérsékleti tényezőket (merevlemez), ennek vonatkozásában a statikus, pontosan szabályozott géptermi klímát (hőmérséklet, páratartalom, stb), a teljes árnyékolást, amely kihatással lehet a gép működésére, a tökéletesen tiszta DC tápot, a mérés szempontjából kiszámíthatatlanul működő merevlemezek tökéletlenségét a feladatra, és azt, hogy egy tömeggyártott, változó minőségű eszközön lehetetlen jónak mondható mérést csinálni, ahhoz a teljes gyártott széria legalább 1%-ával mérni kellene, tökéletes laborkörülmények között.
1. igen, mégis hamarabb végzett. Ez hogy lehet?
2. egyre jobb. Lassabb a fájlrendszer, mégis gyorsabban végez? Wow! Mire lenne képes a FreeBSD natív alkalmazásokkal, gyorsabb fájlrendszerrel! Nem is értem mi ez a hype a Linux körül.
3. ezen meglepődök, jó?

ps: azt hallottam, hogy a statisztikával bármit be lehet bizonyítani, a student faktor meg csak sejtem mi lehet, de biztosan nem tudom. Remélem majd leírod.

Őszintén kíváncsi lennék, hogy te hogy csinálnál egy ilyen quickbenchet, mivel tennéd még kiszámíthatóbbá az eredményeket. Nekem van még ötletem, de nem egy laborban dolgozom és nem az a munkám, hogy űrtechnológiai eszközökkel mérjem kommersz PC-ken a Linux kernel lefordulásának idejét.

:)

Mivel mindket rendszer elegge komplex amin mertel (multitask, meg egyeb kulso zavarok, pl. net, mittudomenmi...) ezert itt is elegge alkalmazando a merestechnika/statisztika fotorvenye, 1 meres nem meres. Ha a student faktorrol nem halottal meg, akkor nezzel utanna... Nem hiszem, hogy kepes lennek a merestechnika/statisztika alapjait itt par sorban barki szamara elmagyarazni :-(... Csak diohejban, arra szolgal, hogy egy meres eredmenyenek a valos erteketol valo elteresenek valoszinuseget megbecsulhesd... :-) remelem jo homalyos volt. Konkretabban kifejtve: ha mersz mondjuk X rendszeren kernelforditasi idoket, tegyuk fel 1000-szer. Kijon kb. ezer kulonbozo eredmenyed. Ezek ismereteben megbecsulheted a varhato erteket (mi az ami korul szornak az eredmenyeid), valamint azt is, hogy az altalad becsult ertket, mekkora -- mondjuk igy -- statisztikai hiba terheli. Nem meglepo, minel tobbszor mertel, annal kisebb a statisztikai hibad, azaz annal jobban ki tudod kuszobolni a "veletlen" zavarokat. Persze ennek az inverze is igaz, minel kevesebbszer mertel annal kerdesesebb az eredmenyed... (tudod szoras, meg gauss gorbe, vagy egyeb eloszlasi fuggveny, meg felertekszelesseg, stb :-)

De visszaterve a man time-ra. Elolvastad? Csak az angolul nem annyira ertok kedveert: azt allitotta, hogy kulonos korulmenyek kozott, mint pl. ha lapatra kerul a time, elkepzelheto, hogy sokkal hoszabb idot ir ki, mint amit a seiko-dal mernel... De nem azt mondja, hogy csak ettol lehet pontatlan... Ettol meg nem hiszem, hogy elvesztene relevanciajat az adott dolog... Ki tudja, hogy az adott mereskor, hanyadik task-valtassal jutott a vezerles a time-ra, hogy kiszamolhassa "most lett vege a dolognak"? Megis, hany processz futott a rendszereken?

Azutan meg sok minden bizony zavarhatja a merest... pl. kulonbozo interruptok kezelese (eger, bill, net, hangartya, vga, usb, ...) Raid sajat belso elete... Egyeb dolgok disk i/o-ja... Taskvaltasok szama...

Amugy a sebesseg kulombseg alulrol eppen utogeti az ipari/gyakorlati (mint emlitetted nem laboratoriumban mertel) merestechnika okolszabalyszeru pontossagat a 10%-ot ;-) Az elso esetben ugyanis a Linux volt real time-ban 10.7%-al gyorsabb a BSD-t alapul veve, a "legrosszabb" esetben 6.52%-al volt lasabb szinten a BSD-re vonatkoztatva ;-).
Persze mint mar emlitettem, amig nem csinalsz minden esetrol tobb merest, addig a dolog tulajdonkeppen ertelmezhetetlen. Mert lehet, hogy a kovetkezo esetben pont forditva alakulnanak a %-ok. Egy meresnel meg a szorast sem szamithatjuk ki, ami pedig minden meres egyik legeslegeslegeslegalapvetobb parametere...

Tehat visszaterve a szerintem eredendo problemara:
amig minden egyes meresi pont mogott nincs szoras ertek (amihez egynel azert tobb meres kell :-) addig semmit sem lehet a dologrol nyilatkozni.

Zsiraf

p.s.: Amugy ne vedd a dolgot szemelyes tamadasnak, de sajnos rengeteg hasonlo osszehasonlitast olvasgattam itt is, meg mashol is, kezdve a file-rendszerek sebessege, kilonbozo bench-ek, stb, stb. Es sehol sem emlekszem olyanra, hogy valaki megemlitette volna, ezt 1000x mertuk az erteke ennyi, a szorasa ennyi... ha meg a varhato hibakat is feltuntetjuk, akkor meg lehet, hogy el kell ismernunk, a meres alapjan nem allithatjuk ez jobb az meg rosszabb. Szoval, most borult ki a bili...

p.s.2: amugy, nyugodtan hidd, hogy a BSD gyorsabb, meg szebb, meg szagosabb nem ennek a hitnek a megdontese volt a celom... Persze lehet, hogy DOS alatt meg gyorsabban lefordulna a Linux kernel...

> p.s.2: amugy, nyugodtan hidd, hogy a BSD gyorsabb, meg szebb, meg szagosabb

Miért, fájna, ha véletlenül így lenne?
Miért fájna, ha véletlenül így lenne?

Nem emlékszem, hogy hasonló teszteknél ennyire belemélyedtél/tetek volna a méréselméletbe.

(Ja, nem tértél ki annak részletezésére, hogy a Bra által jelzett: async mount vs. softupdates két _homlokegyenest_ ellenkező megbízhatóságot kíván elérni, tehát almát naranccsal az összehasonlítás.

Ha szőrszálat hasogatunk, akkor belemehetnénk abba is, hogy:

FreeBSD_sh $ type time
time is /usr/bin/time
FreeBSD_pdksh $ type time
time is a reserved word
FreeBSD_ksh93 $ type time
time is a keyword
FreeBSD_bash $ type time
time is a shell keyword
FreeBSD_csh %which time
time: shell built-in command.

Azaz ki/be lapozódni - no jó, lapátra kerülni - egyedül sh-n tudna a time (mint processz), máshol legfeljebb a shell maga ;-) (Felteszem Linux alatt pedig bash fut, azaz ő áll szemben a valszeg csh-val.

De külön örülök, hogy elhangzott ez is: "ha közvetlenül indítás után mérted, akkor még egy csomó minden szaladgál". Remélem ez arra vonatkozott, hogy Linux alatt, mert FreeBSD-n maximum a bgfsck. Ami _szerintem_ itt nem játszott. Azaz max egy VPS Linux esetén számíthatna bele a dologba.

Szóval csak semmi pánik, kijött _egy_ eredmény, se jobb, se rosszabb dolog nem sült ki, mint a korábbi teszteknél, akárki is végezte, akármilyen eredménnyel.

Szóval csak semmi pánik, kijött _egy_ eredmény, se jobb, se rosszabb dolog nem sült ki, mint a korábbi teszteknél, akárki is végezte, akármilyen eredménnyel.

Akkor megegyszer, s most mar csak a legvelejet a dolognak. Amig a masodpercek melle nem irja oda a varhato hibat vagy esetleg a szorast, addig nem beszelhetunk arrol, hogy kijött _egy_ eredmény.

Zsiraf

p.s.: Amugy egyaltalan nem erdekel, hogy hol gyorsabb a kernelforditas, es mint olvashattad az osszehasonlitas, csak kiboritotta a bilit. Minden gondolat ugyanugy vonatkozik pl. az ezt megelozo reiser/ext3-ra is (ha jol emlekezem mintha valami ilyesmi lett volna)

Mondd meg kérlek, hogy hány futási eredményre van szükséged ahhoz, hogy a pontosság és a korrektség iránti igényed megfelelően kielégítésre kerüljön, illetve, hogy ezekből az adatokból aztán meg tudd határozni az annyira hiányolt méréstechnikai fogalmak értékét.

Egy dologra felhívnám a figyelmed: ha jól számolom a teljes __írd ide mi volt ez__ kb. 210 percig tartott (a tévedés jogát fenntartom). Ez ugye egy menet, ami értékelhetetlen. Ha 100 futásra van igényed, az kb. 15 nap, ha 1000-re, az fél év.

Nagyon szívesen rendelkezésedre bocsájtjuk a gépet erre az időre, de ha 10-nél több futási eredményt szeretnél, kérlek faxolj el egy hivatalos árajánlatkérőt, ez ugyanis már pénzbe fog kerülni.

Treyjel majd megbeszéljük, hogy minden publikált tesztből lesz egy igénytelen, használhatatlan verzió ingyen, meg egy tudományosan alátámasztott, legalább 1000 futási eredményből számolt, de ez már csak a merestechnika.hup.hu oldalon, amelyet csak érvényes és megfelelő fedezettel bíró bankkártyával lehet látogatni. ;)

Na akkor a kedvedért az eredetivel együtt 130 darab eredmény (FreeBSD, make -j 8). Kérlek legyél jó a közösséghez és magadhoz, számold ki a hiányolt méréstechnikai elemeket és tedd közzé azt, hogy mire jutottál. Ezel felül érdekelne, hogy az alábbi 129 eredmény tekintetében mennyire ítéled pontosnak az eredeti, 130-adikat (fent a cikkben).

Köszönöm.

real 7m9.685s
user 34m13.383s
sys 5m58.179s

real 7m9.799s
user 34m14.218s
sys 5m57.218s

real 7m9.438s
user 34m12.563s
sys 5m57.938s

real 7m9.989s
user 34m12.317s
sys 5m58.643s

real 7m9.916s
user 34m11.509s
sys 6m0.284s

real 7m9.480s
user 34m12.900s
sys 5m56.596s

real 7m9.787s
user 34m9.608s
sys 6m2.202s

real 7m10.071s
user 34m14.416s
sys 5m57.661s

real 7m10.459s
user 34m16.448s
sys 5m57.088s

real 7m9.614s
user 34m12.143s
sys 6m0.146s

real 7m9.301s
user 34m12.666s
sys 5m58.907s

real 7m9.723s
user 34m12.243s
sys 5m58.571s

real 7m9.749s
user 34m14.959s
sys 5m55.156s

real 7m9.943s
user 34m15.797s
sys 5m56.812s

real 7m9.804s
user 34m13.991s
sys 5m58.105s

real 7m9.899s
user 34m10.331s
sys 6m2.679s

real 7m9.354s
user 34m11.055s
sys 5m59.016s

real 7m9.748s
user 34m9.032s
sys 6m3.027s

real 7m10.095s
user 34m11.480s
sys 5m59.701s

real 7m9.998s
user 34m14.530s
sys 5m58.148s

real 7m9.790s
user 34m11.364s
sys 6m1.464s

real 7m9.388s
user 34m11.415s
sys 5m58.569s

real 7m9.868s
user 34m13.088s
sys 6m0.478s

real 7m9.804s
user 34m12.667s
sys 5m58.826s

real 7m10.401s
user 34m11.926s
sys 6m3.740s

real 7m10.357s
user 34m13.115s
sys 5m59.764s

real 7m10.149s
user 34m15.691s
sys 5m58.041s

real 7m10.004s
user 34m14.493s
sys 5m59.252s

real 7m10.069s
user 34m13.226s
sys 5m59.770s

real 7m10.020s
user 34m14.911s
sys 5m57.584s

real 7m10.071s
user 34m11.992s
sys 6m3.288s

real 7m9.895s
user 34m12.702s
sys 6m0.839s

real 7m9.777s
user 34m13.686s
sys 5m58.927s

real 7m10.256s
user 34m10.283s
sys 6m4.831s

real 7m10.271s
user 34m13.997s
sys 6m2.236s

real 7m10.447s
user 34m16.978s
sys 5m59.668s

real 7m10.049s
user 34m15.257s
sys 5m57.682s

real 7m9.966s
user 34m14.137s
sys 6m0.482s

real 7m10.137s
user 34m11.699s
sys 6m3.145s

real 7m10.261s
user 34m16.306s
sys 5m58.257s

real 7m9.597s
user 34m11.245s
sys 6m1.344s

real 7m9.745s
user 34m12.227s
sys 6m0.838s

real 7m10.110s
user 34m13.990s
sys 6m0.004s

real 7m10.373s
user 34m14.548s
sys 6m1.209s

real 7m10.156s
user 34m14.003s
sys 5m59.887s

real 7m9.575s
user 34m12.146s
sys 6m1.098s

real 7m9.838s
user 34m16.280s
sys 5m56.149s

real 7m9.871s
user 34m12.653s
sys 6m0.053s

real 7m9.945s
user 34m15.523s
sys 5m58.921s

real 7m10.075s
user 34m12.848s
sys 5m59.631s

real 7m10.104s
user 34m13.503s
sys 6m1.121s

real 7m9.700s
user 34m10.633s
sys 6m1.996s

real 7m10.201s
user 34m16.087s
sys 5m58.317s

real 7m10.439s
user 34m12.270s
sys 6m1.835s

real 7m10.287s
user 34m12.336s
sys 6m3.048s

real 7m9.968s
user 34m10.880s
sys 6m2.886s

real 7m10.135s
user 34m12.790s
sys 6m1.054s

real 7m9.998s
user 34m15.009s
sys 5m58.174s

real 7m9.969s
user 34m12.931s
sys 5m59.847s

real 7m10.161s
user 34m16.244s
sys 5m57.491s

real 7m10.438s
user 34m13.281s
sys 6m1.640s

real 7m10.007s
user 34m14.916s
sys 5m59.968s

real 7m10.318s
user 34m16.614s
sys 5m57.685s

real 7m10.557s
user 34m15.077s
sys 6m1.747s

real 7m10.662s
user 34m15.433s
sys 6m0.822s

real 7m9.969s
user 34m12.664s
sys 5m59.813s

real 7m10.284s
user 34m17.488s
sys 5m57.946s

real 7m10.132s
user 34m13.444s
sys 6m0.873s

real 7m10.433s
user 34m16.706s
sys 5m59.319s

real 7m9.834s
user 34m10.374s
sys 6m4.105s

real 7m10.375s
user 34m16.697s
sys 5m58.955s

real 7m10.576s
user 34m12.726s
sys 6m4.852s

real 7m9.904s
user 34m16.168s
sys 5m58.504s

real 7m10.360s
user 34m16.510s
sys 5m59.037s

real 7m10.150s
user 34m13.952s
sys 6m1.017s

real 7m10.206s
user 34m16.770s
sys 5m59.570s

real 7m10.323s
user 34m15.601s
sys 6m0.112s

real 7m10.042s
user 34m14.321s
sys 6m0.738s

real 7m10.586s
user 34m15.167s
sys 6m0.821s

real 7m10.402s
user 34m12.089s
sys 6m5.401s

real 7m9.920s
user 34m12.577s
sys 6m2.283s

real 7m10.212s
user 34m13.440s
sys 6m2.121s

real 7m10.393s
user 34m13.919s
sys 6m1.177s

real 7m10.319s
user 34m13.525s
sys 6m2.674s

real 7m10.087s
user 34m12.329s
sys 6m2.559s

real 7m10.011s
user 34m11.535s
sys 6m2.425s

real 7m10.088s
user 34m11.874s
sys 6m3.005s

real 7m10.168s
user 34m16.637s
sys 5m58.186s

real 7m10.559s
user 34m12.546s
sys 6m3.919s

real 7m10.086s
user 34m17.946s
sys 5m57.606s

real 7m10.150s
user 34m10.942s
sys 6m2.880s

real 7m10.638s
user 34m16.099s
sys 6m0.987s

real 7m10.100s
user 34m12.467s
sys 6m1.145s

real 7m10.750s
user 34m13.100s
sys 6m4.464s

real 7m10.268s
user 34m14.391s
sys 5m59.576s

real 7m10.486s
user 34m16.098s
sys 6m0.502s

real 7m10.206s
user 34m12.454s
sys 6m3.298s

real 7m10.432s
user 34m13.190s
sys 6m3.539s

real 7m10.423s
user 34m12.545s
sys 6m2.769s

real 7m10.475s
user 34m15.754s
sys 6m1.091s

real 7m10.138s
user 34m15.430s
sys 6m0.852s

real 7m10.147s
user 34m14.453s
sys 6m1.173s

real 7m10.072s
user 34m15.728s
sys 6m0.071s

real 7m10.754s
user 34m15.606s
sys 6m2.314s

real 7m10.249s
user 34m18.307s
sys 5m57.036s

real 7m10.057s
user 34m13.226s
sys 6m2.025s

real 7m9.910s
user 34m13.093s
sys 6m0.136s

real 7m9.829s
user 34m13.754s
sys 6m0.334s

real 7m10.165s
user 34m15.778s
sys 5m58.766s

real 7m10.856s
user 34m16.077s
sys 6m1.797s

real 7m10.047s
user 34m12.075s
sys 6m3.595s

real 7m10.240s
user 34m13.745s
sys 6m1.708s

real 7m10.579s
user 34m17.662s
sys 6m0.331s

real 7m10.128s
user 34m11.921s
sys 6m2.009s

real 7m10.036s
user 34m15.269s
sys 5m59.516s

real 7m10.575s
user 34m14.915s
sys 5m59.519s

real 7m10.479s
user 34m13.966s
sys 6m2.231s

real 7m10.004s
user 34m12.032s
sys 6m2.452s

real 7m10.364s
user 34m13.772s
sys 6m3.371s

real 7m10.081s
user 34m12.393s
sys 6m3.220s

real 7m10.073s
user 34m11.404s
sys 6m3.930s

real 7m10.325s
user 34m14.282s
sys 6m1.262s

real 7m10.613s
user 34m13.193s
sys 6m2.555s

real 7m10.325s
user 34m12.534s
sys 6m3.034s

real 7m10.302s
user 34m15.497s
sys 5m58.833s

real 7m10.071s
user 34m12.775s
sys 6m2.786s

real 7m10.740s
user 34m12.531s
sys 6m2.648s

real 7m10.077s
user 34m13.707s
sys 6m1.101s

real 7m10.262s
user 34m11.959s
sys 6m2.849s

Valami buga lehet a user és sys mérésben a Linux emunál. Ezért sincs értelme azt használni.
Viszont újabb mérési eredmények, amelyek alapján számolhatsz. Ugye nem hagysz cserben és azok után, amiket írtál, valóban kiszámolsz mindent, amit hiányoltál?

Ennyivel tartozol nekünk. :)

real 7m10.153s
user 34m10.467s
sys 6m4.404s

real 7m10.177s
user 34m13.777s
sys 6m0.938s

real 7m10.672s
user 34m13.162s
sys 6m2.906s

real 7m10.160s
user 34m11.753s
sys 6m4.560s

real 7m10.307s
user 34m12.556s
sys 6m3.437s

real 7m10.467s
user 34m11.693s
sys 6m5.449s

real 7m10.562s
user 34m14.682s
sys 6m1.358s

real 7m10.305s
user 34m12.955s
sys 6m3.743s

real 7m10.510s
user 34m15.111s
sys 6m1.032s

real 7m10.752s
user 34m16.569s
sys 6m0.367s

real 7m9.915s
user 34m14.556s
sys 5m58.943s

real 7m10.293s
user 34m14.078s
sys 6m1.531s

real 7m10.235s
user 34m15.393s
sys 6m0.934s

real 7m10.840s
user 34m11.974s
sys 6m4.944s

real 7m9.916s
user 34m15.506s
sys 5m59.744s

real 7m10.680s
user 34m15.455s
sys 6m2.104s

real 7m10.250s
user 34m11.723s
sys 6m4.061s

real 7m10.896s
user 34m15.543s
sys 6m1.795s

real 7m9.983s
user 34m16.700s
sys 5m57.003s

real 7m10.339s
user 34m14.539s
sys 5m59.362s

real 7m10.263s
user 34m12.722s
sys 6m2.346s

real 7m9.764s
user 34m11.551s
sys 6m2.773s

real 7m10.321s
user 34m18.711s
sys 5m58.953s

real 7m10.304s
user 34m14.811s
sys 6m0.335s

real 7m10.544s
user 34m12.626s
sys 6m4.144s

real 7m9.831s
user 34m12.482s
sys 6m1.619s

real 7m10.317s
user 34m12.609s
sys 6m2.953s

real 7m10.548s
user 34m13.780s
sys 6m0.832s

real 7m10.502s
user 34m13.215s
sys 6m2.260s

real 7m10.038s
user 34m13.723s
sys 6m0.088s

real 7m10.063s
user 34m14.626s
sys 6m0.908s

real 7m10.582s
user 34m11.105s
sys 6m6.131s

real 7m10.950s
user 34m13.036s
sys 6m5.007s

real 7m10.923s
user 34m17.310s
sys 5m59.282s

real 7m10.448s
user 34m10.570s
sys 6m6.271s

real 7m9.999s
user 34m13.103s
sys 6m0.765s

real 7m10.006s
user 0m0.326s
sys 40m13.789s

real 7m10.324s
user 0m0.366s
sys 40m15.308s

real 7m10.648s
user 0m0.343s
sys 40m16.369s

real 7m10.623s
user 0m0.353s
sys 40m13.274s

real 7m10.432s
user 0m0.355s
sys 40m13.551s

real 7m10.268s
user 0m0.360s
sys 40m15.309s

real 7m10.172s
user 0m0.353s
sys 40m14.835s

real 7m10.484s
user 0m0.405s
sys 40m17.175s

real 7m10.174s
user 0m0.350s
sys 40m16.071s

real 7m9.960s
user 0m0.394s
sys 40m12.734s

real 7m10.801s
user 0m0.361s
sys 40m17.742s

real 7m10.318s
user 0m0.380s
sys 40m15.142s

real 7m10.275s
user 0m0.386s
sys 40m15.454s

real 7m10.175s
user 0m0.339s
sys 40m14.507s

real 7m10.547s
user 0m0.374s
sys 40m16.479s

real 7m10.694s
user 0m0.362s
sys 40m16.880s

real 7m9.847s
user 0m0.406s
sys 40m13.387s

real 7m10.590s
user 0m0.393s
sys 40m13.986s

real 7m10.276s
user 0m0.378s
sys 40m16.011s

real 7m10.773s
user 0m0.381s
sys 40m14.839s

real 7m10.002s
user 0m0.384s
sys 40m14.196s

real 7m10.589s
user 0m0.389s
sys 40m16.088s

real 7m10.238s
user 0m0.358s
sys 40m14.949s

Azaz ki/be lapozódni - no jó, lapátra kerülni - egyedül sh-n tudna a time (mint processz), máshol legfeljebb a shell maga ;-) (Felteszem Linux alatt pedig bash fut, azaz ő áll szemben a valszeg csh-val.

Akkor megegyszer a time pontatlansagarol.

The elapsed time is not collected atomically with the execution of the program; szerintem ez egy kulcsmondat, s talan vonatkozik a shell builtin-ekre is, mivel a getrusage() nem tartalmazza ezt az informaciot, csak a sys es user-t. Ha belegondolsz, a real_time hibaja attol is fugg, hogy mikor erkezik el a child kilepesenek a hire a mero processzhez...

Zsiraf

Nyilván egy 8 processzoros, minimális számú, semmi mást nem csináló processzekkel rendelkező gépen van értelme arról beszélni, hogy az interruptok kezelése, a taskváltások száma érdemben befolyásolhatja a time kimenetét.
Méréstechnikát én is tanultam még jó régen, de tudod, ahogy a time manualjában is írják, kipage-elte az agyam az egészet. Legnagyobb szomorúságomra a pagefájl a /dev/null-ban van. :(

Szerintem zárjuk a dolgot annyival, hogy amikor te az egyetemen, vagy a laborban mérsz valamit, amelynek a valóságot jobban kell közelítenie, mint egy ilyennek, akkor nyilván ennek megfelelően jársz el.

Hány processz: a Linuxot már nem tudom megnézni neked, de a FreeBSD még fut a gépen. 8 getty, 2 sshd (master és child) és egy shell. Plusz ezen kívül a linuxos shell, amiből ugye a make futott. Az sshd ugye selectben áll, a gettyk ttyin-ben, azaz leginkább egyik sem fog futni.
Komoly esélyét látom a time manualodban leírtaknak. :)
Milyen egyéb dolgok disk io-ja? Lényegében a gettyken és az sshd-n kívül egy single userben futó gépen történt a mérés. Jaj, bocsánat, mérésnek ne hívjuk, mert ez nem volt mérés. Hívjuk becslésnek. Hívhatjuk annak, vagy annak sem jó?

Azt mondod, hogy 10%. Ennél a __írd ide minek hívjam__-nél a legrövidebb időknél 10% kb. 40 másodperc. Azért ezt ugye nem gondoltad komolyan?

ps: nem veszem személyes támadásnak, felesleges okoskodásnak venném, ha arrogáns lennék. De mivel nem vagyok az és mivel az én fejembe is próbáltak ilyeneket beleverni anno, nem hívom mérésnek és nem is mondom, hogy bármit is ér az egész. ISMÉT FELHÍVNÁM A FIGYELMED A CIKK CÍMÉRE: QUICKBENCH.

Hálás vagyok, hogy megosztod velünk az okosságot, mert szakemberként elképesztően idegesítő hülyeségeket olvasni, de ha komolyan gondolod, hogy egy ilyen tesztet tudományos módszerekkel, több tízszer, százszor, ezerszer lefuttatva, az értékekből mindenféle, a köz számára totál értelmezhetetlen és érthetetlen adatokat számolva kellene elvégezni, akkor csak mosolyogni tudok. Így: :)

Csak tippelek: többször lefuttatva ugyanazt a make-et szerintem az eredmények (a valódi idő) egy másodpercen belül lennének, ami igencsak messze van az általad említett 10%-tól.

ps2: DOS alatt biztosan nem. Gyatra az IO-teljesítménye és úgyis csak egy processzort tudnál vele használni, hogy mást ne említsek.

( Zahy v | 2006. 09. 18., h – 23:08 )

Esetleg javasolnám a legközelebbi hasonló időtöltésnél:
FreeBSD-n is ext2 -t használni, esetleg Linux-on is UFS -t ;-) Egyébként lássuk be, megint csúsztattál (no jó, részrehajlóan választottad meg a tesztkörnyezetet), hisz a vacak, elavult ext2-t használtad, a helyett, hogy a sokkal gyorsabb, stabilabb, már mindenhol bizonyított reiserfs-t izé Reiser4-t mitakarokmondani ext3-t illetve dehogyis, hisz JFS-t, no szóval XFS-t választottad volna. Ráadásul, hogy "korrekt" legyen, természetesen a (Veritas eXtended FS-ben "datainlog"-nak nevezett mountolási opcióval) kellett volna. (Ajánlott olvasmány: http://hup.hu/node/17324 bizonyos "magasröptű" válaszai, ahol biz látszik, hogy a válaszadónak halvány dunsztja nincs a kérdés - meg a válasz - mibenlétéről.)

Nem igazán hiszem, hogy érdemi különbségek lettek volna. Azért lett async a Linuxon, mert sokáig ez volt a default mount opció, FreeBSD-n pedig a softupdates az (najó, ha sysinstallt használsz), illetve nincs igazán közös metszete a kettőnek.

Használhattam volna mindkét helyen asyncet, de FreeBSD nincs olyan hülye, aki ilyet használna (hacsak nem szükségből, vagy jól meggondolt okból), journaling FS-t pedig még igazságtalanabb lett volna használni, mert ott a metaadat kétszer került volna kiírásra, magyarul hátrányban lett volna a Linux.

( turul16 v | 2006. 09. 19., k – 17:51 )

make -j 9 -et hiányolom. Mag_szam+1 a javasolt érték.

"FreeBSD annak ellenére volt képes bizonyos (nem is kevés) esetben gyorsabban futtatni a Linux kódot" ez hol van, én vak vagyok vagy mi.

"allyesconfig" az nem sokat mond, arrol, hogy vegülis milyen kernelröl van szó.

Egy ilyen syscall-fordítás jellemzően néhány órajel / asm utasitás, ha jol tudom. Elenyésző.

Ugyan olyan FS használat szerintem jó lett volna, vagy valmi olyat forgatni ami, belefér a memóriába, cache-t megetetni aztán go modszerrel...

Nem szeretem a páratlan számokat. :)

Bolddal van szedve.

Az allyesconfiggal mire célzol? Meg van adva az architektúra, meg a kernel verziószáma. Ennél hogy lehetek konkrétabb?

Szerintem ez ennél egy hangyafaszányival több, de bevallom férfiasan, nem olvastam még el a FreeBSD idevonatkozó részét. Mindenesetre ha így van, nem igazán értem, hogy miért nincs Solaris, Tru64, OpenVMS, meg Windows ABI támogatás, hiszen úgyis csak pár asm utasítás. :)

Trey kernelt fordított, ez a szutyok meg nem fér bele a memóriába (kb. 4 GB kell a Linux lefordításához).

Nem microbenchmark érdekelt, hanem az, hogy egy adott feladatot melyik old meg hamarabb, mennyivel járok rosszabbul, ha ugyanaz a linuxos alkalmazást használom FreeBSD-n, Linux emulációval.

Ebbe pedig beletartozik a fájlrendszer és az is, hogy a ciss driver mennyire képes jól kezelni a diszkeket. Ezek egyébként bárkit megkérdezel, jobbak a Linuxban, mint a FreeBSD-ben (ide értendő a ciss driver FreeBSD-s fejlesztőjét is), úgyhogy értetlenül állok a dolog előtt. :)

Preemption Model, Timer frequency, Function reordering, IO Schedulers ... stb ilyesmire gondoltam. Meg minden olyan cuccra ami befojásolhatja sebességet. Jó lenne egy tesztet csinálni ezekröl, hogy mikor-melyiket érdemesebb használni, és hogy menyit nyom a latba, ha nem a megfelőt választjuk.

"Mindenesetre ha így van, nem igazán értem, hogy miért nincs Solaris, Tru64, OpenVMS, meg Windows ABI támogatás, hiszen úgyis csak pár asm utasítás. :)"
Minden syscall-nál. Csak arra céloztom, hogy nem várnék jelntős teljesítmény veszteséget miatta.
Azért ne keverjük a dolgokat, BSD-LINUX között nincs nagy külömbség ilyen téren szvsz. .