Fórum Root.cz

Hlavní témata => Software => Téma založeno: Martin.V 23. 03. 2017, 22:17:22

Název: Nejlepší nastavení komprese v 7zip
Přispěvatel: Martin.V 23. 03. 2017, 22:17:22
Dobry vecer,

Uz se s tim peru nekolik hodin snazim se najit a pochopit prikaz pro nejlepsi kompresi pomoci LZMA2 v programu 7zip.

Kód: [Vybrat]
7z a -t7z Files.7z -m0=BCJ2 -m1=LZMA2:d=1024m -aoa
Jestli to chapu dobre tak rozdil v "-m0" a "-m1" je ten ze 0 ma prednostni kompresi jak 1 a a BCJ2 se pouziva pro exe soubory protoze ma lepsi kompresi jak LZMA2 jenv pripade asi exe souboru... to -aoa nevim co je :-D

Budu zalohovat kazdych 5min slozky ktere maji asi 5-150mb
a potrebuji nejlepsi kompresi (cpu a ramky me nezajimaji)

Prosim pomocte
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: Jirsákova tchýně 24. 03. 2017, 01:28:37
Budu zalohovat kazdych 5min slozky ktere maji asi 5-150mb
a potrebuji nejlepsi kompresi (cpu a ramky me nezajimaji)

Ne, potřebuješ zálohování, co není úplně dementní.
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: robotron 24. 03. 2017, 01:46:01
potrebuji nejlepsi kompresi (cpu a ramky me nezajimaji)

Vynikajici zadani! V tom pripade kasli na naky trapny LZMA2 a rovnou udelej optimalni kompresi odpovidajici cca Kolmogorovove-Chaitinove slozitosti. Vyber si bajtkod nebo rovnou asm a staci vyzkouset vsechny programy o delce mensi, nez je komprimovanej soubor, od nejkratsiho. Kterej z nich vypise na stdout komprimovanej soubor jako prvni, stava se vitezem a bude tvorit vyslednej archiv. A navic je to automaticky samorozbalovaci!

Skoda, ze vetsina z nas si tolik CPU vykonu dovolit nemuze, uz jen kvuli delce zivota. (Na RAM to naopak zas tak moc narocny neni.)
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: nobody(ten pravej) 24. 03. 2017, 02:01:18
-aoa je volba pouzivana pro ROZBALOVANI a znamena "prepisuj vsechny existujici soubory bez dotazovani" ;)

https://sevenzip.osdn.jp/chm/cmdline/switches/overwrite.htm
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: Honza1 24. 03. 2017, 09:17:49
7z a -t7z -m0=lzma -mx=9 -mfb=273 -md=1024m -ms=on JmenoArchiovu.7z

7z na zacatku plati pro p7zip-full, pro neplnohodnotny 7z mala zmena pocatecniho prikazu na 7za, tedy:

7za a -t7z -m0=lzma -mx=9 -mfb=273 -md=1024m -ms=on JmenoArchiovu.7z

Jmeno archivu muzes zadat jako promennou v bashi
lzma je dobra volba (o malicko lepsi mozna lzma2, nevim, jestli je podporovana)
9 je maximalni mira komrese, tedy ultra
273 je delka slova (cim vic tim lip, komrese trva dyl, 273 je maximum)
1024m je velikost slovniku 1024MB. To je maximalni moznost, i kdyz ted uz jde MOZNA zadat vic.
Jenze velikost slovniku zabere v RAM cca 11ti nasobek (tedy pro 1024 MB 10,7 GB), ale pokud ma slozka 150 MB, bude ta velikost slovniku jen 192 MB, vic nebude bez ohledu na nastaveni.
Pak se jeste do RAM krome slovniku musi nacpat souborovy seznam, to je cca 1-1,5 GB na milion souboru v zavislosti na delce nazvu souboru vc. cely cest.
Ruchlost komprese je pri danem nastaveni 1000-3000 kB/s (text pomaleji, obrazky ryuchleji).

Ve vyslednem archivu je i filelist i adresarova struktura komprimovana.

POKUD NEBUDE RAM STACIT (SLOVNIK a FILELIST), ZKONCI TO CHYBOU CANT ALLOCATE REQUIRED MEMORY.

7zip (v Linuxu p7zip-full) umi dobre hledat a komprimovat podobnosti i mezi ruznymi soubory (hodi se u podobnych html souboru ci obrazku), ne jen v jednom souboru, velmi dobre se komprimuji duplicitni soubory. Ze 100 GB html textu lze udelat i 1 GB, nekdy i min.
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: ByCzech 24. 03. 2017, 09:43:59
Ještě se to liší podle parametry -mmt=[on|off|N] kde N je počet vláken (tuším jen pro LZMA2) - výrazně zrychluje kompresi. U 1024M slovníku je potřeba např. u 8 vláken cca 50GB RAM, u 4 vláken 25 GB RAM...
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: trubicoid2 24. 03. 2017, 10:40:21
jestli je rychlost jedno, tak bych zkusil jeste lrzip, ten umi taky lzma, ale i lepsi a pomalejsi zpaq

lrzip -Uzp 1 -L 9

(i kdyz asi -L 9 pro zpaq neplati)

https://github.com/ckolivas/lrzip
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: davkol 24. 03. 2017, 13:06:35
Asi tak. Proč se snažit nahodit parametry typu velikost okna, když jde použít lepší algoritmus (jako PAQ)?
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: Honza1 24. 03. 2017, 22:08:10
Ještě se to liší podle parametry -mmt=[on|off|N] kde N je počet vláken (tuším jen pro LZMA2) - výrazně zrychluje kompresi. U 1024M slovníku je potřeba např. u 8 vláken cca 50GB RAM, u 4 vláken 25 GB RAM...

U LZMA1 zabere 1024m 10,7 GB, vlakna dokaze vyuzit max. 2. U LZMA2 evidentne zvada vice. Zatimco u LZMA1 stale jeden slovnik bezi pod 1-2 vlakny (blok dat 1024 MB), u LZMA2 to vypada, ze bezi vice bloku-slovniku najednou (kazdy blok 1024m zabere urcitou cast pameti a pokud paralelne bezi vic bloku, nascita se to, dejme tomu, ze pro kazdy blok-slovnik vyuzije 2 vlakna a 12 GB pameti, pak je to okolo 50 GB RAM pri 4 blocich dat-slovnicich po 1024 MB).
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: Honza1 24. 03. 2017, 22:11:56
Ale pokud jsou data velka do 150 MB na jeden zatah, nema smysl poustet vice vlaken a ani s RAM to nebude tak horke. Pak jeste je do naroku na RAM krome slovniku treba pripocist seznam souboru s kompletnimi cestami da cca 0.5-3 MB na tisic souboru (a nejvic pameti to sezere nakonci vytvareni archivu, kdyz se komprimuje filelist).
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: ByCzech 25. 03. 2017, 09:36:41
Ale pokud jsou data velka do 150 MB na jeden zatah, nema smysl poustet vice vlaken a ani s RAM to nebude tak horke. Pak jeste je do naroku na RAM krome slovniku treba pripocist seznam souboru s kompletnimi cestami da cca 0.5-3 MB na tisic souboru (a nejvic pameti to sezere nakonci vytvareni archivu, kdyz se komprimuje filelist).

To je otázka, jestli pak není komprese s menším slovníkem u takových dat na 4 jádrovém či 8 jádrovém CPU výrazně rychlejší než to hrnout přes jedno jádro.
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: Stanislav Petr 25. 03. 2017, 09:41:08
No jestli ti jde o co nejlepsi kompresi a opravdu te nezajima narocnost na procesor tak misto hrani s parametramam LZMA pouzij uplne jinej algoritmus (neco z rodiny PAQ - koukni napr. na PAQ8PX nebo PAQ8HP12). Ale pocitej s tim ze tech 150MB muzes i na dost silnym CPU komprimovat treba i nekolik dni... Nicmene vysledek bude prakticky minimalni mnozstvi dat.
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: ByCzech 25. 03. 2017, 09:43:12
No jestli ti jde o co nejlepsi kompresi a opravdu te nezajima narocnost na procesor tak misto hrani s parametramam LZMA pouzij uplne jinej algoritmus (neco z rodiny PAQ - koukni napr. na PAQ8PX nebo PAQ8HP12). Ale pocitej s tim ze tech 150MB muzes i na dost silnym CPU komprimovat treba i nekolik dni... Nicmene vysledek bude prakticky minimalni mnozstvi dat.

To se tazateli vyloženě hodí, když to chce zálohovat co 5 min :-D
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: JardaP . 25. 03. 2017, 10:20:14
To se tazateli vyloženě hodí, když to chce zálohovat co 5 min :-D

To neni problem. Staci mit dostatecny pocet stroju, z nichz kazdy bude resit jednu zalohu. Staci otestovat, jak dlouho se dela jedna zaloha a pak vim, ze jede 12 zaloh za hodinu, hodin je ve dni 24 a pak uz to jen vynasobis a navrsis o rezervu, kdyby se zalohy zpomalily vlivem komplikovanejsich dat.
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: ByCzech 25. 03. 2017, 11:25:56
To se tazateli vyloženě hodí, když to chce zálohovat co 5 min :-D

To neni problem. Staci mit dostatecny pocet stroju, z nichz kazdy bude resit jednu zalohu. Staci otestovat, jak dlouho se dela jedna zaloha a pak vim, ze jede 12 zaloh za hodinu, hodin je ve dni 24 a pak uz to jen vynasobis a navrsis o rezervu, kdyby se zalohy zpomalily vlivem komplikovanejsich dat.

Dneska se to řeší pronájmem strojového času v cloudu přece ;D, výkonu je hromada
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: Honza1 25. 03. 2017, 12:02:19
Ale pokud jsou data velka do 150 MB na jeden zatah, nema smysl poustet vice vlaken a ani s RAM to nebude tak horke. Pak jeste je do naroku na RAM krome slovniku treba pripocist seznam souboru s kompletnimi cestami da cca 0.5-3 MB na tisic souboru (a nejvic pameti to sezere nakonci vytvareni archivu, kdyz se komprimuje filelist).

To je otázka, jestli pak není komprese s menším slovníkem u takových dat na 4 jádrovém či 8 jádrovém CPU výrazně rychlejší než to hrnout přes jedno jádro.

To je sice pravda, auto chce pro nejlepsi kompresi prave co nejvetsi slovnik (pokud maximum je 150 MB dat do archivu, staci slovnik 192 MB). Nejde mu tak o rychlost.

Avsak velke podobnosti budou i v zalohach z ruznych casu, takze pozdeji jednotlive archivy lze rozbalit a pak data zkomprimovat do jednoho archivu (napr, za den, za mesic, je to 288 zaloh da zen, radove 30-50 GB dat). 7zip umi podobnosti mezi soubory najit.

Ale proc ma zaloha bezet po 5 min, to je prehnane casto. Ono totiz 150 MB dat se maximali kompresi ani za 5 min nemusi stihnout (v pripade textovych dat, slabsi CPU). Pak pobezi vic procesu naraz z jedotlivych casu aproblem muze byt komprimace stejnych dat dvema ruznymi procesy. Pokud to nebude 7zip stihat za 5 min vice nez 50% pripadu, pocet soucasne spustenych procesu bude porad rust.

Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: ByCzech 25. 03. 2017, 12:28:42
Ale proc ma zaloha bezet po 5 min, to je prehnane casto. Ono totiz 150 MB dat se maximali kompresi ani za 5 min nemusi stihnout (v pripade textovych dat, slabsi CPU).

Právě proto tady po několikáté upozorňuji na možnost spuštění na více jádrech, protože s větším slovníkem bude snížení množství času nejspíše zanedbatelné, ale náročnost a tím pádem potřeba času stoupá často exponenciálně.

Já osobně bych to řešil úplně jinak, rychle bych to nalil do tarballu a ten bych potom komprimoval třeba paralelním xz (pxz). Ale tazatel se vyloženě ptal na 7-zip, co ho k tomu vede nevím. Třeba to má své důvody, které tady neuvedl, takže se snažím držet zadání i když se mi může zdát už zadání úkrok bokem.
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: Lol Phirae 25. 03. 2017, 12:37:09
Ale proc ma zaloha bezet po 5 min, to je prehnane casto.

Jak už konstatovala stará Jirsáková (https://forum.root.cz/index.php?topic=15102.msg205096#msg205096), takhle může "zálohovat" akorát magor.  ::)
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: ByCzech 25. 03. 2017, 12:43:14
Ale proc ma zaloha bezet po 5 min, to je prehnane casto.

Jak už konstatovala stará Jirsáková (https://forum.root.cz/index.php?topic=15102.msg205096#msg205096), takhle může "zálohovat" akorát magor.  ::)

Jak jsem už psal, osobně zadání příliš neřeším, kdo ví jaké k tomu má důvody i když mě osobně se to nezdá taky od počátku smysluplné.
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: Honza1 25. 03. 2017, 13:53:01
Ale proc ma zaloha bezet po 5 min, to je prehnane casto. Ono totiz 150 MB dat se maximali kompresi ani za 5 min nemusi stihnout (v pripade textovych dat, slabsi CPU).

Právě proto tady po několikáté upozorňuji na možnost spuštění na více jádrech, protože s větším slovníkem bude snížení množství času nejspíše zanedbatelné, ale náročnost a tím pádem potřeba času stoupá často exponenciálně.

To moc nechapu. S vetsim slovnikem se cas spise malicko zvysi. Snizeni velikosti vysledneho archivu je vetsinou minimalni, nekdy az desitky procent.

Pokud by samotna komprese trvala dele nez tech 5 min, zacali by se soucasne spustene ulohy hromadit, bez ohledu na velikost slovniku, az by dosla RAM (nebo nestihal disk), a archiv se nevytvori, na misto toho hlaska Cant't allocate required memory.

Tady vice vlaken nepomaha, velikost slovniku cas moc neovlivni, takze jestli pobezi jedna uloha kratce na vice vlaknech, nebo vic uloh jedno(dvou) vlaknovych - jeden proces zvlada 2 vlakna, tak to moc nesejde. Akorat kdyz kazdy proces zabere 11 GB RAM, tak vic procesu najednou muze byt problem.

Autor ale ma silny stroj, kde i jedno-slovnikovy beh naraz (tedy 2 vlakna) CPU zvladne prakticky vzdy za 5 min 150 MB (to je 0,5 MB/s, coz yvladaji i postarsi PC vetsinou).

Jeden plok-slovnik uziva 2 vlakna, neco v RAM si vezme system. Takze napr. pri 64 GB RAM a 12-vlaknovem CPU lze pri 1024 slovniku LZMA1 zvladat 5 slovniku-bloku naraz multivlaknove (sesty se nevejde do RAM), rychlost jednoho bloku-slovniku-procesu je podle typu dat na znacne rychlem CPU cca 1000-7000 kB/s, celkem tedy 5-35 MB/s, jen vyjimecne pri nekterych datech a ne uplne nejrychlejsim CPU da jeden proces pod 1000 kB/s. Pak je taky otazka, jak to bude stihat disk, 5 procesu najednou, pokud v kazde kmpriovane slozce budou kvanta malinkych souboru, to taky jak cteni z disku, tak samotny kompresni proces razantne zpomali (a zadrsarova struktura se seznamem souboru take vezme neco v RAM u kazdeho procesu).
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: ByCzech 25. 03. 2017, 14:07:12
Právě proto tady po několikáté upozorňuji na možnost spuštění na více jádrech, protože s větším slovníkem bude snížení množství času nejspíše zanedbatelné, ale náročnost a tím pádem potřeba času stoupá často exponenciálně.
To moc nechapu. S vetsim slovnikem se cas spise malicko zvysi. Snizeni velikosti vysledneho archivu je vetsinou minimalni, nekdy az desitky procent.

Pardon chybka, snížení množství dat s větším slovníkem...
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: ByCzech 25. 03. 2017, 14:13:14
Autor ale ma silny stroj, kde i jedno-slovnikovy beh naraz (tedy 2 vlakna) CPU zvladne prakticky vzdy za 5 min 150 MB (to je 0,5 MB/s, coz yvladaji i postarsi PC vetsinou).

Otázka je, kde se teda bere těch 150 MB (nových/změněných) dat, když ten stroj z toho co píšete je nejspíš dedikovaný jen na zálohování? ;-)

Víme o tom dost málo, pak to svádí k takovým spekulacím. Nevíme jak moc je stroj vytížen jinými věcmi, či jak moc může být vytížen ve špičce. Velikost slovníku a výše komprese může zacloumat složitostí tedy i potřebným časem na zpracování výrazně a pak je otázka, jestli se to do 5 min stíhá nebo nebo ne. Dle mého názoru je nejlepší zvolit správný poměr mezi úrovní komprese a délkou zpracování, protože na to, abych ušetřil pár kB dat mi nemusí komprimovací program běžet 2× delší dobu, že? Ale jak říkám, víme o tom na co to tazatel potřebuje kulové, takže se trefit do ideálu je docela problém.
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: Honza1 25. 03. 2017, 14:46:07
Autor ma k dispozici relativne dost vykonu evidentne.

Ja mam k dispozici 16 GB RAM a 4-jadra - 8 vlaken I7 CPU na 2,2 GHZ.
pouzivam 7z a -t7z -m0=lzma -mx=9 -mfb=273 -md=1024m -ms=on JmenoArchivu.7z (pro 7zip-full, jinak je na zacatku misto 7z jen 7za)

Pokud je maximalni velikost slozky 150 MB (i kdyby tato velikost byla porad), pri rychlosti 600-800 kB/s (slozity text), 1300-2000 kB/s (normalni text, html), 2500-4000 kB/s (obrazky, mp3, video) to zvlasdne vzdy.

Jeden slovnik-blog zvladne obsadit 1 jadro - 2 vlakna a pri 1024 MB slovniku vic nez jeden nemuzu spustit.

Pri velikosti slozky 150 MB staci slovnik 256 MB, vic nejde, takhle je cely archiv jeden slovnik (stacil by i 192 MB), pri 256 MB to zabere 2,6 GB RAM (+filelist a adresarova struktutra) a muzi spustit vzhledem k RAM i CPU 4 slovniky-bloky-archivy najednou (u hodne hodne hodne malych soubory ale ne, nestiha ani disk, filelist obsadi ram)

Pokud je max. slozky 150 MB a cas 300 s (5 min), je rychlost potreba 500 Kb/s, coz prakticky VZDY da, mozna ne v nejslozitejsich textech v hodne malych souborech.
A kdyz nahodou ne (jen velmi vyjimecne, nebot velikost slozky jeste navic neni 150 MB alekolisa 5-150 MB, prumernou velikost a pocet souboru autor nezdelil), 2 procesy najednou nevadi a cas mam 10 min na archiv, 15 min pri trech procesech najednou a 20 min pri 4 procesech najednou. A to snad stihne vzdy (125 kB/s je na dost slabem NTB se slozitejsimi daty).

Tazatel ma ale vykonu mnohem vic nez ja, a zbyvajici vykon bude na dalsi veci. V naproste vetsine komprese vezme 2 vlakna a 2,6-3 GB Ram (velku pocetsouboru nebude predpokladam v 5-150 MB, jinak by to razantne zatizilo disk i pri jedne komprimaci najednou a i vic RAM by to sezralo).


RESENI ZADANI TEDY JE:
7z a -t7z -m0=lzma -mx=9 -mfb=273 -md=256m -ms=on JmenoArchivuZadane ZBashe.7z
Misto lzma lze i lzma2, nepatrne lepsi.
Neplnohodnota verze 7z ma na zacatku 7za misto 7z

BTW NECHCE NAHODOU TAZATEL ZALOHOVAT LOGY NA OBRIM SERVERU ?
Pri 150 MB a velikost logu 150 B je to milion souboru, kazdy ma svuj sektor na disku. Komprese bude ponekud pomalejsi (na mem PC tak 250-500 kB/s - slozity text, hodne souboru), filelist vezme cca 1,5 GB RAM na kazdy proces a vic jak 2 procesy najednou by muj PC nedal moc dobre (mozna 3, ale to disk bude docela problem, i pri dvou, ale jestli ma autor SSD, tak neresit). Doba komprese 6-10 minut (az 10) a povetsinou 1-2 procesy na jednou (na mem stroji). JENZE nez proskenuje pruzkum adresare celou slozku,jen to bude i prez 5 min mozna a navic velka zatez disklu. takze to by mimo SSD stejne cely plan spadnul.
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: Ondrej Nemecek 25. 03. 2017, 20:49:23
Zálohování každých 5min - to vypadá spíš jako replikace :-) Jinými slovy, možná by se našel příhodnější postup.
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: tisnik 25. 03. 2017, 22:28:35
Budu zalohovat kazdych 5min slozky ktere maji asi 5-150mb
a potrebuji nejlepsi kompresi (cpu a ramky me nezajimaji)

Jaky je presny duvod, resp. co presne resis za problem? Nestaci nakonec napriklad jen stary dobry rsync?
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: oldschool 25. 03. 2017, 22:51:32
Tak jsem vyzkousel ten paq8px. Je to hrozne pomaly, a tudiz dost neprakticky :) Ale ten vysledok byl dobrej. Pokusni adresar byl 49MB - webarina, node moduly, multimedia. Vsechny kompresni utilitky byli nastaveny na maximalni kompresi. 7z sem pouzil takhle:
Kód: [Vybrat]
7z a -t7z -mmt=2 -mx=9 -mfb=273 -md=1024m -ms=on pokus.7z pokus/
Porovnani
Kód: [Vybrat]
   5.8M Mar 25 10:38 pokus.7z
   8.1M Mar 25 10:23 pokus.rar
   9.0M Mar 25 10:20 pokus.tar.bz2
    11M Mar 25 10:20 pokus.tar.gz
   5.9M Mar 25 10:25 pokus.tar.lzma
   4.4M Mar 25 18:50 pokus.tar.paq8px
    15M Mar 25 10:21 pokus.zip

Paq stazen odtud http://dhost.info/paq8/paq8px_v69.zip a kompilace pres
Kód: [Vybrat]
g++ paq8px_v69.cpp -DUNIX -DNOASM -O3 -march=core2 -Os -s -fomit-frame-pointer -o paq8px_v69

Komprimovalo to bratru skoro 2h
Kód: [Vybrat]
Total 48447488 bytes compressed to 4636908 bytes.
Time 5842.26 sec, used 905898471 bytes of memory

Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: JardaP . 25. 03. 2017, 23:18:20
@oldschool: Jeste byste pro psinu mohl pridat ppmd, schvalne, jak dopadne.
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: Honza1 29. 03. 2017, 00:46:39
@oldschool:

Multimedia (obazky a videa) nezkomprimuje moz zadny komresor, nebot jiz komprimovana jsou.

Obrazky BMP, text, html, dokumenty Office (nekoprimovany format hlavne, bez obrazku) zvladne vse dobre, rozdily RAR,ZIP,7z jsou velke (7z je novejsi a lepsi).

Dulezota je moznost najit podobnosti mezi ruznymi soubory akomprimace filelist, adresarove struktury.

paq8px dal cca 25 MB za hodinu, to je cca 7,2 kB/s (cca 3000-5000x pomalejsi nez 7z), 2x rychlejsi nez pripojeni dial up a stahovani dat. Archiv je velky 76% velikosti 7z archivu. Jaka je spotreba CPU,RAM ?
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: Herkulesk 29. 03. 2017, 04:26:12
Pro bezneho smrtelnika uz 7zip staci pro maximalni kompresi dat -mx=9 a pouzijese lzma ze?
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: Lojza 29. 03. 2017, 16:55:27
mohl by mi nekdo priblizit co to je a jak funguje ten "slovnik"? to ma v sobe 7zip nebo si ho z neceho vytvari ? stejne tak nerozumim jak bych mel 7zip nastavit aby vyuzival "podobnosti"s jiz vytvorenymi archivy

jinak pred par lety jsem cetl par benchamrku a rar mel nejlepsi pomer rychlost/vysledna velikost archivu, 7zip byl o par procent lepsi co do velikosti vysledneho archivu ale za cenu ze byl o mnoho pomalejsi

imho nastaveni maximalni komprese (aspon u raru) ma za nasledek zcela neobhajitelne zvyseni casu vytvareneho archivu za cenu jen par jednotek procent  snizeni velikosti vysledneho archivu (predpokladam podobne chovani i u 7zip mezi volbou komprese normal a ultra, nezkousel jsem)
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: davkol 29. 03. 2017, 17:28:16
mohl by mi nekdo priblizit co to je a jak funguje ten "slovnik"?
wiki (https://cs.wikipedia.org/wiki/Bezeztr%C3%A1tov%C3%A1_komprese#Slovn.C3.ADkov.C3.A9_algoritmy)
Citace
Zjednodušeně: Algoritmy v této skupině vytvářejí v průběhu komprimace slovník na základě dat již zkomprimovaných, v němž se pak snaží najít data, která se teprve mají komprimovat. Pokud jsou data nalezena ve slovníku, algoritmus zapíše pozici dat ve slovníku místo samotných dat.
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: robotron 29. 03. 2017, 18:01:56
Nakolik je puvodni dotaz podivny, ba zapacha pravdepodobnosti, ze tazatel chce neco jinyho, nez na co se pta, jsem velmi potesen, ze jsem se tu dozvedel zajimave veci o kompresi. Predevsim, ze (uz) existuje paralelni xz "pxz" (dik: ByCzech), porad jsem cekal, kdy dodelaji paralelno do xz a netusil jsem, ze je na to zvlast program. Dale pak jsem velmi vdecen za info o algoritmech PAQ (dik: davkol, St.Petr).
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: ByCzech 30. 03. 2017, 07:09:34
Nakolik je puvodni dotaz podivny, ba zapacha pravdepodobnosti, ze tazatel chce neco jinyho, nez na co se pta, jsem velmi potesen, ze jsem se tu dozvedel zajimave veci o kompresi. Predevsim, ze (uz) existuje paralelni xz "pxz" (dik: ByCzech), porad jsem cekal, kdy dodelaji paralelno do xz a netusil jsem, ze je na to zvlast program. Dale pak jsem velmi vdecen za info o algoritmech PAQ (dik: davkol, St.Petr).

Ono těch paralelních komprimovačů, které jsou jako samostatné programy je více, třeba:

gzip → pigz
lzip → plzip
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: trubicoid2 30. 03. 2017, 08:59:18
treba ten pigz zrovna dokaze transparentne nahradit gzip, udela si tam linky

stejně lbzip2 transparentně nahradí bzip2

pxz ma jinaci prepinace i format, jestli si dobre pamatuju

navic posledni pigz ma i volbu -11, kdy se pouzije zopfli - pomala komprese, dobry vysledek, obycejny gzip to otevre
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: honza1 30. 03. 2017, 13:52:44
mohl by mi nekdo priblizit co to je a jak funguje ten "slovnik"? to ma v sobe 7zip nebo si ho z neceho vytvari ? stejne tak nerozumim jak bych mel 7zip nastavit aby vyuzival "podobnosti"s jiz vytvorenymi archivy

jinak pred par lety jsem cetl par benchamrku a rar mel nejlepsi pomer rychlost/vysledna velikost archivu, 7zip byl o par procent lepsi co do velikosti vysledneho archivu ale za cenu ze byl o mnoho pomalejsi

imho nastaveni maximalni komprese (aspon u raru) ma za nasledek zcela neobhajitelne zvyseni casu vytvareneho archivu za cenu jen par jednotek procent  snizeni velikosti vysledneho archivu (predpokladam podobne chovani i u 7zip mezi volbou komprese normal a ultra, nezkousel jsem)

7z nevyuziva podobnosti mezi archivy, ale podobnosti mezi soubory ve slozce, kterou komprimuje, a to docela efektivne (napr. strasne mo html stranek podobnych - z par desitek GB jsem udelal par desitek MB). 7z umi narozdil od gz,xz celou slozku zkomprimovat, ne jeden soubor. Neni potreba tarovat a podbnosti se lepe hledaji.

7z je pomalejsi nez rar, a pri ULTRA kompresi je pokles rychlosti vysoky, archiv jen o malo mensi. Ale kdyz se procesorovy cas nemusi tolik resit, davam max kompresi z principu.

Narozdil od RAR, ZIP je 7z svobodny.
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: Honza1 04. 04. 2017, 22:05:58
Nakolik je puvodni dotaz podivny, ba zapacha pravdepodobnosti, ze tazatel chce neco jinyho, nez na co se pta, jsem velmi potesen, ze jsem se tu dozvedel zajimave veci o kompresi. Predevsim, ze (uz) existuje paralelni xz "pxz" (dik: ByCzech), porad jsem cekal, kdy dodelaji paralelno do xz a netusil jsem, ze je na to zvlast program. Dale pak jsem velmi vdecen za info o algoritmech PAQ (dik: davkol, St.Petr).

Moje rec. Autor dotazu nedava zpetnou vazbu a tezko poradit, kdyz poradne nevime o co jde. Nicmene jake je vlastne reseni zadani a kolik CPU, RAM to sezere, i jak ma znit prikaz, jsem mu napsal. Nicmene jdem vdecny za diskuzi ohledne aktualnich moznosti komprese dat.

PAQ je v praxi povetsinou nepouzitelny, aje jen tak bych to mohl zkusit taky namensich datech. Vedel by nekdo na to program ?

Take kdysi nekde byla tabulka ruznych kompresoru, jaka je rychlost a ucinnost. 7z vitezi mezi jednotlivymi programy, ale ne moc beznych programu bylo nekolik lesich (mene dat na konci), ale o mnoho pomalejsich. Kde najit tabulku si nemuzu vzpomenout.
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: robotron 04. 04. 2017, 22:19:41
PAQ je v praxi povetsinou nepouzitelny, (..)

Mne nejvic zaujalo, ze autor vytvoril format ZPAQ s VM-kodem dekompresoru coby bytostne soucasti archivu. Jasne, nebude to vhodny pro parbajtovy soubory (to ostatne ale vetsinou stejne nic) -- a dava to sanci na rozsiritelnej format, kterej by se mohl stat takovym ZIPem pro dalsi dlouha desetileti -- a to bez ohledu na to, jestli se bude komprimovat zrovna algoritmem rodiny PAQ. Za me zajimavy, zpaq jsem si hned pokusne nainstaloval.
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: Honza1 04. 04. 2017, 22:33:23
Nasel jsem jednu stranku, zabyvajici se kompresi dat a test mnoho algoritmu. Ale bude to uz starsiho.

https://cs.fit.edu/~mmahoney/compression/text.html
https://cs.fit.edu/~mmahoney/compression/

PAQ je podle vseho lepsi nez LZMA1-2, ale brutalne je pomaly.
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: l 04. 04. 2017, 23:17:26
vsak na archivaci ok
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: Honza1 05. 04. 2017, 21:03:23
Paq stazen odtud http://dhost.info/paq8/paq8px_v69.zip a kompilace pres
Kód: [Vybrat]
g++ paq8px_v69.cpp -DUNIX -DNOASM -O3 -march=core2 -Os -s -fomit-frame-pointer -o paq8px_v69

Komprimovalo to bratru skoro 2h
Kód: [Vybrat]
Total 48447488 bytes compressed to 4636908 bytes.
Time 5842.26 sec, used 905898471 bytes of memory

paq8px_v69 jsem zkompiloval binarku ze zdrojaku danym prikazem. Ale ted nemuzu prijit na to, jak binarku pouzit (mam Ubuntu). jak si pouzil binarku a prikaz ke kompresi ? Musi se binarka nekam pridat ?
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: Honza1 05. 04. 2017, 23:38:22
Tak jeste jeden odkaz, tentokrat novejsi benchmarky a test na vykonnem stroji, komrese i 10 GB textu a dat.

http://mattmahoney.net/dc/
http://mattmahoney.net/dc/#paq
http://mattmahoney.net/dc/10gb.html
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: oldschool 06. 04. 2017, 08:33:43
paq8px_v69 jsem zkompiloval binarku ze zdrojaku danym prikazem. Ale ted nemuzu prijit na to, jak binarku pouzit (mam Ubuntu). jak si pouzil binarku a prikaz ke kompresi ? Musi se binarka nekam pridat ?

Standardni security v unixech (nebo rekneme to na rovinu, chyba v navrhu OS, kdysi jsme tak hackovali skolni BSD) je, ze binarky ktere nejsou v slozkach kde smeruje cesta se musi spoustet jako ./nazev-binarky aby bylo jasno, ze spoustis prave tu co mas v ceste. Ja to kompiloval v downloads.

Kód: [Vybrat]
~/Downloads/paq$ ./paq8px_v69   
paq8px archiver (C) 2008, Matt Mahoney et al.
Free under GPL, http://www.gnu.org/licenses/gpl.txt

To compress:
  paq8px -level file               (compresses to file.paq8px)
  paq8px -level archive files...   (creates archive.paq8px)
  paq8px file                      (level -5, pause when done)
level: -0 = store, -1 -2 -3 = faster (uses 35, 48, 59 MB)
-4 -5 -6 -7 -8 = smaller (uses 133, 233, 435, 837, 1643 MB)
You may also compress directories.

To extract or compare:
  paq8px -d dir1/archive.paq8px      (extract to dir1)
  paq8px -d dir1/archive.paq8px dir2 (extract to dir2)
  paq8px archive.paq8px              (extract, pause when done)

To view contents: paq8px -l archive.paq8px

Nebo binarku presun do /usr/local/bin (bdes potrebovat root opravneni) a pak to uz pujde i bez ./ z libovolneho adresare.
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: Honza1 06. 04. 2017, 18:52:46
To oldschool

Diky, presne tak jsem to delal, jen jsem nepsal pomlcku pred urovni komrese. Na slabem PC jsem zkusil soubor o par stovkach kB a pomalu je to na pauzu na kafe. I na rychlem CPU muze 1 GB trvat dny.

Mel by zvladat snad i komprimaci slozky.

Ale jinak super pro ne moc velke veci, napr. kdyz chci hodne textu poslat mailem a mam limit pro prilohu.
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: Ondrej Nemecek 06. 04. 2017, 18:56:04
Citace
Standardni security v unixech (nebo rekneme to na rovinu, chyba v navrhu OS, kdysi jsme tak hackovali skolni BSD)

To se security moc nesouvisí a proč by to měla být chyba v návrhu OS taky nevím. Zbytek samosebou souhlasí.
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: dw 07. 04. 2017, 12:06:08
Nebo binarku presun do /usr/local/bin (bdes potrebovat root opravneni) a pak to uz pujde i bez ./ z libovolneho adresare.

Alebo si to presun do zlozky bin svojho domovskeho adresara (~/bin) nech si nevyrobis pripadnu dalsiu dieru do systemu :D
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: Honza1 07. 04. 2017, 12:08:43
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.


Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: ByCzech 07. 04. 2017, 12:54:05
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
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: Boo 07. 04. 2017, 13:40:30
Provedl sem pokus, komprese adresare je o 14% lepsi nez komprese taru.
Kód: [Vybrat]
3277744 dir.7z
3762806 tar.7z
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: Trubicoid2 07. 04. 2017, 14:05:32
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/ (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?
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: Trubicoid2 07. 04. 2017, 14:08:20
Jinak jak tam zmiňují xz, to by mělo být srovnatelné se 7zip. Nejlepší komprese
Kód: [Vybrat]
xz -9e souboř.tař
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: Boo 07. 04. 2017, 14:49:33
Můžeš to zkusit se sortovaným tarem taky?

kousek lepsi

Kód: [Vybrat]
3277744 dir.7z
3408565 sorted-tar.7z
3762806 tar.7z
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: Honza1 07. 04. 2017, 14:50:50
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.
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: Honza1 07. 04. 2017, 14:53:15
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.
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: trubicoid2 07. 04. 2017, 14:59:18
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
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: Honza1 07. 04. 2017, 15:16:50
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.
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: Boo 07. 04. 2017, 16:05:27
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.
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: Honza1 07. 04. 2017, 17:11:02
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.
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: Honza1 07. 04. 2017, 17:27:16
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.
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: Boo 07. 04. 2017, 18:14:09
Jake stranky projektu pouzivas ?

http://dhost.info/paq8/  je tam mnoho verzi, nektere zipy maji v sobe i asm zdrojaky
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: Honza1 07. 04. 2017, 18:54:06
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)
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: Honza1 07. 04. 2017, 19:17:57
Tahle tabulka je asi nejlepsi. Je tam efektivita komprese (o kolik procent se zmensil objem dat), rychlost rozbalovani i rychlost komprese. Co se tyce minimalizace dat, vyhrava paq8px (za cenu obrovskeho procesoroveho casu).
Mnoho programu jelepsich nez 7zip.
Talbulka je maximalne prehledna.

http://www.maximumcompression.com/data/summary_mf2.php

A na strankach zdrojaku paq8px je taky tabulkapro ruzne verze (divne, ze se tak lisi):
http://dhost.info/paq8/
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: Honza1 07. 04. 2017, 19:30:47
Jinak tech tabulek je pro ruzne typy dat opravdu hodne zde:
http://www.maximumcompression.com

Preheled webu s tematikou:
http://www.maximumcompression.com
http://dhost.info/paq8/
http://www.squeezechart.com/
http://compressionratings.com/
http://mattmahoney.net/dc/
http://mattmahoney.net/dc/index.html
https://cs.fit.edu/~mmahoney/compression/
http://en.wikipedia.org/wiki/PAQ
http://encode.dreamhosters.com/

U paq8px je nevyhodou i to, ze dekomprese zabere skoro stejne casu jako komprese (i kdyz potrebuje mene RAM o cca ctvrtinu-petinu).
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: Honza1Ubuntu 09. 04. 2017, 20:03:19
STALE NENI TADY MOC NAVRHU (JEN MUJ) NA ZADANI, JAKE JE NEJLEPSI NASTAVENI KOMPRESE V 7Z

Maly test pro lzma vs. lzma2.

Nastaveni bylo vzdy toto:
7z a -t7z -m0=lzma -mx=9 -mfb=273 -md=64m -ms=on JmenoArchivu.7z
7z a -t7z -m0=lzma2 -mx=9 -mfb=273 -md=64m -ms=on JmenoArchivu.7z

Data c.1 - textove soubory z daty.
Folders: 364
Files: 1272
Size:       482187948 B

Velikost lzma: 64143646 B
Velikost lzma2: 64158311 B

Data c.2 Linuxove skripty v ruznych verzich, hodne cyklu a pod. Data docela podobna.
Folders: 16
Files: 237
Size:       20059298 B

Velikost lzma: 624962 B
Velikost lzma2: 624273 B

Data c. 3 Linuxove skripty v ruznych verzich, hodne cyklu a pod. K tomu navic 2 datove soubory s cisly (real, integer), tyto stejne soubory na nekolika ruznych mistech. Opet dost podobnosti.

Folders: 24
Files: 535
Size:       236838685 B

Velikost lzma: 3184034 B
Velikost lzma2: 3170817 B

Data c. 4 - hodne excelovych souboru ve formatu do r. 2003. Excelove soubory jsou hodne podobne se stejnym formatem, data v nich se lisi. K tomu pod 10% odhaduji tvori samotne textove soubory s daty (cisla) - format TXT, CSV, DAT. Do cca. 2-3 MB, tedy cca 0,1% dat jsou nekomprimovatelne PNG obrazky (barevna hlobka 8 bit, uroven PNG komprese 9 - max). V nazvech souboru jsou mezery, hacky, carky, blbost z minulych let.

Folders: 213
Files: 6444
Size:       2370465554 B

Velikost lzma: 135076665 B
Velikost lzma2: 134751155 B

Data c. 5 - PNG obrazky, schematickeho typu. Barevna hloubka 24 bit, uroven png komprese 9 - maximalni.

Folders: 49
Files: 5867
Size:       634094047 B

Velikost lzma: 598956622 B
Velikost lzma2: 599022977 B

Tedy lzma2 je o neco lepsi vetsinou, radove setiny procenta Rozdil nikdy nepresahl 0,1%. U lzma2 procento dokonceni archivu i kontroly dat skokove pribyvalo, u lzma1 to bylo plynulejsi. Rychlost je vicemene stejna, mozna lzma2 je o neco rychlejsi. Procesorovy cas na slabem Pc byl delsi nez hodinu akorat u velkeho datoveho souboru (cca. 2,3 GB). CPU jeden blok naraz (a s tim okolo 720 MB RAM pri 64 MB slovniku) to vyuziva na 2 vlakna/jadra, pricemz vetsinou vyuziti je 110-195% normalizovano 1 vlakono = 100 %. paq8px vyuziva jedno vlakno jen, vetsinou k 100%, ten ale ted testovan nebyl (trochu to trva). Jak je to u lzma vs. lzma2 s chybovosti archivu, tod otazka. Ale oboji by melo byt OK a u obou je rozbaleni ci kontrola archivu podstatne rychlejsi nez komprese.

Rychlost na slabem PC je okolo 200-600 kB/s, pri paq8px cca 0,5-2 kB/s
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: Honza1 10. 04. 2017, 11:12:22
Nedari se mi prijit na to jak udelat archiv cely jako solid archive.
Deafultne je nastavena velikost sold block 4 GB.

Muzu zkusit napr -ms=65536g a tim bude velikost solid block cca 64 TB.

Nekde jsem nasel  -msNg ale to nevim, jak pouzit.

V manualu velikost solid bloku neni.
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: ByCzech 10. 04. 2017, 11:20:03
STALE NENI TADY MOC NAVRHU (JEN MUJ) NA ZADANI, JAKE JE NEJLEPSI NASTAVENI KOMPRESE V 7Z

V zadání je taky, že se má zálohovat co 5 min až 150 MB dat. :)
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: Honza1 10. 04. 2017, 11:58:24
STALE NENI TADY MOC NAVRHU (JEN MUJ) NA ZADANI, JAKE JE NEJLEPSI NASTAVENI KOMPRESE V 7Z

V zadání je taky, že se má zálohovat co 5 min až 150 MB dat. :)

To sice jo, ale me to zajima pro moje ucely. A v zadani je relatovne neomezene CPU a RAM (staci 8 vlaken a 16 GB RAM v pohode, ale kdovi kde ma autor strop).
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: ByCzech 10. 04. 2017, 13:34:50
Tak to by na jiné zadání možná bylo vhodnější udělat jiné vlákno...
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: Ovrscout 10. 04. 2017, 14:40:52
Pro textové sobory(plain-text) zkus použít PPMD (místo toho LZMA2), mohlo by ti to dát lepší výsledky.
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: Honza1 11. 04. 2017, 12:42:00
Tak to by na jiné zadání možná bylo vhodnější udělat jiné vlákno...

Ono je to vicemenne to same zadani. Jinak zatim to vypada na nejlepe resenou kompresi:

7z a -t7z -m0=lzma2 -mx=9 -mfb=273 -md=1024m -ms=on -ms=65536g -mmt=2 JmenoArchivu.7z

-ms=65536g znamena Solid Archive az do cca 64 TB (deafultne je to 4 GB), -mtt=2 znamena 2 vlakma multi threating (davat jen jedno vlakno je zbytecne, pro kazdy slovnik dokaze 7z vyuzit2 vlakna, pokud dame -mtt=4(nebo 3), 7z si zabere dvojnasobek pameti na 2 slovniky, pro -mtt=5-6 trojnasobek a pod. Pokud mtt nezadame, znamena to automaticky ano, vyuzije vsechny vlakna. Tim padem ale nemusi stacit RAM a zkonci to padem programu). -md=1024m znamena 1024 MB slovnik. To zabere 10,7 GB RAM + filelist. Slovnik lze zadat tusim az do 4096m (4 GB), coz ale zabere 43 GB RAM + filelist (na jeden blok, tedy -mtt=2 nebo 1). Metoda kmprese -m0=lzma2 ale novejsi 7z si pro jiste typy souboru (exe) zvoli jiny typ automaticky, i kdyz to nezadame. Jinak pro vetsinou souboru pouzije lzma2.

Pro autora - velikost slozek do 150 MB, velikost slovniku tedy 256m postaci. Aby byla vetsi rychlost a jistota, ze se to vzdy stihne do 5 m, tak multithreating na 8 vlakem (4 bloky soucasne). To zabere cca 10,6 GB RAM + filelisst.

Tedy:
7z a -t7z -m0=lzma2 -mx=9 -mfb=273 -md=256m -ms=on -ms=65536g -mmt=8 JemenoArchivu.7z
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: Honza1Ubuntu 16. 05. 2017, 20:07:29
Opet jeden dalsi test. Jednalo se o 91.72 GiB dat, grafy a texttove soubory. Celkovy pocet souboru je 10 344 588 a pocet slozek 451 319.

Textove soubory tvori priblizne 17-18% dat (okolo 16-17 GiB) textovych souboru je okolo 460 000, zbytek jsou grafy, png obrazky s kompresi quality 95, barevna hloubka 8 bit, rozliseni 1280x960.

Kód: [Vybrat]
p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,16 CPUs x64)

Nejdriv LZMA1:
Kód: [Vybrat]
7z a -t7z -m0=lzma -mx=9 -mfb=273 -md=1024m -ms=on Archive.7z

Vysledek:
Kód: [Vybrat]
Physical Size = 58343558019
Headers Size = 84804868
Method = LZMA:30
Solid = +
Blocks = 23

Everything is Ok                                                               

Folders: 451319
Files: 10344588
Size:       98566411542
Compressed: 58343558019

Po te jako LZMA2, jako jeden blok (jinak je velikost bloku deafultne 4 GB nebo 4 GiB, jak to bylo v prvnim pripade).

Kód: [Vybrat]
7z a -t7z -m0=lzma2 -mx=9 -mfb=273 -md=1024m -ms=on -ms=65536g -mmt=2 Archive.7z

Vysledek:
Kód: [Vybrat]
Physical Size = 58006341138
Headers Size = 84905891
Method = LZMA2:30
Solid = +
Blocks = 1

Everything is Ok                                                               

Folders: 451319
Files: 10344588
Size:       98566411542
Compressed: 58006341138

Pri velkem poctu souboru je LZMA2 uspornejsi na pamet podle vseho. V pripade LZMA1 to sezralo az 26.5 GB RAM,  v pripade lZMA2 "jen" 20.5 GB RAM, k dispozici je 32 GB.

Zatimco stara verze p7zip do verze 9.20 minimalne radila pri kompresi soubory nejdriv podle pripony, pak podle jmena, pak az podle umisteni v adresari, nova verze radi soubory presne abecedne podle cele cesty (nejdriv podle umisteni v adresari, pak podle jmena abecedne, pak az podle pripony). To ma za vysledek, ze u nove verze je vysledny archiv zbytecne vetsi, u specifickych dat to muze byt obrovsky rozdil.
Snad by tam mel byt nejaky prikaz, jak data radit korektne (tak jako v drivejsich verzich). Zatim nevim jaky.
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: Honza1Ubuntu 16. 05. 2017, 22:30:35
Tak nove razeni podle jmena je od verze 15.06 - tam je moznost dvojiho razeni. Deafultne podle jmena abecedne, druha moznost je podle pripony-typu, prepinac -mqs , v graficke verzi pak zaskrtnuti volby qs. Predchozi verze radily vzdy podle pripomy-typu.
Razenim podle pripony-typu je komprese ucinnejsi a vysledny archiv mensi.

Celkovy prikaz pro maximalni kompresy od verze 15.06:
Kód: [Vybrat]
7z a -t7z -m0=lzma2 -mqs -mx=9 -mfb=273 -md=1024m -ms=on -ms=65536g -mmt=2 JmenoArchivu.7z
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: Honza1Ubuntu 20. 10. 2017, 11:12:51
Tady jsou vysledky testu 7z vs. paq8px

V pripade lzma2 je pro kazde zapocate vlakna u multi-threading alokovan v ram novy slovnik, proto byly pouzity jen 2 vlakna.
Maximalni velikost slovniku je 1536 MB, misto drivejsich 1024 MB. Maximalni slovnik zabere 16.5 GB RAM plus filelist.

Prikaz pro maximalni moznou kompresi je (co se mi podarilo najit a vyzkouset):
7z a -t7z -m0=lzma2 -mqs -mx=9 -mfb=273 -md=1536m -ms=on -ms=65536g -mmt=2 JmenoArchivu.7z

Pro maximalni kompresi 7z je dulezite uvest prepinac -mqs, jez radi soubory podle typu, jinak jsou razeny abecedne.
Starsi verze 7zip nemaji prepinac -mqs a radi soubory vzdy podle typu.

Rychlost podle typu CPU a dat 500-5000 kB/s, vetsinou 1000-2000 kB/s.
Dekomprese je mnohonasobne rychlejsi.
Drivejsi komprese lzma u starsich verzi 7z mohla byt o par setin lepsi,pri maximalnim 1024 MB slovniku, zato vic to sezralo RAM, pri velkem poctu souboru.
ms je velikost bloku, v GB, takze az do 65.536 TB je archiv z jednoho bloku. Ale nekdy si 7z udela dalsi blok s jinou metodou komprese, kdyz je ta metoda lepsi pro urcity typ dat.

U paq8px je moznost vyuzit jen rizdilnou velikost slovniku. Nejvetsi slovnik (prepinac -8) zabere neco prez 1600 MB RAM a jedno vlakno CPU.
Rychlost v zavislosti na CPU je 2-5 kB/s jen, 1 GB trva nekolik dni, u me okolo tydne.

1. archiv - hodne souboru Excel 2003 s grafy, daty, par textovejch souboru, nekolik malo (stovky kB) PNG obrazku.
Type = 7z
Physical Size = 129067144
Headers Size = 79190
Method = LZMA2:1536m
Solid = +
Blocks = 1
Folders: 213
Files: 6444
Size:       2 370 465 554
Compressed: 129 067 144
Doba vytvareni okolo 1.5 hodiny

Velikost paq8px: 126 906 868
Doba vytvoreni okolo 15000 minut. Jen tady vyhrava paq8px.

Druhy archiv - specialni textovy soubor velky presne 1 GiB. V tomto souboru jsou pouze jednicky a znaky noveho radku - aby to slo co nejvic zmensit.
Type = 7z
Physical Size = 156707
Headers Size = 138
Method = LZMA2:30
Solid = -
Blocks = 1
Size:       1 073 741 824
Compressed: 156 707
Doba vytvareni okolo 15 minut

Velikost paq8px: 378 374
Doba vytvoreni okolo 10000 minut

Treti archiv - PNG obrazky s barevnou hloubkou 8 bit, maximalni komprese PNG 9. Zde bude komprese 7z vicemene nulova.
Data maji jen 569 MiB, proto 7z zvoli maximalni mozny slovnik pro cely archiv 768 MB
Type = 7z
Physical Size = 596451652
Headers Size = 70334
Method = LZMA2:768m
Solid = +
Blocks = 1
Folders: 49
Files: 5867
Size:       634 094 047
Compressed: 596 451 652
Doba vytvareni okolo 7 minut

Velikost paq8px - 1 187 866 833 - naprosto necekane nastal narust.
Doba vytvoreni okolo 7000 minut.

Ctvrty archiv - mnoho rozsahlych i malych skriptu bash, jejich ruzne verze v case a par souradnicovych textovych souboru.
Vzhledem k ruznym verzim je podobnost mezi soubory vyskoka.
Type = 7z
Physical Size = 26653854
Headers Size = 101573
Method = LZMA2:1536m LZMA:20 BCJ2
Solid = +
Blocks = 2
Folders: 1208
Files: 13144
Size:       3 287 918 624
Compressed: 26 653 854
Doba vytvareni cca 2 hodiny

Velikost paq8px: 28 693 188
Doba vytvoreni okolo 22000 minut

Paty archiv - skripty a casto rozsahle textove soubory se souradnicemi. Lisi se vice-mene jen nastaveni, podobnost mexi soubory je obrovska.
Type = 7z
Physical Size = 44914889
Headers Size = 17300
Method = LZMA2:1536m
Solid = +
Blocks = 1
Folders: 60
Files: 2298
Size:       3 470 148 572
Compressed: 44 914 889
Doba vytvareni cca 2.5 hodiny

Velikost paq8px: 305 756 083
Doba vytvoreni okolo 28000 minut

Ted archiv s extremnim poctem souboru - vetsinou jsou t grafy - PNG obrazky 256 barev, konverze -quailty 95, rozliseni 1280x960
Krome grafu je asi 18% velikosti a 5% poctu souboru jako textova data.
Slovnik byl pouzit 1024 MB, 2 vlakna (jeden slovnik naraz). lzma si vzala 27 GB RAM, lzma2 20.5 GB RAM. Jen kontrola spotrebuje RAM 4103 MB virt, 3.9 GB RES.
Pri velkem poctu souboru je lzma2 uspornejsi na pamet nez lzma.
paq8px zde samozrejme nezkouseno, asi by to ani nemelo smysl.
Doba vytvareni 7z okolo 30 hodin (cca 3300 minut CPU casu)
Type = 7z
Physical Size = 58605641722
Headers Size = 86105422
Method = LZMA2:30
Solid = +
Blocks = 1
Folders: 451 319
Files: 10 344 588
Size:       98 566 411 542
Compressed: 58 605 641 722

Archiv s mnoho malymi soubory TXT. Soubory jsou hodne podobne, jeden tadovy soubor v ruznych verzich je na ruznych mistech.
Z duvodu hodne malych souboru je komprese (cca 40 hod) i rozbaleni (cca 10 hod) o dost pomalejsi.
Type = 7z
Physical Size = 307417835
Headers Size = 13591949
Method = LZMA2:30
Solid = +
Blocks = 1
Folders: 251
Files: 8 808 081
Size:       19 431 833 053
Compressed: 307 417 835
Archiv ma 294 MiB, bez pouziti -mqs okolo 1500 MiB. Pokud se data nejdriv zataruji, ma archiv okolo 1500 MiB. paq8px nezkouseno.

A jeste jeden archiv. Jedna se o slozku s desetitisici datovymi soubory v kazde verzi a tech verzi je 47.
Datove soubory jsou si v jednotlivych verzich dosti podobne. Podobnosti mezi soubory je tu mnoho.
Jeden tadovy soubor v ruznych verzich je na ruznych mistech.
Velikost dat je temer 2 TiB.
Pouzit byl slovnik 1024 MB, vzalo si to RAM 11.5 GB virt 11 GB RES.
Doba vytvareni 7z okolo 36 000 minut CPU casu, 23.3 dni to bezelo, prumerna zatez 106% CPU (2 vlakna na jeden slovnik v RAM)
Type = 7z
Physical Size = 3702993437
Headers Size = 8373990
Method = LZMA2:30
Solid = +
Blocks = 1
Folders: 86
Files: 1388977
Size:       2 022 208 880 899
Compressed: 3 702 993 437


paq8px SE TEDY ANI NEMUSI VYPLATIT, DOBRE NASTAVENY 7Z MUZE CASTO VYHRAVAT - 4 Z 5 PRIPADU VYHRAL 7zip.
Navic u paq8px je rychlost brutalne nizka, velka narocnost CPU. U paq8px je navic cca stejna narocnost rozbaleni jako zabaleni.
7z je pri rozbalovani mnohem rychlejsi - 10-15 MB/s archivu (nikoliv nerozbalenych dat, tam casto limituje disk).
7zip vyhrava tam, kde je velke mnozstvi hodne podobnych souboru, jinak si vede lip spis paq8px
paq8px nema kontrolu dat, rozbaleni i zabaleni trva hodne dlouho, neni mozne uzit multi-threading.
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: Spoon 20. 10. 2017, 12:24:40
paq8px nema kontrolu dat, rozbaleni i zabaleni trva hodne dlouho, neni mozne uzit multi-threading.

Tady mas multithreadovy klon zvany zpaq http://mattmahoney.net/dc/zpaq.html dej vedet jestli se rychlost zlepsi.
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: Honza1 30. 10. 2017, 00:59:44
paq8px nema kontrolu dat, rozbaleni i zabaleni trva hodne dlouho, neni mozne uzit multi-threading.

Tady mas multithreadovy klon zvany zpaq http://mattmahoney.net/dc/zpaq.html dej vedet jestli se rychlost zlepsi.

Zkusim az bude cas.
zpaq by melo mit i pri jednom vlakne vyssi rychlost, nebot paq8px je delany na absolutne maximalni kompresi, odtud rychlost 1-5 kB/s i na dost silnym CPU.
zpaq bz melo mit s kaydzm vlaknem rzchlost vzssi nez paq8px a multithreading proces jeste urzchli, ale zabere vic RAM. I tak je pro paq procesorovz cas nesrovnatelne vyssi, nez u 7z. Na RAM to tak strasny neni.
Název: Re:Nejlepší nastavení komprese v 7zip
Přispěvatel: Honza1Ubuntu 04. 02. 2018, 15:18:41
Dalsi mensi test

U kazdeho archivu jsou paeametry nastavei
#########################################################################################################

A) Jedna se o nekolik grafu vytvorenych v Gnuplotu 2000x1000 bodu, par grafu 3000x1000 bodu, barev tam tolik neni, jen cervene body, nebo linie. Proto obrazky 24 Bit i 8 Bit barevne hloubky vypadaji stejne a velikost je skoro stejna.

Puvodni obrazek PNG, prez BMP konvert do 24 Bit a prez GIF konvert do 8 Bit barevne hloubky. Ulozeni PNG: convert quality 95.

Rozliseni 2000x1000 nektere grafy 3000x1000
2 357 771 B SWM08.7z PNG 8 bit PNG
1 249 712 B SWM08_BMP.7z 8 Bit BMP
3 619 839 B SWM1.7z After Gnuplotting original PNG Files
2 358 820 B SWM24.7z PNG 24 Bit PNG
1 560 653 B5 SWM24_BMP.7z BMP 24 Bit BMP
Parametry komprimace u vsech archivu:   7z a -t7z -m0=lzma2 -mqs -mx=9 -mfb=273 -md=64m -ms=on -ms=65536g -mmt=2
#######################
BMP08 data:
Everything is Ok
Folders: 8
Files: 238
Size:       255 048 076 B
Compressed: 1 249 712 B
#######################
PNG08 data:
Everything is Ok
Folders: 8
Files: 238
Size:       3 323 802 B
Compressed: 2 357 771 B
#######################
BMP24 data:
Everything is Ok
Folders: 8
Files: 238
Size:       1 030 208 774 B
Compressed: 1 560 653 B
#######################
PNG24 data:
Everything is Ok
Folders: 8
Files: 238
Size:       3 319 994 B
Compressed: 2 358 820 B
#######################
PNG24 Originalni soubory vytvorene Gnuplotem
Everything is Ok
Folders: 8
Files: 238
Size:       5 294 868 B
Compressed: 3 619 839 B
#######################

#########################################################################################################

B) Podobna vec - automaticke printscreen html stranky pomoci NodeJS. Stranka obsahuje barevnou tabulku, JPG se tedy absolutne nehodi.

Nejmensi velikost archivu ma zkomprimovane BMP v hloubce 24 Bit (mensi nez BMP v houbce 8 Bit). Zato rozbaleni a komprimace BMP je mnoho-nasobne delsi nez PNG, stejne tak, jako objem dat.

400 452 683 B Ogimet_Data_Daily_PrintScreens_Lite_BMP.7z  7z a -t7z -m0=lzma2 -mqs -mx=9 -mfb=273 -md=64m -ms=on -ms=65536g -mmt=2
925 626 546 B Ogimet_Data_Daily_PrintScreens_Lite_PNG08.7z  7z a -t7z -m0=lzma2 -mqs -mx=9 -mfb=273 -md=64m -ms=on -ms=65536g -mmt=2
Nejlepsi komprese pro BMP 24 bit, druha nejlepsi BMP 08 bit, treti nejlepsi pro PNG 08 bit
Archiv z puvodnich PNG24 bez konvertu mel prez 2 GiB
#######################
Uvnitr archivu:
PNG08:
Everything is Ok
Folders: 28
Files: 6048
Size:       941 631 614 B
Compressed: 925 626 546 B
#######################
BMP24:
Everything is Ok
Folders: 28
Files: 6048
Size:       34 063 170 624yl B
Compressed: 400 452 683 B

#########################################################################################################

C) Test datove soubory CSV, oddelovac strednik. Vetsina znaku v souboru jsou cisla.

Byl vytvoren archiv z puvodnich dat (komprimace slozky), tak byl vytvoren nejdriv TAR soubor a pak zkomprimovan.

OGIMET CSV DATA
Vytvoreni archivu z adresare
503 339 454 B Ogimet_CSV_201711_64.7z 7z a -t7z -m0=lzma2 -mqs -mx=9 -mfb=273 -md=64m -ms=on -ms=65536g -mmt=2
485 767 317 B Ogimet_CSV_201711.7z 7z a -t7z -m0=lzma2 -mqs -mx=9 -mfb=273 -md=1536m -ms=on -ms=65536g -mmt=2 Velky slovnik sezere 16.5 GB RAM !!! Nejlepsi vysledek
535 219 878 B Ogimet_Data_CSV_201711.paq8px paq8px_v69 -8 (cca 1.7 GB RAM cca 33000 min CPU Time)

vytvoreni TARu a pak komprese
3 342 653 440 B Ogimet_CSV_201711.tar NORMAL TAR tar -cf file.tar *
555 309 052 B Ogimet_CSV_201711b.tar.xz xz -9 -T 1
554 798 645 B Ogimet_CSV_201711_TAR_64.7z  7z a -t7z -m0=lzma2 -mqs -mx=9 -mfb=273 -md=64m -ms=on -ms=65536g -mmt=2
554 862 908 B Ogimet_CSV_201711.tar.xz xz -9e -T 1
549 644 276 B Ogimet_CSV_201711.tar.xz  xz -9e -T 1 TAR Soubor 3 342 878 720 B Pokus o Sorted TAR, Data uvnitr TARu stejna
#######################
DATA UVNITR ARCHIVU
CSV soubory, hodne cisel
Everything is Ok
Folders: 19
Files: 2983
Size:       3 340 330 625 B
Compressed: 503 339 454 B