Nejlepší nastavení komprese v 7zip

[Honza1]

Maly test 7z a paq8px. Jednalo se o skriptypro bash, gnuplot, tedy textove soubory, ve kterych je hodne podobnosti (fraze, cykly), i jednotlive soubory maji mezi sebou docela dost podobnosti. Zkouska jak komprimace slozky, tak TAR archivu. 7z i paq8px umi najit podobnosti mezi soubory, takze TAR spis kompresi zhorsi, nez zlepsi. Navic neni mozne tak jednoduse rozbalit z archivu jen vybrane soubory-slozky v pripade TAR. Velikost slovniku staci vetsi, nez velikost slozky o neco, tedy 24 MB u 7z. U paq8px vybrana uroven 5 (vyzaduje okolo 233 MB RAM).

Zdrojova data:
Folders: 4
Files: 117
Size:       13515147

Velikost TAR souboru 13639680 B

7z komprese:
7z a -t7z -m0=lzma -mx=9 -mfb=273 -md=24m -ms=on
paq8px komprese -5

7z archiv zkoprimovana slozka se soubory: 574129 B
7z archiv zkomprimovany TAR: 569895 B
paq8px archiv zkomprimovana slozka se soubory: 315310 B
paq8px archiv zkomprimovany TAR: 316448 B

Doba v pripade 7z okolo 20-30 s, v pripade paq8px okolo 3-4 hod (procesor ATOM).

paq8px napsal dobu komprese necelych 1000 s, ale bylo to mnohem delsi (mozna pocita primo procesorovy cas komprese).

Nejak se mi tam pripletla nula, paq8px je cca 300-500 pomajejsi nez 7z, nikoliv 3000-5000 krat.

7z archiv jde snadno zkontrolovat (7z t Archiv.7z), u paq8px je spolehlivost otazkou.

Asi by docela byla sranda komprimovat dataset Openstreetmaps (cca 800 GB, s 1024 slovnikem na I7 CPU okolo 9 dni), nebo Anglickou Wikipedii (neco okolo 60-70 GB tusim, 2 dny komprese 7z). Dobu paq8px radsi nechci videt. Kdovi jestli paq8px umi i multithreating.

[Reklama]

[ByCzech]

7z i paq8px umi najit podobnosti mezi soubory, takze TAR spis kompresi zhorsi, nez zlepsi.

Zdroj? Já mám přesně opačné informace už roky a roky zpátky - od té doby, co existuje RAR a tzv. solid archive. K lepší kompresi si tím pomáhá nejen RAR, ale i 7zip. Je to stejný princip jako nejdříve sbalit do tarballu a pak komprimovat. Viz např. https://en.wikipedia.org/wiki/Solid_compression

[Boo]

Provedl sem pokus, komprese adresare je o 14% lepsi nez komprese taru.

Kód: [Vybrat]

3277744 dir.7z
3762806 tar.7z


[Trubicoid2]

Ten solid archive to je známý. Myslím rozdíl je v tom pořadí souborů v tar a v tom solid archive. Když budou u sebe podobné, bude výsledek menší. Rar to řadil podle koncovky myslím, tar snad podle inode, tedy spíš náhodně? Ale find sort tar není složité. Tady říkají, že to může být až o 20% výhodnější. https://nctritech.wordpress.com/2010/11/27/sort-compressed-tar-archives-to-make-them-smaller-20-percent-smaller/

Můžeš to zkusit se sortovaným tarem taky?

[Trubicoid2]

Jinak jak tam zmiňují xz, to by mělo být srovnatelné se 7zip. Nejlepší komprese

Kód: [Vybrat]

xz -9e souboř.tař

[Reklama]

[Boo]

Můžeš to zkusit se sortovaným tarem taky?

kousek lepsi

Kód: [Vybrat]

3277744 dir.7z
3408565 sorted-tar.7z
3762806 tar.7z


[Honza1]

7z i paq8px umi najit podobnosti mezi soubory, takze TAR spis kompresi zhorsi, nez zlepsi.

Zdroj? Já mám přesně opačné informace už roky a roky zpátky - od té doby, co existuje RAR a tzv. solid archive. K lepší kompresi si tím pomáhá nejen RAR, ale i 7zip. Je to stejný princip jako nejdříve sbalit do tarballu a pak komprimovat. Viz např. https://en.wikipedia.org/wiki/Solid_compression

Zdroj ? No zkusil jsem si to. V pripade 7z jiz nespocetnekrat.

7z jsem mnohokrat pouzil na mraky podobnych souboru a funguje to dobre. Ted i paq8px jsem zkusil. Ta podobnost mezi soubory je v tzv. Solid Archive, podobne jako TAR. Ale poradi souboru se lisi (7z radi podle koncovky, pak jmena, pak az umisteni ve slozce, a to je vyhodne dosti). Zkomprimovany TAR je mensi ? To se mi stavalo pri malem slovniku, pri velkem slovniku je to naopak (rozdil muze byt velky). RAR jsem pouzival pred 15-11 lety, naposled nekdy v roce 2007 a podobnosti mezi soubory podle vseho neumel (Test v roce 2007 - zdrojova data 8 GiB, RAR 900 MiB, 7z tusim 55 MiB, jednalo se o podobne html soubory. 7z to zvladnul za cca 6 hodin, RAR tusim pod hodinu - tenkrat jeste jednojadrovy Celeron).

RAR je komercni, proprietalni, a komprese neni tak dobra, ZIP je jeste slabsi. Ale zase jsou RAR, ZIP rychlejsi. XZ moc zkusenosti nemam, GZ je slapsi nez 7z o dost, BZ2 je srovnatelne se 7z, ale 7z je lepsi. paq8px je nejlepsi, ale vicemene se, vzhledem k procesorovemu casu, nevyplati.

[Honza1]

Jinak jak tam zmiňují xz, to by mělo být srovnatelné se 7zip. Nejlepší komprese

Kód: [Vybrat]

xz -9e souboř.tař

XZ je dobrej, ale musis to nejdriv TARovat. Napodobne BZ2.

[trubicoid2]

tak ten tař má taky výhody, každej ho umí, tar xvf se sám dovtípí jestli použít k rozbalení gzip, bzip2 nebo xz a tar taky ukládá správně unixový práva a vlastníky, což třeba ten 7z nevím

[Honza1]

Podle vseho dave na lepsim CPU paq8px okiolo 7 kB/s plus minus, dvojnasobek rychlosti prenosud dat dial-up. Na horsim CPU i pod 1 kB/s. Nejlepsi paq8px komprese, level -8 zabere 1633 MB RAM (a nejspis jeste navic filelist musi byt v RAM).

Vzhledem k potrebnemu procesorovemu casu by zabrala komprese OpenStreetMaps 4 roky a komprese Anglicke Wiki (Pages, Articles) okolo 5 mesicu. Verze uz za tu dobu bude uplne jina nova, navic za 4 roky se zmeni i vykon PC a asi neni jednoduche vyhnout se vypadku proudu.

paq8px deafultne v teto verz pouziva na raz jen jedno vlakno (jadro) (nektera jadra CPU se deli na 2 vlakna). Ale pokud je mozny multi-treating, je to jina. I la laptopu je k dispozici 8 vlaken a 16 GB RAM. Nejnovejsi Intel-AMD jsou 8-jadrove s 8/16 vlakny (a potreba je uz 32 GB RAM cca), Xeony jsou az 18-jadrove a 36-vlaknove (s tim potreba 64 GB RAM). Pri 2048 vlaknech-1024 jadrech a 4 TB RAM se i OSM dataset da s paq8px zvladnout pod 1 den a EN Wiki za 2-3 hod.

Pozadovany CPU cas (+ RAM a velmi rychly disk, SSD pri hodne vlaknech) bude neskutecne drazsi, nez usporene misto na disku (7z archiv je vetsinou max. 2x vetsi). Takze pro usporu mista na disku se to zcela nevyplati. Leda tak pro pocit nejlepsi komprese.

Vyplatit se to muze tam, kde si soubor stahne hodne uzivatelu (miliony) a nebo site nejsou tak propustne. Nebo prilohu v mailu je potreba odeslat hodne prijemcum. Nektere site a servery nemaji moc velkou kapacitu a sitovou propustnost napr. kvuli bezpecnosti.

Otazkou je, kolik procesoroveho casu a RAM je potreba na rozbaleni.

[Boo]

Otazkou je, kolik procesoroveho casu a RAM je potreba na rozbaleni.

Rozbaleni je vuci baleni trivialni zalezitost. Vezmi tenhle kousek a nakopiruj tady a tady. Pametovo to samozrejme neco zabere, protoze je lepsi soubor skladat v ram az pak ho zapsat.

Navic ten paq je ciste C++, na strankach projektu maji i assembler verzi, ktera by mohla byt o dost rychlejsi nez co vygeneruje C compiler. Akorat je to pak svazany s x86 architekturou.

[Honza1]

Otazkou je, kolik procesoroveho casu a RAM je potreba na rozbaleni.

Rozbaleni je vuci baleni trivialni zalezitost. Vezmi tenhle kousek a nakopiruj tady a tady. Pametovo to samozrejme neco zabere, protoze je lepsi soubor skladat v ram az pak ho zapsat.

Navic ten paq je ciste C++, na strankach projektu maji i assembler verzi, ktera by mohla byt o dost rychlejsi nez co vygeneruje C compiler. Akorat je to pak svazany s x86 architekturou.

Jake stranky projektu pouzivas ?

Muzu vyzkouset samozrejme. U 7z je spotreba RAM cca 10x nizssi i procesorovy cas pri rozbaleni je nizsi. Rozbalovani bezi vetsinou 10-20 MB/s ale to je rychlost zpracovavani archivu. Tedy napr. 10-20 GB velky archiv se rozbali za 1000 s, bez ohledu na to, zda obsahuje 20, 100, nebo 1000 GB dat (je to samozrejme limitovano rychlosti zapisu na disk, u SSD muze byt ale rychlost obrovska).

Je-li rychlost rozbalovani radove 10-100 krat vyssi (aplikovano na obem nekomprimovany dat) nez zabalovani (jako u vetsiny archivu). Tak bezny uzivatel s beznym PC si taky muze docela pockat u paq8px.

[Honza1]

Tak dekomprese je u paq8px jen rychlejsi cca 3-5x to vypada. Takze vyuziti jakozto zabaleni na vykonnem stroji a rozsirit archiv, at si to uzivatele rozbali, to je vhodne tak pro omezene prilohy do mailu, ne pro velke archivy.

[Boo]

Jake stranky projektu pouzivas ?

http://dhost.info/paq8/  je tam mnoho verzi, nektere zipy maji v sobe i asm zdrojaky

[Honza1]

Jake stranky projektu pouzivas ?

http://dhost.info/paq8/  je tam mnoho verzi, nektere zipy maji v sobe i asm zdrojaky

Diky
Jinak ja nasel tyto stranky (jeden web stary z r. 2009, druhy aktualni):

https://cs.fit.edu/~mmahoney/compression/
http://mattmahoney.net/dc/

Kompresoru tam maji mnoho, vc. PAQ, 7zip tam neni. Tabulky vysledku moc nechapu.

BTW: JAKE JE VLASTNE RESENI ZADANI, TEDY NEJLEPSI NASTAVENI KOPRESE V 7z (radeji bez multithreating, RAM je pomerne omezena vzdy, slovnik 1024M je ok)