Az egész cikk úgy kezdődött, hogy meg sem fordult a fejemben ilyet írni. :) Mindössze annyi történt, hogy a lacyc3eu és „kellékeit” futtató szerver eddigi backup megoldását egyszerűen obselete (szép magyar szó!) jelzővel láttam el, mert az új igényekhez már nem tudott igazodni. A megváltozott igények megnövekedett adatmennyiséget is takarnak, számszerűen jelenleg a napi mentés (tömörítetlenül azért) „mindössze” 2,4 GB-ot tesz ki. Ezt pedig tömöríteni kellene. A szerveren erre még este sincs kapacitás. Itt kezdődtek a bajok.

Öröm az ürömben, hogy jól tömöríthető adatokról van szó. Hogy mennyire, azt jól mutatja, hogy alapértelmezett „ultra” beállításokkal a 7z 160 MB körülire tömöríti az anyagot, ami azért nem rossz. Ehhez viszont nagyobb mennyiségű memóriára és processzorteljesítményre van szükség, így adja magát, hogy jó lenne valami használható teljesítményű gépen megütni a dolgot.

Még mielőtt jobban belemennénk, tisztázzunk pár technikai részletet: a 7z alapértelmezett verziója 9.20, a használt GCC pedig 4.9.1.

Cikkem főszereplői Ingvildr (12 GB RAM, i7-3930K) és Sigfried (4 GB RAM, Xeon X3430), akiken természetesen Gentoo van. Mellékszereplők pedig Selina (8 GB RAM, i7-2630QM), Hailey v2 (16 GB RAM, i7-4790) és A* (4 GB RAM, i3-3220), akiken Xubuntu és Ubuntu (és Gentoo) van. Az egész cikk onnan indult, hogy az lzma tömörítő szótárméretének a módosításával próbálkoztam maximalizálni a tömörítés hatékonyságát (hogy több férjen a felhőbe). A tesztelés elsősorban Sigfrieden futott, azonban meglepően sokáig dolgozott vele, így gyanút fogtam. Első körben a „párjával” (Ingvildr) hasonlítottam össze. Ahol az eredmények elég mellbevágóan különböztek. De ne szaladjunk ennyire előre, lássuk a 7z 9.20 eredményeket.

Elsősorban az érdekelt, hogy az ajánlott maximum beállításokon kívül mennyit lehet még kihozni belőle és milyen áron, így a javasolt maximum 32 MB méretű szótár mellett kipróbáltam 64-es és 128-as értékkel is. Természetesen time paranccsal mértem is a tömörítéshez szükséges időt.

Az eredményekből látszik, hogy nem meglepő módon a tömörítés költsége nagyban függ az eszköz teljesítményétől.

Hailey v2 eredményeiből látszik, hogy plusz fél perc ráfordítással sikerült 9 MB-ot lefaragni az alapértelmezett beállításokkal készült archívum méretből, illetve további 5 másodperc árán egy további MB-ot nyertünk. Fontos azonban tudni, hogy 128 MB-nyi szótármérettel már igen nagy, gigabyte feletti a 7z memóriaigénye tömörítés közben. Ezt sem szabad elfelejteni.

Normál esetben, itt állt volna meg a cikk. De egyre jobban zavartak Sigfried egész elkeserítő eredményei, így elkezdtem más gépeket is tesztelni. Első körben, Charmedet kértem meg, hogy mérjen egyet Selijén, majd én is megtettem Hailey v2 + Gentoo pároson, illetve A*-on (a-csillag). Más, jóval gyengébb gépekkel összevetve is lassú volt. Olyan szinten, hogy ezt már nem lehet a memória sávszélességre fogni.

Optimalizáljunk!

Mivel Ingvildr is és Sigfried is Gentoo-t futtat, ezért igen egyszerűen lehet rendszerszinten is komolyabb változásokat eszközölni. Ezt kihasználva a hardver rejtett tartalékait is a szolgálatunkba állíthatjuk.

Ez dupla teszt: részben szeretném kideríteni, hogy mennyit ér egy program optimalizálása akkor, ha a teljes rendszerrel nem tettük meg ugyanezt (Sigfried), illetve fordítva: mennyit ér egy teljes rendszerhez képest optimalizálatlan program (Ingvildr).

A kiinduló állapot Sigfried esetén a 3.18.9-es, hardened (biztonságilag megerősített) Gentoo kernel, míg Ingvildr 4.0.0-pf2-es, semmilyen biztonsági kiegészítéssel nem rendelkező rendszermag.

Sigfrid „alatt” szintén megerősített programok vannak és az összes program, lib és egyebek -mtune=generic -O2 -pipe -fomit-frame-pointer opciókkal lettek fordítva.

Ingvildr, mint említettem, teljesen hardverre optimalizált programokat futtat, ami -arch=native -O2 -pipe -fomit-frame-pointer gcc opciókat jelent. Az eredmények két táblázattal fentebb vannak.

Mennyit számít az, ha a gcc-t általános architektúráról specifikusabb optimalizálásra állítom: -march=corei7 -O2 -pipe -fomit-frame-pointer?

Sigfried esetén igazán látványos a javulás, ez a majd 20 másodperc komoly előrelépés. Bár nem akkora, mint amekkorára számítottam, de ne legyünk telhetetlenek, nemde? :) Ingvildr esetén, 32 MB-os szótárméretnél szinte mérési hibahatáron belül vagyunk, de nagyobb értékeknél szépen látszik a javulás.

A következő lépés az, hogy közvetlenül az adott processzorra optimalizáltam a 7z kódját, így: -arch=native -O2 -pipe -fomit-frame-pointer Itt már nem olyan látványos a javulás, mint eddig (sőt, többszöri mérés után is az -md128 mindkét esetben rosszabb lett, ahogy látható), mégis észrevehető.

Végül, ezt a teszt szekciót verzióváltással fejezem be. Mindkét gépen frissítettem a 7z-t 9.20-ról 9.38.1-re, minden más maradt, azaz -arch=native -O2 -pipe -fomit-frame-pointer gcc opciókkal fordult.

Ubuntu vs Gentoo

Ha már ilyen jól belejöttem a méricskélésbe, kíváncsi voltam, hogy az Ubuntu 15.04 és az össze-vissza optimalizált, túrt, „cutting-edge” Gentoo teljesítménye között mekkora különbség van és kinek a javára.

Mint az jól látszik, szótármérettől függően 6-10s a Gentoo előnye. Persze, nem feltétlen fair az összehasonlítás, hiszen a Gentoo más ligában játszik, ugyanakkor jól látszik, hogy érdemes belefogni az optimalizálásba. Persze, ha számít neked az a 6-10 másodperc.

Kernelek egymás közt

Mivel a cikk lassacskán íródott, így akarva-akaratlan lehetőségem nyílt a kernel verziók és alverziók tesztelésére. Különösen Charmed segített ebben sokat, hiszen szépen körbejárta a Xubuntu 14.10 → 15.04 → Xubuntu Core útvonalat, így volt lehetősége futtatni a scriptemet. :)

Gentoo – Megéri?

Végül, de nem utolsósorban, kanyarodjunk vissza egy kicsit Ingvildr és Sigfried esetéhez. Volt egy olyan érzésem, hogy abban a majdnem 7 perces tömörítési idő mögött nem csak az áll, hogy Sigfried korosodik, hanem a hardened rendszer miatt feláldoztunk „némi” teljesítményt. Így egy új, 4.0.0-pf2-es kernelt fordítva és a meglévő eszközöket felhasználva újramértem. Az eredmény többszöri mérés után is ugyanez maradt, azaz sikerült az eredeti kernelnél lassabban végezni a feladattal. Más szóval érdekes, hogy nem vesz el érdemben teljesítményt egy biztonságosabb kernel. Természetesen nem elégedtem meg ezzel és kifejezetten kíváncsi lettem, hogy a rendszer teljes, hardened profil nélküli újrafordításával mekkora különbségre teszünk szert. Hogy minden „klappoljon”, egyúttal támogatott, Gentoo kernel forrásra is váltottam. Az eredmény tisztán látszik: 31 másodperccel hamarabb végzett a szóló rendszer, mint a megerősített. Persze mondhatnánk, hogy többi is veszett Mohácsnál és ennyit kibírunk a biztonság árán, amit nem is vitatok. De érdemes belegondolni, hogy szükség van-e erre. A helyzet tovább rontja, hogy az eredeti felállás sem tartalmazott minden lehetséges felállást, többek között nem használtam a gcc stack protectorát a kernelben, ami további másodperceket adhatott volna hozzá.

Kicsit kapkodós? Mondhatni. Megmondom őszintén, elég vadul próbáltam megtalálni az okot, amiért Sigfried ilyen kritikán alul teljesített. Sokkal többet vártam tőle. Nem csak azért, mert négy Nehalem magot tartalmazó Xeonról van szó, hanem mert – ahogy az fentebb is látható – az alsó-közép kategóriába tartozó A* is megveri, nem is kicsit.

Szóval, megéri? Talán. Érdemes a táblázatokat nézegetni. Sigfried esetén a teljesen optimalizálatlan és optimalizált állapot között közel 50 másodperc van. Ha azt nézzük, akkor ez az 50 másodperc ingyen van és ott lakik a hardverben, csak elő kell csalogatni. Másrészről rengeteg emberi idő megy el vele. Így jól meg kell gondolni, hogy hol játszik vele az ember. Amit még érdemes még nézegetni, az Selina és Hailey v2 (igen, kell neki egy rendes név). Mindkét hölgynél jól látható, hogy mennyi különbség van a kernelek között.

Mivel kifutottam a hétfőből és hirtelen kedd lett, ezért a cikk itt ér véget, azonban továbbra is keresem Sigfried gondját. Továbbá terveim közt szerepel eme teszteket kiterjeszteni, aka. ha már pingvin, legyen szamár (gentoo): az eredményeket tartalmazó táblázatból egy „megtisztított” változatot fel szeretnék rakni Gdrive-ra, amit majd ahogy időm engedi, folyamatosan frissítenék: lehetne látni a kernelek „fejlődési” görbéjét.