Tömörítő teszt (gzip, zopfli, bzip2, lzma, lz4, zpaq)

Címkék

A múltkori Zopfli-bejelentés után fellángolt bennem a vágy, hogy újra betömörítsem az egyik mail folderemet (mbox formában lementve), és megnézzem, hogy melyik tömörítő hogy szerepel.
Sajnos csak odáig jutottam, hogy megírtam, majd elindítottam a scriptet, aztán el is felejtettem az egészet. De ma egy blogbejegyzés kapcsán eszembe jutott a dolog, így legeneráltam a képeket, és megírom a cikket, hátha valamire jó lesz. :)

Az "áldozat" a fent említett mbox formátumú fájl, kereken 100 megás. Van benne szöveg, kép, doc és egyéb csatolmányok (és pár spam is, bár ez ebből a szempontból irreleváns).
A gép, amelyen a teszteket futtattam két darab Intel Xeon E5-2680 (2,7 GHz, 8 mag, HT, így összesen 32 CPU látszik az OS-nek) CPU-t és 32 GB memóriát tartalmazott. A tesztek minden IO-ja ramdisken (tmpfs) történt, a használt OS FreeBSD 9 64 biten.

A tesztelt tömörítők: gzip, bzip2, lzma (az OS-ben lévő verziók), zopfli (git: acc035299f8dfe1ddcbc93c99f8600269790f88c), lz4 (svn r90) és a zpaq (6.22).

Magyarázat a grafikonokhoz:
Az x skálán minden képen 10 érték szerepel, ebből a legelső a nullás, amely némely tömörítőnél nem értelmezett (pld. gzip, bzip2). Az lz4-nek két tömörítési állapota van (fast és high), ezek a grafikonok 0-ás és 1-es részén szerepelnek.
A zopfli esetében iterációkat lehet megadni 5-től 1000-ig (kilenc lépcső), így annak értékei illeszkednek a gzip-bzip2 1-9-ig terjedő beállításaihoz. A zopflival gzip formátumba tömörítettem.
A sorból némileg kilóg a zpaq, hiszen az csak metaadatokkal (fájlok) ellátott archívot tud készíteni, így kicsit alma-körte jellegű a direkt gzip vs zpaq összehasonlítás a tar.gz vs zpaq helyett, de azt gondolom még így is érdekes lehet.
A zpaq csomagban elérhető zpipe-ot (amely képes streamet tömöríteni) nem vettem be a tesztbe.
A szálak számát ott ahol lehetett egyre vettem, hogy ne kerüljenek előnybe azok a tömörítők, amelyek több szálon is képesek működni.

Mivel is lehetne kezdeni, mint a tömörítési arányokkal?

Mivel első körben a zopfli kapcsán készült a teszt, leginkább azt néztem. Rögtön szemet szúr, hogy az iterációk száma gyakorlatilag semmivel sem növelte a tömörítési hatékonyságot (a grafikonról egyáltalán nem látszik a különbség, számokban kifejezve is elenyésző: 0,11%. a skála két vége között). Lehet, hogy más típusú adaton jobban tud érvényesülni...
Dícséretes viszont, hogy az ígérethez híven végig verte a gzipet, a legnagyobb különbség 2,72%., a legkisebb 0,36 százalékpont.
Az árát majd később látjuk...

Az lz4 is hozza az ígértet, kevésbé tömörít, de gyorsan (ez is később). A bzip2 a szokásos köröket veri a gzipre, amit az lzma magasabb tömörítési fokozatokon (illetve az "extrém" kapcsolójával végig) tud csak überelni.
A saját kedvenc zpaq a 3-4-es fokozatnál kezd igazán aktív lenni, 9-esen pedig még mindig 2,9%.-ot ver az extrém tömörítős lzma-ra.

Node lássuk mennyi időt is kell várni a tömörítésre:

A grafikonon lényegében csak egy versenyző látszik, a google új adatközpont-gyilkosa a zopfli. Magasabb iterációknál egyértelműen viszi a pálmát lassúságban, de az előző grafikonnal összevetve megnyugodhatunk: úgyis feleslegesen pörög, 0,36%.-ért egyszerűen nem éri meg több, mint három órát (!) várni (YMMV utoljára: erre az adatra legalábbis).

Hogy látsszanak a többiek is, ugyanez zopfli nélkül:

és az lz4 kedvéért zpaq nélkül:

Az lz4 abszolút bajnok a tömörítési időben, a gyors opciójánál először azt hittem, hogy nem is tömörít, pedig de, sőt, ahhoz képest, hogy kb. annyi idő alatt lefut, mint a "cp src dst", nem is rosszul. Talán nem véletlen, hogy a ZFS-ben is ez lett az első nem Oracle tömörítő-kiegészítés.
A zpaq megkéri az árát a legjobb tömörítésnek, a leglassabb-dobogó harmadik helyére pedig -nem éppen váratlanul- az lzma(-e) állhat.

A CPU idő mellett már csak a memória szabhat gátat a tömörítési elképzeléseinknek, de hogy mennyire, az itt látható:

A zpaq sokat gondolkozik, cserébe jó nagy agy is kell neki. Hogy mekkora? Majdnem 5 GB...
Mint látható, kisebb fokozaton "jóval" kevesebbel is beéri. :)

zpaq nélkül a mezőny RSS foglalása:

Mint látható, a zopfli cserébe azért, hogy alig tömörít jobban, nem is kér többet memóriából, ellenben az lzma-val, amely memóriahasználata szépen "skálázódik" a tömörítési fokkal.
Pozitív viszont, hogy az extrém tömörítés nem kerül extrém sok memóriába, a legalacsonyabb fokoktól eltekintve gyakorlatilag semennyivel sem többe.
Érdekes lehet még az lz4 viszonylag magas memóriaigénye, de szerencsére még koránt sem a kiugró érték (illetve lehet, hogy optimalizálható még), és sebességben bőven visszaadja.
A gzip és a bzip2 említést sem érdemel, gyakorlatilag beleolvad az x skálába.

CPU idők system és user különösebb kommentár nélkül:



Majd a folyamat visszafelé: kitömörítés.

Látható, hogy a többiekkel ellentétben a zpaq meglehetősen szimmetrikus tömörítő, amit sokáig csomagol befelé, azzal bizony elszöszöl kifelé is.

Megtisztítva tőle a grafikont ezt kapjuk:

Sebességben továbbra is az lz4 a verhetetlen, az lzma stabilan veri a bzip2-őt, és annak ellenére, hogy a zopfli esetében a kitömörítés is gzippel történik, a jobban tömörített adat miatt szinte minden alkalommal rövidebb ideig tartott, mint az eredeti programmal.

A kitömörítéshez használt memória:

A zpaq a szimmetrikussága miatt itt is kikényszeríti, hogy nélküle is készüljön grafikon:

amelynél az elvárásoknak megfelelően a gzip-zopfli már tökéletesen együtt jár.

Végezetül álljanak itt a user-sys grafikonok:



és a végkövetkeztetés:
A zopfli ezen az adaton nem vizsgázott olyan jól a gzippel szemben, viszont stabilan hozta a nyereséget, amely a magasabb fokozatokra gyakorlatilag teljesen elolvadt, az ehhez szükséges tömörítési idő viszont már a zpaq idegtépő lassúságát is megszépíti, így gyakorlati alkalmazhatósága kérdéses a gzip -9-cel szemben.
A zpaq továbbra is favorit, bár így 2013 környékén a TB-ok már teljesen természetesek, a THz-ek viszont még nem, így legfeljebb azoknak ajánlható jó szívvel, akik még mindig 8 collos floppykra mentik az adataikat a 32 magos, 3 GHz-es gépeikről.

További jó tömörítést mindenkinek!

Hozzászólások

Köszönjük a tesztbe fektetett időt és energiát!

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

szerintem ennek a kiflinek a legfontosabb felhasznalasa a PNG-k jobb tomoritese lehet. neha nezek weboldal statokat, es az adatforgalom jelentos reszet a pici kepek teszik ki, amikbol a "design" keszult.

A'rpi

Azon gondolkodom, hogy ha ennyire vadul ingadoznak a mért értékek, nem lenne-e szerencsésebb a logaritmikus y-tengely?
--
Fight / For The Freedom / Fighting With Steel

pont emiatt kellett volna a legelso abrat 0-100 skalara rakni, mert igy pont az aranyok nem latszanak. eloszor en is neztem hogy a zpaq hogy a f@szba tudja felere tomoriteni a tobbihez kepest :) aztan rajottem hogy nem 0-rol indul. itt pont jobb lett volna ha az aranyok latszanak, eleg nagyon a kulonbsegek ugyis.

A'rpi

Köszi az alapos tesztet.

xz -t próbáltad? Ez az lzma2 lenne. Érdekességét az adja, hogy a Linux kernelforrás és több Linux diszribúció installja xz-re áll át.

http://www.kernel.org/pub/linux/kernel/v3.x/

linux-3.8.3.tar.gz 14-Mar-2013 18:43 102M
linux-3.8.3.tar.bz2 14-Mar-2013 18:43 81M
linux-3.8.3.tar.xz 14-Mar-2013 18:43 68M

Tapasztalataim szerint az xz (=lzma2) lzma körül mozog, általában jobb, bizonyos esetekben picivel rosszabb.

Köszi, ezzel is tanultam.
Cserébe a fenti kernel sorhoz a zpaq-t is összeraktam (zp parancs, ubuntu 13.04 beta) i5 laptop procin.

linux-3.8.3.tar.zpaq 75 MB (216 másodperc, 1-as gyenge tömörítéssel, kicsomagolás 225 másodperc)
linux-3.8.3.tar.zpaq 55 MB (1236 másodperc, 2-es default tömörítéssel. A kicsomagolás 710 másodperc)
linux-3.8.3.tar.zpaq 50 MB (3533 másodperc, 3-as erős tömörítéssel, a kicsomagolás 1900 másodperc)

A zp-nél figyelemreméltó a brutális tömörítés. Praktikusságát tekintve azonban az xz nyert, ahol a tömörítés ugyan hosszú (320 másodperc körül), azonban például ha installcsomag céljára használjuk, a 7,8 másodperces nagyon gyors kibontási idő igen kellemes. Ellenben az xz 68 MB-ra tudta tömöríteni.

Úgy nézem, a gzip -9 még mindig egy jó kompromisszum, esetleg bzip :)

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)

"így kicsit alma-körte jellegű a direkt gzip vs zpaq összehasonlítás" - kivéve, ha az alma és a körte egy Abel-csoportot alkotnak. :D

köszi a beletett munkát, ez egy jó referenciapost lesz, ha a későbbiekben tömörítős gondom akad.

Köszi a cikket, érdekes.

"Belépés díjtalan, kilépés bizonytalan."

Az utolsó mondat szivet melengető volt.

Te, Bra! Kihagytad a compress-t! :-D

Hér ha már, akkor a pack/unpack/pcat triót is, de még lehetne pár olyat hozni, ami szinte elenyészett. Mondjuk engem az érdekelne, hogy azért a még mindig eléggé elterjed 7z de főleg a RAR (esetleg az ARJ) hogy teljesítene ehhez a készlethez képest - szerintem azért azok jóval elterjedtebbek, mint a fent emlegetettek jó része.

Köszönöm a cikket, végre szakmai tartalom a HUP-on! :)

Nahh, ez egy hiánypótló cikk, megérte belefektetni a munkát :)
Mondjuk, érdekes lett volna még akár néhány különféle fájltipuson is megcsinálni azeket a teszteket, hogy melyik tömörítőt mire jobb használni.
Futási idő: itt meg az is számít, hogy milyen optimizációval lett lefordítva maga a tömörítő. Amikor az optimizációkat próbálgattam, pont a bzip2 volt a kísérleti nyulam, egy 20MByte-os fájllal. Olyan 5% körüli volt a szórás. Még a -ffast-math -ot is rápróbáltam :D ezzel lett a leggyorsabb, de CRC hibás tömörítvényeket produkált XD

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

Nice one!

RAR-t én is hiányoltam,
de főleg a multithreados teszteket...

Az MT-teszttel vannak azért problémák. Kezdve azzal, hogy mit teszteljünk? Azaz a gzip-et (ami ha jól tudom még mindig egyszálú), vagy a pigz-et (ami pont a többszálúsított gzip akarna lenni) tegyük bele? Nyilván ha egy szoftvert eleve úgy írtk meg, hogy tud többszáló lenni, az nagyon jó, de aiket nem, ott mit csinálsz?

Fogalmam sincs. :)
Viszont ma kellett tömörítenem egy 12 gigás loggyűjteményt (text).
rar max tömörítés:
663648844 bájt
zpaq max tömörítés:
310479487

Durván rávert. Két óra alatt nyomta össze, közben 22 giga ramot evett (6 szálon tömörítettem, minden szálon eszik sokat)

DB Dumpot általában nem nagy munka tömöríteni, lévén, hogy az ócskább SQL szerverek jellemzően csak plain textet képesek produkálni. (Még ócskábbak mindezt úgy, hogy addig beáll az egész szerver...) PostgreSQL-nél pl. ott a "custom" nevű bináris formátum, amely alapból tömörít. Az egy 30G-s DB-ből nekünk 1,6G körüli backupot csinál.

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